draft-ietf-dtn-tcpclv4-08.txt | draft-ietf-dtn-tcpclv4-09.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: November 21, 2018 J. Ott | Expires: December 26, 2018 J. Ott | |||
Aalto University | Aalto University | |||
S. Perreault | S. Perreault | |||
May 20, 2018 | June 24, 2018 | |||
Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 | Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 | |||
draft-ietf-dtn-tcpclv4-08 | draft-ietf-dtn-tcpclv4-09 | |||
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 and updates to the Bundle Protocol contents, | TCPCL Version 3 of [RFC7242] and updates to the Bundle Protocol | |||
encodings, and convergence layer requirements in Bundle Protocol | contents, encodings, and convergence layer requirements in Bundle | |||
Version 7. Specifically, the TCPCLv4 uses CBOR-encoded BPv7 bundles | Protocol Version 7. Specifically, the TCPCLv4 uses CBOR-encoded BPv7 | |||
as its service data unit being transported and provides a reliable | bundles as its service data unit being transported and provides a | |||
transport of such bundles. Several new IANA registries are defined | reliable transport of such bundles. Several new IANA registries are | |||
for TCPCLv4 which define some behaviors inherited from TCPCLv3 but | defined for TCPCLv4 which define some behaviors inherited from | |||
with updated encodings and/or semantics. | TCPCLv3 but with updated encodings and/or semantics. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
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 November 21, 2018. | This Internet-Draft will expire on December 26, 2018. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2018 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 2, line 21 ¶ | skipping to change at page 2, line 21 ¶ | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. Convergence Layer Services . . . . . . . . . . . . . . . 4 | 1.1. Convergence Layer Services . . . . . . . . . . . . . . . 4 | |||
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 | 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 | |||
2.1. Definitions Specific to the TCPCL Protocol . . . . . . . 6 | 2.1. Definitions Specific to the TCPCL Protocol . . . . . . . 6 | |||
3. General Protocol Description . . . . . . . . . . . . . . . . 8 | 3. General Protocol Description . . . . . . . . . . . . . . . . 9 | |||
3.1. TCPCL Session Overview . . . . . . . . . . . . . . . . . 8 | 3.1. TCPCL Session Overview . . . . . . . . . . . . . . . . . 9 | |||
3.2. Transfer Segmentation Policies . . . . . . . . . . . . . 10 | 3.2. TCPCL States and Transitions . . . . . . . . . . . . . . 11 | |||
3.3. Example Message Exchange . . . . . . . . . . . . . . . . 11 | 3.3. Transfer Segmentation Policies . . . . . . . . . . . . . 16 | |||
4. Session Establishment . . . . . . . . . . . . . . . . . . . . 13 | 3.4. Example Message Exchange . . . . . . . . . . . . . . . . 17 | |||
4.1. TCP Connection . . . . . . . . . . . . . . . . . . . . . 13 | 4. Session Establishment . . . . . . . . . . . . . . . . . . . . 19 | |||
4.2. Contact Header . . . . . . . . . . . . . . . . . . . . . 13 | 4.1. TCP Connection . . . . . . . . . . . . . . . . . . . . . 19 | |||
4.3. Contact Validation and Negotiation . . . . . . . . . . . 14 | 4.2. Contact Header . . . . . . . . . . . . . . . . . . . . . 19 | |||
4.4. Session Security . . . . . . . . . . . . . . . . . . . . 15 | 4.3. Contact Validation and Negotiation . . . . . . . . . . . 20 | |||
4.4.1. TLS Handshake Result . . . . . . . . . . . . . . . . 16 | 4.4. Session Security . . . . . . . . . . . . . . . . . . . . 21 | |||
4.4.2. Example TLS Initiation . . . . . . . . . . . . . . . 16 | 4.4.1. TLS Handshake Result . . . . . . . . . . . . . . . . 22 | |||
4.5. Message Type Codes . . . . . . . . . . . . . . . . . . . 17 | 4.4.2. Example TLS Initiation . . . . . . . . . . . . . . . 22 | |||
4.6. Session Initialization Message (SESS_INIT) . . . . . . . 18 | 4.5. Message Type Codes . . . . . . . . . . . . . . . . . . . 23 | |||
4.6.1. Session Extension Items . . . . . . . . . . . . . . . 20 | 4.6. Session Initialization Message (SESS_INIT) . . . . . . . 24 | |||
4.7. Session Parameter Negotiation . . . . . . . . . . . . . . 21 | 4.6.1. Session Extension Items . . . . . . . . . . . . . . . 26 | |||
5. Established Session Operation . . . . . . . . . . . . . . . . 22 | 4.7. Session Parameter Negotiation . . . . . . . . . . . . . . 27 | |||
5.1. Upkeep and Status Messages . . . . . . . . . . . . . . . 22 | 5. Established Session Operation . . . . . . . . . . . . . . . . 28 | |||
5.1.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 22 | 5.1. Upkeep and Status Messages . . . . . . . . . . . . . . . 28 | |||
5.1.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 23 | 5.1.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 28 | |||
5.2. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 24 | 5.1.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 29 | |||
5.2.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 24 | 5.2. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 30 | |||
5.2.2. Transfer Initialization (XFER_INIT) . . . . . . . . . 25 | 5.2.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 30 | |||
5.2.3. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 28 | 5.2.2. Transfer Initialization (XFER_INIT) . . . . . . . . . 31 | |||
5.2.4. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 29 | 5.2.3. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 34 | |||
5.2.5. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 30 | 5.2.4. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 35 | |||
6. Session Termination . . . . . . . . . . . . . . . . . . . . . 32 | 5.2.5. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 36 | |||
6.1. Session Termination Message (SESS_TERM) . . . . . . . . . 32 | 6. Session Termination . . . . . . . . . . . . . . . . . . . . . 38 | |||
6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 35 | 6.1. Session Termination Message (SESS_TERM) . . . . . . . . . 38 | |||
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 35 | 6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 40 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 | 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 41 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 41 | |||
9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 37 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 | |||
9.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 37 | 9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 43 | |||
9.3. Session Extension Types . . . . . . . . . . . . . . . . . 38 | 9.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 43 | |||
9.4. Transfer Extension Types . . . . . . . . . . . . . . . . 38 | 9.3. Session Extension Types . . . . . . . . . . . . . . . . . 44 | |||
9.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 39 | 9.4. Transfer Extension Types . . . . . . . . . . . . . . . . 44 | |||
9.6. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 40 | 9.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 45 | |||
9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 41 | 9.6. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 46 | |||
9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 42 | 9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 47 | |||
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 | 9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 48 | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 | 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . 42 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 | |||
11.2. Informative References . . . . . . . . . . . . . . . . . 43 | 11.1. Normative References . . . . . . . . . . . . . . . . . . 48 | |||
Appendix A. Significant changes from RFC7242 . . . . . . . . . . 44 | 11.2. Informative References . . . . . . . . . . . . . . . . . 49 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 | Appendix A. Significant changes from RFC7242 . . . . . . . . . . 50 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 | ||||
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 4, line 39 ¶ | skipping to change at page 4, line 39 ¶ | |||
are defined elsewhere in [RFC5050] and [I-D.ietf-dtn-bpbis]. This | are defined elsewhere in [RFC5050] and [I-D.ietf-dtn-bpbis]. This | |||
includes the concept of bundle fragmentation or bundle | includes the concept of bundle fragmentation or bundle | |||
encapsulation. The TCPCL transfers bundles as opaque data blocks. | encapsulation. The TCPCL transfers bundles as opaque data blocks. | |||
o Mechanisms for locating or identifying other bundle entities | o Mechanisms for locating or identifying other bundle entities | |||
within an internet. | within an internet. | |||
1.1. Convergence Layer Services | 1.1. Convergence Layer Services | |||
This version of the TCPCL provides the following services to support | This version of the TCPCL provides the following services to support | |||
the overlaying Bundle Protocol agent: | the overlaying Bundle Protocol agent. In all cases, this is not an | |||
API defintion but a logical description of how the CL may interact | ||||
with the BP agent. Each of these interactions may be associated with | ||||
any number of additional metadata items as necessary to support the | ||||
operation of the CL or BP agent. | ||||
Attempt Session The TCPCL allows a BP agent to pre-emptively attempt | Attempt Session The TCPCL allows a BP agent to pre-emptively attempt | |||
to establish a TCPCL session with a peer entity. Each session | to establish a TCPCL session with a peer entity. Each session | |||
attempt can send a different set of contact header parameters as | attempt can send a different set of session negotiation parameters | |||
directed by the BP agent. | as directed by the BP agent. | |||
Shutdown Session The TCPCL allows a BP agent to pre-emptively | Terminate Session The TCPCL allows a BP agent to pre-emptively | |||
shutdown an established TCPCL session with a peer entity. The | terminate an established TCPCL session with a peer entity. The | |||
shutdown request is on a per-session basis. | terminate request is on a per-session basis. | |||
Session is Started The TCPCL supports indication when a new TCP | Session State Changed The TCPCL supports indication when the session | |||
connection has been started (as either client or server) before | state changes. The top-level session states indicated are: | |||
the TCPCL handshake has begun. | ||||
Session is Established The TCPCL supports indication when a new | Contact Negotating: A TCP connection has been made (as either | |||
session has been fully established and is ready for its first | active or passive entity) and contact negotiation has begun. | |||
transfer. | ||||
Session is Shutdown The TCPCL supports indication when an | Session Negotiating: Contact negotation has been completed | |||
established session has been ended by normal exchange of SESS_TERM | (including possible TLS use) and session negotiation has begun. | |||
messages with all transfers completed. | ||||
Session is Failed The TCPCL supports indication when a session | Established: The session has been fully established and is ready | |||
fails, either during contact negotiation, TLS negotiation, or | for its first transfer. | |||
after establishement for any reason other than normal shutdown. | ||||
Closing: The entity received a SESS_TERM message and is in the | ||||
closing state. | ||||
Terminated: The session has finished normal termination | ||||
sequencing.. | ||||
Failed: The session ended without normal termination sequencing. | ||||
Session Idle Changed The TCPCL supports indication when the live/ | ||||
idle sub-state changes. This occurs only when the top-level | ||||
session state is Established. Because TCPCL transmits serially | ||||
over a TCP connection, it suffers from "head of queue blocking" | ||||
this indication provides information about when a session is | ||||
available for immediate transfer start. | ||||
Begin Transmission The principal purpose of the TCPCL is to allow a | Begin Transmission The principal purpose of the TCPCL is to allow a | |||
BP agent to transmit bundle data over an established TCPCL | BP agent to transmit bundle data over an established TCPCL | |||
session. Transmission request is on a per-session basis, the CL | session. Transmission request is on a per-session basis, the CL | |||
does not necessarily perform any per-session or inter-session | does not necessarily perform any per-session or inter-session | |||
queueing. Any queueing of transmissions is the obligation of the | queueing. Any queueing of transmissions is the obligation of the | |||
BP agent. | BP agent. | |||
Transmission Availability Because TCPCL transmits serially over a | ||||
TCP connection, it suffers from "head of queue blocking" and | ||||
supports indication of when an established session is live-but- | ||||
idle (i.e. available for immediate transfer start) or live-and- | ||||
not-idle. | ||||
Transmission Success The TCPCL supports positive indication when a | Transmission Success The TCPCL supports positive indication when a | |||
bundle has been fully transferred to a peer entity. | bundle has been fully transferred to a peer entity. | |||
Transmission Intermediate Progress The TCPCL supports positive | Transmission Intermediate Progress The TCPCL supports positive | |||
indication of intermediate progress of transferr to a peer entity. | indication of intermediate progress of transferr to a peer entity. | |||
This intermediate progress is at the granularity of each | This intermediate progress is at the granularity of each | |||
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 | ||||
just before any transmssion data is sent. This corresponds to | ||||
reception of the XFER_INIT message. | ||||
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). | not). Interruption can occur any time after the reception is | |||
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 | |||
indication of intermediate progress of transfer from the peer | indication of intermediate progress of transfer from the peer | |||
entity. This intermediate progress is at the granularity of each | entity. This intermediate progress is at the granularity of each | |||
transferred segment. Intermediate reception indication allows a | transferred segment. Intermediate reception indication allows a | |||
BP agent the chance to inspect bundle header contents before the | BP agent the chance to inspect bundle header contents before the | |||
entire bundle is available, and thus supports the "Reception | entire bundle is available, and thus supports the "Reception | |||
skipping to change at page 6, line 46 ¶ | skipping to change at page 7, line 13 ¶ | |||
transmitter of information to another entity in the network. | transmitter of information to another entity in the network. | |||
A TCPCL Entity MAY support zero or more passive listening | A TCPCL Entity MAY support zero or more passive listening | |||
elements that listen for connection requests from other TCPCL | elements that listen for connection requests from other TCPCL | |||
Entities operating on other entitys in the network. | Entities operating on other entitys in the network. | |||
A TCPCL Entity MAY passivley initiate any number of TCPCL | A TCPCL Entity MAY passivley initiate any number of TCPCL | |||
Sessions from requests received by its passive listening | Sessions from requests received by its passive listening | |||
element(s) if the entity uses such elements. | element(s) if the entity uses such elements. | |||
For most TCPCL behavior within a session, the two entities are | These relationships are illustrated in Figure 2. For most TCPCL | |||
symmetric and there is no protocol distinction between them. Some | behavior within a session, the two entities are symmetric and | |||
specific behavior, particularly during session establishment, | there is no protocol distinction between them. Some specific | |||
distinguishes between the active entity and the passive entity. | behavior, particularly during session establishment, distinguishes | |||
For the remainder of this document, the term "entity" without the | between the active entity and the passive entity. For the | |||
prefix "TCPCL" refers to a TCPCL entity. | remainder of this document, the term "entity" without the prefix | |||
"TCPCL" refers to a TCPCL entity. | ||||
TCP Connection: The term Connection in this specification | TCP Connection: The term Connection in this specification | |||
exclusively refers to a TCP connection and any and all behaviors, | exclusively refers to a TCP connection and any and all behaviors, | |||
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. | |||
skipping to change at page 8, line 6 ¶ | skipping to change at page 8, line 23 ¶ | |||
Idle Session: A TCPCL session is idle while the only messages being | Idle Session: A TCPCL session is idle while the only messages being | |||
transmitted or received are KEEPALIVE messages. | transmitted or received are KEEPALIVE messages. | |||
Live Session: A TCPCL session is live while any messages are being | Live Session: A TCPCL session is live while any messages are being | |||
transmitted or received. | transmitted or received. | |||
Reason Codes: The TCPCL uses numeric codes to encode specific | Reason Codes: The TCPCL uses numeric codes to encode specific | |||
reasons for individual failure/error message types. | reasons for individual failure/error message types. | |||
The relationship between connections, sessions, and streams is shown | The relationship between connections, sessions, and streams is shown | |||
in Figure 2. | in Figure 3. | |||
+--------------------------------------------+ | ||||
| TCPCL Entity | | ||||
| | +----------------+ | ||||
| +--------------------------------+ | | |-+ | ||||
| | Actively Inititated Session #1 +------------->| Other | | | ||||
| +--------------------------------+ | | TCPCL Entity's | | | ||||
| ... | | Passive | | | ||||
| +--------------------------------+ | | Listener | | | ||||
| | Actively Inititated Session #n +------------->| | | | ||||
| +--------------------------------+ | +----------------+ | | ||||
| | +-----------------+ | ||||
| +---------------------------+ | | ||||
| +---| +---------------------------+ | +----------------+ | ||||
| | | | Optional Passive | | | |-+ | ||||
| | +-| Listener(s) +<-------------+ | | | ||||
| | +---------------------------+ | | | | | ||||
| | | | Other | | | ||||
| | +---------------------------------+ | | TCPCL Entity's | | | ||||
| +--->| Passively Inititated Session #1 +-------->| Active | | | ||||
| | +---------------------------------+ | | Initiator(s) | | | ||||
| | | | | | | ||||
| | +---------------------------------+ | | | | | ||||
| +--->| Passively Inititated Session #n +-------->| | | | ||||
| +---------------------------------+ | +----------------+ | | ||||
| | +-----------------+ | ||||
+--------------------------------------------+ | ||||
Figure 2: The relationships between TCPCL entities | ||||
+----------------------------+ +--------------------------+ | +----------------------------+ +--------------------------+ | |||
| TCPCL Session | | TCPCL "Other" Session | | | TCPCL Session | | TCPCL "Other" Session | | |||
| | | | | | | | | | |||
| +-----------------------+ | | +---------------------+ | | | +-----------------------+ | | +---------------------+ | | |||
| | TCP Connection | | | | TCP Connection | | | | | TCP Connection | | | | TCP Connection | | | |||
| | | | | | | | | | | | | | | | | | |||
| | +-------------------+ | | | | +-----------------+ | | | | | +-------------------+ | | | | +-----------------+ | | | |||
| | | Optional Inbound | | | | | | Peer Outbound | | | | | | | Optional Inbound | | | | | | Peer Outbound | | | | |||
| | | Transfer Stream |<-[Seg]--[Seg]--[Seg]-| | Transfer Stream | | | | | | | Transfer Stream |<-[Seg]--[Seg]--[Seg]-| | Transfer Stream | | | | |||
skipping to change at page 8, line 30 ¶ | skipping to change at page 9, line 27 ¶ | |||
| | | | | | | | | | | | | | | | | | |||
| | +-------------------+ | | | | +-----------------+ | | | | | +-------------------+ | | | | +-----------------+ | | | |||
| | | Optional Outbound | | | | | | Peer Inbound | | | | | | | Optional Outbound | | | | | | Peer Inbound | | | | |||
| | | Transfer Stream |------[Seg]---[Seg]---->| Transfer Stream | | | | | | | Transfer Stream |------[Seg]---[Seg]---->| Transfer Stream | | | | |||
| | | ----- | | | | | | ----- | | | | | | | ----- | | | | | | ----- | | | | |||
| | | SENDER | | | | | | RECEIVER | | | | | | | SENDER | | | | | | RECEIVER | | | | |||
| | +-------------------+ | | | | +-----------------+ | | | | | +-------------------+ | | | | +-----------------+ | | | |||
| +-----------------------+ | | +---------------------+ | | | +-----------------------+ | | +---------------------+ | | |||
+----------------------------+ +--------------------------+ | +----------------------------+ +--------------------------+ | |||
Figure 2: The relationship within a TCPCL Session of its two streams | Figure 3: The relationship within a TCPCL Session of its two streams | |||
3. General Protocol Description | 3. General Protocol Description | |||
The service of this protocol is the transmission of DTN bundles via | The service of this protocol is the transmission of DTN bundles via | |||
the Transmission Control Protocol (TCP). This document specifies the | the Transmission Control Protocol (TCP). This document specifies the | |||
encapsulation of bundles, procedures for TCP setup and teardown, and | encapsulation of bundles, procedures for TCP setup and teardown, and | |||
a set of messages and node requirements. The general operation of | a set of messages and node requirements. The general operation of | |||
the protocol is as follows. | the protocol is as follows. | |||
3.1. TCPCL Session Overview | 3.1. TCPCL Session Overview | |||
First, one node establishes a TCPCL session to the other by | First, one node establishes a TCPCL session to the other by | |||
initiating a TCP connection in accordance with [RFC0793]. After | initiating a TCP connection in accordance with [RFC0793]. After | |||
setup of the TCP connection is complete, an initial contact header is | setup of the TCP connection is complete, an initial contact header is | |||
exchanged in both directions to set parameters of the TCPCL session | exchanged in both directions to establish a shared TCPCL version and | |||
and exchange a singleton endpoint identifier for each node (not the | possibly initiate TLS security. Once contact negotiation is | |||
singleton Endpoint Identifier (EID) of any application running on the | complete, TCPCL messaging is available and the session negotiation is | |||
node) to denote the bundle-layer identity of each DTN node. This is | used to set parameters of the TCPCL session. One of these parameters | |||
used to assist in routing and forwarding messages (e.g. to prevent | is a singleton endpoint identifier for each node (not the singleton | |||
loops). | Endpoint Identifier (EID) of any application running on the node) to | |||
denote the bundle-layer identity of each DTN node. This is used to | ||||
assist in routing and forwarding messages (e.g. to prevent loops). | ||||
Once negotiated, the parameters of a TCPCL session cannot change and | ||||
if there is a desire by either peer to transfer data under different | ||||
parameters then a new session must be established. This makes CL | ||||
logic simpler but relies on the assumption that establishing a TCP | ||||
connection is lightweight enough that TCP connection overhead is | ||||
negligable compared to TCPCL data sizes. | ||||
Once the TCPCL session is established and configured in this way, | Once the TCPCL session is established and configured in this way, | |||
bundles can be transferred in either direction. Each transfer is | bundles can be transferred in either direction. Each transfer is | |||
performed by an initialization (XFER_INIT) message followed by one or | performed by an initialization (XFER_INIT) message followed by one or | |||
more logical segments of data within an XFER_SEGMENT message. | more logical segments of data within an XFER_SEGMENT message. | |||
Multiple bundles can be transmitted consecutively on a single TCPCL | Multiple bundles can be transmitted consecutively on a single TCPCL | |||
connection. Segments from different bundles are never interleaved. | connection. Segments from different bundles are never interleaved. | |||
Bundle interleaving can be accomplished by fragmentation at the BP | Bundle interleaving can be accomplished by fragmentation at the BP | |||
layer or by establishing multiple TCPCL sessions between the same | layer or by establishing multiple TCPCL sessions between the same | |||
peers. | peers. | |||
skipping to change at page 9, line 45 ¶ | skipping to change at page 10, line 49 ¶ | |||
information during otherwise message-less time intervals. | information during otherwise message-less time intervals. | |||
A SESS_TERM message is used to start the closing of a TCPCL session | A SESS_TERM message is used to start the closing 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). It is an implementation matter to determine whether or | |||
not to close a TCPCL session while there are no transfers queued or | not to close a TCPCL session while there are no transfers queued or | |||
in-progress. | in-progress. | |||
TCPCL is a symmetric protocol between the peers of a session. Both | Once a session is established established, TCPCL is a symmetric | |||
sides can start sending data segments in a session, and one side's | protocol between the peers. Both sides can start sending data | |||
bundle transfer does not have to complete before the other side can | segments in a session, and one side's bundle transfer does not have | |||
start sending data segments on its own. Hence, the protocol allows | to complete before the other side can start sending data segments on | |||
for a bi-directional mode of communication. Note that in the case of | its own. Hence, the protocol allows for a bi-directional mode of | |||
concurrent bidirectional transmission, acknowledgment segments MAY be | communication. Note that in the case of concurrent bidirectional | |||
interleaved with data segments. | transmission, acknowledgment segments MAY be interleaved with data | |||
segments. | ||||
3.2. Transfer Segmentation Policies | 3.2. TCPCL States and Transitions | |||
The states of a nominal TCPCL session (i.e. without session failures) | ||||
are indicated in Figure 4. | ||||
+-------+ | ||||
| START | | ||||
+-------+ | ||||
| | ||||
TCP Establishment | ||||
| | ||||
V | ||||
+-----------+ +---------------------+ | ||||
| TCP |----------->| Contact / Session | | ||||
| Connected | | Negotiation | | ||||
+-----------+ +---------------------+ | ||||
| | ||||
+-----Session Parameters-----+ | ||||
| Negotiated | ||||
V | ||||
+-------------+ +-------------+ | ||||
| Established |----New Transfer---->| Established | | ||||
| Session | | Session | | ||||
| Idle |<---Transfers Done---| Live | | ||||
+-------------+ +-------------+ | ||||
| | | ||||
+------------------------------------+ | ||||
| | ||||
SESS_TERM Exchange | ||||
| | ||||
V | ||||
+-------------+ | ||||
| Established | +-------------+ | ||||
| Session |----Transfers------>| TCP | | ||||
| Ending | Done | Terminating | | ||||
+-------------+ +-------------+ | ||||
| | ||||
+------------Close Message------------+ | ||||
| | ||||
V | ||||
+-------+ | ||||
| END | | ||||
+-------+ | ||||
Figure 4: Top-level states of a TCPCL session | ||||
Notes on Established Session states: | ||||
Session "Live" means transmitting or reeiving over a transfer | ||||
stream. | ||||
Session "Idle" means no transmission/reception over a transfer | ||||
stream. | ||||
Session "Closing" means no new transfers will be allowed. | ||||
The contact negotiation sequencing is performed either as the active | ||||
or passive peer, and is illustrated in Figure 5 and Figure 6 | ||||
respectively which both share the data validation and analyze final | ||||
states of Figure 7. | ||||
+-------+ | ||||
| START |-----TCP-----+ | ||||
+-------+ Connecting | | ||||
V | ||||
+-----------+ +---------+ | ||||
| Connected |--OK-->| Send CH |--OK-->[PCH] | ||||
+-----------+ +---------+ | ||||
| | | ||||
Error Error | ||||
| | | ||||
V | | ||||
[TCPTERM]<-------------+ | ||||
Figure 5: Contact Initiation as Active peer | ||||
+-------+ | ||||
| START |-----TCP----->[PCH] | ||||
+-------+ Connected | ||||
Figure 6: Contact Initiation as Passive peer | ||||
+-------->[TCPTERM]<----------+ | ||||
| | | ||||
Timeout Error | ||||
or Error | | ||||
| | | ||||
+-------+ +---------+ Contact +----------+ | ||||
| START |---->| Waiting |---- Header --->| Validate | | ||||
+-------+ +---------+ Received +----------+ | ||||
| | ||||
+---------------------------+ | ||||
| | ||||
V | ||||
+---------+ | ||||
+--Error--| Analyze |---No TLS---->[SI] | ||||
| | | ^ | ||||
| +---------+ | | ||||
| | | | ||||
V TLS | | ||||
[TCPTERM] Negotiated | | ||||
^ | | | ||||
| V | | ||||
| +-----------+ | | ||||
| | Establish |---Success---+ | ||||
+--Error--| TLS | | ||||
+-----------+ | ||||
Figure 7: Processing of Contact Header (PCH) | ||||
The session negotiation sequencing is performed either as the active | ||||
or passive peer, and is illustrated in Figure 8 and Figure 9 | ||||
respectively which both share the data validation and analyze final | ||||
states of Figure 10. | ||||
+-------+ TCPCL | ||||
| START |--Messaging--+ | ||||
+-------+ Available | | ||||
V | ||||
+----------------+ | ||||
| Send SESS_INIT |--OK-->[PSI] | ||||
+----------------+ | ||||
| | ||||
Error | ||||
| | ||||
V | ||||
[SESSTERM] | ||||
Figure 8: Session Initiation as Active peer | ||||
+-------+ TCPCL | ||||
| START |---Messaging-->[PSI] | ||||
+-------+ Available | ||||
Figure 9: Session Initiation as Passive peer | ||||
+------->[SESSTERM]<--------+ | ||||
| | | ||||
Timeout Error | ||||
or Error | | ||||
| | | ||||
+-------+ +---------+ +----------+ | ||||
| START |---->| Waiting |---SESS_INIT--->| Validate | | ||||
+-------+ +---------+ Received +----------+ | ||||
| | ||||
+---------------------------+ | ||||
| | ||||
V | ||||
+---------+ +--------------+ | ||||
+--Error--| Analyze |---->| Established | | ||||
| | | | Session Idle | | ||||
| +---------+ +--------------+ | ||||
V | ||||
[SESSTERM] | ||||
Figure 10: Processing of Session Initiation (PSI) | ||||
Transfers can occur after a session is established and it's not in | ||||
the ending state. Each transfer occurs within a single logical | ||||
transfer stream between a sender and a receiver, as illustrated in | ||||
Figure 11 and Figure 12 respectively. | ||||
+--Send XFER_DATA--+ | ||||
+--------+ | | | ||||
| Stream | +-------------+ | | ||||
| Idle |---Send XFER_INIT-->| In Progress |<---------+ | ||||
+--------+ +-------------+ | ||||
| | ||||
+------All segments sent-------+ | ||||
| | ||||
V | ||||
+---------+ +--------+ | ||||
| Waiting |---- Receive Final---->| Stream | | ||||
| for Ack | Ack | IDLE | | ||||
+---------+ +--------+ | ||||
Figure 11: Transfer sender states | ||||
Notes on transfer sending: | ||||
Pipelining of transfers can occur when the sending entity begins a | ||||
new transfer while in the "Waiting for Ack" state. | ||||
+-Receive XFER_DATA-+ | ||||
+--------+ | Send Ack | | ||||
| Stream | +-------------+ | | ||||
| IDLE |--Receive XFER_INIT-->| In Progress |<----------+ | ||||
+--------+ +-------------+ | ||||
| | ||||
+---------Sent Final Ack---------+ | ||||
| | ||||
V | ||||
+--------+ | ||||
| Stream | | ||||
| IDLE | | ||||
+--------+ | ||||
Figure 12: Transfer receiver states | ||||
3.3. Transfer Segmentation Policies | ||||
Each TCPCL session allows a negotiated transfer segmentation polcy to | Each TCPCL session allows a negotiated transfer segmentation polcy to | |||
be applied in each transfer direction. A receiving node can set the | be applied in each transfer direction. A receiving node can set the | |||
Segment MRU in its contact header to determine the largest acceptable | Segment MRU in its contact header to determine the largest acceptable | |||
segment size, and a transmitting node can segment a transfer into any | segment size, and a transmitting node can segment a transfer into any | |||
sizes smaller than the receiver's Segment MRU. It is a network | sizes smaller than the receiver's Segment MRU. It is a network | |||
administration matter to determine an appropriate segmentation policy | administration matter to determine an appropriate segmentation policy | |||
for entities operating TCPCL, but guidance given here can be used to | for entities operating TCPCL, but guidance given here can be used to | |||
steer policy toward performance goals. | steer policy toward performance goals. It is also advised to | |||
consider the Segment MRU in relation to chunking/packetization | ||||
performed by TLS, TCP, and any intermediate network-layer nodes. | ||||
Minimum Overhead For a simple network expected to exchange | Minimum Overhead For a simple network expected to exchange | |||
relatively small bundles, the Segment MRU can be set to be | relatively small bundles, the Segment MRU can be set to be | |||
identical to the Transfer MRU which indicates that all transfers | identical to the Transfer MRU which indicates that all transfers | |||
can be sent with a single data segment (i.e. no actual | can be sent with a single data segment (i.e. no actual | |||
segmentation). If the network is closed and all transmitters are | segmentation). If the network is closed and all transmitters are | |||
known to follow a single-segment transfer policy, then receivers | known to follow a single-segment transfer policy, then receivers | |||
can avoid the necessity of segment reassembly. Because this CL | can avoid the necessity of segment reassembly. Because this CL | |||
operates over a TCP stream, which suffers from a form of head-of- | operates over a TCP stream, which suffers from a form of head-of- | |||
queue blocking between messages, while one node is transmitting a | queue blocking between messages, while one node is transmitting a | |||
skipping to change at page 11, line 5 ¶ | skipping to change at page 17, line 24 ¶ | |||
MRU. In a situation where network "goodput" is dynamic, the | MRU. In a situation where network "goodput" is dynamic, the | |||
transfer segmentation size can also be dynamic in order to control | transfer segmentation size can also be dynamic in order to control | |||
message transmission duration. | message transmission duration. | |||
Many other policies can be established in a TCPCL network between | Many other policies can be established in a TCPCL network between | |||
these two extremes. Different policies can be applied to each | these two extremes. Different policies can be applied to each | |||
direction to/from any particular node. Additionally, future header | direction to/from any particular node. Additionally, future header | |||
and transfer extension types can apply further nuance to transfer | and transfer extension types can apply further nuance to transfer | |||
policies and policy negotiation. | policies and policy negotiation. | |||
3.3. Example Message Exchange | 3.4. Example Message Exchange | |||
The following figure depicts the protocol exchange for a simple | The following figure depicts the protocol exchange for a simple | |||
session, showing the session establishment and the transmission of a | session, showing the session establishment and the transmission of a | |||
single bundle split into three data segments (of lengths "L1", "L2", | single bundle split into three data segments (of lengths "L1", "L2", | |||
and "L3") from Entity A to Entity B. | and "L3") from Entity A to Entity B. | |||
Note that the sending node MAY transmit multiple XFER_SEGMENT | Note that the sending node MAY transmit multiple XFER_SEGMENT | |||
messages without necessarily waiting for the corresponding XFER_ACK | messages without necessarily waiting for the corresponding XFER_ACK | |||
responses. This enables pipelining of messages on a channel. | responses. This enables pipelining of messages on a transfer stream. | |||
Although this example only demonstrates a single bundle transmission, | Although this example only demonstrates a single bundle transmission, | |||
it is also possible to pipeline multiple XFER_SEGMENT messages for | it is also possible to pipeline multiple XFER_SEGMENT messages for | |||
different bundles without necessarily waiting for XFER_ACK messages | different bundles without necessarily waiting for XFER_ACK messages | |||
to be returned for each one. However, interleaving data segments | to be returned for each one. However, interleaving data segments | |||
from different bundles is not allowed. | from different bundles is not allowed. | |||
No errors or rejections are shown in this example. | No errors or rejections are shown in this example. | |||
Entity A Entity B | Entity A Entity B | |||
======== ======== | ======== ======== | |||
skipping to change at page 12, line 51 ¶ | skipping to change at page 18, line 51 ¶ | |||
<- | XFER_ACK (end) | | <- | XFER_ACK (end) | | |||
| Transfer ID [I1] | | | Transfer ID [I1] | | |||
| Length [L1+L2+L3] | | | Length [L1+L2+L3] | | |||
+-------------------------+ | +-------------------------+ | |||
+-------------------------+ | +-------------------------+ | |||
| SESS_TERM | -> +-------------------------+ | | SESS_TERM | -> +-------------------------+ | |||
+-------------------------+ <- | SESS_TERM | | +-------------------------+ <- | SESS_TERM | | |||
+-------------------------+ | +-------------------------+ | |||
Figure 3: An example of the flow of protocol messages on a single TCP | Figure 13: An example of the flow of protocol messages on a single | |||
Session between two entities | TCP Session between two entities | |||
4. Session Establishment | 4. Session Establishment | |||
For bundle transmissions to occur using the TCPCL, a TCPCL session | For bundle transmissions to occur using the TCPCL, a TCPCL session | |||
MUST first be established between communicating entities. It is up | MUST first be established between communicating entities. It is up | |||
to the implementation to decide how and when session setup is | to the implementation to decide how and when session setup is | |||
triggered. For example, some sessions MAY be opened proactively and | triggered. For example, some sessions MAY be opened proactively and | |||
maintained for as long as is possible given the network conditions, | maintained for as long as is possible given the network conditions, | |||
while other sessions MAY be opened only when there is a bundle that | while other sessions MAY be opened only when there is a bundle that | |||
is queued for transmission and the routing algorithm selects a | is queued for transmission and the routing algorithm selects a | |||
skipping to change at page 14, line 15 ¶ | skipping to change at page 20, line 15 ¶ | |||
The format for the Contact Header is as follows: | The format for the Contact Header is as follows: | |||
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| magic='dtn!' | | | magic='dtn!' | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| Version | Flags | | | Version | Flags | | |||
+---------------+---------------+ | +---------------+---------------+ | |||
Figure 4: Contact Header Format | Figure 14: Contact Header Format | |||
See Section 4.3 for details on the use of each of these contact | See Section 4.3 for details on the use of each of these contact | |||
header fields. The fields of the contact header are: | header fields. The fields of the contact header are: | |||
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 protocol). | version of the protocol). | |||
skipping to change at page 15, line 31 ¶ | skipping to change at page 21, line 31 ¶ | |||
operation to conform to the older version of the protocol. The | operation to conform to the older version of the protocol. The | |||
decision of version fall-back is an implementation matter. | decision of version fall-back is an implementation matter. | |||
4.4. Session Security | 4.4. Session Security | |||
This version of the TCPCL supports establishing a Transport Layer | This version of the TCPCL supports establishing a Transport Layer | |||
Security (TLS) session within an existing TCP connection. When TLS | Security (TLS) session within an existing TCP connection. When TLS | |||
is used within the TCPCL it affects the entire session. Once | is used within the TCPCL it affects the entire session. Once | |||
established, there is no mechanism available to downgrade a TCPCL | established, there is no mechanism available to downgrade a TCPCL | |||
session to non-TLS operation. If this is desired, the entire TCPCL | session to non-TLS operation. If this is desired, the entire TCPCL | |||
session MUST be shutdown and a new non-TLS-negotiated session | session MUST be terminated and a new non-TLS-negotiated session | |||
established. | established. | |||
The use of TLS is negotated using the Contact Header as described in | The use of TLS is negotated using the Contact Header as described in | |||
Section 4.3. After negotiating an Enable TLS parameter of true, and | Section 4.3. After negotiating an Enable TLS parameter of true, and | |||
before any other TCPCL messages are sent within the session, the | before any other TCPCL messages are sent within the session, the | |||
session entities SHALL begin a TLS handshake in accordance with | session entities SHALL begin a TLS handshake in accordance with | |||
[RFC5246]. The parameters within each TLS negotiation are | [RFC5246]. The parameters within each TLS negotiation are | |||
implementation dependent but any TCPCL node SHOULD follow all | implementation dependent but any TCPCL node SHOULD follow all | |||
recommended best practices of [RFC7525]. By convention, this | recommended best practices of [RFC7525]. By convention, this | |||
protocol uses the node which initiated the underlying TCP connection | protocol uses the node which initiated the underlying TCP connection | |||
as the "client" role of the TLS handshake request. | as the "client" role of the TLS handshake 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. | |||
4.4.1. TLS Handshake Result | 4.4.1. TLS Handshake Result | |||
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 start a TCPCL shutdown with reason "TLS | the TCPCL session SHALL terminate the TCP connection. At this point | |||
Failure". | the TCPCL session has not yet been established so there is no TCPCL | |||
session to terminate. This also avoids any potential security issues | ||||
assoicated with further TCP communication with an untrusted peer. | ||||
After a TLS session is successfully established, both TCPCL entities | After a TLS session is successfully established, the active peer | |||
SHALL re-exchange TCPCL Contact Header messages. Any information | SHALL send a SESS_INIT message to begin session negotiation. This | |||
cached from the prior Contact Header exchange SHALL be discarded. | session negotation and all subsequent messaging are secured. | |||
This re-exchange avoids a "man-in-the-middle" attack in identical | ||||
fashion to [RFC2595]. Each re-exchange header CAN_TLS flag SHALL be | ||||
identical to the original header CAN_TLS flag from the same node. | ||||
The CAN_TLS logic (TLS negotiation) SHALL NOT apply during header re- | ||||
exchange. This reinforces the fact that there is no TLS downgrade | ||||
mechanism. | ||||
4.4.2. Example TLS Initiation | 4.4.2. Example TLS Initiation | |||
A summary of a typical CAN_TLS usage is shown in the sequence in | A summary of a typical CAN_TLS usage is shown in the sequence in | |||
Figure 5 below. | Figure 15 below. | |||
Entity A Entity B | Entity A Entity B | |||
======== ======== | ======== ======== | |||
+-------------------------+ | +-------------------------+ | |||
| Open TCP Connnection | -> | | Open TCP Connnection | -> | |||
+-------------------------+ +-------------------------+ | +-------------------------+ +-------------------------+ | |||
<- | Accept Connection | | <- | Accept Connection | | |||
+-------------------------+ | +-------------------------+ | |||
+-------------------------+ | ||||
| Contact Header | -> | ||||
+-------------------------+ +-------------------------+ | +-------------------------+ +-------------------------+ | |||
| Contact Header | -> <- | Contact Header | | <- | Contact Header | | |||
+-------------------------+ +-------------------------+ | +-------------------------+ | |||
+-------------------------+ +-------------------------+ | +-------------------------+ +-------------------------+ | |||
| TLS Negotiation | -> <- | TLS Negotiation | | | TLS Negotiation | -> <- | TLS Negotiation | | |||
| (as client) | | (as server) | | | (as client) | | (as server) | | |||
+-------------------------+ +-------------------------+ | +-------------------------+ +-------------------------+ | |||
... secured TCPCL messaging, starting with SESS_INIT ... | ... secured TCPCL messaging, starting with SESS_INIT ... | |||
+-------------------------+ +-------------------------+ | +-------------------------+ +-------------------------+ | |||
| SESS_TERM | -> <- | SESS_TERM | | | SESS_TERM | -> <- | SESS_TERM | | |||
+-------------------------+ +-------------------------+ | +-------------------------+ +-------------------------+ | |||
Figure 5: A simple visual example of TCPCL TLS Establishment between | Figure 15: A simple visual example of TCPCL TLS Establishment between | |||
two entities | two entities | |||
4.5. Message Type Codes | 4.5. Message Type Codes | |||
After the initial exchange of a contact header, all messages | After the initial exchange of a contact header, all messages | |||
transmitted over the session are identified by a one-octet header | transmitted over the session are identified by a one-octet header | |||
with the following structure: | with the following structure: | |||
0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 | |||
+---------------+ | +---------------+ | |||
| Message Type | | | Message Type | | |||
+---------------+ | +---------------+ | |||
Figure 6: Format of the Message Header | Figure 16: Format of the Message Header | |||
The message header fields are as follows: | The message header fields are as follows: | |||
Message Type: Indicates the type of the message as per Table 2 | Message Type: Indicates the type of the message as per Table 2 | |||
below. Encoded values are listed in Section 9.5. | below. Encoded values are listed in Section 9.5. | |||
+--------------+----------------------------------------------------+ | +--------------+----------------------------------------------------+ | |||
| Type | Description | | | Type | Description | | |||
+--------------+----------------------------------------------------+ | +--------------+----------------------------------------------------+ | |||
| SESS_INIT | Contains the session parameter inputs from one of | | | SESS_INIT | Contains the session parameter inputs from one of | | |||
skipping to change at page 18, line 44 ¶ | skipping to change at page 24, line 44 ¶ | |||
Table 2: TCPCL Message Types | Table 2: TCPCL Message Types | |||
4.6. Session Initialization Message (SESS_INIT) | 4.6. Session Initialization Message (SESS_INIT) | |||
Before a session is established and ready to transfer bundles, the | Before a session is established and ready to transfer bundles, the | |||
session parameters are negotiated between the connected entities. | session parameters are negotiated between the connected entities. | |||
The SESS_INIT message is used to convey the per-entity parameters | The SESS_INIT message is used to convey the per-entity parameters | |||
which are used together to negotiate the per-session parameters. | which are used together to negotiate the per-session parameters. | |||
The format of a SESS_INIT message is as follows in Figure 7. | The format of a SESS_INIT message is as follows in Figure 17. | |||
+-------------------------------+ | +-------------------------------+ | |||
| 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) | | | EID Length (U16) | | |||
+-------------------------------+ | +-------------------------------+ | |||
| EID Data (variable) | | | EID Data (variable) | | |||
+-------------------------------+ | +-------------------------------+ | |||
| Session Extension Length (U64)| | | Session Extension Length (U64)| | |||
+-------------------------------+ | +-------------------------------+ | |||
| Session Extension Items (var.)| | | Session Extension Items (var.)| | |||
+-------------------------------+ | +-------------------------------+ | |||
Figure 7: SESS_INIT Format | Figure 17: SESS_INIT Format | |||
A 16-bit unsigned integer indicating the interval, in seconds, | A 16-bit unsigned integer indicating the interval, in seconds, | |||
between any subsequent messages being transmitted by the peer. | between any subsequent messages being transmitted by the peer. | |||
The peer receiving this contact header uses this interval to | The peer receiving this contact header uses this interval to | |||
determine how long to wait after any last-message transmission and | determine how long to wait after any last-message transmission and | |||
a necessary subsequent KEEPALIVE message transmission. | a necessary subsequent KEEPALIVE message transmission. | |||
A 64-bit unsigned integer indicating the largest allowable single- | A 64-bit unsigned integer indicating the largest allowable single- | |||
segment data payload size to be received in this session. Any | segment data payload size to be received in this session. Any | |||
XFER_SEGMENT sent to this peer SHALL have a data payload no longer | XFER_SEGMENT sent to this peer SHALL have a data payload no longer | |||
skipping to change at page 20, line 21 ¶ | skipping to change at page 26, line 21 ¶ | |||
Session Extension Item list. The encoding of each Session | Session Extension Item list. The encoding of each Session | |||
Extension Item is within a consistent data container as described | Extension Item is within a consistent data container as described | |||
in Section 4.6.1. The full set of Session Extension Items apply | in Section 4.6.1. The full set of Session Extension Items apply | |||
for the duration of the TCPCL session to follow. The order and | for the duration of the TCPCL session to follow. The order and | |||
mulitplicity of these Session Extension Items MAY be significant, | mulitplicity of these Session Extension Items MAY be significant, | |||
as defined in the associated type specification(s). | as defined in the associated type specification(s). | |||
4.6.1. Session Extension Items | 4.6.1. 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 8. The | Type-Length-Value (TLV) container form as indicated in Figure 18. | |||
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. If a TCPCL entity receives a | Item, which are listed in Table 3. 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 set, 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 not | |||
set, an entity SHALL skip over and ignore any item with an unknown | set, an entity SHALL skip over and ignore any item with an unknown | |||
Item Type. | Item 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 | |||
skipping to change at page 21, line 15 ¶ | skipping to change at page 27, line 15 ¶ | |||
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| Item Flags | Item Type | Item Length...| | | Item Flags | Item Type | Item Length...| | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| length contd. | Item Value... | | | length contd. | Item Value... | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| value contd. | | | value contd. | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
Figure 8: Session Extension Item Format | Figure 18: Session Extension Item Format | |||
+----------+--------+-----------------------------------------------+ | +----------+--------+-----------------------------------------------+ | |||
| Name | Code | Description | | | Name | Code | Description | | |||
+----------+--------+-----------------------------------------------+ | +----------+--------+-----------------------------------------------+ | |||
| CRITICAL | 0x01 | If bit is set, indicates that the receiving | | | CRITICAL | 0x01 | If bit is set, indicates that the receiving | | |||
| | | peer must handle the extension item. | | | | | peer must handle the extension item. | | |||
| | | | | | | | | | |||
| Reserved | others | | | Reserved | others | | |||
+----------+--------+-----------------------------------------------+ | +----------+--------+-----------------------------------------------+ | |||
skipping to change at page 22, line 4 ¶ | skipping to change at page 28, line 4 ¶ | |||
each transmitted segment is an implementation matter. | each transmitted segment is an implementation matter. | |||
Session Keepalive: Negotiation of the Session Keepalive parameter is | Session Keepalive: Negotiation of the Session Keepalive parameter is | |||
performed by taking the minimum of this two contact headers' | performed by taking the minimum of this two contact headers' | |||
Keepalive Interval. The Session Keepalive interval is a parameter | Keepalive Interval. The Session Keepalive interval is a parameter | |||
for the behavior described in Section 5.1.1. | for the behavior described in Section 5.1.1. | |||
Enable TLS: Negotiation of the Enable TLS parameter is performed by | Enable TLS: Negotiation of the Enable TLS parameter is performed by | |||
taking the logical AND of the two contact headers' CAN_TLS flags. | taking the logical AND of the two contact headers' CAN_TLS flags. | |||
A local security policy is then applied to determine of the | A local security policy is then applied to determine of the | |||
negotated value of Enable TLS is acceptable. If not, the node | negotated value of Enable TLS is acceptable. It can be a | |||
SHALL shutdown the session with a reason code of "Contact | reasonable security policy to both require or disallow the use of | |||
Failure". Note that this contact failure is different than a "TLS | TLS depending upon the desired network flows. If the Enable TLS | |||
Failure" after an agreed-upon and acceptable Enable TLS state. If | state is unacceptable, the node SHALL terminate the session with a | |||
the negotiated Enable TLS value is true and acceptable then TLS | reason code of "Contact Failure". Note that this contact failure | |||
negotiation feature (described in Section 4.4) begins immediately | is different than a failure of TLS handshake after an agreed-upon | |||
following the contact header exchange. | and acceptable Enable TLS state. If the negotiated Enable TLS | |||
value is true and acceptable then TLS negotiation feature | ||||
(described in Section 4.4) begins immediately following the | ||||
contact header exchange. | ||||
Once this process of parameter negotiation is completed (which | Once this process of parameter negotiation is completed (which | |||
includes a possible completed TLS handshake of the connection to use | includes a possible completed TLS handshake of the connection to use | |||
TLS), this protocol defines no additional mechanism to change the | TLS), this protocol defines no additional mechanism to change the | |||
parameters of an established session; to effect such a change, the | parameters of an established session; to effect such a change, the | |||
TCPCL session MUST be terminated and a new session established. | TCPCL session MUST be terminated and a new session established. | |||
5. Established Session Operation | 5. Established Session Operation | |||
This section describes the protocol operation for the duration of an | This section describes the protocol operation for the duration of an | |||
skipping to change at page 23, line 25 ¶ | skipping to change at page 29, line 27 ¶ | |||
5.1.2. Message Rejection (MSG_REJECT) | 5.1.2. Message Rejection (MSG_REJECT) | |||
If a TCPCL node receives a message which is unknown to it (possibly | If a TCPCL node receives a message which is unknown to it (possibly | |||
due to an unhandled protocol mismatch) or is inappropriate for the | due to an unhandled protocol mismatch) or is inappropriate for the | |||
current session state (e.g. a KEEPALIVE message received after | current session state (e.g. a KEEPALIVE message received after | |||
contact header negotiation has disabled that feature), there is a | contact header negotiation has disabled that feature), there is a | |||
protocol-level message to signal this condition in the form of a | protocol-level message to signal this condition in the form of a | |||
MSG_REJECT reply. | MSG_REJECT reply. | |||
The format of a MSG_REJECT message is as follows in Figure 9. | The format of a MSG_REJECT message is as follows in Figure 19. | |||
+-----------------------------+ | +-----------------------------+ | |||
| Message Header | | | Message Header | | |||
+-----------------------------+ | +-----------------------------+ | |||
| Reason Code (U8) | | | Reason Code (U8) | | |||
+-----------------------------+ | +-----------------------------+ | |||
| Rejected Message Header | | | Rejected Message Header | | |||
+-----------------------------+ | +-----------------------------+ | |||
Figure 9: Format of MSG_REJECT Messages | Figure 19: Format of MSG_REJECT Messages | |||
The fields of the MSG_REJECT message are: | The fields of the MSG_REJECT message are: | |||
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 4. | to the descriptions in Table 4. | |||
Rejected Message Header: The Rejected Message Header is a copy of | Rejected Message Header: The Rejected Message Header is a copy of | |||
the Message Header to which the MSG_REJECT message is sent as a | the Message Header to which the MSG_REJECT message is sent as a | |||
response. | response. | |||
skipping to change at page 25, line 39 ¶ | skipping to change at page 31, line 39 ¶ | |||
prepare storage on the receiving node for the upcoming bundle data. | prepare storage on the receiving node for the upcoming bundle data. | |||
See Section 5.2.5 for details on when refusal based on XFER_INIT | See Section 5.2.5 for details on when refusal based on XFER_INIT | |||
content is acceptable. | content is acceptable. | |||
The Total Bundle Length field within a XFER_INIT message SHALL be | The Total Bundle Length field within a XFER_INIT message SHALL be | |||
treated as authoritative by the receiver. If, for whatever reason, | treated as authoritative by the receiver. If, for whatever reason, | |||
the actual total length of bundle data received differs from the | the actual total length of bundle data received differs from the | |||
value indicated by the XFER_INIT message, the receiver SHOULD treat | value indicated by the XFER_INIT message, the receiver SHOULD treat | |||
the transmitted data as invalid. | the transmitted data as invalid. | |||
The format of the XFER_INIT message is as follows in Figure 10. | The format of the XFER_INIT message is as follows in Figure 20. | |||
+-----------------------------+ | +-----------------------------+ | |||
| Message Header | | | Message Header | | |||
+-----------------------------+ | +-----------------------------+ | |||
| Transfer ID (U64) | | | Transfer ID (U64) | | |||
+-----------------------------+ | +-----------------------------+ | |||
| Total Bundle Length (U64) | | | Total Bundle Length (U64) | | |||
+-----------------------------+ | +-----------------------------+ | |||
| Transfer Extension | | | Transfer Extension | | |||
| Length (U64) | | | Length (U64) | | |||
+-----------------------------+ | +-----------------------------+ | |||
| Transfer Extension Items... | | | Transfer Extension Items... | | |||
+-----------------------------+ | +-----------------------------+ | |||
Figure 10: Format of XFER_INIT Messages | Figure 20: Format of XFER_INIT Messages | |||
The fields of the XFER_INIT message are: | The fields of the XFER_INIT message are: | |||
Transfer ID: A 64-bit unsigned integer identifying the transfer | Transfer ID: A 64-bit unsigned integer identifying the transfer | |||
about to begin. | about to begin. | |||
Total Bundle Length: A 64-bit unsigned integer indicating the size | Total Bundle Length: A 64-bit unsigned integer indicating the size | |||
of the data-to-be-transferred. | of the data-to-be-transferred. | |||
Transfer Extension Length and Transfer Extension Items: Together | Transfer Extension Length and Transfer Extension Items: Together | |||
skipping to change at page 26, line 48 ¶ | skipping to change at page 32, line 48 ¶ | |||
An XFER_INIT message SHALL be sent as the first message in a transfer | An XFER_INIT message SHALL be sent as the first message in a transfer | |||
sequence, before transmission of any XFER_SEGMENT messages for the | sequence, before transmission of any XFER_SEGMENT messages for the | |||
same Transfer ID. XFER_INIT messages MUST NOT be sent unless the | same Transfer ID. XFER_INIT messages MUST NOT be sent unless the | |||
next XFER_SEGMENT message has the 'START' bit set to "1" (i.e., just | next XFER_SEGMENT message has the 'START' bit set to "1" (i.e., just | |||
before the start of a new transfer). | before the start of a new transfer). | |||
5.2.2.1. Transfer Extension Items | 5.2.2.1. 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 11. | Type-Length-Value (TLV) container form as indicated in Figure 21. | |||
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 5. If a TCPCL node receives a | Item, which are listed in Table 5. 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 close the TCPCL session with SESS_TERM | flag set, the node SHALL refuse the transfer with an XFER_REFUSE | |||
reason code of "Contact Failure". If the CRITICAL flag is not | reason code of "Extension Failure". If the CRITICAL flag is not | |||
set, an entity SHALL skip over and ignore any item with an unknown | set, an entity SHALL skip over and ignore any item with an unknown | |||
Item Type. | Item 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.4). | such codes (see Section 9.4). | |||
Item Length: A 32-bit unsigned integer field containing the number | Item Length: A 32-bit unsigned integer field containing the number | |||
of Item Value octets to follow. | of Item Value octets to follow. | |||
skipping to change at page 27, line 35 ¶ | skipping to change at page 33, line 35 ¶ | |||
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| Item Flags | Item Type | Item Length...| | | Item Flags | Item Type | Item Length...| | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| length contd. | Item Value... | | | length contd. | Item Value... | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| value contd. | | | value contd. | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
Figure 11: Transfer Extension Item Format | Figure 21: Transfer Extension Item Format | |||
+----------+--------+-----------------------------------------------+ | +----------+--------+-----------------------------------------------+ | |||
| Name | Code | Description | | | Name | Code | Description | | |||
+----------+--------+-----------------------------------------------+ | +----------+--------+-----------------------------------------------+ | |||
| CRITICAL | 0x01 | If bit is set, indicates that the receiving | | | CRITICAL | 0x01 | If bit is set, indicates that the receiving | | |||
| | | peer must handle the extension item. | | | | | peer must handle the extension item. | | |||
| | | | | | | | | | |||
| Reserved | others | | | Reserved | others | | |||
+----------+--------+-----------------------------------------------+ | +----------+--------+-----------------------------------------------+ | |||
Table 5: Transfer Extension Item Flags | Table 5: Transfer Extension Item Flags | |||
5.2.3. Data Transmission (XFER_SEGMENT) | 5.2.3. Data Transmission (XFER_SEGMENT) | |||
Each bundle is transmitted in one or more data segments. The format | Each bundle is transmitted in one or more data segments. The format | |||
of a XFER_SEGMENT message follows in Figure 12. | of a XFER_SEGMENT message follows in Figure 22. | |||
+------------------------------+ | +------------------------------+ | |||
| Message Header | | | Message Header | | |||
+------------------------------+ | +------------------------------+ | |||
| Message Flags (U8) | | | Message Flags (U8) | | |||
+------------------------------+ | +------------------------------+ | |||
| Transfer ID (U64) | | | Transfer ID (U64) | | |||
+------------------------------+ | +------------------------------+ | |||
| Data length (U64) | | | Data length (U64) | | |||
+------------------------------+ | +------------------------------+ | |||
| Data contents (octet string) | | | Data contents (octet string) | | |||
+------------------------------+ | +------------------------------+ | |||
Figure 12: 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 6. | according to the descriptions in Table 6. | |||
Transfer ID: A 64-bit unsigned integer identifying the transfer | Transfer ID: A 64-bit unsigned integer identifying the transfer | |||
being made. | being made. | |||
Data length: A 64-bit unsigned integer indicating the number of | Data length: A 64-bit unsigned integer indicating the number of | |||
skipping to change at page 29, line 29 ¶ | skipping to change at page 35, line 29 ¶ | |||
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 | |||
some data, the TCPCL needs an additional mechanism to determine | some data, the TCPCL needs an additional mechanism to determine | |||
whether the receiving agent has successfully received the segment. | whether the receiving agent has successfully received the segment. | |||
To this end, the TCPCL protocol provides feedback messaging whereby a | To this end, the TCPCL protocol provides feedback messaging whereby a | |||
receiving node transmits acknowledgments of reception of data | receiving node transmits acknowledgments of reception of data | |||
segments. | segments. | |||
The format of an XFER_ACK message follows in Figure 13. | The format of an XFER_ACK message follows in Figure 23. | |||
+-----------------------------+ | +-----------------------------+ | |||
| Message Header | | | Message Header | | |||
+-----------------------------+ | +-----------------------------+ | |||
| Message Flags (U8) | | | Message Flags (U8) | | |||
+-----------------------------+ | +-----------------------------+ | |||
| Transfer ID (U64) | | | Transfer ID (U64) | | |||
+-----------------------------+ | +-----------------------------+ | |||
| Acknowledged length (U64) | | | Acknowledged length (U64) | | |||
+-----------------------------+ | +-----------------------------+ | |||
Figure 13: 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 6. | according to the descriptions in Table 6. | |||
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 | |||
XFER_ACK header SHALL be set to match the corresponding DATA_SEGMENT | XFER_ACK header SHALL be set to match the corresponding DATA_SEGMENT | |||
message being acknowledged. The acknowledged length of each XFER_ACK | message being acknowledged. The acknowledged length of each XFER_ACK | |||
contains the sum of the data length fields of all XFER_SEGMENT | contains the sum of the data length fields of all XFER_SEGMENT | |||
messages received so far in the course of the indicated transfer. | messages received so far in the course of the indicated transfer. | |||
The sending node MAY transmit multiple XFER_SEGMENT messages without | The sending node MAY transmit multiple XFER_SEGMENT messages without | |||
necessarily waiting for the corresponding XFER_ACK responses. This | necessarily waiting for the corresponding XFER_ACK responses. This | |||
enables pipelining of messages on a channel. | enables pipelining of messages on a transfer stream. | |||
For example, suppose the sending node transmits four segments of | For example, suppose the sending node transmits four segments of | |||
bundle data with lengths 100, 200, 500, and 1000, respectively. | bundle data with lengths 100, 200, 500, and 1000, respectively. | |||
After receiving the first segment, the node sends an acknowledgment | After receiving the first segment, the node sends an acknowledgment | |||
of length 100. After the second segment is received, the node sends | of length 100. After the second segment is received, the node sends | |||
an acknowledgment of length 300. The third and fourth | an acknowledgment of length 300. The third and fourth | |||
acknowledgments are of length 800 and 1800, respectively. | acknowledgments are of length 800 and 1800, respectively. | |||
5.2.5. Transfer Refusal (XFER_REFUSE) | 5.2.5. Transfer Refusal (XFER_REFUSE) | |||
skipping to change at page 30, line 48 ¶ | skipping to change at page 36, line 48 ¶ | |||
XFER_REFUSE can be used in cases where the agent's bundle storage is | XFER_REFUSE can be used in cases where the agent's bundle storage is | |||
temporarily depleted or somehow constrained. A XFER_REFUSE can also | temporarily depleted or somehow constrained. A XFER_REFUSE can also | |||
be used after the bundle header or any bundle data is inspected by an | be used after the bundle header or any bundle data is inspected by an | |||
agent and determined to be unacceptable. | agent and determined to be unacceptable. | |||
A receiver MAY send an XFER_REFUSE message as soon as it receives a | A receiver MAY send an XFER_REFUSE message as soon as it receives a | |||
XFER_INIT message without waiting for the next XFER_SEGMENT message. | XFER_INIT message without waiting for the next XFER_SEGMENT message. | |||
The sender MUST be prepared for this and MUST associate the refusal | The sender MUST be prepared for this and MUST associate the refusal | |||
with the correct bundle via the Transfer ID fields. | with the correct bundle via the Transfer ID fields. | |||
The format of the XFER_REFUSE message is as follows in Figure 14. | The format of the XFER_REFUSE message is as follows in Figure 24. | |||
+-----------------------------+ | +-----------------------------+ | |||
| Message Header | | | Message Header | | |||
+-----------------------------+ | +-----------------------------+ | |||
| Reason Code (U8) | | | Reason Code (U8) | | |||
+-----------------------------+ | +-----------------------------+ | |||
| Transfer ID (U64) | | | Transfer ID (U64) | | |||
+-----------------------------+ | +-----------------------------+ | |||
Figure 14: Format of XFER_REFUSE Messages | Figure 24: Format of XFER_REFUSE Messages | |||
The fields of the XFER_REFUSE message are: | The fields of the XFER_REFUSE message are: | |||
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 7. | to the descriptions in Table 7. | |||
Transfer ID: A 64-bit unsigned integer identifying the transfer | Transfer ID: A 64-bit unsigned integer identifying the transfer | |||
being refused. | being refused. | |||
+------------+------------------------------------------------------+ | +------------+------------------------------------------------------+ | |||
| Name | Semantics | | | Name | Semantics | | |||
+------------+------------------------------------------------------+ | +------------+------------------------------------------------------+ | |||
| Unknown | Reason for refusal is unknown or not specified. | | | Unknown | Reason for refusal is unknown or not specified. | | |||
| | | | | | | | |||
| Extension | A failure processing the Transfer Extension Items ha | | ||||
| Failure | occurred. | | ||||
| | | | ||||
| Completed | The receiver already has the complete bundle. The | | | Completed | The receiver already has the complete bundle. The | | |||
| | sender MAY consider the bundle as completely | | | | sender MAY consider the bundle as completely | | |||
| | received. | | | | received. | | |||
| | | | | | | | |||
| No | The receiver's resources are exhausted. The sender | | | No | The receiver's resources are exhausted. The sender | | |||
| Resources | SHOULD apply reactive bundle fragmentation before | | | Resources | SHOULD apply reactive bundle fragmentation before | | |||
| | retrying. | | | | retrying. | | |||
| | | | | | | | |||
| Retransmit | The receiver has encountered a problem that requires | | | Retransmit | The receiver has encountered a problem that requires | | |||
| | the bundle to be retransmitted in its entirety. | | | | the bundle to be retransmitted in its entirety. | | |||
skipping to change at page 32, line 46 ¶ | skipping to change at page 38, line 49 ¶ | |||
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. When performing an unclean shutodwn, a transmitting node | connection. When performing an unclean shutodwn, a transmitting node | |||
SHALL treat either sending or receiving a SESS_TERM message (i.e. | SHALL treat either sending or receiving a SESS_TERM message (i.e. | |||
before the final acknowledgment) as a failure of the transfer. Any | before the final acknowledgment) as a failure of the transfer. Any | |||
delay between request to terminate the TCP connection and actual | delay between request to terminate the TCP connection and actual | |||
closing of the connection (a "half-closed" state) MAY be ignored by | closing of the connection (a "half-closed" state) MAY be ignored by | |||
the TCPCL node. | the TCPCL node. | |||
The format of the SESS_TERM message is as follows in Figure 15. | The format of the SESS_TERM message is as follows in Figure 25. | |||
+-----------------------------------+ | +-----------------------------------+ | |||
| Message Header | | | Message Header | | |||
+-----------------------------------+ | +-----------------------------------+ | |||
| Message Flags (U8) | | | Message Flags (U8) | | |||
+-----------------------------------+ | +-----------------------------------+ | |||
| Reason Code (optional U8) | | | Reason Code (optional U8) | | |||
+-----------------------------------+ | +-----------------------------------+ | |||
Figure 15: Format of SESS_TERM Messages | Figure 25: 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. | according to the descriptions in Table 8. | |||
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. The Reason Code is present or | to the descriptions in Table 9. The Reason Code is present or | |||
absent as indicated by one of the flags. | absent as indicated by one of the flags. | |||
skipping to change at page 34, line 19 ¶ | skipping to change at page 40, line 19 ¶ | |||
| | | | | | | | |||
| Version | The node cannot conform to the specified TCPCL | | | Version | The node cannot conform to the specified TCPCL | | |||
| mismatch | protocol version. | | | mismatch | protocol version. | | |||
| | | | | | | | |||
| Busy | The node is too busy to handle the current | | | Busy | The node is too busy to handle the current | | |||
| | session. | | | | session. | | |||
| | | | | | | | |||
| Contact | The node cannot interpret or negotiate contact | | | Contact | The node cannot interpret or negotiate contact | | |||
| Failure | header option. | | | Failure | header option. | | |||
| | | | | | | | |||
| TLS Failure | The node failed to negotiate TLS session and | | ||||
| | cannot continue the session. | | ||||
| | | | ||||
| Resource | The node has run into some resource limit and | | | Resource | The node has run into some resource limit and | | |||
| Exhaustion | cannot continue the session. | | | Exhaustion | cannot continue the session. | | |||
+---------------+---------------------------------------------------+ | +---------------+---------------------------------------------------+ | |||
Table 9: SESS_TERM Reason Codes | Table 9: SESS_TERM Reason Codes | |||
A session shutdown MAY occur immediately after transmission of a | A session shutdown MAY occur immediately after transmission of a | |||
contact header (and prior to any further message transmit). This | contact header (and prior to any further message transmit). This | |||
MAY, for example, be used to notify that the node is currently not | MAY, for example, be used to notify that the node is currently not | |||
able or willing to communicate. However, an entity MUST always send | able or willing to communicate. However, an entity MUST always send | |||
skipping to change at page 37, line 10 ¶ | skipping to change at page 43, line 7 ¶ | |||
service on other, well-behaving sessions. There is also nothing to | service on other, well-behaving sessions. There is also nothing to | |||
prevent a malicious entity from continually establishing sessions and | prevent a malicious entity from continually establishing sessions and | |||
repeatedly trying to send copious amounts of bundle data. A | repeatedly trying to send copious amounts of bundle data. A | |||
listening entity MAY take countermeasures such as ignoring TCP SYN | listening entity MAY take countermeasures such as ignoring TCP SYN | |||
messages, closing TCP connections as soon as they are established, | messages, closing TCP connections as soon as they are established, | |||
waiting before sending the contact header, sending a SESS_TERM | waiting before sending the contact header, sending a SESS_TERM | |||
message quickly or with a delay, etc. | message quickly or with a delay, etc. | |||
9. IANA Considerations | 9. IANA Considerations | |||
In this section, registration procedures are as defined in [RFC5226]. | In this section, registration procedures are as defined in [RFC8126]. | |||
Some of the registries below are created new for TCPCLv4 but share | Some of the registries below are created new for TCPCLv4 but share | |||
code values with TCPCLv3. This was done to disambiguate the use of | code values with TCPCLv3. This was done to disambiguate the use of | |||
these values between TCPCLv3 and TCPCLv4 while preserving the | these values between TCPCLv3 and TCPCLv4 while preserving the | |||
semantics of some values. | semantics of some values. | |||
9.1. Port Number | 9.1. Port Number | |||
Port number 4556 has been previously assigned as the default port for | Port number 4556 has been previously assigned as the default port for | |||
the TCP convergence layer in [RFC7242]. This assignment is unchanged | the TCP convergence layer in [RFC7242]. This assignment is unchanged | |||
skipping to change at page 41, line 10 ¶ | skipping to change at page 47, line 10 ¶ | |||
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 14. The registration procedure is RFC Required. | Table 14. The registration procedure is RFC Required. | |||
+----------+---------------------------+ | +----------+---------------------------+ | |||
| Code | Refusal Reason | | | Code | Refusal Reason | | |||
+----------+---------------------------+ | +----------+---------------------------+ | |||
| 0x0 | Unknown | | | 0x0 | Unknown | | |||
| | | | | | | | |||
| 0x1 | Completed | | | 0x1 | Extension Failure | | |||
| | | | | | | | |||
| 0x2 | No Resources | | | 0x2 | Completed | | |||
| | | | | | | | |||
| 0x3 | Retransmit | | | 0x3 | No Resources | | |||
| | | | | | | | |||
| 0x4--0x7 | Unassigned | | | 0x4 | Retransmit | | |||
| | | | ||||
| 0x5--0x7 | Unassigned | | ||||
| | | | | | | | |||
| 0x8--0xf | Reserved for future usage | | | 0x8--0xf | Reserved for future usage | | |||
+----------+---------------------------+ | +----------+---------------------------+ | |||
Table 14: XFER_REFUSE Reason Codes | Table 14: XFER_REFUSE Reason Codes | |||
9.7. SESS_TERM Reason Codes | 9.7. SESS_TERM Reason Codes | |||
EDITOR NOTE: sub-registry to-be-created upon publication of this | EDITOR NOTE: sub-registry to-be-created upon publication of this | |||
specification. | specification. | |||
skipping to change at page 41, line 44 ¶ | skipping to change at page 47, line 46 ¶ | |||
| Code | Shutdown Reason | | | Code | Shutdown Reason | | |||
+------------+---------------------+ | +------------+---------------------+ | |||
| 0x00 | Idle timeout | | | 0x00 | Idle timeout | | |||
| | | | | | | | |||
| 0x01 | Version mismatch | | | 0x01 | Version mismatch | | |||
| | | | | | | | |||
| 0x02 | Busy | | | 0x02 | Busy | | |||
| | | | | | | | |||
| 0x03 | Contact Failure | | | 0x03 | Contact Failure | | |||
| | | | | | | | |||
| 0x04 | TLS failure | | | 0x04 | Resource Exhaustion | | |||
| | | | ||||
| 0x05 | Resource Exhaustion | | ||||
| | | | | | | | |||
| 0x06--0xFF | Unassigned | | | 0x05--0xFF | Unassigned | | |||
+------------+---------------------+ | +------------+---------------------+ | |||
Table 15: SESS_TERM Reason Codes | Table 15: SESS_TERM Reason Codes | |||
9.8. MSG_REJECT Reason Codes | 9.8. MSG_REJECT Reason Codes | |||
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- | |||
skipping to change at page 42, line 42 ¶ | skipping to change at page 48, line 42 ¶ | |||
This specification is based on comments on implementation of | This specification is based on comments on implementation of | |||
[RFC7242] provided from Scott Burleigh. | [RFC7242] provided from Scott Burleigh. | |||
11. References | 11. References | |||
11.1. Normative References | 11.1. Normative References | |||
[I-D.ietf-dtn-bpbis] | [I-D.ietf-dtn-bpbis] | |||
Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol | Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol | |||
Version 7", draft-ietf-dtn-bpbis-10 (work in progress), | Version 7", draft-ietf-dtn-bpbis-11 (work in progress), | |||
November 2017. | May 2018. | |||
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, | [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, | |||
RFC 793, DOI 10.17487/RFC0793, September 1981, | RFC 793, DOI 10.17487/RFC0793, September 1981, | |||
<https://www.rfc-editor.org/info/rfc793>. | <https://www.rfc-editor.org/info/rfc793>. | |||
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - | [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - | |||
Communication Layers", STD 3, RFC 1122, | Communication Layers", STD 3, RFC 1122, | |||
DOI 10.17487/RFC1122, October 1989, | DOI 10.17487/RFC1122, October 1989, | |||
<https://www.rfc-editor.org/info/rfc1122>. | <https://www.rfc-editor.org/info/rfc1122>. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol | ||||
Specification", RFC 5050, DOI 10.17487/RFC5050, November | ||||
2007, <https://www.rfc-editor.org/info/rfc5050>. | ||||
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | ||||
IANA Considerations Section in RFCs", RFC 5226, | ||||
DOI 10.17487/RFC5226, May 2008, | ||||
<https://www.rfc-editor.org/info/rfc5226>. | ||||
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security | [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security | |||
(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>. | |||
[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 | |||
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May | (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May | |||
2015, <https://www.rfc-editor.org/info/rfc7525>. | 2015, <https://www.rfc-editor.org/info/rfc7525>. | |||
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | ||||
Writing an IANA Considerations Section in RFCs", BCP 26, | ||||
RFC 8126, DOI 10.17487/RFC8126, June 2017, | ||||
<https://www.rfc-editor.org/info/rfc8126>. | ||||
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-06 (work in | Specification", draft-ietf-dtn-bpsec-06 (work in | |||
skipping to change at page 44, line 5 ¶ | skipping to change at page 49, line 47 ¶ | |||
[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>. | |||
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol | ||||
Specification", RFC 5050, DOI 10.17487/RFC5050, November | ||||
2007, <https://www.rfc-editor.org/info/rfc5050>. | ||||
[RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, | [RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, | |||
"Bundle Security Protocol Specification", RFC 6257, | "Bundle Security Protocol Specification", RFC 6257, | |||
DOI 10.17487/RFC6257, May 2011, | DOI 10.17487/RFC6257, May 2011, | |||
<https://www.rfc-editor.org/info/rfc6257>. | <https://www.rfc-editor.org/info/rfc6257>. | |||
[RFC7242] Demmer, M., Ott, J., and S. Perreault, "Delay-Tolerant | [RFC7242] Demmer, M., Ott, J., and S. Perreault, "Delay-Tolerant | |||
Networking TCP Convergence-Layer Protocol", RFC 7242, | Networking TCP Convergence-Layer Protocol", RFC 7242, | |||
DOI 10.17487/RFC7242, June 2014, | DOI 10.17487/RFC7242, June 2014, | |||
<https://www.rfc-editor.org/info/rfc7242>. | <https://www.rfc-editor.org/info/rfc7242>. | |||
skipping to change at page 44, line 26 ¶ | skipping to change at page 50, line 26 ¶ | |||
Code: The Implementation Status Section", BCP 205, | Code: The Implementation Status Section", BCP 205, | |||
RFC 7942, DOI 10.17487/RFC7942, July 2016, | RFC 7942, DOI 10.17487/RFC7942, July 2016, | |||
<https://www.rfc-editor.org/info/rfc7942>. | <https://www.rfc-editor.org/info/rfc7942>. | |||
Appendix A. Significant changes from RFC7242 | Appendix A. Significant changes from RFC7242 | |||
The areas in which changes from [RFC7242] have been made to existing | The areas in which changes from [RFC7242] have been made to existing | |||
headers and messages are: | headers and messages are: | |||
o Split contact header into pre-TLS protocol negotiation and | o Split contact header into pre-TLS protocol negotiation and | |||
SESS_INIT parameter negotiation. | SESS_INIT parameter negotiation. The contact header is now fixed- | |||
length. | ||||
o Changed contact header content to limit number of negotiated | o Changed contact header content to limit number of negotiated | |||
options. | options. | |||
o Added contact option to negotiate maximum segment size (per each | o Added contact option to negotiate maximum segment size (per each | |||
direction). | direction). | |||
o Added session extension capability. | o Added session extension capability. | |||
o Added transfer extension capability. | o Added transfer extension capability. | |||
skipping to change at page 45, line 17 ¶ | skipping to change at page 51, line 19 ¶ | |||
The areas in which extensions from [RFC7242] have been made as new | The areas in which extensions from [RFC7242] have been made as new | |||
messages and codes are: | messages and codes are: | |||
o Added contact negotiation failure SESS_TERM reason code. | o Added contact negotiation failure SESS_TERM reason code. | |||
o Added MSG_REJECT message to indicate an unknown or unhandled | o Added MSG_REJECT message to indicate an unknown or unhandled | |||
message was received. | message was received. | |||
o Added TLS session security mechanism. | o Added TLS session security mechanism. | |||
o Added TLS failure and Resource Exhaustion SESS_TERM reason code. | o Added Resource Exhaustion SESS_TERM reason code. | |||
Authors' Addresses | Authors' Addresses | |||
Brian Sipos | Brian Sipos | |||
RKF Engineering Solutions, LLC | RKF Engineering Solutions, LLC | |||
7500 Old Georgetown Road | 7500 Old Georgetown Road | |||
Suite 1275 | Suite 1275 | |||
Bethesda, MD 20814-6198 | Bethesda, MD 20814-6198 | |||
US | United States of America | |||
Email: BSipos@rkf-eng.com | Email: BSipos@rkf-eng.com | |||
Michael Demmer | Michael Demmer | |||
University of California, Berkeley | University of California, Berkeley | |||
Computer Science Division | Computer Science Division | |||
445 Soda Hall | 445 Soda Hall | |||
Berkeley, CA 94720-1776 | Berkeley, CA 94720-1776 | |||
US | United States of America | |||
Email: demmer@cs.berkeley.edu | Email: demmer@cs.berkeley.edu | |||
Joerg Ott | Joerg Ott | |||
Aalto University | Aalto University | |||
Department of Communications and Networking | Department of Communications and Networking | |||
PO Box 13000 | PO Box 13000 | |||
Aalto 02015 | Aalto 02015 | |||
Finland | Finland | |||
End of changes. 73 change blocks. | ||||
182 lines changed or deleted | 439 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/ |