idnits 2.17.1 draft-irtf-dtnrg-bundle-metadata-block-10.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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 18, 2011) is 4815 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-irtf-dtnrg-iana-bp-registries-00 == Outdated reference: A later version (-19) exists of draft-irtf-dtnrg-bundle-security-15 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DTN Research Group S. Symington 3 Internet-Draft The MITRE Corporation 4 Intended status: Experimental February 18, 2011 5 Expires: August 22, 2011 7 Delay-Tolerant Networking Metadata Extension Block 8 draft-irtf-dtnrg-bundle-metadata-block-10 10 Abstract 12 This document defines an extension block that may be used with the 13 DTN Bundle Protocol. This Metadata Extension Block is designed to 14 carry additional information that DTN nodes can use to make 15 processing decisions regarding bundles, such as deciding whether to 16 store a bundle or determining to which nodes to forward a bundle. 17 The metadata that is carried in a metadata block must be formatted 18 according to the metadata type that is identified in the block's 19 metadata type field. One specific metadata type, for carrying URIs 20 as metadata, is defined in this document. Other metadata types may 21 be defined in separate documents. This document is a product of the 22 Delay Tolerant Networking Research Group and has been reviewed by 23 that group. No objections to its publication as an RFC were raised. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 22, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 61 2. Metadata Block Format . . . . . . . . . . . . . . . . . . . . 5 62 3. Metadata Block Processing . . . . . . . . . . . . . . . . . . 7 63 3.1. Bundle Transmission . . . . . . . . . . . . . . . . . . . 7 64 3.2. Bundle Forwarding . . . . . . . . . . . . . . . . . . . . 7 65 3.3. Bundle Reception . . . . . . . . . . . . . . . . . . . . . 7 66 4. Predefined Metadata Types . . . . . . . . . . . . . . . . . . 8 67 4.1. URI Metadata Type . . . . . . . . . . . . . . . . . . . . 8 68 4.2. Private Metadata Types . . . . . . . . . . . . . . . . . . 8 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 71 6.1. Metadata Type Codes . . . . . . . . . . . . . . . . . . . 11 72 6.2. Block Type Code for the Metadata Block . . . . . . . . . . 11 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 75 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 1. Introduction 80 This document defines an extension block that may be used with the 81 Bundle Protocol [RFC 5050] within the context of a Delay-Tolerant 82 Network architecture [RFC 4838]. The DTN bundle protocol [RFC 5050] 83 defines the bundle as its protocol data unit. This document defines 84 a bundle block called a Metadata Block. This block is designed to 85 carry additional information that DTN nodes can use to make 86 processing decisions regarding bundles. 88 The metadata block has been deliberately defined to be flexible 89 enough that it would be capable of supporting a variety of metadata 90 types and formats. Indeed, the only restriction imposed on the 91 metadata to be used is that its type and format be pre-defined and 92 registered (if public) so that it can be parsed and processed by DTN 93 nodes that support metadata of that type. Section 4 defines a 94 specific metadata type and discusses the use of other metadata types 95 that may be defined elsewhere. As mentioned, it is the intention 96 that the metadata that is carried in this block be application- 97 related information. For example, the metadata might be information 98 that is associated with the payload of a bundle. Additional 99 extension blocks could be (and have been) defined for carrying 100 additional network-related information. 102 While the bundle payload may be processed opaquely by DTN nodes, 103 metadata is intended to serve as a mechanism for providing DTN nodes 104 with access to additional information that they can use to process 105 the bundle. Examples of such additional information include keywords 106 found in the payload, payload provenance information, GPS coordinates 107 (if the payload is a map, for instance), message IDs, and artist, 108 album and track name (if the payload is a song). Even though the 109 metadata is additional information related to the application, its 110 purpose is to be used by DTN nodes to make decisions regarding how to 111 process bundles within the network, such as whether or not a bundle 112 should be stored or to which nodes a bundle should be forwarded. 113 Metadata that is about bundle payload, for example, might serve as a 114 content-based index of bundles that are stored in a DTN cache. So, 115 in response to a request for bundles related to a certain subject or 116 related to specific GPS coordinates, for example, the metadata of 117 stored bundles could be searched and all bundles with metadata 118 matching the search criteria could be retrieved and returned to the 119 requestor. 121 This document defines the general format of and the processing 122 required to support the Metadata Block. The actual metadata to be 123 inserted into a metadata block MUST be formatted according to the 124 metadata type that is identified in the block's metadata type field. 125 One specific metadata type, for carrying Uniform Resource Identifiers 126 (URIs) [RFC 3986] as metadata, is defined in this document. Other 127 metadata types may be defined in separate documents, along with the 128 steps required to process records of that type, if necessary. If 129 such other metadata types are defined, they should be registered to 130 ensure global uniqueness (see the IANA Considerations section). 132 The capabilities described in this document are OPTIONAL for 133 deployment with the Bundle Protocol. Bundle Protocol implementations 134 claiming to support the Metadata Block MUST be capable of: 136 -Generating a Metadata Block and inserting it into a bundle, 138 -Receiving bundles containing a Metadata Block and making the 139 information contained in this Metadata Block's metadata field 140 available for use, e.g., in bundle storage or forwarding 141 decisions, 143 -Deleting a metadata block from a received bundle before 144 forwarding the bundle 146 as defined in this document. 148 Bundle Protocol implementations claiming to support a specific 149 metadata type must both support the metadata block as defined above 150 and be capable of parsing and processing the metadata itself 151 according to the definition of the metadata type in which the 152 metadata is expressed. This metadata type may be the URI Metadata 153 Type (see the URI Metadata Type section), or it may be another 154 metadata type defined in a separate document. 156 1.1. Requirements Language 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in RFC 2119 [RFC 2119]. 162 2. Metadata Block Format 164 The Metadata Block uses the Canonical Bundle Block Format as defined 165 in the Bundle Protocol [RFC 5050]. That is, it is comprised of the 166 following elements, which are defined as in all bundle protocol 167 blocks except the primary bundle block. (Note that SDNV encoding is 168 described in the Bundle Protocol.): 170 -Block-type code (1 byte) - defined as in all bundle protocol 171 blocks except the primary bundle block (as described in the Bundle 172 Protocol). The block type code for the Metadata Block is 0x08. 174 -Block processing control flags (SDNV) - defined as in all bundle 175 protocol blocks except the primary bundle block. SDNV encoding is 176 described in the Bundle Protocol. There are no constraints on the 177 use of the Block Processing Control Flags. If a bundle node 178 receives a bundle with a metadata block and it is capable of 179 supporting the metadata block but it is not able to parse and 180 process the metadata itself, either because it does not support 181 the metadata type being used or because the metadata is not well- 182 formed according to the metadata type definition, the bundle node 183 must process the bundle as if it cannot process the metadata 184 block. That is, it must operate according to the settings of the 185 Block Processing Control Flags, including the "Delete bundle if 186 block can't be processed" flag and the "Discard block if it can't 187 be processed" flag. 189 -Block EID reference count and EID references (optional) - 190 composite field defined in the bundle protocol that is present if 191 and only if the metadata block references EID elements in the 192 primary block's dictionary. Presence of this field is indicated 193 by the setting of the "Block contains an EID-reference field" bit 194 of the block processing control flags. If EIDs are referenced in 195 the metadata block, then their interpretation is defined by the 196 particular metadata type that is being used in this metadata 197 block, as indicated in the metadata type field. 199 -Block data length (SDNV) - defined as in all bundle protocol 200 blocks except the primary bundle block. SDNV encoding is 201 described in the bundle protocol. 203 -Block-type-specific data fields as follows: 205 - Metadata Type field (SDNV) - indicates which metadata type is 206 to be used to interpret both the metadata in the metadata field 207 and the EID references in the optional Block EID reference 208 count and EID references field (if present). One metadata type 209 is defined in this document. Other metadata types may be 210 defined in separate documents. 212 - Metadata field - contains the metadata itself, formatted 213 according to the metadata type that has been specified for this 214 block. One metadata type is defined in Section 4.1. Other 215 metadata types may be defined elsewhere, as discussed in 216 Section 4. 218 The Structure of a Metadata Block is as follows: 220 Metadata Block Format: 221 +-----+------+--------------------+------+----------+----------| 222 |Type |Flags |EID Reference count |Len | Metadata | Metadata | 223 | |(SDNV)| and list (opt) |(SDNV)| Type | | 224 +-----+------+--------------------+------+----------+----------+ 226 Figure 1 228 3. Metadata Block Processing 230 The following are the processing steps that a bundle node may take 231 relative to generation, reception, and processing of Metadata Blocks. 233 3.1. Bundle Transmission 235 When an outbound bundle is created per the parameters of the bundle 236 transmission request, this bundle MAY (as influenced by local policy 237 and the metadata type being used) include one or more metadata blocks 238 (as defined in this specification). 240 3.2. Bundle Forwarding 242 A node MAY insert one or more metadata Blocks into a bundle before 243 forwarding it; and a node MAY delete one or more metadata blocks from 244 a bundle before forwarding it, as dictated by local policy and the 245 metadata type being used. 247 3.3. Bundle Reception 249 If the bundle includes one or more metadata blocks, the metadata 250 information records in these blocks SHALL be made available for use 251 at this node (e.g., in bundle storage or forwarding decisions, or, if 252 the receiving node is the bundle destination, the metadata 253 information records may be provided to the receiving application). 255 4. Predefined Metadata Types 257 As mentioned in the previous section, any number of different 258 metadata types may be defined to indicate the format of both the 259 metadata field and the EID references in the optional Block EID 260 reference count and EID references field (if present) and, if 261 necessary, how metadata of this type should be processed. One 262 metadata type is defined in this document, URI Metadata Type (0x01). 263 In addition, a range of metadata type values is reserved for private 264 use. 266 4.1. URI Metadata Type 268 It is believed that use of URIs will in many cases be adequate for 269 encoding metadata, although it is recognized that use of URIs may not 270 be the most efficient method for such encoding. Because of the 271 expected utility of using URI encoding for metadata, the metadata 272 type value of 0x01 is defined to indicate a metadata type of URI. 273 Metadata type values other than 0x01 will be used to indicate 274 alternative metadata types. 276 The Metadata field for metadata of metadata type URI (0x01) consists 277 of an array of bytes formed by concatenating one or more null- 278 terminated URIs. Unless determined by local policy, the specific 279 processing steps that must be performed on bundles with metadata 280 blocks containing metadata of type URI are expected to be indicated 281 as part of the URI encoding of the metadata. It is envisioned that 282 users might define URI schemes for this purpose. Metadata blocks 283 containing metadata of type URI MUST NOT include a Block EID 284 reference count and EID references field. The absence of this field 285 MUST be indicated by a value of 0 for the "block contains an EID 286 reference field" flag in the block processing control flags. Support 287 for the URI metadata type is OPTIONAL. 289 4.2. Private Metadata Types 291 Metadata type values 192 through 249 are not defined in this 292 specification and are available for private and/or experimental use. 293 Such private metadata types are not required to be registered. All 294 other values of the metadata type are reserved for future use and, 295 when defined, should be registered to ensure global uniqueness (see 296 the IANA Considerations section). Local policy will define how 297 private metadata types are handled. 299 5. Security Considerations 301 The DTN Bundle Security Protocol [DTN BSP] defines security-related 302 blocks to provide hop-by-hop authentication, end-to-end 303 authentication, end-to-end confidentiality of bundles or parts of 304 bundles, and an extension security block to provide confidentiality 305 and integrity for extension blocks, as well as a set of standard 306 ciphersuites that may be used to calculate security results carried 307 in these security blocks. All ciphersuites that use the strict 308 canonicalisation algorithm [DTN BSP] to calculate and verify security 309 results (e.g., many hop-by-hop authentication ciphersuites) apply to 310 all blocks in the bundle, and so would apply to bundles that include 311 an optional Metadata Block and would include that block in the 312 calculation of their security result. In particular, bundles 313 including the optional Metadata Block would be protected in their 314 entirety for the duration of a single hop, from a forwarding node to 315 an adjacent receiving node (but not from source to destination over 316 multiple hops), using the standard BAH-HMAC ciphersuite defined in 317 the Bundle Security Protocol. 319 Ciphersuites that use the mutable canonicalisation algorithm to 320 calculate and verify security results (e.g., the mandatory PSH-RSA- 321 SHA256 ciphersuite and most end-to-end authentication ciphersuites) 322 will omit the Metadata Block from their calculation. Therefore, the 323 fact that metadata in the metadata block may be modified or that 324 metadata blocks themselves may be added to or deleted from a bundle 325 as it transits the network will not interfere with end-to-end 326 security protection when using ciphersuites that use mutable 327 canonicalisation. 329 The Metadata Block will not be encrypted by the mandatory CH-RSA-AES- 330 PAYLOAD-PSH end-to-end confidentiality ciphersuite, which only allows 331 for payload and PSH encryption. 333 In order to provide the metadata block with end-to-end 334 confidentiality and authentication independent of any confidentiality 335 or authentication that is provided for the payload or other parts of 336 the bundle, the extension security block may be used to encrypt and 337 authenticate the metadata block. A bundle may contain multiple 338 metadata extension blocks. In some cases, multiple metadata blocks 339 may be carried in the bundle, possibly with each being encrypted 340 separately from each other and from the payload. Such separate 341 encryption of metadata from payload would enable bundle nodes to 342 perform content-based searching and routing on bundle metadata that 343 they are able to decrypt, even if they are not able to decrypt the 344 bundle payload. 346 Given that metadata can be modified by forwarding nodes, it may be 347 desirable to eventually support the ability to audit changes to the 348 metadata at the individual record level. No such capability has been 349 provided in this specification as currently written. 351 6. IANA Considerations 353 6.1. Metadata Type Codes 355 The Metadata Block carried in the Metadata Extension Block has a 356 Metadata Type Code field (see Sections 2 and 3). An IANA registry 357 shall be set up as follows. 359 Metadata Type Codes Registry 361 The registration policy for this registry is: 362 0-191: Specification Required 363 192-255: Private and/or experimental use. No assignment by IANA. 365 The Value range is unsigned 8-bit integer. 367 +---------+---------------------------------+---------------+ 368 | Value | Description | Reference | 369 +---------+---------------------------------+---------------+ 370 | 0 | Reserved | This document | 371 | 1 | URI | This document | 372 | 2-191 | Unassigned | | 373 | 192-255 | Private and/or experimental use | This document | 374 +---------+---------------------------------+---------------+ 376 6.2. Block Type Code for the Metadata Block 378 This specification allocates a codepoint from the Bundle Block Type 379 Codes registry defined in [I-D.irtf-dtnrg-iana-bp-registries] (see 380 Section 2): 382 Additional Entry for the Bundle Block Type Codes Registry: 383 +-------+----------------------------------------+----------------+ 384 | Value | Description + Reference | 385 +-------+----------------------------------------+----------------+ 386 | 8 | Metadata Extension Block + This document | 387 +-------+----------------------------------------+----------------+ 389 7. References 391 7.1. Normative References 393 [RFC 2119] 394 Bradner, S. and J. Reynolds, "Key words for use in RFCs to 395 Indicate Requirement Levels", RFC 2119, October 1997. 397 [RFC 3986] 398 Berners-Lee, T. and L. Masinter, "Uniform Resource 399 Identifier (URI): Generic Syntax", RFC 3986, STD 66, 400 January 2005. 402 [RFC 5050] 403 Scott, K. and S. Burleigh, "Bundle Protocol 404 Specification", RFC 5050, November 2007. 406 [I-D.irtf-dtnrg-iana-bp-registries] 407 Blanchet, M., "Delay-Tolerant Networks (DTN) Bundle 408 Protocol IANA Registries", draft-irtf-dtnrg-iana-bp- 409 registries-00.txt, work-in-progress, April 2010. 411 7.2. Informative References 413 [RFC 4838] 414 Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 415 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 416 Network Architecture", RFC 4838, April 2007. 418 [DTN BSP] Symington, S., Farrell, S., and H. Weiss, "Bundle Security 419 Protocol Specification", 420 draft-irtf-dtnrg-bundle-security-15.txt, work-in-progress, 421 February 2010. 423 Author's Address 425 Susan Flynn Symington 426 The MITRE Corporation 427 7515 Colshire Drive 428 McLean, VA 22102 429 US 431 Phone: +1 (703) 983-7209 432 Email: susan@mitre.org 433 URI: http://mitre.org/