draft-ietf-dtn-tcpclv4-13.txt   draft-ietf-dtn-tcpclv4-14.txt 
Delay Tolerant Networking B. Sipos Delay Tolerant Networking B. Sipos
Internet-Draft RKF Engineering Internet-Draft RKF Engineering
Obsoletes: 7242 (if approved) M. Demmer Obsoletes: 7242 (if approved) M. Demmer
Intended status: Standards Track UC Berkeley Intended status: Standards Track UC Berkeley
Expires: February 21, 2020 J. Ott Expires: March 22, 2020 J. Ott
Aalto University Aalto University
S. Perreault S. Perreault
August 20, 2019 September 19, 2019
Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4
draft-ietf-dtn-tcpclv4-13 draft-ietf-dtn-tcpclv4-14
Abstract Abstract
This document describes a revised protocol for the TCP-based This document describes a revised protocol for the TCP-based
convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). The convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). The
protocol revision is based on implementation issues in the original protocol revision is based on implementation issues in the original
TCPCL Version 3 of RFC7242 and updates to the Bundle Protocol TCPCL Version 3 of RFC7242 and updates to the Bundle Protocol
contents, encodings, and convergence layer requirements in Bundle contents, encodings, and convergence layer requirements in Bundle
Protocol Version 7. Specifically, the TCPCLv4 uses CBOR-encoded BPv7 Protocol Version 7. Specifically, the TCPCLv4 uses CBOR-encoded BPv7
bundles as its service data unit being transported and provides a bundles as its service data unit being transported and provides a
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 21, 2020. This Internet-Draft will expire on March 22, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 11 skipping to change at page 3, line 11
6.1. Session Termination Message (SESS_TERM) . . . . . . . . . 43 6.1. Session Termination Message (SESS_TERM) . . . . . . . . . 43
6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 45 6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 45
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 45 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 45
8. Security Considerations . . . . . . . . . . . . . . . . . . . 46 8. Security Considerations . . . . . . . . . . . . . . . . . . . 46
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 47 9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 47
9.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 48 9.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 48
9.3. Session Extension Types . . . . . . . . . . . . . . . . . 48 9.3. Session Extension Types . . . . . . . . . . . . . . . . . 48
9.4. Transfer Extension Types . . . . . . . . . . . . . . . . 49 9.4. Transfer Extension Types . . . . . . . . . . . . . . . . 49
9.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 50 9.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 50
9.6. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 50 9.6. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 51
9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 51 9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 52
9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 52 9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 53
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
11.1. Normative References . . . . . . . . . . . . . . . . . . 53 11.1. Normative References . . . . . . . . . . . . . . . . . . 54
11.2. Informative References . . . . . . . . . . . . . . . . . 54 11.2. Informative References . . . . . . . . . . . . . . . . . 55
Appendix A. Significant changes from RFC7242 . . . . . . . . . . 55 Appendix A. Significant changes from RFC7242 . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57
1. Introduction 1. Introduction
This document describes the TCP-based convergence-layer protocol for This document describes the TCP-based convergence-layer protocol for
Delay-Tolerant Networking. Delay-Tolerant Networking is an end-to- Delay-Tolerant Networking. Delay-Tolerant Networking is an end-to-
end architecture providing communications in and/or through highly end architecture providing communications in and/or through highly
stressed environments, including those with intermittent stressed environments, including those with intermittent
connectivity, long and/or variable delays, and high bit error rates. connectivity, long and/or variable delays, and high bit error rates.
More detailed descriptions of the rationale and capabilities of these More detailed descriptions of the rationale and capabilities of these
networks can be found in "Delay-Tolerant Network Architecture" networks can be found in "Delay-Tolerant Network Architecture"
skipping to change at page 5, line 7 skipping to change at page 5, line 7
o Policies or mechanisms for assigning X.509 certificates, o Policies or mechanisms for assigning X.509 certificates,
provisioning or deploying certificates and private keys, or provisioning or deploying certificates and private keys, or
configuring security parameters on an individual BP node or across configuring security parameters on an individual BP node or across
a network. a network.
Any TCPCL implementation requires a BP agent to perform those above Any TCPCL implementation requires a BP agent to perform those above
listed functions in order to perform end-to-end bundle delivery. listed functions in order to perform end-to-end bundle delivery.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2.1. Definitions Specific to the TCPCL Protocol 2.1. Definitions Specific to the TCPCL Protocol
This section contains definitions specific to the TCPCL protocol. This section contains definitions specific to the TCPCL protocol.
TCPCL Entity: This is the notional TCPCL application that initiates TCPCL Entity: This is the notional TCPCL application that initiates
skipping to change at page 6, line 8 skipping to change at page 6, line 8
sessions, and other states association with that TCP connection. sessions, and other states association with that TCP connection.
TCPCL Session: A TCPCL session (as opposed to a TCP connection) is a TCPCL Session: A TCPCL session (as opposed to a TCP connection) is a
TCPCL communication relationship between two TCPCL entities. TCPCL communication relationship between two TCPCL entities.
Within a single TCPCL session there are two possible transfer Within a single TCPCL session there are two possible transfer
streams; one in each direction, with one stream from each entity streams; one in each direction, with one stream from each entity
being the outbound stream and the other being the inbound stream. being the outbound stream and the other being the inbound stream.
The lifetime of a TCPCL session is bound to the lifetime of an The lifetime of a TCPCL session is bound to the lifetime of an
underlying TCP connection. A TCPCL session is terminated when the underlying TCP connection. A TCPCL session is terminated when the
TCP connection ends, due either to one or both entities actively TCP connection ends, due either to one or both entities actively
terminating the TCP connection or due to network errors causing a closing the TCP connection or due to network errors causing a
failure of the TCP connection. For the remainder of this failure of the TCP connection. For the remainder of this
document, the term "session" without the prefix "TCPCL" refers to document, the term "session" without the prefix "TCPCL" refers to
a TCPCL session. a TCPCL session.
Session parameters: These are a set of values used to affect the Session parameters: These are a set of values used to affect the
operation of the TCPCL for a given session. The manner in which operation of the TCPCL for a given session. The manner in which
these parameters are conveyed to the bundle entity and thereby to these parameters are conveyed to the bundle entity and thereby to
the TCPCL is implementation dependent. However, the mechanism by the TCPCL is implementation dependent. However, the mechanism by
which two entities exchange and negotiate the values to be used which two entities exchange and negotiate the values to be used
for a given session is described in Section 4.3. for a given session is described in Section 4.3.
skipping to change at page 10, line 18 skipping to change at page 10, line 18
transferred segment. transferred segment.
Transmission Failure: The TCPCL supports positive indication of Transmission Failure: The TCPCL supports positive indication of
certain reasons for bundle transmission failure, notably when the certain reasons for bundle transmission failure, notably when the
peer entity rejects the bundle or when a TCPCL session ends before peer entity rejects the bundle or when a TCPCL session ends before
transferr success. The TCPCL itself does not have a notion of transferr success. The TCPCL itself does not have a notion of
transfer timeout. transfer timeout.
Reception Initialized: The TCPCL supports indication to the reciver Reception Initialized: The TCPCL supports indication to the reciver
just before any transmssion data is sent. This corresponds to just before any transmssion data is sent. This corresponds to
reception of the XFER_SEGMENT message with the START flag set. reception of the XFER_SEGMENT message with the START flag of 1.
Interrupt Reception: The TCPCL allows a BP agent to interrupt an Interrupt Reception: The TCPCL allows a BP agent to interrupt an
individual transfer before it has fully completed (successfully or individual transfer before it has fully completed (successfully or
not). Interruption can occur any time after the reception is not). Interruption can occur any time after the reception is
initialized. initialized.
Reception Success: The TCPCL supports positive indication when a Reception Success: The TCPCL supports positive indication when a
bundle has been fully transferred from a peer entity. bundle has been fully transferred from a peer entity.
Reception Intermediate Progress: The TCPCL supports positive Reception Intermediate Progress: The TCPCL supports positive
skipping to change at page 12, line 4 skipping to change at page 12, line 4
bundles. bundles.
For sessions that are idle, a KEEPALIVE message is sent at a For sessions that are idle, a KEEPALIVE message is sent at a
negotiated interval. This is used to convey node live-ness negotiated interval. This is used to convey node live-ness
information during otherwise message-less time intervals. information during otherwise message-less time intervals.
A SESS_TERM message is used to start the ending of a TCPCL session A SESS_TERM message is used to start the ending of a TCPCL session
(see Section 6.1). During shutdown sequencing, in-progress transfers (see Section 6.1). During shutdown sequencing, in-progress transfers
can be completed but no new transfers can be initiated. A SESS_TERM can be completed but no new transfers can be initiated. A SESS_TERM
message can also be used to refuse a session setup by a peer (see message can also be used to refuse a session setup by a peer (see
Section 4.3). It is an implementation matter to determine whether or Section 4.3). Regardless of the reason, session termination is
not to close a TCPCL session while there are no transfers queued or initiated by one of the entities and responded-to by the other as
in-progress. illustrated by Figure 13 and Figure 14. Even when there are no
transfers queued or in-progress, the session termination procedure
allows each entity to distinguish between a clean end to a session
and the TCP connection being closed because of some underlying
network issue.
Once a session is established, TCPCL is a symmetric protocol between Once a session is established, TCPCL is a symmetric protocol between
the peers. Both sides can start sending data segments in a session, the peers. Both sides can start sending data segments in a session,
and one side's bundle transfer does not have to complete before the and one side's bundle transfer does not have to complete before the
other side can start sending data segments on its own. Hence, the other side can start sending data segments on its own. Hence, the
protocol allows for a bi-directional mode of communication. Note protocol allows for a bi-directional mode of communication. Note
that in the case of concurrent bidirectional transmission, that in the case of concurrent bidirectional transmission,
acknowledgment segments MAY be interleaved with data segments. acknowledgment segments MAY be interleaved with data segments.
3.3. TCPCL States and Transitions 3.3. TCPCL States and Transitions
skipping to change at page 22, line 43 skipping to change at page 22, line 43
magic: A four-octet field that always contains the octet sequence magic: A four-octet field that always contains the octet sequence
0x64 0x74 0x6E 0x21, i.e., the text string "dtn!" in US-ASCII (and 0x64 0x74 0x6E 0x21, i.e., the text string "dtn!" in US-ASCII (and
UTF-8). UTF-8).
Version: A one-octet field value containing the value 4 (current Version: A one-octet field value containing the value 4 (current
version of the TCPCL). version of the TCPCL).
Flags: A one-octet field of single-bit flags, interpreted according Flags: A one-octet field of single-bit flags, interpreted according
to the descriptions in Table 1. All reserved header flag bits to the descriptions in Table 1. All reserved header flag bits
SHALL be not set by the sender. All reserved header flag bits SHALL be set to 0 by the sender. All reserved header flag bits
SHALL be ignored by the receiver. SHALL be ignored by the receiver.
+----------+--------+-----------------------------------------------+ +----------+--------+-----------------------------------------------+
| Name | Code | Description | | Name | Code | Description |
+----------+--------+-----------------------------------------------+ +----------+--------+-----------------------------------------------+
| CAN_TLS | 0x01 | If bit is set, indicates that the sending | | CAN_TLS | 0x01 | If bit is set, indicates that the sending |
| | | peer is capable of TLS security. | | | | peer is capable of TLS security. |
| | | | | | | |
| Reserved | others | | Reserved | others |
+----------+--------+-----------------------------------------------+ +----------+--------+-----------------------------------------------+
skipping to change at page 23, line 42 skipping to change at page 23, line 42
response from the passive node. The active node can repeatedly response from the passive node. The active node can repeatedly
attempt different protocol versions in descending order until the attempt different protocol versions in descending order until the
passive node accepts one with a corresponding Contact Header reply. passive node accepts one with a corresponding Contact Header reply.
Only upon response of a Contact Header from the passive node is the Only upon response of a Contact Header from the passive node is the
TCPCL protocol version established and parameter negotiation begun. TCPCL protocol version established and parameter negotiation begun.
During contact initiation, the active TCPCL node SHALL send the During contact initiation, the active TCPCL node SHALL send the
highest TCPCL protocol version on a first session attempt for a TCPCL highest TCPCL protocol version on a first session attempt for a TCPCL
peer. If the active node receives a Contact Header with a different peer. If the active node receives a Contact Header with a different
protocol version than the one sent earlier on the TCP connection, the protocol version than the one sent earlier on the TCP connection, the
TCP connection SHALL be terminated. If the active node receives a TCP connection SHALL be closed. If the active node receives a
SESS_TERM message with reason of "Version Mismatch", that node MAY SESS_TERM message with reason of "Version Mismatch", that node MAY
attempt further TCPCL sessions with the peer using earlier protocol attempt further TCPCL sessions with the peer using earlier protocol
version numbers in decreasing order. Managing multi-TCPCL-session version numbers in decreasing order. Managing multi-TCPCL-session
state such as this is an implementation matter. state such as this is an implementation matter.
If the passive node receives a contact header containing a version If the passive node receives a contact header containing a version
that is greater than the current version of the TCPCL that the node that is greater than the current version of the TCPCL that the node
implements, then the node SHALL shutdown the session with a reason implements, then the node SHALL shutdown the session with a reason
code of "Version mismatch". If the passive node receives a contact code of "Version mismatch". If the passive node receives a contact
header with a version that is lower than the version of the protocol header with a version that is lower than the version of the protocol
skipping to change at page 24, line 37 skipping to change at page 24, line 37
underlying TCP connection as the "client" role of the TLS handshake underlying TCP connection as the "client" role of the TLS handshake
request. request.
The TLS handshake, if it occurs, is considered to be part of the The TLS handshake, if it occurs, is considered to be part of the
contact negotiation before the TCPCL session itself is established. contact negotiation before the TCPCL session itself is established.
Specifics about sensitive data exposure are discussed in Section 8. Specifics about sensitive data exposure are discussed in Section 8.
The parameters within each TLS negotiation are implementation The parameters within each TLS negotiation are implementation
dependent but any TCPCL node SHALL follow all recommended practices dependent but any TCPCL node SHALL follow all recommended practices
of BCP 195 [RFC7525], or any updates or successors that become part of BCP 195 [RFC7525], or any updates or successors that become part
of BCP 195. The TLS handshake SHOULD include a Server Name of BCP 195. When possible, the TLS handshake SHOULD include a Server
Indication from the active peer. The TLS handshake SHALL request a Name Indication (SNI) from the active peer in accordance with
client-side certificate to allow authentication of the active peer. [RFC6066]. The SNI SHALL contain the same host name used to
The passive peer SHOULD supply a certificate within the TLS handshake establish the TCP connection. The passive peer MAY use the SNI host
to allow authentication of its side of the session. The active peer name to choose an appropriate server-side certificate. The TLS
SHOULD supply a certificate within the TLS handshake to allow handshake SHALL request a client-side certificate to allow
authentication of its side of the session. All certificates supplied authentication of the active peer. The passive peer SHOULD supply a
during TLS handshake SHALL conform with the profile of [RFC5280]. certificate within the TLS handshake to allow authentication of its
When a certificate is supplied during TLS handshake, the full side of the session. The active peer SHOULD supply a certificate
certification chain SHOULD be included unless security policy within the TLS handshake to allow authentication of its side of the
indicates that is unnecessary. session. All certificates supplied during TLS handshake SHALL
conform with the profile of [RFC5280], or any updates or successors
to that profile. When a certificate is supplied during TLS
handshake, the full certification chain SHOULD be included unless
security policy indicates that is unnecessary.
If a TLS handshake cannot negotiate a TLS session, both entities of If a TLS handshake cannot negotiate a TLS session, both entities of
the TCPCL session SHALL close the TCP connection. At this point the the TCPCL session SHALL close the TCP connection. At this point the
TCPCL session has not yet been established so there is no TCPCL TCPCL session has not yet been established so there is no TCPCL
session to terminate. This also avoids any potential security issues session to terminate. This also avoids any potential security issues
assoicated with further TCP communication with an untrusted peer. assoicated with further TCP communication with an untrusted peer.
After a TLS session is successfully established, the active peer After a TLS session is successfully established, the active peer
SHALL send a SESS_INIT message to begin session negotiation. This SHALL send a SESS_INIT message to begin session negotiation. This
session negotation and all subsequent messaging are secured. session negotation and all subsequent messaging are secured.
skipping to change at page 25, line 49 skipping to change at page 26, line 4
validation fails (including failure because the certificate does not validation fails (including failure because the certificate does not
contain any DNS-ID), the entity SHOULD terminate the session (with a contain any DNS-ID), the entity SHOULD terminate the session (with a
reason code of "Contact Failure") unless security policy allows an reason code of "Contact Failure") unless security policy allows an
unauthticated host. unauthticated host.
Immediately before Session Parameter Negotiation, each side of the Immediately before Session Parameter Negotiation, each side of the
session SHALL perform Node ID validation of its peer as described session SHALL perform Node ID validation of its peer as described
below. Node ID validation SHALL succeed if the associated below. Node ID validation SHALL succeed if the associated
certificate contains a subjectAltName entry of type certificate contains a subjectAltName entry of type
uniformResourceIdentifier whose value matches the Node ID of the uniformResourceIdentifier whose value matches the Node ID of the
TCPCL entity. URI matching of Node IDs SHALL use the URI comparison TCPCL entity. Unless specified otherwise by the definition of the
logic of [RFC3986] and scheme-based normalization of those schemes URI scheme being authenticated, URI matching of Node IDs SHALL use
specified in [I-D.ietf-dtn-bpbis]. This is similar to the URI-ID of the URI comparison logic of [RFC3986] and scheme-based normalization
of those schemes specified in [I-D.ietf-dtn-bpbis]. This is similar
[RFC6125] but does not require any structure to the scheme-specific- to the URI-ID of [RFC6125] but does not require any structure to the
part of the URI. If Node ID validation fails (including failure scheme-specific-part of the URI. A URI scheme can refine this "exact
because the certificate does not contain any subjectAltName URI), the match" logic with rules about how Node IDs within that scheme are to
entity SHOULD terminate the session (with a reason code of "Contact be compared with the certificate-authenticated URI. If Node ID
Failure") unless security policy allows an unauthticated node. validation fails (including failure because the certificate does not
contain any subjectAltName URI), the entity SHOULD terminate the
session (with a reason code of "Contact Failure") unless security
policy allows an unauthticated node.
4.4.3. Example TLS Initiation 4.4.3. Example TLS Initiation
A summary of a typical TLS use is shown in the sequence in Figure 17 A summary of a typical TLS use is shown in the sequence in Figure 17
below. below.
Entity A Entity B Entity A Entity B
active peer passive peer active peer passive peer
+-------------------------+ +-------------------------+
skipping to change at page 29, line 14 skipping to change at page 29, line 18
+-----------------------------+ +-----------------------------+
| Message Header | | Message Header |
+-----------------------------+ +-----------------------------+
| Keepalive Interval (U16) | | Keepalive Interval (U16) |
+-----------------------------+ +-----------------------------+
| Segment MRU (U64) | | Segment MRU (U64) |
+-----------------------------+ +-----------------------------+
| Transfer MRU (U64) | | Transfer MRU (U64) |
+-----------------------------+ +-----------------------------+
| EID Length (U16) | | Node ID Length (U16) |
+-----------------------------+ +-----------------------------+
| EID Data (variable) | | Node ID Data (variable) |
+-----------------------------+ +-----------------------------+
| Session Extension | | Session Extension |
| Items Length (U32) | | Items Length (U32) |
+-----------------------------+ +-----------------------------+
| Session Extension | | Session Extension |
| Items (var.) | | Items (var.) |
+-----------------------------+ +-----------------------------+
Figure 19: SESS_INIT Format Figure 19: SESS_INIT Format
skipping to change at page 31, line 31 skipping to change at page 31, line 36
4.8. Session Extension Items 4.8. Session Extension Items
Each of the Session Extension Items SHALL be encoded in an identical Each of the Session Extension Items SHALL be encoded in an identical
Type-Length-Value (TLV) container form as indicated in Figure 20. Type-Length-Value (TLV) container form as indicated in Figure 20.
The fields of the Session Extension Item are: The fields of the Session Extension Item are:
Flags: A one-octet field containing generic bit flags about the Flags: A one-octet field containing generic bit flags about the
Item, which are listed in Table 3. All reserved header flag bits Item, which are listed in Table 3. All reserved header flag bits
SHALL be not set by the sender. All reserved header flag bits SHALL be set to 0 by the sender. All reserved header flag bits
SHALL be ignored by the receiver. If a TCPCL entity receives a SHALL be ignored by the receiver. If a TCPCL entity receives a
Session Extension Item with an unknown Item Type and the CRITICAL Session Extension Item with an unknown Item Type and the CRITICAL
flag set, the entity SHALL close the TCPCL session with SESS_TERM flag of 1, the entity SHALL close the TCPCL session with SESS_TERM
reason code of "Contact Failure". If the CRITICAL flag is not reason code of "Contact Failure". If the CRITICAL flag is 0, an
set, an entity SHALL skip over and ignore any item with an unknown entity SHALL skip over and ignore any item with an unknown Item
Item Type. Type.
Item Type: A 16-bit unsigned integer field containing the type of Item Type: A 16-bit unsigned integer field containing the type of
the extension item. This specification does not define any the extension item. This specification does not define any
extension types directly, but does allocate an IANA registry for extension types directly, but does allocate an IANA registry for
such codes (see Section 9.3). such codes (see Section 9.3).
Item Length: A 16-bit unsigned integer field containing the number Item Length: A 16-bit unsigned integer field containing the number
of Item Value octets to follow. of Item Value octets to follow.
Item Value: A variable-length data field which is interpreted Item Value: A variable-length data field which is interpreted
skipping to change at page 34, line 38 skipping to change at page 34, line 41
All of the messages in this section are directly associated with All of the messages in this section are directly associated with
transferring a bundle between TCPCL entities. transferring a bundle between TCPCL entities.
A single TCPCL transfer results in a bundle (handled by the A single TCPCL transfer results in a bundle (handled by the
convergence layer as opaque data) being exchanged from one node to convergence layer as opaque data) being exchanged from one node to
the other. In TCPCL a transfer is accomplished by dividing a single the other. In TCPCL a transfer is accomplished by dividing a single
bundle up into "segments" based on the receiving-side Segment MRU bundle up into "segments" based on the receiving-side Segment MRU
(see Section 4.2). The choice of the length to use for segments is (see Section 4.2). The choice of the length to use for segments is
an implementation matter, but each segment MUST be no larger than the an implementation matter, but each segment MUST be no larger than the
receiving node's maximum receive unit (MRU) (see the field "Segment receiving node's maximum receive unit (MRU) (see the field "Segment
MRU" of Section 4.2). The first segment for a bundle MUST set the MRU" of Section 4.2). The first segment for a bundle is indicated by
'START' flag, and the last one MUST set the 'end' flag in the the 'START' flag and the last segment is indicated by the 'END' flag.
XFER_SEGMENT message flags.
A single transfer (and by extension a single segment) SHALL NOT A single transfer (and by extension a single segment) SHALL NOT
contain data of more than a single bundle. This requirement is contain data of more than a single bundle. This requirement is
imposed on the agent using the TCPCL rather than TCPCL itself. imposed on the agent using the TCPCL rather than TCPCL itself.
If multiple bundles are transmitted on a single TCPCL connection, If multiple bundles are transmitted on a single TCPCL connection,
they MUST be transmitted consecutively without interleaving of they MUST be transmitted consecutively without interleaving of
segments from multiple bundles. segments from multiple bundles.
5.2.1. Bundle Transfer ID 5.2.1. Bundle Transfer ID
skipping to change at page 36, line 31 skipping to change at page 36, line 31
+------------------------------+ +------------------------------+
| Data contents (octet string) | | Data contents (octet string) |
+------------------------------+ +------------------------------+
Figure 22: Format of XFER_SEGMENT Messages Figure 22: Format of XFER_SEGMENT Messages
The fields of the XFER_SEGMENT message are: The fields of the XFER_SEGMENT message are:
Message Flags: A one-octet field of single-bit flags, interpreted Message Flags: A one-octet field of single-bit flags, interpreted
according to the descriptions in Table 5. All reserved header according to the descriptions in Table 5. All reserved header
flag bits SHALL be not set by the sender. All reserved header flag bits SHALL be set to 0 by the sender. All reserved header
flag bits SHALL be ignored by the receiver. flag bits SHALL be ignored by the receiver.
Transfer ID: A 64-bit unsigned integer identifying the transfer Transfer ID: A 64-bit unsigned integer identifying the transfer
being made. being made.
Transfer Extension Length and Transfer Extension Items: Together Transfer Extension Length and Transfer Extension Items: Together
these fields represent protocol extension data for this these fields represent protocol extension data for this
specification. The Transfer Extension Length and Transfer specification. The Transfer Extension Length and Transfer
Extension Item fields SHALL only be present when the 'START' flag Extension Item fields SHALL only be present when the 'START' flag
is set on the message. The Transfer Extension Length is the total is set to 1 on the message. The Transfer Extension Length is the
number of octets to follow which are used to encode the Transfer total number of octets to follow which are used to encode the
Extension Item list. The encoding of each Transfer Extension Item Transfer Extension Item list. The encoding of each Transfer
is within a consistent data container as described in Extension Item is within a consistent data container as described
Section 5.2.5. The full set of transfer extension items apply in Section 5.2.5. The full set of transfer extension items apply
only to the assoicated single transfer. The order and only to the assoicated single transfer. The order and
mulitplicity of these transfer extension items MAY be significant, mulitplicity of these transfer extension items MAY be significant,
as defined in the associated type specification(s). as defined in the associated type specification(s).
Data length: A 64-bit unsigned integer indicating the number of Data length: A 64-bit unsigned integer indicating the number of
octets in the Data contents to follow. octets in the Data contents to follow.
Data contents: The variable-length data payload of the message. Data contents: The variable-length data payload of the message.
+----------+--------+-----------------------------------------------+ +----------+--------+-----------------------------------------------+
skipping to change at page 37, line 23 skipping to change at page 37, line 23
| START | 0x02 | If bit is set, indicates that this is the | | START | 0x02 | If bit is set, indicates that this is the |
| | | first segment of the transfer. | | | | first segment of the transfer. |
| | | | | | | |
| Reserved | others | | Reserved | others |
+----------+--------+-----------------------------------------------+ +----------+--------+-----------------------------------------------+
Table 5: XFER_SEGMENT Flags Table 5: XFER_SEGMENT Flags
The flags portion of the message contains two optional values in the The flags portion of the message contains two optional values in the
two low-order bits, denoted 'START' and 'END' in Table 5. The two low-order bits, denoted 'START' and 'END' in Table 5. The
'START' bit MUST be set to one if it precedes the transmission of the 'START' flag SHALL be set to 1 when transmitting the first segment of
first segment of a transfer. The 'END' bit MUST be set to one when a transfer. The 'END' flag SHALL be set to 1 when transmitting the
transmitting the last segment of a transfer. In the case where an last segment of a transfer. In the case where an entire transfer is
entire transfer is accomplished in a single segment, both the 'START' accomplished in a single segment, both the 'START' and 'END' flags
and 'END' bits MUST be set to one. SHALL be set to 1.
Once a transfer of a bundle has commenced, the node MUST only send Once a transfer of a bundle has commenced, the node MUST only send
segments containing sequential portions of that bundle until it sends segments containing sequential portions of that bundle until it sends
a segment with the 'END' bit set. No interleaving of multiple a segment with the 'END' flag set to 1. No interleaving of multiple
transfers from the same node is possible within a single TCPCL transfers from the same node is possible within a single TCPCL
session. Simultaneous transfers between two entities MAY be achieved session. Simultaneous transfers between two entities MAY be achieved
using multiple TCPCL sessions. using multiple TCPCL sessions.
5.2.3. Data Acknowledgments (XFER_ACK) 5.2.3. Data Acknowledgments (XFER_ACK)
Although the TCP transport provides reliable transfer of data between Although the TCP transport provides reliable transfer of data between
transport peers, the typical BSD sockets interface provides no means transport peers, the typical BSD sockets interface provides no means
to inform a sending application of when the receiving application has to inform a sending application of when the receiving application has
processed some amount of transmitted data. Thus, after transmitting processed some amount of transmitted data. Thus, after transmitting
skipping to change at page 38, line 21 skipping to change at page 38, line 21
+-----------------------------+ +-----------------------------+
| Acknowledged length (U64) | | Acknowledged length (U64) |
+-----------------------------+ +-----------------------------+
Figure 23: Format of XFER_ACK Messages Figure 23: Format of XFER_ACK Messages
The fields of the XFER_ACK message are: The fields of the XFER_ACK message are:
Message Flags: A one-octet field of single-bit flags, interpreted Message Flags: A one-octet field of single-bit flags, interpreted
according to the descriptions in Table 5. All reserved header according to the descriptions in Table 5. All reserved header
flag bits SHALL be not set by the sender. All reserved header flag bits SHALL be set to 0 by the sender. All reserved header
flag bits SHALL be ignored by the receiver. flag bits SHALL be ignored by the receiver.
Transfer ID: A 64-bit unsigned integer identifying the transfer Transfer ID: A 64-bit unsigned integer identifying the transfer
being acknowledged. being acknowledged.
Acknowledged length: A 64-bit unsigned integer indicating the total Acknowledged length: A 64-bit unsigned integer indicating the total
number of octets in the transfer which are being acknowledged. number of octets in the transfer which are being acknowledged.
A receiving TCPCL node SHALL send an XFER_ACK message in response to A receiving TCPCL node SHALL send an XFER_ACK message in response to
each received XFER_SEGMENT message. The flags portion of the each received XFER_SEGMENT message. The flags portion of the
skipping to change at page 40, line 46 skipping to change at page 40, line 46
message. There is no way to interrupt an individual TCPCL message message. There is no way to interrupt an individual TCPCL message
partway through sending it. The sender MUST NOT commence partway through sending it. The sender MUST NOT commence
transmission of any further segments of the refused bundle transmission of any further segments of the refused bundle
subsequently. Note, however, that this requirement does not ensure subsequently. Note, however, that this requirement does not ensure
that an entity will not receive another XFER_SEGMENT for the same that an entity will not receive another XFER_SEGMENT for the same
bundle after transmitting a XFER_REFUSE message since messages MAY bundle after transmitting a XFER_REFUSE message since messages MAY
cross on the wire; if this happens, subsequent segments of the bundle cross on the wire; if this happens, subsequent segments of the bundle
SHALL also be refused with a XFER_REFUSE message. SHALL also be refused with a XFER_REFUSE message.
Note: If a bundle transmission is aborted in this way, the receiver Note: If a bundle transmission is aborted in this way, the receiver
MAY not receive a segment with the 'END' flag set to '1' for the MAY not receive a segment with the 'END' flag set to 1 for the
aborted bundle. The beginning of the next bundle is identified by aborted bundle. The beginning of the next bundle is identified by
the 'START' bit set to '1', indicating the start of a new transfer, the 'START' flag set to 1, indicating the start of a new transfer,
and with a distinct Transfer ID value. and with a distinct Transfer ID value.
5.2.5. Transfer Extension Items 5.2.5. Transfer Extension Items
Each of the Transfer Extension Items SHALL be encoded in an identical Each of the Transfer Extension Items SHALL be encoded in an identical
Type-Length-Value (TLV) container form as indicated in Figure 25. Type-Length-Value (TLV) container form as indicated in Figure 25.
The fields of the Transfer Extension Item are: The fields of the Transfer Extension Item are:
Flags: A one-octet field containing generic bit flags about the Flags: A one-octet field containing generic bit flags about the
Item, which are listed in Table 7. All reserved header flag bits Item, which are listed in Table 7. All reserved header flag bits
SHALL be not set by the sender. All reserved header flag bits SHALL be set to 0 by the sender. All reserved header flag bits
SHALL be ignored by the receiver. If a TCPCL node receives a SHALL be ignored by the receiver. If a TCPCL node receives a
Transfer Extension Item with an unknown Item Type and the CRITICAL Transfer Extension Item with an unknown Item Type and the CRITICAL
flag set, the node SHALL refuse the transfer with an XFER_REFUSE flag is 1, the node SHALL refuse the transfer with an XFER_REFUSE
reason code of "Extension Failure". If the CRITICAL flag is not reason code of "Extension Failure". If the CRITICAL flag is 0, an
set, an entity SHALL skip over and ignore any item with an unknown entity SHALL skip over and ignore any item with an unknown Item
Item Type. Type.
Item Type: A 16-bit unsigned integer field containing the type of Item Type: A 16-bit unsigned integer field containing the type of
the extension item. This specification allocates an IANA registry the extension item. This specification allocates an IANA registry
for such codes (see Section 9.4). for such codes (see Section 9.4).
Item Length: A 16-bit unsigned integer field containing the number Item Length: A 16-bit unsigned integer field containing the number
of Item Value octets to follow. of Item Value octets to follow.
Item Value: A variable-length data field which is interpreted Item Value: A variable-length data field which is interpreted
according to the associated Item Type. This specification places according to the associated Item Type. This specification places
skipping to change at page 42, line 29 skipping to change at page 42, line 29
preemptively refuse bundles that would exceed their resources or to preemptively refuse bundles that would exceed their resources or to
prepare storage on the receiving node for the upcoming bundle data. prepare storage on the receiving node for the upcoming bundle data.
Multiple Transfer Length extension items SHALL NOT occur within the Multiple Transfer Length extension items SHALL NOT occur within the
same transfer. The lack of a Transfer Length extension item in any same transfer. The lack of a Transfer Length extension item in any
transfer SHALL NOT imply anything about the potential length of the transfer SHALL NOT imply anything about the potential length of the
transfer. The Transfer Length extension SHALL be assigned transfer transfer. The Transfer Length extension SHALL be assigned transfer
extension type ID 0x0001. extension type ID 0x0001.
If a transfer occupies exactly one segment (i.e. both START and END If a transfer occupies exactly one segment (i.e. both START and END
bits are set) the Transfer Length extension SHOULD NOT be present. flags are 1) the Transfer Length extension SHOULD NOT be present.
The extension does not provide any additional information for single- The extension does not provide any additional information for single-
segment transfers. segment transfers.
The format of the Transfer Length data is as follows in Figure 26. The format of the Transfer Length data is as follows in Figure 26.
+----------------------+ +----------------------+
| Total Length (U64) | | Total Length (U64) |
+----------------------+ +----------------------+
Figure 26: Format of Transfer Length data Figure 26: Format of Transfer Length data
skipping to change at page 43, line 14 skipping to change at page 43, line 14
6. Session Termination 6. Session Termination
This section describes the procedures for ending a TCPCL session. This section describes the procedures for ending a TCPCL session.
6.1. Session Termination Message (SESS_TERM) 6.1. Session Termination Message (SESS_TERM)
To cleanly shut down a session, a SESS_TERM message SHALL be To cleanly shut down a session, a SESS_TERM message SHALL be
transmitted by either node at any point following complete transmitted by either node at any point following complete
transmission of any other message. When sent to initiate a transmission of any other message. When sent to initiate a
termination, the REPLY bit of a SESS_TERM message SHALL NOT be set. termination, the REPLY flag of a SESS_TERM message SHALL be 0. Upon
Upon receiving a SESS_TERM message after not sending a SESS_TERM receiving a SESS_TERM message after not sending a SESS_TERM message
message in the same session, an entity SHALL send an acknowledging in the same session, an entity SHALL send an acknowledging SESS_TERM
SESS_TERM message. When sent to acknowledge a termination, a message. When sent to acknowledge a termination, a SESS_TERM message
SESS_TERM message SHALL have identical data content from the message SHALL have identical data content from the message being acknowledged
being acknowledged except for the REPLY bit, which is set to indicate except for the REPLY flag, which is set to 1 to indicate
acknowledgement. acknowledgement.
After sending a SESS_TERM message, an entity MAY continue a possible After sending a SESS_TERM message, an entity MAY continue a possible
in-progress transfer in either direction. After sending a SESS_TERM in-progress transfer in either direction. After sending a SESS_TERM
message, an entity SHALL NOT begin any new outgoing transfer for the message, an entity SHALL NOT begin any new outgoing transfer for the
remainder of the session. After receving a SESS_TERM message, an remainder of the session. After receving a SESS_TERM message, an
entity SHALL NOT accept any new incoming transfer for the remainder entity SHALL NOT accept any new incoming transfer for the remainder
of the session. of the session.
Instead of following a clean shutdown sequence, after transmitting a Instead of following a clean shutdown sequence, after transmitting a
SESS_TERM message an entity MAY immediately close the associated TCP SESS_TERM message an entity MAY immediately close the associated TCP
connection. When performing an unclean shutdown, a receiving node connection. When performing an unclean shutdown, a receiving node
SHOULD acknowledge all received data segments before closing the TCP SHOULD acknowledge all received data segments before closing the TCP
connection. Not acknowledging received segments can result in connection. Not acknowledging received segments can result in
unnecessary retransmission. When performing an unclean shutodwn, a unnecessary retransmission. When performing an unclean shutodwn, a
transmitting node SHALL treat either sending or receiving a SESS_TERM transmitting node SHALL treat either sending or receiving a SESS_TERM
message (i.e. before the final acknowledgment) as a failure of the message (i.e. before the final acknowledgment) as a failure of the
transfer. Any delay between request to terminate the TCP connection transfer. Any delay between request to close the TCP connection and
and actual closing of the connection (a "half-closed" state) MAY be actual closing of the connection (a "half-closed" state) MAY be
ignored by the TCPCL node. ignored by the TCPCL node.
The format of the SESS_TERM message is as follows in Figure 27. The format of the SESS_TERM message is as follows in Figure 27.
+-----------------------------+ +-----------------------------+
| Message Header | | Message Header |
+-----------------------------+ +-----------------------------+
| Message Flags (U8) | | Message Flags (U8) |
+-----------------------------+ +-----------------------------+
| Reason Code (U8) | | Reason Code (U8) |
+-----------------------------+ +-----------------------------+
Figure 27: Format of SESS_TERM Messages Figure 27: Format of SESS_TERM Messages
The fields of the SESS_TERM message are: The fields of the SESS_TERM message are:
Message Flags: A one-octet field of single-bit flags, interpreted Message Flags: A one-octet field of single-bit flags, interpreted
according to the descriptions in Table 8. All reserved header according to the descriptions in Table 8. All reserved header
flag bits SHALL be not set by the sender. All reserved header flag bits SHALL be set to 0 by the sender. All reserved header
flag bits SHALL be ignored by the receiver. flag bits SHALL be ignored by the receiver.
Reason Code: A one-octet refusal reason code interpreted according Reason Code: A one-octet refusal reason code interpreted according
to the descriptions in Table 9. to the descriptions in Table 9.
+----------+--------+-----------------------------------------------+ +----------+--------+-----------------------------------------------+
| Name | Code | Description | | Name | Code | Description |
+----------+--------+-----------------------------------------------+ +----------+--------+-----------------------------------------------+
| REPLY | 0x01 | If bit is set, indicates that this message is | | REPLY | 0x01 | If bit is set, indicates that this message is |
| | | an acknowledgement of an earlier SESS_TERM | | | | an acknowledgement of an earlier SESS_TERM |
skipping to change at page 46, line 24 skipping to change at page 46, line 24
8. Security Considerations 8. Security Considerations
TCPCL can be used to provide point-to-point transport security, but TCPCL can be used to provide point-to-point transport security, but
does not provide security of data-at-rest and does not guarantee end- does not provide security of data-at-rest and does not guarantee end-
to-end bundle security. The bundle security mechanisms defined in to-end bundle security. The bundle security mechanisms defined in
[I-D.ietf-dtn-bpsec] are to be used instead. [I-D.ietf-dtn-bpsec] are to be used instead.
When negotating whether to use TLS security as part of the contact When negotating whether to use TLS security as part of the contact
header exchange, it is possible for a man-in-the-middle attacker to header exchange, it is possible for a man-in-the-middle attacker to
unset the CAN_TLS flag on either side of the exchange. This leads to set the CAN_TLS flag to 0 on either side of the exchange. This leads
the "SSL Stripping" attack described in [RFC7457]. If TLS is desired to the "SSL Stripping" attack described in [RFC7457]. If TLS is
for use on any TCPCL network, it is strongly encouraged that the desired for use on any TCPCL network, it is strongly encouraged that
security policy disallow use of TCPCL when "Enable TLS" is negotiated the security policy disallow use of TCPCL when "Enable TLS" is
to false. This requires that the TLS handshake occurs, regardless of negotiated to false. This requires that the TLS handshake occurs,
the policy-driven parameters of the handshake and policy-driven regardless of the policy-driven parameters of the handshake and
handling of the handshake outcome. policy-driven handling of the handshake outcome.
Even when using TLS to secure the TCPCL session, the actual Even when using TLS to secure the TCPCL session, the actual
ciphersuite negotiated between the TLS peers MAY be insecure. TLS ciphersuite negotiated between the TLS peers MAY be insecure. TLS
can be used to perform authentication without data confidentiality, can be used to perform authentication without data confidentiality,
for example. It is up to security policies within each TCPCL node to for example. It is up to security policies within each TCPCL node to
ensure that the negotiated TLS ciphersuite meets transport security ensure that the negotiated TLS ciphersuite meets transport security
requirements. This is identical behavior to STARTTLS use in requirements. This is identical behavior to STARTTLS use in
[RFC2595]. [RFC2595].
The certificates exchanged by TLS enable authentication of peer host The certificates exchanged by TLS enable authentication of peer host
skipping to change at page 49, line 10 skipping to change at page 49, line 10
specification. specification.
IANA will create, under the "Bundle Protocol" registry, a sub- IANA will create, under the "Bundle Protocol" registry, a sub-
registry titled "Bundle Protocol TCP Convergence-Layer Version 4 registry titled "Bundle Protocol TCP Convergence-Layer Version 4
Session Extension Types" and initialize it with the contents of Session Extension Types" and initialize it with the contents of
Table 10. The registration procedure is Expert Review within the Table 10. The registration procedure is Expert Review within the
lower range 0x0001--0x7FFF. Values in the range 0x8000--0xFFFF are lower range 0x0001--0x7FFF. Values in the range 0x8000--0xFFFF are
reserved for use on private networks for functions not published to reserved for use on private networks for functions not published to
the IANA. the IANA.
Specifications of new session extension types need to define the
encoding of the Item Value data as well as any meaning or restriction
on the number of or order of instances of the type within an
extension item list. Specifications need to define how the extension
functions when no instance of the new extension type is received
during session negotiation.
Expert(s) are encouraged to be biased towards approving registrations
unless they are abusive, frivolous, or actively harmful (not merely
aesthetically displeasing, or architecturally dubious).
+----------------+--------------------------+ +----------------+--------------------------+
| Code | Session Extension Type | | Code | Session Extension Type |
+----------------+--------------------------+ +----------------+--------------------------+
| 0x0000 | Reserved | | 0x0000 | Reserved |
| | | | | |
| 0x0001--0x7FFF | Unassigned | | 0x0001--0x7FFF | Unassigned |
| | | | | |
| 0x8000--0xFFFF | Private/Experimental Use | | 0x8000--0xFFFF | Private/Experimental Use |
+----------------+--------------------------+ +----------------+--------------------------+
skipping to change at page 49, line 35 skipping to change at page 49, line 46
specification. specification.
IANA will create, under the "Bundle Protocol" registry, a sub- IANA will create, under the "Bundle Protocol" registry, a sub-
registry titled "Bundle Protocol TCP Convergence-Layer Version 4 registry titled "Bundle Protocol TCP Convergence-Layer Version 4
Transfer Extension Types" and initialize it with the contents of Transfer Extension Types" and initialize it with the contents of
Table 11. The registration procedure is Expert Review within the Table 11. The registration procedure is Expert Review within the
lower range 0x0001--0x7FFF. Values in the range 0x8000--0xFFFF are lower range 0x0001--0x7FFF. Values in the range 0x8000--0xFFFF are
reserved for use on private networks for functions not published to reserved for use on private networks for functions not published to
the IANA. the IANA.
Specifications of new transfer extension types need to define the
encoding of the Item Value data as well as any meaning or restriction
on the number of or order of instances of the type within an
extension item list. Specifications need to define how the extension
functions when no instance of the new extension type is received in a
transfer.
Expert(s) are encouraged to be biased towards approving registrations
unless they are abusive, frivolous, or actively harmful (not merely
aesthetically displeasing, or architecturally dubious).
+----------------+---------------------------+ +----------------+---------------------------+
| Code | Transfer Extension Type | | Code | Transfer Extension Type |
+----------------+---------------------------+ +----------------+---------------------------+
| 0x0000 | Reserved | | 0x0000 | Reserved |
| | | | | |
| 0x0001 | Transfer Length Extension | | 0x0001 | Transfer Length Extension |
| | | | | |
| 0x0002--0x7FFF | Unassigned | | 0x0002--0x7FFF | Unassigned |
| | | | | |
| 0x8000--0xFFFF | Private/Experimental Use | | 0x8000--0xFFFF | Private/Experimental Use |
skipping to change at page 50, line 17 skipping to change at page 50, line 35
EDITOR NOTE: sub-registry to-be-created upon publication of this EDITOR NOTE: sub-registry to-be-created upon publication of this
specification. specification.
IANA will create, under the "Bundle Protocol" registry, a sub- IANA will create, under the "Bundle Protocol" registry, a sub-
registry titled "Bundle Protocol TCP Convergence-Layer Version 4 registry titled "Bundle Protocol TCP Convergence-Layer Version 4
Message Types" and initialize it with the contents of Table 12. The Message Types" and initialize it with the contents of Table 12. The
registration procedure is RFC Required within the lower range 0x01-- registration procedure is RFC Required within the lower range 0x01--
0xEF. Values in the range 0xF0--0xFF are reserved for use on private 0xEF. Values in the range 0xF0--0xFF are reserved for use on private
networks for functions not published to the IANA. networks for functions not published to the IANA.
Specifications of new message types need to define the encoding of
the message data as well as the purpose and relationship of the new
message to existing session/transfer state within the baseline
message sequencing.
Expert(s) are encouraged to favor new session/transfer extension
types over new message types. TCPCL messages are not self-
delimiting, so care must be taken in introducing new message types.
If an entity receives an unknown message type the only thing that can
be done is to send a MSG_REJECT and close the TCP connection; not
even a clean termination can be done at that point.
+------------+--------------------------+ +------------+--------------------------+
| Code | Message Type | | Code | Message Type |
+------------+--------------------------+ +------------+--------------------------+
| 0x00 | Reserved | | 0x00 | Reserved |
| | | | | |
| 0x01 | XFER_SEGMENT | | 0x01 | XFER_SEGMENT |
| | | | | |
| 0x02 | XFER_ACK | | 0x02 | XFER_ACK |
| | | | | |
| 0x03 | XFER_REFUSE | | 0x03 | XFER_REFUSE |
skipping to change at page 51, line 7 skipping to change at page 51, line 44
specification. specification.
IANA will create, under the "Bundle Protocol" registry, a sub- IANA will create, under the "Bundle Protocol" registry, a sub-
registry titled "Bundle Protocol TCP Convergence-Layer Version 4 registry titled "Bundle Protocol TCP Convergence-Layer Version 4
XFER_REFUSE Reason Codes" and initialize it with the contents of XFER_REFUSE Reason Codes" and initialize it with the contents of
Table 13. The registration procedure is Specification Required Table 13. The registration procedure is Specification Required
within the lower range 0x00--0xEF. Values in the range 0xF0--0xFF within the lower range 0x00--0xEF. Values in the range 0xF0--0xFF
are reserved for use on private networks for functions not published are reserved for use on private networks for functions not published
to the IANA. to the IANA.
Specifications of new XFER_REFUSE reason codes need to define the
meaning of the reason and disambiguate it with pre-exisiting reasons.
Each refusal reason needs to be usable by the receving BP Agent to
make retransmission or re-routing decisions.
Expert(s) are encouraged to be biased towards approving registrations
unless they are abusive, frivolous, or actively harmful (not merely
aesthetically displeasing, or architecturally dubious).
+------------+--------------------------+ +------------+--------------------------+
| Code | Refusal Reason | | Code | Refusal Reason |
+------------+--------------------------+ +------------+--------------------------+
| 0x00 | Unknown | | 0x00 | Unknown |
| | | | | |
| 0x01 | Extension Failure | | 0x01 | Extension Failure |
| | | | | |
| 0x02 | Completed | | 0x02 | Completed |
| | | | | |
| 0x03 | No Resources | | 0x03 | No Resources |
skipping to change at page 52, line 5 skipping to change at page 52, line 38
specification. specification.
IANA will create, under the "Bundle Protocol" registry, a sub- IANA will create, under the "Bundle Protocol" registry, a sub-
registry titled "Bundle Protocol TCP Convergence-Layer Version 4 registry titled "Bundle Protocol TCP Convergence-Layer Version 4
SESS_TERM Reason Codes" and initialize it with the contents of SESS_TERM Reason Codes" and initialize it with the contents of
Table 14. The registration procedure is Specification Required Table 14. The registration procedure is Specification Required
within the lower range 0x00--0xEF. Values in the range 0xF0--0xFF within the lower range 0x00--0xEF. Values in the range 0xF0--0xFF
are reserved for use on private networks for functions not published are reserved for use on private networks for functions not published
to the IANA. to the IANA.
Specifications of new SESS_TERM reason codes need to define the
meaning of the reason and disambiguate it with pre-exisiting reasons.
Each termination reason needs to be usable by the receving BP Agent
to make re-connection decisions.
Expert(s) are encouraged to be biased towards approving registrations
unless they are abusive, frivolous, or actively harmful (not merely
aesthetically displeasing, or architecturally dubious).
+------------+--------------------------+ +------------+--------------------------+
| Code | Termination Reason | | Code | Termination Reason |
+------------+--------------------------+ +------------+--------------------------+
| 0x00 | Unknown | | 0x00 | Unknown |
| | | | | |
| 0x01 | Idle timeout | | 0x01 | Idle timeout |
| | | | | |
| 0x02 | Version mismatch | | 0x02 | Version mismatch |
| | | | | |
| 0x03 | Busy | | 0x03 | Busy |
skipping to change at page 53, line 5 skipping to change at page 53, line 40
specification. specification.
IANA will create, under the "Bundle Protocol" registry, a sub- IANA will create, under the "Bundle Protocol" registry, a sub-
registry titled "Bundle Protocol TCP Convergence-Layer Version 4 registry titled "Bundle Protocol TCP Convergence-Layer Version 4
MSG_REJECT Reason Codes" and initialize it with the contents of MSG_REJECT Reason Codes" and initialize it with the contents of
Table 15. The registration procedure is Specification Required Table 15. The registration procedure is Specification Required
within the lower range 0x01--0xEF. Values in the range 0xF0--0xFF within the lower range 0x01--0xEF. Values in the range 0xF0--0xFF
are reserved for use on private networks for functions not published are reserved for use on private networks for functions not published
to the IANA. to the IANA.
Specifications of new MSG_REJECT reason codes need to define the
meaning of the reason and disambiguate it with pre-exisiting reasons.
Each rejection reason needs to be usable by the receving TCPCL Entity
to make message sequencing and/or session termination decisions.
Expert(s) are encouraged to be biased towards approving registrations
unless they are abusive, frivolous, or actively harmful (not merely
aesthetically displeasing, or architecturally dubious).
+------------+--------------------------+ +------------+--------------------------+
| Code | Rejection Reason | | Code | Rejection Reason |
+------------+--------------------------+ +------------+--------------------------+
| 0x00 | reserved | | 0x00 | reserved |
| | | | | |
| 0x01 | Message Type Unknown | | 0x01 | Message Type Unknown |
| | | | | |
| 0x02 | Message Unsupported | | 0x02 | Message Unsupported |
| | | | | |
| 0x03 | Message Unexpected | | 0x03 | Message Unexpected |
skipping to change at page 54, line 21 skipping to change at page 55, line 21
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>. 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
skipping to change at page 55, line 7 skipping to change at page 56, line 12
11.2. Informative References 11.2. Informative References
[github-dtn-bpbis-tcpcl] [github-dtn-bpbis-tcpcl]
Sipos, B., "TCPCL Example Implementation", Sipos, B., "TCPCL Example Implementation",
<https://github.com/BSipos-RKF/dtn-bpbis-tcpcl/tree/ <https://github.com/BSipos-RKF/dtn-bpbis-tcpcl/tree/
develop>. develop>.
[I-D.ietf-dtn-bpsec] [I-D.ietf-dtn-bpsec]
Birrane, E. and K. McKeever, "Bundle Protocol Security Birrane, E. and K. McKeever, "Bundle Protocol Security
Specification", draft-ietf-dtn-bpsec-10 (work in Specification", draft-ietf-dtn-bpsec-12 (work in
progress), April 2019. progress), September 2019.
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP",
RFC 2595, DOI 10.17487/RFC2595, June 1999, RFC 2595, DOI 10.17487/RFC2595, June 1999,
<https://www.rfc-editor.org/info/rfc2595>. <https://www.rfc-editor.org/info/rfc2595>.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,
April 2007, <https://www.rfc-editor.org/info/rfc4838>. April 2007, <https://www.rfc-editor.org/info/rfc4838>.
 End of changes. 40 change blocks. 
90 lines changed or deleted 166 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/