idnits 2.17.1 draft-irtf-dtnrg-cbhe-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 28, 2011) is 4806 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Burleigh 3 Internet-Draft Jet Propulsion Laboratory, 4 Intended status: Experimental California Institute of 5 Expires: September 1, 2011 Technology 6 February 28, 2011 8 Compressed Bundle Header Encoding (CBHE) 9 draft-irtf-dtnrg-cbhe-09 11 Abstract 13 This document describes a convention by which Delay-Tolerant 14 Networking (DTN) Bundle Protocol (BP) "convergence-layer" adapters 15 may represent endpoint identifiers in a compressed form within the 16 primary blocks of bundles, provided those endpoint identifiers 17 conform to the structure prescribed by this convention. 19 CBHE compression is a convergence-layer adaptation. It is opaque to 20 bundle processing. It therefore has no impact on the 21 interoperability of different Bundle Protocol implementations, but 22 instead affects only the interoperability of different convergence 23 layer adaptation implementations. 25 This document is a product of the Delay Tolerant Networking Research 26 Group and has been reviewed by that group. No objections to its 27 publication as an RFC were raised. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on September 1, 2011. 51 Copyright Notice 53 Copyright (c) 2011 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Compression convention . . . . . . . . . . . . . . . . . . . . 5 70 2.1. Constraints . . . . . . . . . . . . . . . . . . . . . . . 5 71 2.2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 8 73 3.1. Transmission . . . . . . . . . . . . . . . . . . . . . . . 8 74 3.2. Reception . . . . . . . . . . . . . . . . . . . . . . . . 8 75 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 77 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 79 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 This document describes a convention by which Delay-Tolerant 85 Networking (DTN) Bundle Protocol (BP) [RFC5050] "convergence-layer 86 adapters" may represent endpoint identifiers in a compressed form 87 within the primary blocks of bundles, provided those endpoint 88 identifiers conform to the structure prescribed by this convention. 90 Each DTN bundle's primary block contains the following four BP 91 endpoint identifiers (EIDs), of which any two, any three, or even all 92 four may be lexically identical: the endpoint identifiers of the 93 bundle's source, destination, report-to endpoint, and current 94 custodian. Each EID is a Uniform Record Identifier (URI) as defined 95 by [RFC3986]. More specifically, each BP EID is a URI consisting of 96 a "scheme name" followed by ":", followed by a sequence of characters 97 - historically termed the "scheme-specific part" (SSP) in DTN 98 specifications - conforming to URI syntax as defined by RFC3986. 100 A degree of block compression is provided by the design of the 101 primary block: the scheme names and scheme-specific parts of the four 102 endpoints' IDs - up to eight NULL-terminated strings - are 103 concatenated at the end of the block in a variable-length character 104 array called a "dictionary", enabling each EID to be represented by a 105 pair of integers indicating the offsets (within the dictionary) of 106 the EID's scheme name and scheme-specific part. Duplicate strings 107 may be omitted from the dictionary, so the actual number of 108 concatenated NULL-terminated strings in the dictionary may be less 109 than eight, and two or more of the scheme name or scheme-specific 110 part offsets in the block may have the same value. Moreover, the 111 eight offsets in the primary block are encoded as self-delimiting 112 numeric values (SDNVs), which shrink to fit the encoded values; when 113 the total length of the dictionary is less than 127 bytes, all eight 114 offsets can be encoded into just eight bytes. 116 However, these strategems do not prevent the scheme names and 117 especially the scheme-specific parts themselves from being lengthy 118 strings of ASCII text. It is therefore still possible for the length 119 of a bundle's primary header to be a very large fraction of the total 120 length of the bundle when the bundle's payload is relatively small, 121 as is anticipated for a number of DTN applications such as space 122 flight operations (and as is in any case true of bundles carrying BP 123 administrative records). 125 The Compressed Bundle Header Encoding (CBHE) convention was developed 126 to improve DTN transmission efficiency for such applications by 127 further reducing the number of bytes used by convergence-layer 128 adapters to represent EIDs in the primary blocks of bundles. 130 2. Compression convention 132 2.1. Constraints 134 The only valid scheme name for BP EIDs identified to date is "dtn". 135 Although no specification of valid SSP syntax for URIs composed 136 within the "dtn" scheme has yet been formally defined, the syntax on 137 which rough agreement has been reached in practice is unsuitable for 138 CBHE's compression procedures. For the purposes of CBHE, then, this 139 document defines an additional URI scheme named "ipn". As noted in 140 Section 4 below, IANA registration is requested for this new URI 141 scheme. 143 Compressed Bundle Header Encoding (CBHE) is possible only when all 144 endpoint IDs in the primary block of a given bundle are "CBHE- 145 conformant". The following two forms of endpoint ID are CBHE- 146 conformant: (a) the null endpoint ID "dtn:none" and (b) any endpoint 147 ID formed within the "ipn" scheme. 149 The SSP of every URI formed within the "ipn" scheme must comprise: 151 1. A sequence of ASCII numeric digits representing an integer in the 152 range 1 to (2^64 - 1), termed the "node number" of the URI. 154 2. An ASCII period ('.') character. 156 3. A sequence of ASCII numeric digits representing an integer in the 157 range 0 to (2^64 - 1), termed the "service number" of the URI. 159 The node number notionally identifies a BP node. However, since CBHE 160 is not used universally in delay-tolerant networking it must not be 161 assumed that all BP nodes are identified by node numbers. 163 Negative integers and integers larger than (2^64 - 1) cannot be used 164 as node numbers because they cannot be encoded into the SDNVs that 165 are used for representation of scheme name and SSP offsets in the 166 primary blocks of bundles and therefore could not be compressed as 167 described later in this specification. Node number zero is reserved 168 for representation of the null endpoint ID in the compressed form 169 described later; decompressing a compressed null EID must always 170 yield the standard null endpoint ID URI "dtn:none". 172 The service number notionally functions as a de-multiplexing token. 173 When the bundle payload is a protocol data unit of some protocol that 174 has its own de-multiplexing identifiers, the service number may 175 function in a manner similar to that of the protocol number in an IP 176 packet, characterizing the encapsulated protocol; alternatively, the 177 service number may function in a manner similar to that of the port 178 number in a UDP datagram. Service numbers enable inbound bundles' 179 application data units to be de-multiplexed to instances of 180 application functionality that are designed to process them, so that 181 effective communication relationships can be developed between bundle 182 producers and consumers. 184 Service number must not be negative or exceed (2^64 - 1) for the same 185 reason that node number must not do so. 187 For example, "ipn:9.37" would be a CBHE-conformant endpoint ID. 189 Conversion of a CBHE-conformant EID to and from a tuple of two 190 integers is therefore straightforward: all characters in the EID 191 other than the node number and service number are constant (as 192 defined by the "ipn" scheme definition) and the node number and 193 service number are taken as the two integers of the tuple. This ease 194 of conversion enables an array of pairs of integers to serve the same 195 function as a dictionary of ASCII string EIDs. 197 Note, however, that CBHE decompression cannot faithfully recreate the 198 dictionary of a compressed primary block from an array of integer 199 pairs unless the order of the scheme names and scheme-specific part 200 strings in the dictionary of the original, uncompressed block is 201 known. (The bundle protocol specification does not require that the 202 strings in the dictionary appear in any particular order and does not 203 require that redundant strings be omitted from the dictionary.) 204 Therefore, a further precondition to CBHE compression is that the 205 strings in the dictionary of the bundle to be compressed must be 206 exactly as follows, in this order and without addition: 208 1. The scheme name of the destination endpoint ID. 210 2. The scheme-specific part of the destination endpoint ID. 212 3. The scheme name of the source endpoint ID, if and only if 213 different from any prior string in the dictionary. 215 4. The scheme-specific part of the source endpoint ID, if and only 216 if different from any prior string in the dictionary. 218 5. The scheme name of the report-to endpoint ID, if and only if 219 different from any prior string in the dictionary. 221 6. The scheme-specific part of the report-to endpoint ID, if and 222 only if different from any prior string in the dictionary. 224 7. The scheme name of the current custodian endpoint ID, if and only 225 if different from any prior string in the dictionary. 227 8. The scheme-specific part of the current custodian endpoint ID, if 228 and only if different from any prior string in the dictionary. 230 Note: this constraint implies that a bundle which includes any 231 extension blocks containing EID references to endpoint IDs other than 232 the block's destination, source, report-to, and current custodian 233 cannot be CBHE-compressed since such compression would result in a 234 dictionary that would deviate from this structure. 236 2.2. Method 238 When the constraints enumerated above are met, the CBHE block 239 compression method can be applied by the convergence layer adapter 240 (CLA) at the time the bundle is transmitted via a convergence-layer 241 protocol. In a CBHE-compressed primary block, the eight SDNVs that 242 normally contain EIDs' scheme name and SSP offsets within the 243 dictionary are instead used to contain the eight integer values 244 listed below, in the order shown: 246 1. The node number of the destination endpoint ID, or zero if the 247 destination endpoint is the null endpoint. 249 2. The service number of the destination endpoint ID, or zero if the 250 destination endpoint is the null endpoint. 252 3. The node number of the source endpoint ID, or zero if the source 253 endpoint is the null endpoint. 255 4. The service number of the source endpoint ID, or zero if the 256 source endpoint is the null endpoint. 258 5. The node number of the report-to endpoint ID, or zero if the 259 report-to endpoint is the null endpoint. 261 6. The service number of the report-to endpoint ID, or zero if the 262 report-to endpoint is the null endpoint. 264 7. The node number of the current custodian endpoint ID, or zero if 265 the current custodian endpoint is the null endpoint. 267 8. The service number of the current custodian endpoint ID, or zero 268 if the current custodian endpoint is the null endpoint. 270 Further, the dictionary is omitted from the primary block and the 271 primary block's dictionary length is set to zero. 273 Upon reception the receiving convergence-layer adaptation de- 274 compresses the block by simply reversing the process so that the 275 bundle presented to the bundle protocol agent has the standard form 276 (i.e., the dictionary is reconstituted). 278 3. Specification 280 CBHE compression is a convergence-layer adaptation. It is opaque to 281 bundle processing. It therefore has no impact on the 282 interoperability of different Bundle Protocol implementations, but 283 instead affects only the interoperability of different convergence 284 layer adaptation implementations. 286 Bundle Protocol convergence-layer adapters that conform to the CBHE 287 specification must implement the following procedures. 289 3.1. Transmission 291 When and only when required by the bundle protocol agent to transmit 292 a bundle whose primary block's endpoint IDs satisfy the constraints 293 identified in section 2.1 above, the CLA MAY encode the primary block 294 of the bundle in accordance with the CBHE compression convention 295 described in section 2.2 above UNLESS the CLA to which the bundle is 296 to be transmitted is known to be non-CBHE-conformant. Note that CBHE 297 compression may be applied only if the receiving CLA is known or 298 presumed to be CBHE-conformant, i.e., able to decode the encoded 299 primary block. Knowledge as to whether or not a receiving CLA is (or 300 might be) CBHE-conformant may be asserted by node administration 301 and/or may be inferred from reception of a CBHE-compressed bundle as 302 noted in section 3.2 below. 304 3.2. Reception 306 Upon receiving a bundle whose dictionary length is zero (and only in 307 this circumstance), a CBHE-conformant convergence layer adapter: 309 1. MAY infer that the CLA from which the bundle was received is 310 CBHE-conformant. 312 2. MUST decode the primary block of the bundle in accordance with 313 the CBHE compression convention described in section 2.2 above 314 before delivering it to the bundle protocol agent. 316 Note that when a non-CBHE-conformant CLA receives a bundle whose 317 dictionary length is zero, it has no choice but to pass it to the 318 bundle agent without modification. In this case the bundle protocol 319 agent will be unable to dispatch the received bundle, because it will 320 be unable to determine the destination endpoint; the bundle will be 321 judged to be malformed. The behavior of the bundle protocol agent in 322 this circumstance is an implementation matter. 324 4. IANA Considerations 326 Provisional registration (per [RFC4395]) for a URI scheme for CBHE is 327 requested, with the string "ipn" as the suggested scheme name, as 328 follows. 330 URI scheme name: "ipn". 332 Status: provisional. 334 URI scheme syntax: 336 This specification uses the Augmented Backus-Naur Form (ABNF) 337 notation of [RFC5234], including the core ABNF syntax rule for DIGIT 338 defined by that specification. 340 ipn-uri = "ipn:" ipn-hier-part 341 ipn-hier-part = node-nbr nbr-delim service-nbr ; a path-rootless 342 node-nbr = 1*DIGIT 343 nbr-delim = "." 344 service-nbr = 1*DIGIT 346 None of the reserved characters defined in the generic URI syntax are 347 used as delimiters within URIs of the IPN scheme. 349 URI scheme semantics: URIs of the IPN scheme are used as endpoint 350 identifiers in the Delay-Tolerant Networking (DTN) Bundle Protocol 351 (BP) [RFC5050] as described in 2.1 above. 353 Encoding considerations: URIs of the IPN scheme are encoded 354 exclusively in US-ASCII characters. 356 Applications and/or protocols that use this URI scheme name: the 357 Delay-Tolerant Networking (DTN) Bundle Protocol (BP) [RFC5050]. 359 Interoperability considerations: as noted above, URIs of the IPN 360 scheme are encoded exclusively in US-ASCII characters. 362 Security considerations: 364 o Reliability and consistency: none of the BP endpoints identified 365 by the URIs of the IPN scheme are guaranteed to be reachable at 366 any time, and the identity of the processing entities operating on 367 those endpoints is never guaranteed by the Bundle Protocol itself. 368 Bundle authentication as defined by the Bundle Security Protocol 369 is required for this purpose. 371 o Malicious construction: malicious construction of a conformant 372 IPN-scheme URI is limited to malicious selection of node number 373 and malicious selection of service number. That is, a maliciously 374 constructed IPN-scheme URI could be used to direct a bundle to an 375 endpoint that might be damaged by the arrival of that bundle or, 376 alternatively, to declare a false source for a bundle and thereby 377 cause incorrect processing at a node that receives the bundle. In 378 both cases (and indeed in all bundle processing) the node that 379 receives a bundle should verify its authenticity and validity 380 before operating on it in any way. 382 o Back-end transcoding: the limited expressiveness of URIs of the 383 IPN scheme effectively eliminates the possibility of threat due to 384 errors in back-end transcoding. 386 o Rare IP address formats: not relevant, as IP addresses do not 387 appear anywhere in conformant IPN-scheme URIs. 389 o Sensitive information: because IPN-scheme URIs are used only to 390 represent the identities of Bundle Protocol endpoints, the risk of 391 disclosure of sensitive information due to interception of these 392 URIs is minimal. Examination of IPN-scheme URIs could be used to 393 support traffic analysis; where traffic analysis is a plausible 394 danger, bundles should be conveyed by secure convergence-layer 395 protocols that don't expose endpoint IDs. 397 o Semantic attacks: the simplicity of IPN-scheme URI syntax 398 minimizes the possibility of misinterpretation of a URI by a human 399 user. 401 Contact: Scott Burleigh, Jet Propulsion Laboratory, California 402 Institute of Technology, scott.c.burleigh@jpl.nasa.gov, +1 (800) 393- 403 3353. 405 Author/Change controller: Scott Burleigh, Jet Propulsion Laboratory, 406 California Institute of Technology, scott.c.burleigh@jpl.nasa.gov, +1 407 (800) 393-3353. 409 References: S. Burleigh, "Compressed Bundle Header Encoding (CBHE)", 410 draft-irtf-dtnrg-cbhe-09, February 2011. 412 5. Security Considerations 414 The Bundle Security Protocol may under some conditions insert 415 additional endpoint ID strings into the dictionary of a bundle and 416 reference those strings in BSP extension blocks. Because a bundle 417 that includes any extension blocks containing EID references to 418 endpoint IDs other than the block's destination, source, report-to, 419 and current custodian cannot be CBHE-compressed, bundles cannot be 420 compressed under those conditions. 422 Specifically, the specification detailed above implies that a bundle 423 cannot be CBHE-compressed when the security source endpoint for the 424 Bundle Authentication Block (BAB) is noted in the dictionary 425 (typically because there is no other way for the receiving bundle 426 protocol agent to determine the security source endpoint), when the 427 security destination endpoint for the BAB is noted in the dictionary 428 (in the rare case that the receiving endpoint is not the security 429 destination endpoint), when the security source endpoint for the 430 Payload Integrity Block (PIB), Payload Confidentiality Block (PCB), 431 or Extension Security Block (ESB) is not the source endpoint, or when 432 the security destination endpoint for the PIB, PCB, or ESB is not the 433 destination endpoint. 435 Also, the CBHE-conformance inference mechanism identified in section 436 3.2 above introduces a possible denial-of-service attack. Malicious 437 code could issue a CHBE-compressed bundle whose source EID falsely 438 identifies the bundle origin as some node whose CLA is non-CBHE- 439 conformant; a CBHE-conformant CLA receiving this bundle might 440 incorrectly infer that the CLA at the purported source node was CBHE- 441 conformant and might then begin CBHE-compressing all bundles that it 442 sends to that node, thus preventing those bundles from being 443 dispatched by the node's bundle protocol agent. Nodes can defend 444 against such an attack by requiring Bundle Authentication Blocks and 445 discarding any inference of CBHE conformance for the CLAs at nodes 446 from which inauthentic bundles are received. 448 These caveats aside, CBHE introduces no new security considerations 449 beyond those discussed in the DTN Bundle Protocol and Bundle Security 450 Protocol specifications. 452 6. References 454 6.1. Normative References 456 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 457 Requirement Levels", BCP 14, RFC 2119, March 1997. 459 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 460 Resource Identifier (URI): Generic Syntax", STD 66, 461 RFC 3986, January 2005. 463 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 464 Specification", RFC 5050, November 2007. 466 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 467 Specifications: ABNF", STD 68, RFC 5234, January 2008. 469 6.2. Informative References 471 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 472 Registration Procedures for New URI Schemes", BCP 35, 473 RFC 4395, February 2006. 475 Author's Address 477 Scott Burleigh 478 Jet Propulsion Laboratory, California Institute of Technology 479 4800 Oak Grove Drive, m/s 301-490 480 Pasadena, CA 91109 481 USA 483 Phone: +1 818 393 3353 484 Email: Scott.C.Burleigh@jpl.nasa.gov