diff options
Diffstat (limited to 'doc/rfc/rfc6260.txt')
| -rw-r--r-- | doc/rfc/rfc6260.txt | 675 |
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc6260.txt b/doc/rfc/rfc6260.txt new file mode 100644 index 0000000..042aadb --- /dev/null +++ b/doc/rfc/rfc6260.txt @@ -0,0 +1,675 @@ + + + + + + +Internet Research Task Force (IRTF) S. Burleigh +Request for Comments: 6260 Jet Propulsion Laboratory, +Category: Experimental California Institute of Technology +ISSN: 2070-1721 May 2011 + + + Compressed Bundle Header Encoding (CBHE) + +Abstract + + This document describes a convention by which Delay-Tolerant + Networking (DTN) Bundle Protocol (BP) "convergence-layer" adapters + may represent endpoint identifiers in a compressed form within the + primary blocks of bundles, provided those endpoint identifiers + conform to the structure prescribed by this convention. + + Compressed Bundle Header Encoding (CBHE) compression is a + convergence-layer adaptation. It is opaque to bundle processing. + Therefore, it has no impact on the interoperability of different + Bundle Protocol implementations, but instead affects only the + interoperability of different convergence-layer adaptation + implementations. + + This document is a product of the Delay-Tolerant Networking Research + Group and has been reviewed by that group. No objections to its + publication as an RFC were raised. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Research Task + Force (IRTF). The IRTF publishes the results of Internet-related + research and development activities. These results might not be + suitable for deployment. This RFC represents the consensus of the + Delay-Tolerant Networking Research Group of the Internet Research + Task Force (IRTF). Documents approved for publication by the IRSG + are not a candidate for any level of Internet Standard; see Section 2 + of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6260. + + + + + +Burleigh Experimental [Page 1] + +RFC 6260 CBHE May 2011 + + +Copyright Notice + + Copyright (c) 2011 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 + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. Requirements Language ......................................3 + 2. Compression Convention ..........................................3 + 2.1. Constraints ................................................3 + 2.2. Method .....................................................6 + 3. Specification ...................................................7 + 3.1. Transmission ...............................................7 + 3.2. Reception ..................................................7 + 4. IANA Considerations .............................................8 + 5. Security Considerations ........................................10 + 6. References .....................................................11 + 6.1. Normative References ......................................11 + 6.2. Informative References ....................................11 + Appendix A. Acknowledgments .......................................12 + +1. Introduction + + This document describes a convention by which Delay-Tolerant + Networking (DTN) Bundle Protocol (BP) [RFC5050] "convergence-layer" + adapters may represent endpoint identifiers (EIDs) in a compressed + form within the primary blocks of bundles, provided those endpoint + identifiers conform to the structure prescribed by this convention. + + Each DTN bundle's primary block contains the following four BP + endpoint identifiers, of which any two, any three, or even all four + may be lexically identical: the endpoint identifiers of the bundle's + source, destination, report-to endpoint, and current custodian. Each + EID is a Uniform Record Identifier (URI) as defined by [RFC3986]. + More specifically, each BP EID is a URI consisting of a "scheme name" + followed by ":", followed by a sequence of characters -- + historically, termed the "scheme-specific part" (SSP) in DTN + specifications -- conforming to URI syntax as defined by RFC 3986. + + + + + +Burleigh Experimental [Page 2] + +RFC 6260 CBHE May 2011 + + + A degree of block compression is provided by the design of the + primary block: the scheme names and scheme-specific parts of the four + endpoints' IDs -- up to eight NULL-terminated strings -- are + concatenated at the end of the block in a variable-length character + array called a "dictionary", enabling each EID to be represented by a + pair of integers indicating the offsets (within the dictionary) of + the EID's scheme name and scheme-specific part. Duplicate strings + may be omitted from the dictionary, so the actual number of + concatenated NULL-terminated strings in the dictionary may be less + than eight, and two or more of the scheme name or scheme-specific + part offsets in the block may have the same value. Moreover, the + eight offsets in the primary block are encoded as Self-Delimiting + Numeric Values (SDNVs), which shrink to fit the encoded values; when + the total length of the dictionary is less than 127 bytes, all eight + offsets can be encoded into just eight bytes. + + However, these strategems do not prevent the scheme names and + especially the scheme-specific parts themselves from being lengthy + strings of ASCII text. It is therefore still possible for the length + of a bundle's primary header to be a very large fraction of the total + length of the bundle when the bundle's payload is relatively small, + as is anticipated for a number of DTN applications such as space + flight operations (and as is in any case true of bundles carrying BP + administrative records). + + The Compressed Bundle Header Encoding (CBHE) convention was developed + to improve DTN transmission efficiency for such applications by + further reducing the number of bytes used by convergence-layer + adapters to represent EIDs in the primary blocks of bundles. + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +2. Compression Convention + +2.1. Constraints + + The only valid scheme name for BP EIDs identified to date is "dtn". + Although no specification of valid SSP syntax for URIs composed + within the "dtn" scheme has yet been formally defined, the syntax on + which rough agreement has been reached in practice is unsuitable for + CBHE's compression procedures. For the purposes of CBHE, then, this + document defines an additional URI scheme named "ipn". As noted in + Section 4, IANA has registered this new URI scheme. + + + + +Burleigh Experimental [Page 3] + +RFC 6260 CBHE May 2011 + + + Compressed Bundle Header Encoding (CBHE) is possible only when all + endpoint IDs in the primary block of a given bundle are "CBHE + conformant". The following two forms of endpoint ID are CBHE + conformant: (a) the null endpoint ID "dtn:none" and (b) any endpoint + ID formed within the "ipn" scheme. + + The SSP of every URI formed within the "ipn" scheme must comprise: + + 1. A sequence of ASCII numeric digits representing an integer in the + range 1 to (2^64 - 1), termed the "node number" of the URI. + + 2. An ASCII period ('.') character. + + 3. A sequence of ASCII numeric digits representing an integer in the + range 0 to (2^64 - 1), termed the "service number" of the URI. + + The node number notionally identifies a BP node. However, since CBHE + is not used universally in Delay-Tolerant Networking, it must not be + assumed that all BP nodes are identified by node numbers. + + Negative integers and integers larger than (2^64 - 1) cannot be used + as node numbers because they cannot be encoded into the SDNVs that + are used for representation of scheme name and SSP offsets in the + primary blocks of bundles and therefore could not be compressed as + described later in this specification. Node number zero is reserved + for representation of the null endpoint ID in the compressed form + described later; decompressing a compressed null EID must always + yield the standard null endpoint ID URI "dtn:none". + + The service number notionally functions as a de-multiplexing token. + When the bundle payload is a protocol data unit of some protocol that + has its own de-multiplexing identifiers, the service number may + function in a manner similar to that of the protocol number in an IP + packet, characterizing the encapsulated protocol; alternatively, the + service number may function in a manner similar to that of the port + number in a UDP datagram. Service numbers enable inbound bundles' + application data units to be de-multiplexed to instances of + application functionality that are designed to process them, so that + effective communication relationships can be developed between bundle + producers and consumers. + + A service number must not be negative or exceed (2^64 - 1) for the + same reason that a node number must not do so. + + For example, "ipn:9.37" would be a CBHE-conformant endpoint ID. + + + + + + +Burleigh Experimental [Page 4] + +RFC 6260 CBHE May 2011 + + + Conversion of a CBHE-conformant EID to and from a tuple of two + integers is therefore straightforward: all characters in the EID + other than the node number and service number are constant (as + defined by the "ipn" scheme definition), and the node number and + service number are taken as the two integers of the tuple. This ease + of conversion enables an array of pairs of integers to serve the same + function as a dictionary of ASCII string EIDs. + + Note, however, that CBHE decompression cannot faithfully recreate the + dictionary of a compressed primary block from an array of integer + pairs unless the order of the scheme names and scheme-specific part + strings in the dictionary of the original, uncompressed block is + known. (The Bundle Protocol Specification does not require that the + strings in the dictionary appear in any particular order and does not + require that redundant strings be omitted from the dictionary.) + Therefore, a further precondition to CBHE compression is that the + strings in the dictionary of the bundle to be compressed must be + exactly as follows, in this order and without addition: + + 1. The scheme name of the destination endpoint ID. + + 2. The scheme-specific part of the destination endpoint ID. + + 3. The scheme name of the source endpoint ID, if and only if + different from any prior string in the dictionary. + + 4. The scheme-specific part of the source endpoint ID, if and only + if different from any prior string in the dictionary. + + 5. The scheme name of the report-to endpoint ID, if and only if + different from any prior string in the dictionary. + + 6. The scheme-specific part of the report-to endpoint ID, if and + only if different from any prior string in the dictionary. + + 7. The scheme name of the current custodian endpoint ID, if and only + if different from any prior string in the dictionary. + + 8. The scheme-specific part of the current custodian endpoint ID, if + and only if different from any prior string in the dictionary. + + Note: this constraint implies that a bundle that includes any + extension blocks containing EID-references to endpoint IDs other than + the block's destination, source, report-to, and current custodian + cannot be CBHE compressed since such compression would result in a + dictionary that would deviate from this structure. + + + + + +Burleigh Experimental [Page 5] + +RFC 6260 CBHE May 2011 + + +2.2. Method + + When the constraints enumerated above are met, the CBHE block + compression method can be applied by the convergence-layer adapter + (CLA) at the time the bundle is transmitted via a convergence-layer + protocol. In a CBHE-compressed primary block, the eight SDNVs that + normally contain EIDs' scheme name and SSP offsets within the + dictionary are instead used to contain the eight integer values + listed below, in the order shown: + + 1. The node number of the destination endpoint ID, or zero if the + destination endpoint is the null endpoint. + + 2. The service number of the destination endpoint ID, or zero if the + destination endpoint is the null endpoint. + + 3. The node number of the source endpoint ID, or zero if the source + endpoint is the null endpoint. + + 4. The service number of the source endpoint ID, or zero if the + source endpoint is the null endpoint. + + 5. The node number of the report-to endpoint ID, or zero if the + report-to endpoint is the null endpoint. + + 6. The service number of the report-to endpoint ID, or zero if the + report-to endpoint is the null endpoint. + + 7. The node number of the current custodian endpoint ID, or zero if + the current custodian endpoint is the null endpoint. + + 8. The service number of the current custodian endpoint ID, or zero + if the current custodian endpoint is the null endpoint. + + Further, the dictionary is omitted from the primary block and the + primary block's dictionary length is set to zero. + + Upon reception, the receiving convergence-layer adaptation de- + compresses the block by simply reversing the process so that the + bundle presented to the bundle protocol agent has the standard form + (i.e., the dictionary is reconstituted). + + + + + + + + + + +Burleigh Experimental [Page 6] + +RFC 6260 CBHE May 2011 + + +3. Specification + + CBHE compression is a convergence-layer adaptation. It is opaque to + bundle processing. Therefore, it has no impact on the + interoperability of different Bundle Protocol implementations, but + instead affects only the interoperability of different convergence- + layer adaptation implementations. + + Bundle Protocol convergence-layer adapters that conform to the CBHE + specification must implement the following procedures. + +3.1. Transmission + + When and only when required by the bundle protocol agent to transmit + a bundle whose primary block's endpoint IDs satisfy the constraints + identified in Section 2.1, the CLA MAY encode the primary block of + the bundle in accordance with the CBHE compression convention + described in Section 2.2 UNLESS the CLA to which the bundle is to be + transmitted is known not to be CBHE conformant. Note that CBHE + compression may be applied only if the receiving CLA is known or + presumed to be CBHE conformant, i.e., able to decode the encoded + primary block. Knowledge as to whether or not a receiving CLA is (or + might be) CBHE conformant may be asserted by node administration + and/or may be inferred from reception of a CBHE-compressed bundle as + noted in Section 3.2. + +3.2. Reception + + Upon receiving a bundle whose dictionary length is zero (and only in + this circumstance), a CBHE-conformant convergence-layer adapter: + + 1. MAY infer that the CLA from which the bundle was received is CBHE + conformant. + + 2. MUST decode the primary block of the bundle in accordance with + the CBHE compression convention described in Section 2.2 before + delivering it to the bundle protocol agent. + + Note that when a CLA that is not CBHE conformant receives a bundle + whose dictionary length is zero, it has no choice but to pass it to + the bundle agent without modification. In this case, the bundle + protocol agent will be unable to dispatch the received bundle, + because it will be unable to determine the destination endpoint; the + bundle will be judged to be malformed. The behavior of the bundle + protocol agent in this circumstance is an implementation matter. + + + + + + +Burleigh Experimental [Page 7] + +RFC 6260 CBHE May 2011 + + +4. IANA Considerations + + IANA has registered a provisional registration (per [RFC4395]) for a + URI scheme for CBHE, with the string "ipn" as the scheme name, as + follows: + + URI scheme name: "ipn" + + Status: provisional + + URI scheme syntax: + + This specification uses the Augmented Backus-Naur Form (ABNF) + notation of [RFC5234], including the core ABNF syntax rule for DIGIT + defined by that specification. + + ipn-uri = "ipn:" ipn-hier-part + ipn-hier-part = node-nbr nbr-delim service-nbr ; a path-rootless + node-nbr = 1*DIGIT + nbr-delim = "." + service-nbr = 1*DIGIT + + None of the reserved characters defined in the generic URI syntax are + used as delimiters within URIs of the IPN scheme. + + URI scheme semantics: URIs of the IPN scheme are used as endpoint + identifiers in the Delay-Tolerant Networking (DTN) Bundle Protocol + (BP) [RFC5050] as described in Section 2.1. + + Encoding considerations: URIs of the IPN scheme are encoded + exclusively in US-ASCII characters. + + Applications and/or protocols that use this URI scheme name: the + Delay-Tolerant Networking (DTN) Bundle Protocol (BP) [RFC5050]. + + Interoperability considerations: as noted above, URIs of the IPN + scheme are encoded exclusively in US-ASCII characters. + + Security considerations: + + o Reliability and consistency: none of the BP endpoints identified + by the URIs of the IPN scheme are guaranteed to be reachable at + any time, and the identity of the processing entities operating on + those endpoints is never guaranteed by the Bundle Protocol itself. + Bundle authentication as defined by the Bundle Security Protocol + is required for this purpose. + + + + + +Burleigh Experimental [Page 8] + +RFC 6260 CBHE May 2011 + + + o Malicious construction: malicious construction of a conformant + IPN-scheme URI is limited to the malicious selection of node + numbers and the malicious selection of service numbers. That is, + a maliciously constructed IPN-scheme URI could be used to direct a + bundle to an endpoint that might be damaged by the arrival of that + bundle or, alternatively, to declare a false source for a bundle + and thereby cause incorrect processing at a node that receives the + bundle. In both cases (and indeed in all bundle processing), the + node that receives a bundle should verify its authenticity and + validity before operating on it in any way. + + o Back-end transcoding: the limited expressiveness of URIs of the + IPN scheme effectively eliminates the possibility of threat due to + errors in back-end transcoding. + + o Rare IP address formats: not relevant, as IP addresses do not + appear anywhere in conformant IPN-scheme URIs. + + o Sensitive information: because IPN-scheme URIs are used only to + represent the identities of Bundle Protocol endpoints, the risk of + disclosure of sensitive information due to interception of these + URIs is minimal. Examination of IPN-scheme URIs could be used to + support traffic analysis; where traffic analysis is a plausible + danger, bundles should be conveyed by secure convergence-layer + protocols that do not expose endpoint IDs. + + o Semantic attacks: the simplicity of IPN-scheme URI syntax + minimizes the possibility of misinterpretation of a URI by a human + user. + + Contact: + Scott Burleigh + Jet Propulsion Laboratory, + California Institute of Technology + scott.c.burleigh@jpl.nasa.gov + +1 (800) 393-3353 + + Author/Change controller: + Scott Burleigh + Jet Propulsion Laboratory, + California Institute of Technology + scott.c.burleigh@jpl.nasa.gov + +1 (800) 393-3353 + + References: S. Burleigh, "Compressed Bundle Header Encoding (CBHE)", + RFC 6260, May 2011. + + + + + +Burleigh Experimental [Page 9] + +RFC 6260 CBHE May 2011 + + +5. Security Considerations + + The Bundle Security Protocol (BSP) may, under some conditions, insert + additional endpoint ID strings into the dictionary of a bundle and + reference those strings in BSP extension blocks. Because a bundle + that includes any extension blocks containing EID-references to + endpoint IDs other than the block's destination, source, report-to, + and current custodian cannot be CBHE compressed, bundles cannot be + compressed under those conditions. + + Specifically, the specification detailed above implies that a bundle + cannot be CBHE compressed when the security-source endpoint for the + Bundle Authentication Block (BAB) is noted in the dictionary + (typically, because there is no other way for the receiving bundle + protocol agent to determine the security-source endpoint); when the + security-destination endpoint for the BAB is noted in the dictionary + (in the rare case that the receiving endpoint is not the security- + destination endpoint); when the security-source endpoint for the + Payload Integrity Block (PIB), Payload Confidentiality Block (PCB), + or Extension Security Block (ESB) is not the source endpoint; or when + the security-destination endpoint for the PIB, PCB, or ESB is not the + destination endpoint. + + Also, the CBHE-conformance inference mechanism identified in + Section 3.2 introduces a possible denial-of-service attack. + Malicious code could issue a CHBE-compressed bundle whose source EID + falsely identifies the bundle origin as some node whose CLA is not + CBHE conformant; a CBHE-conformant CLA receiving this bundle might + incorrectly infer that the CLA at the purported source node was CBHE + conformant and might then begin CBHE compressing all bundles that it + sends to that node, thus preventing those bundles from being + dispatched by the node's bundle protocol agent. Nodes can defend + against such an attack by requiring Bundle Authentication Blocks and + discarding any inference of CBHE conformance for the CLAs at nodes + from which inauthentic bundles are received. + + These caveats aside, CBHE introduces no new security considerations + beyond those discussed in the DTN Bundle Protocol RFC 5050 [RFC5050] + and Bundle Security Protocol RFC 6257 [RFC6257] Specifications. + + + + + + + + + + + + +Burleigh Experimental [Page 10] + +RFC 6260 CBHE May 2011 + + +6. References + +6.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, January 2005. + + [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol + Specification", RFC 5050, November 2007. + + [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, January 2008. + + [RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, + "Bundle Security Protocol Specification", RFC 6257, + May 2011. + +6.2. Informative References + + [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and + Registration Procedures for New URI Schemes", BCP 35, + RFC 4395, February 2006. + + + + + + + + + + + + + + + + + + + + + + + + + +Burleigh Experimental [Page 11] + +RFC 6260 CBHE May 2011 + + +Appendix A. Acknowledgments + + This research was carried out at the Jet Propulsion Laboratory, + California Institute of Technology, under a contract with the + National Aeronautics and Space Administration. Government + sponsorship acknowledged. + +Author's Address + + Scott Burleigh + Jet Propulsion Laboratory, California Institute of Technology + 4800 Oak Grove Drive, m/s 301-490 + Pasadena, CA 91109 + USA + + Phone: +1 818 393 3353 + EMail: Scott.C.Burleigh@jpl.nasa.gov + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Burleigh Experimental [Page 12] + |