draft-ietf-dtn-tcpclv4-14.txt   draft-ietf-dtn-tcpclv4-15.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: March 22, 2020 J. Ott Expires: April 18, 2020 J. Ott
Aalto University Aalto University
S. Perreault S. Perreault
September 19, 2019 October 16, 2019
Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4
draft-ietf-dtn-tcpclv4-14 draft-ietf-dtn-tcpclv4-15
Abstract Abstract
This document describes a revised protocol for the TCP-based This document describes a revised protocol for the TCP-based
convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). The convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). The
protocol revision is based on implementation issues in the original protocol revision is based on implementation issues in the original
TCPCL Version 3 of RFC7242 and updates to the Bundle Protocol TCPCL Version 3 of RFC7242 and updates to the Bundle Protocol
contents, encodings, and convergence layer requirements in Bundle contents, encodings, and convergence layer requirements in Bundle
Protocol Version 7. Specifically, the TCPCLv4 uses CBOR-encoded BPv7 Protocol Version 7. Specifically, the TCPCLv4 uses CBOR-encoded BPv7
bundles as its service data unit being transported and provides a bundles as its service data unit being transported and provides a
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 22, 2020. This Internet-Draft will expire on April 18, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
3.3. TCPCL States and Transitions . . . . . . . . . . . . . . 12 3.3. TCPCL States and Transitions . . . . . . . . . . . . . . 12
3.4. Transfer Segmentation Policies . . . . . . . . . . . . . 18 3.4. Transfer Segmentation Policies . . . . . . . . . . . . . 18
3.5. Example Message Exchange . . . . . . . . . . . . . . . . 19 3.5. Example Message Exchange . . . . . . . . . . . . . . . . 19
4. Session Establishment . . . . . . . . . . . . . . . . . . . . 21 4. Session Establishment . . . . . . . . . . . . . . . . . . . . 21
4.1. TCP Connection . . . . . . . . . . . . . . . . . . . . . 21 4.1. TCP Connection . . . . . . . . . . . . . . . . . . . . . 21
4.2. Contact Header . . . . . . . . . . . . . . . . . . . . . 22 4.2. Contact Header . . . . . . . . . . . . . . . . . . . . . 22
4.3. Contact Validation and Negotiation . . . . . . . . . . . 23 4.3. Contact Validation and Negotiation . . . . . . . . . . . 23
4.4. Session Security . . . . . . . . . . . . . . . . . . . . 24 4.4. Session Security . . . . . . . . . . . . . . . . . . . . 24
4.4.1. TLS Handshake . . . . . . . . . . . . . . . . . . . . 24 4.4.1. TLS Handshake . . . . . . . . . . . . . . . . . . . . 24
4.4.2. TLS Authentication . . . . . . . . . . . . . . . . . 25 4.4.2. TLS Authentication . . . . . . . . . . . . . . . . . 25
4.4.3. Example TLS Initiation . . . . . . . . . . . . . . . 26 4.4.3. Example TLS Initiation . . . . . . . . . . . . . . . 27
4.5. Message Header . . . . . . . . . . . . . . . . . . . . . 27 4.5. Message Header . . . . . . . . . . . . . . . . . . . . . 27
4.6. Session Initialization Message (SESS_INIT) . . . . . . . 28 4.6. Session Initialization Message (SESS_INIT) . . . . . . . 28
4.7. Session Parameter Negotiation . . . . . . . . . . . . . . 30 4.7. Session Parameter Negotiation . . . . . . . . . . . . . . 30
4.8. Session Extension Items . . . . . . . . . . . . . . . . . 31 4.8. Session Extension Items . . . . . . . . . . . . . . . . . 31
5. Established Session Operation . . . . . . . . . . . . . . . . 32 5. Established Session Operation . . . . . . . . . . . . . . . . 32
5.1. Upkeep and Status Messages . . . . . . . . . . . . . . . 32 5.1. Upkeep and Status Messages . . . . . . . . . . . . . . . 32
5.1.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 32 5.1.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 32
5.1.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 33 5.1.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 33
5.2. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 34 5.2. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 34
5.2.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 35 5.2.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 35
skipping to change at page 24, line 37 skipping to change at page 24, line 37
underlying TCP connection as the "client" role of the TLS handshake underlying TCP connection as the "client" role of the TLS handshake
request. request.
The TLS handshake, if it occurs, is considered to be part of the The TLS handshake, if it occurs, is considered to be part of the
contact negotiation before the TCPCL session itself is established. contact negotiation before the TCPCL session itself is established.
Specifics about sensitive data exposure are discussed in Section 8. Specifics about sensitive data exposure are discussed in Section 8.
The parameters within each TLS negotiation are implementation The parameters within each TLS negotiation are implementation
dependent but any TCPCL node SHALL follow all recommended practices dependent but any TCPCL node SHALL follow all recommended practices
of BCP 195 [RFC7525], or any updates or successors that become part of BCP 195 [RFC7525], or any updates or successors that become part
of BCP 195. When possible, the TLS handshake SHOULD include a Server of BCP 195. Within each TLS handshake, the following requirements
Name Indication (SNI) from the active peer in accordance with apply (using the rough order in which they occur):
[RFC6066]. The SNI SHALL contain the same host name used to
establish the TCP connection. The passive peer MAY use the SNI host Client Hello: When a resolved host name was used to establish the
name to choose an appropriate server-side certificate. The TLS TCP connection, the TLS ClientHello SHOULD include a Server Name
handshake SHALL request a client-side certificate to allow Indication (SNI) from the active peer in accordance with
authentication of the active peer. The passive peer SHOULD supply a [RFC6066]. When present, the SNI SHALL contain the same host name
certificate within the TLS handshake to allow authentication of its used to establish the TCP connection.
side of the session. The active peer SHOULD supply a certificate
within the TLS handshake to allow authentication of its side of the Server Certificate: The passive peer SHOULD supply a certificate
session. All certificates supplied during TLS handshake SHALL within the TLS handshake to allow authentication of its side of
conform with the profile of [RFC5280], or any updates or successors the session. When assigned a stable host name or address, the
to that profile. When a certificate is supplied during TLS passive peer certificate SHOULD contain a subjectAltName entry
handshake, the full certification chain SHOULD be included unless which authenticates that host name or address. The passive peer
security policy indicates that is unnecessary. certificate SHOULD contain a subjectAltName entry of type
uniformResourceIdentifier which authenticates the Node ID of the
peer. The passive peer MAY use the SNI host name to choose an
appropriate server-side certificate which authenticates that host
name and corresponding Node ID.
Certificate Request: During TLS handshake, the passive peer SHALL
request a client-side certificate.
Client Certificate: The active peer SHOULD supply a certificate
chain within the TLS handshake to allow authentication of its side
of the session. When assigned a stable host name or address, the
active peer certificate SHOULD contain a subjectAltName entry
which authenticates that host name or address. The active peer
certificate SHOULD contain a subjectAltName entry of type
uniformResourceIdentifier which authenticates the Node ID of the
peer.
All certificates supplied during TLS handshake SHALL conform with the
profile of [RFC5280], or any updates or successors to that profile.
When a certificate is supplied during TLS handshake, the full
certification chain SHOULD be included unless security policy
indicates that is unnecessary.
If a TLS handshake cannot negotiate a TLS session, both entities of If a TLS handshake cannot negotiate a TLS session, both entities of
the TCPCL session SHALL close the TCP connection. At this point the the TCPCL session SHALL close the TCP connection. At this point the
TCPCL session has not yet been established so there is no TCPCL TCPCL session has not yet been established so there is no TCPCL
session to terminate. This also avoids any potential security issues session to terminate. This also avoids any potential security issues
assoicated with further TCP communication with an untrusted peer. assoicated with further TCP communication with an untrusted peer.
After a TLS session is successfully established, the active peer After a TLS session is successfully established, the active peer
SHALL send a SESS_INIT message to begin session negotiation. This SHALL send a SESS_INIT message to begin session negotiation. This
session negotation and all subsequent messaging are secured. session negotation and all subsequent messaging are secured.
skipping to change at page 25, line 27 skipping to change at page 25, line 49
Using X.509 certificates exchanged during the TLS handshake, each of Using X.509 certificates exchanged during the TLS handshake, each of
the entities can attempt to authenticate its peer at the network the entities can attempt to authenticate its peer at the network
layer (host name and address) and at the application layer (BP Node layer (host name and address) and at the application layer (BP Node
ID). The Node ID exchanged in the Session Initialization is likely ID). The Node ID exchanged in the Session Initialization is likely
to be used by the BP agent for making transfer and routing decisions, to be used by the BP agent for making transfer and routing decisions,
so attempting host name validation is optional while attempting Node so attempting host name validation is optional while attempting Node
ID validation is required. The logic for attempting validation is ID validation is required. The logic for attempting validation is
separate from the logic for handling the result of validation, which separate from the logic for handling the result of validation, which
is based on local security policy. is based on local security policy.
By using the SNI host name (see Section 4.4.1) a single passive
entity can act as a convergence layer for multiple BP agents with
distinct Node IDs. When this "virtual host" behavior is used, the
host name is used as the indication of which BP Node the passive
entity is attempting to communicate with. A virtual host CL entity
can be authenticated by a certificate containing all of the host
names and/or Node IDs being hosted or by several certificates each
authenticating a single host name and/or Node ID.
Any certificate received during TLS handshake SHALL be validated up Any certificate received during TLS handshake SHALL be validated up
to one or more trusted certificate authority (CA) certificates. If to one or more trusted certificate authority (CA) certificates. If
certificate validation fails or if security policy disallows a certificate validation fails or if security policy disallows a
certificate for any reason, the entity SHOULD terminate the session certificate for any reason, the entity SHOULD terminate the session
(with a reason code of "Contact Failure"). (with a reason code of "Contact Failure").
Immediately after the TLS handshake, each side of the TCP connection Immediately after the TLS handshake, each side of the TCP connection
SHOULD perform host name validation of its peer in accordance with SHOULD perform host name validation of its peer in accordance with
[RFC6125] unless it is not needed by security policy. The active [RFC6125] unless it is not needed by security policy. The active
peer SHALL attempt to authenticate the host name (of the passive peer SHALL attempt to authenticate the host name (of the passive
skipping to change at page 50, line 38 skipping to change at page 50, line 38
IANA will create, under the "Bundle Protocol" registry, a sub- IANA will create, under the "Bundle Protocol" registry, a sub-
registry titled "Bundle Protocol TCP Convergence-Layer Version 4 registry titled "Bundle Protocol TCP Convergence-Layer Version 4
Message Types" and initialize it with the contents of Table 12. The Message Types" and initialize it with the contents of Table 12. The
registration procedure is RFC Required within the lower range 0x01-- registration procedure is RFC Required within the lower range 0x01--
0xEF. Values in the range 0xF0--0xFF are reserved for use on private 0xEF. Values in the range 0xF0--0xFF are reserved for use on private
networks for functions not published to the IANA. networks for functions not published to the IANA.
Specifications of new message types need to define the encoding of Specifications of new message types need to define the encoding of
the message data as well as the purpose and relationship of the new the message data as well as the purpose and relationship of the new
message to existing session/transfer state within the baseline message to existing session/transfer state within the baseline
message sequencing. message sequencing. The use of new message types need to be
negotiated between TCPCL entities within a session (using the session
extension mechanism) so that the receving entity can properly decode
all message types used in the session.
Expert(s) are encouraged to favor new session/transfer extension Expert(s) are encouraged to favor new session/transfer extension
types over new message types. TCPCL messages are not self- types over new message types. TCPCL messages are not self-
delimiting, so care must be taken in introducing new message types. delimiting, so care must be taken in introducing new message types.
If an entity receives an unknown message type the only thing that can If an entity receives an unknown message type the only thing that can
be done is to send a MSG_REJECT and close the TCP connection; not be done is to send a MSG_REJECT and close the TCP connection; not
even a clean termination can be done at that point. even a clean termination can be done at that point.
+------------+--------------------------+ +------------+--------------------------+
| Code | Message Type | | Code | Message Type |
 End of changes. 8 change blocks. 
21 lines changed or deleted 55 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/