--- 1/draft-ietf-dtn-tcpclv4-14.txt 2019-10-16 08:13:10.291775662 -0700 +++ 2/draft-ietf-dtn-tcpclv4-15.txt 2019-10-16 08:13:10.411778712 -0700 @@ -1,22 +1,22 @@ Delay Tolerant Networking B. Sipos Internet-Draft RKF Engineering Obsoletes: 7242 (if approved) M. Demmer Intended status: Standards Track UC Berkeley -Expires: March 22, 2020 J. Ott +Expires: April 18, 2020 J. Ott Aalto University S. Perreault - September 19, 2019 + October 16, 2019 Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 - draft-ietf-dtn-tcpclv4-14 + draft-ietf-dtn-tcpclv4-15 Abstract This document describes a revised protocol for the TCP-based convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). The protocol revision is based on implementation issues in the original TCPCL Version 3 of RFC7242 and updates to the Bundle Protocol contents, encodings, and convergence layer requirements in Bundle Protocol Version 7. Specifically, the TCPCLv4 uses CBOR-encoded BPv7 bundles as its service data unit being transported and provides a @@ -32,21 +32,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on March 22, 2020. + This Internet-Draft will expire on April 18, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -68,21 +68,21 @@ 3.3. TCPCL States and Transitions . . . . . . . . . . . . . . 12 3.4. Transfer Segmentation Policies . . . . . . . . . . . . . 18 3.5. Example Message Exchange . . . . . . . . . . . . . . . . 19 4. Session Establishment . . . . . . . . . . . . . . . . . . . . 21 4.1. TCP Connection . . . . . . . . . . . . . . . . . . . . . 21 4.2. Contact Header . . . . . . . . . . . . . . . . . . . . . 22 4.3. Contact Validation and Negotiation . . . . . . . . . . . 23 4.4. Session Security . . . . . . . . . . . . . . . . . . . . 24 4.4.1. TLS Handshake . . . . . . . . . . . . . . . . . . . . 24 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.6. Session Initialization Message (SESS_INIT) . . . . . . . 28 4.7. Session Parameter Negotiation . . . . . . . . . . . . . . 30 4.8. Session Extension Items . . . . . . . . . . . . . . . . . 31 5. Established Session Operation . . . . . . . . . . . . . . . . 32 5.1. Upkeep and Status Messages . . . . . . . . . . . . . . . 32 5.1.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 32 5.1.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 33 5.2. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 34 5.2.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 35 @@ -1026,35 +1026,57 @@ underlying TCP connection as the "client" role of the TLS handshake request. The TLS handshake, if it occurs, is considered to be part of the contact negotiation before the TCPCL session itself is established. Specifics about sensitive data exposure are discussed in Section 8. The parameters within each TLS negotiation are implementation 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. When possible, the TLS handshake SHOULD include a Server - Name Indication (SNI) from the active peer in accordance with - [RFC6066]. The SNI SHALL contain the same host name used to - establish the TCP connection. The passive peer MAY use the SNI host - name to choose an appropriate server-side certificate. The TLS - handshake SHALL request a client-side certificate to allow - authentication of the active peer. The passive peer SHOULD supply a - certificate within the TLS handshake to allow authentication of its - side of the session. The active peer SHOULD supply a certificate - within the TLS handshake to allow authentication of its side of the - session. All certificates supplied during TLS handshake SHALL - conform with the profile of [RFC5280], or any updates or successors - to that profile. When a certificate is supplied during TLS - handshake, the full certification chain SHOULD be included unless - security policy indicates that is unnecessary. + of BCP 195. Within each TLS handshake, the following requirements + apply (using the rough order in which they occur): + + Client Hello: When a resolved host name was used to establish the + TCP connection, the TLS ClientHello SHOULD include a Server Name + Indication (SNI) from the active peer in accordance with + [RFC6066]. When present, the SNI SHALL contain the same host name + used to establish the TCP connection. + + Server Certificate: The passive peer SHOULD supply a certificate + within the TLS handshake to allow authentication of its side of + the session. When assigned a stable host name or address, the + passive peer certificate SHOULD contain a subjectAltName entry + which authenticates that host name or address. The passive peer + 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 the TCPCL session SHALL close the TCP connection. At this point 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, the active peer SHALL send a SESS_INIT message to begin session negotiation. This session negotation and all subsequent messaging are secured. @@ -1064,20 +1086,29 @@ Using X.509 certificates exchanged during the TLS handshake, each of the entities can attempt to authenticate its peer at the network layer (host name and address) and at the application layer (BP Node ID). The Node ID exchanged in the Session Initialization is likely to be used by the BP agent for making transfer and routing decisions, so attempting host name validation is optional while attempting Node ID validation is required. The logic for attempting validation is separate from the logic for handling the result of validation, which 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 to one or more trusted certificate authority (CA) certificates. If certificate validation fails or if security policy disallows a certificate for any reason, the entity SHOULD terminate the session (with a reason code of "Contact Failure"). Immediately after the TLS handshake, each side of the TCP connection SHOULD perform host name validation of its peer in accordance with [RFC6125] unless it is not needed by security policy. The active peer SHALL attempt to authenticate the host name (of the passive @@ -2190,21 +2221,24 @@ IANA will create, under the "Bundle Protocol" registry, a sub- registry titled "Bundle Protocol TCP Convergence-Layer Version 4 Message Types" and initialize it with the contents of Table 12. The registration procedure is RFC Required within the lower range 0x01-- 0xEF. Values in the range 0xF0--0xFF are reserved for use on private networks for functions not published to the IANA. Specifications of new message types need to define the encoding of the message data as well as the purpose and relationship of the new message to existing session/transfer state within the baseline - message sequencing. + 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 types over new message types. TCPCL messages are not self- delimiting, so care must be taken in introducing new message types. If an entity receives an unknown message type the only thing that can be done is to send a MSG_REJECT and close the TCP connection; not even a clean termination can be done at that point. +------------+--------------------------+ | Code | Message Type |