draft-ietf-dtn-tcpclv4-27.txt   draft-ietf-dtn-tcpclv4-28.txt 
Delay-Tolerant Networking B. Sipos Delay-Tolerant Networking B. Sipos
Internet-Draft RKF Engineering Internet-Draft RKF Engineering
Intended status: Standards Track M. Demmer Intended status: Standards Track M. Demmer
Expires: 26 March 2022 UC Berkeley Expires: 9 April 2022 UC Berkeley
J. Ott J. Ott
Aalto University Aalto University
S. Perreault S. Perreault
22 September 2021 6 October 2021
Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4
draft-ietf-dtn-tcpclv4-27 draft-ietf-dtn-tcpclv4-28
Abstract Abstract
This document describes a TCP-based convergence layer (TCPCL) for This document describes a TCP-based convergence layer (TCPCL) for
Delay-Tolerant Networking (DTN). This version of the TCPCL protocol Delay-Tolerant Networking (DTN). This version of the TCPCL protocol
resolves implementation issues in the earlier TCPCL Version 3 of resolves implementation issues in the earlier TCPCL Version 3 of
RFC7242 and updates to the Bundle Protocol (BP) contents, encodings, RFC7242 and updates to the Bundle Protocol (BP) contents, encodings,
and convergence layer requirements in BP Version 7. Specifically, and convergence layer requirements in BP Version 7. Specifically,
the TCPCLv4 uses CBOR-encoded BPv7 bundles as its service data unit the TCPCLv4 uses CBOR-encoded BPv7 bundles as its service data unit
being transported and provides a reliable transport of such bundles. being transported and provides a reliable transport of such bundles.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 26 March 2022. This Internet-Draft will expire on 9 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 34 skipping to change at page 3, line 34
8.13. Predictability of Transfer IDs . . . . . . . . . . . . . 62 8.13. Predictability of Transfer IDs . . . . . . . . . . . . . 62
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62
9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 62 9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 62
9.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 63 9.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 63
9.3. Session Extension Types . . . . . . . . . . . . . . . . . 64 9.3. Session Extension Types . . . . . . . . . . . . . . . . . 64
9.4. Transfer Extension Types . . . . . . . . . . . . . . . . 64 9.4. Transfer Extension Types . . . . . . . . . . . . . . . . 64
9.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 65 9.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 65
9.6. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 66 9.6. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 66
9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 67 9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 67
9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 68 9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 68
9.9. Object Identifier for PKIX Other Name Forms . . . . . . . 69 9.9. Object Identifier for PKIX Module Identifier . . . . . . 69
9.10. Object Identifier for PKIX Extended Key Usage . . . . . . 70 9.10. Object Identifier for PKIX Other Name Forms . . . . . . . 69
9.11. Object Identifier for PKIX Extended Key Usage . . . . . . 70
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 70 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 70
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 70
11.1. Normative References . . . . . . . . . . . . . . . . . . 70 11.1. Normative References . . . . . . . . . . . . . . . . . . 70
11.2. Informative References . . . . . . . . . . . . . . . . . 72 11.2. Informative References . . . . . . . . . . . . . . . . . 72
Appendix A. Significant changes from RFC7242 . . . . . . . . . . 74 Appendix A. Significant changes from RFC7242 . . . . . . . . . . 74
Appendix B. Example of bundleEID Other Name Form . . . . . . . . 75 Appendix B. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 76
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76 Appendix C. Example of the BundleEID Other Name Form . . . . . . 78
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 78
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 29, line 16 skipping to change at page 29, line 16
wildcard DNS-ID is discouraged due to the complex rules for wildcard DNS-ID is discouraged due to the complex rules for
matching and dependence on implementation support for wildcard matching and dependence on implementation support for wildcard
matching (see Section 6.4.3 of [RFC6125]). matching (see Section 6.4.3 of [RFC6125]).
Network Address: If no stable DNS name is available but a stable Network Address: If no stable DNS name is available but a stable
network address is available and CA policy allows a certificate to network address is available and CA policy allows a certificate to
contain a IPADDR-ID (as defined below) then one or more network contain a IPADDR-ID (as defined below) then one or more network
addresses can be identified in the certificate. addresses can be identified in the certificate.
This specification defines a NODE-ID of a certificate as being the This specification defines a NODE-ID of a certificate as being the
subjectAltName entry of type otherName with a name form of subjectAltName entry of type otherName with a name form of BundleEID
"bundleEID" (see Section 4.4.2.1) and a value limited to a Node ID. (see Section 4.4.2.1) and a value limited to a Node ID. An entity
An entity SHALL ignore any otherName with a name form of "bundleEID" SHALL ignore any otherName with a name form of BundleEID and a value
and a value which is some URI other than a Node ID. The NODE-ID is which is some URI other than a Node ID. The NODE-ID is similar to
similar to the URI-ID of [RFC6125] but restricted to a Node ID rather the URI-ID of [RFC6125] but restricted to a Node ID rather than a URI
than a URI with a qualified-name authority part. Unless specified with a qualified-name authority part. Unless specified otherwise by
otherwise by the definition of the URI scheme being authenticated, the definition of the URI scheme being authenticated, URI matching of
URI matching of a NODE-ID SHALL use the URI comparison logic of a NODE-ID SHALL use the URI comparison logic of [RFC3986] and scheme-
[RFC3986] and scheme-based normalization of those schemes specified based normalization of those schemes specified in
in [I-D.ietf-dtn-bpbis]. A URI scheme can refine this "exact match" [I-D.ietf-dtn-bpbis]. A URI scheme can refine this "exact match"
logic with rules about how Node IDs within that scheme are to be logic with rules about how Node IDs within that scheme are to be
compared with the certificate-authenticated NODE-ID. compared with the certificate-authenticated NODE-ID.
This specification reuses the DNS-ID definition of Section 1.8 of This specification reuses the DNS-ID definition of Section 1.8 of
[RFC6125], which is the subjectAltName entry of type dNSName whose [RFC6125], which is the subjectAltName entry of type dNSName whose
value is encoded according to [RFC5280]. value is encoded according to [RFC5280].
This specification defines a IPADDR-ID of a certificate as being the This specification defines a IPADDR-ID of a certificate as being the
subjectAltName entry of type iPAddress whose value is encoded subjectAltName entry of type iPAddress whose value is encoded
according to [RFC5280]. according to [RFC5280].
skipping to change at page 30, line 29 skipping to change at page 30, line 29
contain a NODE-ID which authenticates the Node ID of the peer. When contain a NODE-ID which authenticates the Node ID of the peer. When
assigned one or more stable DNS names, a TCPCL end-entity certificate assigned one or more stable DNS names, a TCPCL end-entity certificate
SHOULD contain DNS-ID which authenticates those (fully qualified) SHOULD contain DNS-ID which authenticates those (fully qualified)
names. When assigned one or more stable network addresses, a TCPCL names. When assigned one or more stable network addresses, a TCPCL
end-entity certificate MAY contain IPADDR-ID which authenticates end-entity certificate MAY contain IPADDR-ID which authenticates
those addresses. those addresses.
When allowed by CA policy, a BPSec end-entity certificate SHOULD When allowed by CA policy, a BPSec end-entity certificate SHOULD
contain a PKIX Extended Key Usage extension in accordance with contain a PKIX Extended Key Usage extension in accordance with
Section 4.2.1.12 of [RFC5280]. When the PKIX Extended Key Usage Section 4.2.1.12 of [RFC5280]. When the PKIX Extended Key Usage
extension is present, it SHOULD contain a key purpose "id-kp- extension is present, it SHOULD contain a key purpose id-kp-
bundleSecurity" (see Section 4.4.2.1 and Section 9.10). Although not bundleSecurity (see Section 4.4.2.1). Although not specifically
specifically required by TCPCL, some networks or TLS implementations required by TCPCL, some networks or TLS implementations assume the
assume the use of "id-kp-clientAuth" and "id-kp-serverAuth" are use of id-kp-clientAuth and id-kp-serverAuth are needed for,
needed for, respectively, the client-side and server-side of TLS respectively, the client-side and server-side of TLS authentication.
authentication. For interoperability, a TCPCL end-entity certificate For interoperability, a TCPCL end-entity certificate MAY contain an
MAY contain an Extended Key Usage with both "id-kp-clientAuth" and Extended Key Usage with both id-kp-clientAuth and id-kp-serverAuth
"id-kp-serverAuth" values. values.
When allowed by CA policy, a TCPCL end-entity certificate SHOULD When allowed by CA policy, a TCPCL end-entity certificate SHOULD
contain a PKIX Key Usage extension in accordance with Section 4.2.1.3 contain a PKIX Key Usage extension in accordance with Section 4.2.1.3
of [RFC5280]. The PKIX Key Usage bit which is consistent with TCPCL of [RFC5280]. The PKIX Key Usage bit which is consistent with TCPCL
security using TLS 1.3 is digitalSignature. The specific algorithms security using TLS 1.3 is digitalSignature. The specific algorithms
used during the TLS handshake will determine which of those key uses used during the TLS handshake will determine which of those key uses
are exercised. Earlier versions of TLS can mandate use of the bits are exercised. Earlier versions of TLS can mandate use of the bits
keyEncipherment or keyAgreement. keyEncipherment or keyAgreement.
When allowed by CA policy, a TCPCL end-entity certificate SHOULD When allowed by CA policy, a TCPCL end-entity certificate SHOULD
contain an Online Certificate Status Protocol (OCSP) URI within an contain an Online Certificate Status Protocol (OCSP) URI within an
Authority Information Access extension in accordance with Authority Information Access extension in accordance with
Section 4.2.2.1 of [RFC5280]. Section 4.2.2.1 of [RFC5280].
4.4.2.1. PKIX OID Allocations 4.4.2.1. PKIX OID Allocations
This document defines a PKIX Other Name Form identifier of "id-on- This document defines a PKIX Other Name Form identifier of id-on-
bundleEID" in Section 9.9 which can be used as the "type-id" in a bundleEID in Appendix B which can be used as the type-id in a
subjectAltName entry of type otherName. The "bundleEID" value subjectAltName entry of type otherName. The BundleEID value
associated with otherName type-id "id-on-bundleEID" SHALL be a URI, associated with otherName type-id id-on-bundleEID SHALL be a URI,
encoded as an IA5String, with a scheme which is present in the IANA encoded as an IA5String, with a scheme which is present in the IANA
"Bundle Protocol URI Scheme Type" registry [IANA-BUNDLE]. Although "Bundle Protocol URI Scheme Type" registry [IANA-BUNDLE]. Although
this otherName form allows any Endpoint ID to be present, the NODE-ID this otherName form allows any Endpoint ID to be present, the NODE-ID
defined in Section 4.4.1 limits its use to contain only a Node ID. defined in Section 4.4.1 limits its use to contain only a Node ID.
This document defines a PKIX Extended Key Usage key purpose "id-kp- This document defines a PKIX Extended Key Usage key purpose id-kp-
bundleSecurity" in Section 9.10 which can be used to restrict a bundleSecurity in Appendix B which can be used to restrict a
certificate's use. The "id-kp-bundleSecurity" purpose can be certificate's use. The id-kp-bundleSecurity purpose can be combined
combined with other purposes in the same certificate. with other purposes in the same certificate.
4.4.3. TLS Handshake 4.4.3. TLS Handshake
The use of TLS is negotiated using the Contact Header as described in The use of TLS is negotiated 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
[RFC8446]. By convention, this protocol uses the entity which [RFC8446]. By convention, this protocol uses the entity which
initiated the underlying TCP connection (the active peer) as the initiated the underlying TCP connection (the active peer) as the
"client" role of the TLS handshake request. "client" role of the TLS handshake request.
skipping to change at page 34, line 19 skipping to change at page 34, line 19
accordance with Section 6 of [RFC6125] using the Node ID of the accordance with Section 6 of [RFC6125] using the Node ID of the
peer's SESS_INIT message as the NODE-ID reference identifier. If the peer's SESS_INIT message as the NODE-ID reference identifier. If the
NODE-ID validation result is Failure or if the result is Absent and NODE-ID validation result is Failure or if the result is Absent and
security policy requires an authenticated Node ID, the entity SHALL security policy requires an authenticated Node ID, the entity SHALL
terminate the session (with a reason code of "Contact Failure"). terminate the session (with a reason code of "Contact Failure").
4.4.5. Policy Recommendations 4.4.5. Policy Recommendations
A RECOMMENDED security policy is to enable the use of OCSP checking A RECOMMENDED security policy is to enable the use of OCSP checking
during TLS handshake. A RECOMMENDED security policy is that if an during TLS handshake. A RECOMMENDED security policy is that if an
Extended Key Usage is present that it needs to contain "id-kp- Extended Key Usage is present that it needs to contain id-kp-
bundleSecurity" (of Section 4.4.4.1) to be usable with TCPCL bundleSecurity (of Section 4.4.2.1) to be usable with TCPCL security.
security. A RECOMMENDED security policy is to require a validated A RECOMMENDED security policy is to require a validated Node ID (of
Node ID (of Section 4.4.4.3) and to ignore any network-level Section 4.4.4.3) and to ignore any network-level identifier (of
identifier (of Section 4.4.4.2). Section 4.4.4.2).
This policy relies on and informs the certificate requirements in This policy relies on and informs the certificate requirements in
Section 4.4.3. This policy assumes that a DTN-aware CA (see Section 4.4.3. This policy assumes that a DTN-aware CA (see
Section 3.4) will only issue a certificate for a Node ID when it has Section 3.4) will only issue a certificate for a Node ID when it has
verified that the private key holder actually controls the DTN node; verified that the private key holder actually controls the DTN node;
this is needed to avoid the threat identified in Section 8.9. This this is needed to avoid the threat identified in Section 8.9. This
policy requires that a certificate contain a NODE-ID and allows the policy requires that a certificate contain a NODE-ID and allows the
certificate to also contain network-level identifiers. A tailored certificate to also contain network-level identifiers. A tailored
policy on a more controlled network could relax the requirement on policy on a more controlled network could relax the requirement on
Node ID validation and allow just network-level identifiers to Node ID validation and allow just network-level identifiers to
skipping to change at page 60, line 7 skipping to change at page 60, line 7
transferred is in fact the node which the BP Agent expects it to be. transferred is in fact the node which the BP Agent expects it to be.
In circumstances where certificates can only be issued to DNS names, In circumstances where certificates can only be issued to DNS names,
Node ID validation is not possible but it could be reasonable to Node ID validation is not possible but it could be reasonable to
assume that a trusted host is not going to present an invalid Node assume that a trusted host is not going to present an invalid Node
ID. Determining when a DNS-ID/IPADDR-ID authentication can be ID. Determining when a DNS-ID/IPADDR-ID authentication can be
trusted to validate a Node ID is also a policy matter outside of the trusted to validate a Node ID is also a policy matter outside of the
scope of this document. scope of this document.
One mitigation to arbitrary entities with valid PKIX certificates One mitigation to arbitrary entities with valid PKIX certificates
impersonating arbitrary Node IDs is the use of the PKIX Extended Key impersonating arbitrary Node IDs is the use of the PKIX Extended Key
Usage key purpose "id-kp-bundleSecurity" in Section 9.10. When this Usage key purpose id-kp-bundleSecurity (see Section 4.4.2.1). When
Extended Key Usage is present in the certificate, it represents a this Extended Key Usage is present in the certificate, it represents
stronger assertion that the private key holder should in fact be a stronger assertion that the private key holder should in fact be
trusted to operate as a DTN Node. trusted to operate as a DTN Node.
8.10. Threat: Denial of Service 8.10. Threat: Denial of Service
The behaviors described in this section all amount to a potential The behaviors described in this section all amount to a potential
denial-of-service to a TCPCL entity. The denial-of-service could be denial-of-service to a TCPCL entity. The denial-of-service could be
limited to an individual TCPCL session, could affect other well- limited to an individual TCPCL session, could affect other well-
behaving sessions on an entity, or could affect all sessions on a behaving sessions on an entity, or could affect all sessions on a
host. host.
skipping to change at page 69, line 23 skipping to change at page 69, line 23
+------------+--------------------------+ +------------+--------------------------+
| 0x03 | Message Unexpected | | 0x03 | Message Unexpected |
+------------+--------------------------+ +------------+--------------------------+
| 0x04--0xEF | Unassigned | | 0x04--0xEF | Unassigned |
+------------+--------------------------+ +------------+--------------------------+
| 0xF0--0xFF | Private/Experimental Use | | 0xF0--0xFF | Private/Experimental Use |
+------------+--------------------------+ +------------+--------------------------+
Table 17: MSG_REJECT Reason Codes Table 17: MSG_REJECT Reason Codes
9.9. Object Identifier for PKIX Other Name Forms 9.9. Object Identifier for PKIX Module Identifier
IANA has created, under the "Structure of Management Information
(SMI) Numbers" registry [IANA-SMI], a sub-registry titled "SMI
Security for PKIX Module Identifier". The table is updated to
include a row "id-mod-dtn-tcpclv4-2021" for identifying the module in
Appendix B as in the following table.
+=========+=========================+=====================+
| Decimal | Description | References |
+=========+=========================+=====================+
| MOD-TBD | id-mod-dtn-tcpclv4-2021 | This specification. |
+---------+-------------------------+---------------------+
Table 18
9.10. Object Identifier for PKIX Other Name Forms
IANA has created, under the "Structure of Management Information IANA has created, under the "Structure of Management Information
(SMI) Numbers" registry [IANA-SMI], a sub-registry titled "SMI (SMI) Numbers" registry [IANA-SMI], a sub-registry titled "SMI
Security for PKIX Other Name Forms". The other name forms table is Security for PKIX Other Name Forms". The other name forms table is
updated to include a row "id-on-bundleEID" for identifying DTN updated to include a row "id-on-bundleEID" for identifying DTN
Endpoint IDs as in the following table. Endpoint IDs as in the following table.
+=========+=================+=====================+ +=========+=================+=====================+
| Decimal | Description | References | | Decimal | Description | References |
+=========+=================+=====================+ +=========+=================+=====================+
| ON-TBD | id-on-bundleEID | This specification. | | ON-TBD | id-on-bundleEID | This specification. |
+---------+-----------------+---------------------+ +---------+-----------------+---------------------+
Table 18 Table 19
This also corresponds with the following SMI, in ASN.1 syntax of
[X.680], for that otherName type-id and value:
<CODE BEGINS>
-- The otherName type-value sequence
bundleEID OTHER-NAME ::= { BundleEID IDENTIFIED BY { id-on-bundleEID }}
id-on-bundleEID OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) on(8) ON-TBD }
-- Same encoding as GeneralName of uniformResourceIdentifier The formal structure of the associated other name form is in
BundleEID ::= IA5String Appendix B. The use of this OID is defined in Section 4.4.1 and
<CODE ENDS> Section 4.4.2.
The use of this OID is defined in Section 4.4.1 and Section 4.4.2.
9.10. Object Identifier for PKIX Extended Key Usage 9.11. Object Identifier for PKIX Extended Key Usage
IANA has created, under the "Structure of Management Information IANA has created, under the "Structure of Management Information
(SMI) Numbers" registry [IANA-SMI], a sub-registry titled "SMI (SMI) Numbers" registry [IANA-SMI], a sub-registry titled "SMI
Security for PKIX Extended Key Purpose". The extended key purpose Security for PKIX Extended Key Purpose". The extended key purpose
table is updated to include a purpose "id-kp-bundleSecurity" for table is updated to include a purpose "id-kp-bundleSecurity" for
identifying DTN endpoints as in the following table. identifying DTN endpoints as in the following table.
+=========+======================+=====================+ +=========+======================+=====================+
| Decimal | Description | References | | Decimal | Description | References |
+=========+======================+=====================+ +=========+======================+=====================+
| KP-TBD | id-kp-bundleSecurity | This specification. | | KP-TBD | id-kp-bundleSecurity | This specification. |
+---------+----------------------+---------------------+ +---------+----------------------+---------------------+
Table 19 Table 20
This also corresponds with the following SMI, in ASN.1 syntax of
[X.680], for that key purpose:
<CODE BEGINS>
id-kp-bundleSecurity OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) kp(3) KP-TBD }
<CODE ENDS>
The use of this OID is defined in Section 4.4.2. The formal definition of this EKU is in Appendix B. The use of this
OID is defined in Section 4.4.2.
10. Acknowledgments 10. Acknowledgments
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
skipping to change at page 73, line 20 skipping to change at page 73, line 20
[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>.
[RFC5489] Badra, M. and I. Hajjeh, "ECDHE_PSK Cipher Suites for [RFC5489] Badra, M. and I. Hajjeh, "ECDHE_PSK Cipher Suites for
Transport Layer Security (TLS)", RFC 5489, Transport Layer Security (TLS)", RFC 5489,
DOI 10.17487/RFC5489, March 2009, DOI 10.17487/RFC5489, March 2009,
<https://www.rfc-editor.org/info/rfc5489>. <https://www.rfc-editor.org/info/rfc5489>.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
DOI 10.17487/RFC5912, June 2010,
<https://www.rfc-editor.org/info/rfc5912>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <https://www.rfc-editor.org/info/rfc6698>. 2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC7122] Kruse, H., Jero, S., and S. Ostermann, "Datagram [RFC7122] Kruse, H., Jero, S., and S. Ostermann, "Datagram
Convergence Layers for the Delay- and Disruption-Tolerant Convergence Layers for the Delay- and Disruption-Tolerant
Networking (DTN) Bundle Protocol and Licklider Networking (DTN) Bundle Protocol and Licklider
Transmission Protocol (LTP)", RFC 7122, Transmission Protocol (LTP)", RFC 7122,
DOI 10.17487/RFC7122, March 2014, DOI 10.17487/RFC7122, March 2014,
skipping to change at page 75, line 47 skipping to change at page 76, line 5
* Added MSG_REJECT message to indicate an unknown or unhandled * Added MSG_REJECT message to indicate an unknown or unhandled
message was received. message was received.
* Added TLS connection security mechanism. * Added TLS connection security mechanism.
* Added "Not Acceptable", "Extension Failure", and "Session * Added "Not Acceptable", "Extension Failure", and "Session
Terminating" XFER_REFUSE reason codes. Terminating" XFER_REFUSE reason codes.
* Added "Resource Exhaustion" SESS_TERM reason code. * Added "Resource Exhaustion" SESS_TERM reason code.
Appendix B. Example of bundleEID Other Name Form Appendix B. ASN.1 Module
The following ASN.1 module formally specifies the BundleEID
structure, its Other Name form, and the bundleSecurity Extended Key
Usage in the syntax of [X.680]. This specification uses the ASN.1
definitions from [RFC5912] with the 2002 ASN.1 notation used in that
document.
<CODE BEGINS>
DTN-TCPCLPv4-2021
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-dtn-tcpclv4-2021(MOD-TBD) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
OTHER-NAME
FROM PKIX1Implicit-2009 -- [RFC5912]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-implicit-02(59) }
id-pkix
FROM PKIX1Explicit-2009 -- [RFC5912]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-explicit-02(51) } ;
id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
DTNOtherNames OTHER-NAME ::= { on-bundleEID, ... }
-- The otherName definition for Bundle EID
on-bundleEID OTHER-NAME ::= {
BundleEID IDENTIFIED BY { id-on-bundleEID }
}
id-on-bundleEID OBJECT IDENTIFIER ::= { id-on ON-TBD }
-- Same encoding as GeneralName of uniformResourceIdentifier
BundleEID ::= IA5String
-- The Extended Key Usage key for bundle security
id-kp-bundleSecurity OBJECT IDENTIFIER ::= { id-kp KP-TBD }
END
<CODE ENDS>
Appendix C. Example of the BundleEID Other Name Form
EDITOR NOTE: The encoded hex part "0b" and OID segment "11" are to be EDITOR NOTE: The encoded hex part "0b" and OID segment "11" are to be
replaced by ON-TBD allocated value. It was necessary to choose some replaced by ON-TBD allocated value. It was necessary to choose some
OID value, so I chose the first not-allocated code point. OID value, so I chose the first not-allocated code point.
This non-normative example demonstrates an otherName with a name form This non-normative example demonstrates an otherName with a name form
of "bundleEID" to encode the Node ID "dtn://example/". of BundleEID to encode the Node ID "dtn://example/".
The hexadecimal form of the DER encoding of the otherName is: The hexadecimal form of the DER encoding of the otherName is:
a01c06082b0601050507080ba010160e64746e3a2f2f6578616d706c652f a01c06082b0601050507080ba010160e64746e3a2f2f6578616d706c652f
And the text decoding in Figure 28 is an output of Peter Gutmann's And the text decoding in Figure 28 is an output of Peter Gutmann's
"dumpasn1" program. "dumpasn1" program.
0 28: [0] { 0 28: [0] {
2 8: OBJECT IDENTIFIER '1 3 6 1 5 5 7 8 11' 2 8: OBJECT IDENTIFIER '1 3 6 1 5 5 7 8 11'
12 16: [0] { 12 16: [0] {
14 14: IA5String 'dtn://example/' 14 14: IA5String 'dtn://example/'
: } : }
: } : }
Figure 28: Visualized decoding of the bundleEID Figure 28: Visualized decoding of the on-bundleEID
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
United States of America United States of America
Email: BSipos@rkf-eng.com Email: brian.sipos+ietf@gmail.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
United States of America 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
FI-02015 Aalto FI-02015 Aalto
Finland Finland
Email: ott@in.tum.de Email: ott@in.tum.de
Simon Perreault Simon Perreault
Quebec QC Quebec QC
Canada Canada
Email: simon@per.reau.lt Email: simon@per.reau.lt
 End of changes. 25 change blocks. 
76 lines changed or deleted 131 lines changed or added

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