idnits 2.17.1 draft-irtf-dtnrg-bundle-previous-hop-block-12.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 (May 17, 2010) is 5092 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 May 17, 2010 5 Expires: November 18, 2010 7 Delay-Tolerant Networking Previous Hop Insertion Block 8 draft-irtf-dtnrg-bundle-previous-hop-block-12 10 Abstract 12 This document defines an extension block for use with the DTN Bundle 13 Protocol. This Previous Hop Insertion Block (PHIB) extension block 14 is designed to be inserted by a forwarding node to provide the 15 endpoint identifier (EID) of an endpoint of which the forwarding node 16 is a member so that this EID may be conveyed to the next-hop 17 receiving node. Knowledge of an EID of an endpoint of which a 18 previous-hop node is a member may be required in some circumstances 19 to support certain routing protocols (e.g., flood routing). If this 20 EID cannot be provided by the convergence layer or other means, the 21 PHIB defines the mechanism whereby the EID can be provided with the 22 bundle. Each PHIB is always removed from the bundle by the receiving 23 node so that its presence within the bundle is limited to exactly one 24 hop. This document defines the format and processing of this PHIB. 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 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on November 18, 2010. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Previous Hop Insertion Block Format . . . . . . . . . . . . . 5 65 3. Previous Hop Insertion Block Processing . . . . . . . . . . . 7 66 3.1. Bundle Transmission . . . . . . . . . . . . . . . . . . . 7 67 3.2. Bundle Forwarding . . . . . . . . . . . . . . . . . . . . 7 68 3.3. Bundle Reception . . . . . . . . . . . . . . . . . . . . . 8 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 73 6.2. Informative References . . . . . . . . . . . . . . . . . . 11 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in RFC 2119 [RFC 2119]. 82 This document defines an extension block for use with the Bundle 83 Protocol [RFC 5050] within the context of a Delay-Tolerant Network 84 architecture [RFC 4838]. The DTN Bundle Protocol defines the bundle 85 as its protocol data unit and defines "bundle blocks" to carry data 86 of different types. This document defines an optional bundle block 87 called a Previous Hop Insertion Block (PHIB). 89 The PHIB is inserted into a bundle by a forwarding node to provide 90 the endpoint ID (EID) of an endpoint of which the forwarding node is 91 a member so that this EID may be conveyed to the next-hop receiving 92 node. (Hereafter, an EID of an endpoint of which a node is a member 93 will be referred to as an "M-EID" of that node. A node may have one 94 or more M-EIDs, depending on the number of endpoints to which it 95 belongs. An EID of a singleton endpoint of which a node is a member 96 will be referred to as a "singleton M-EID" of that node.) In 97 situations where there is a requirement that the receiving node be 98 able to determine an M-EID of a forwarding node, but the M-EID of the 99 forwarding node cannot be inferred by the receiving node through 100 existing mechanisms, the forwarding node must explicitly provide this 101 M-EID in the bundle. This specification defines the mechanism 102 whereby a node can insert such an M-EID into a bundle before 103 forwarding it to the bundle's next hop. 105 This previous-hop M-EID information may be used in some circumstances 106 to support various routing protocols. For example, the PHIB could be 107 helpful when implementing flood routing because each receiving node 108 could use the PHIB to determine which EID to exclude from the list of 109 adjacent nodes to which it forwards received bundles as it does its 110 part in flooding the bundle. A node will flood the bundle to all 111 neighboring nodes except for the node from which it received the 112 bundle, as identified in the PHIB. 114 The PHIB could also be used in conjunction with the Bundle 115 Authentication Block (BAB) of the DTN Bundle Security Protocol 116 [DTNBSP] to provide the security source EID for the BAB. The PHIB 117 can be used to carry the BAB's security source EID instead of 118 conveying this EID using a reference in the BAB's EID reference field 119 or including the EID as part of the BAB's key information parameters. 121 In many situations, a node that receives a bundle may be able to 122 infer an M-EID of the node that forwarded the bundle. In some 123 situations, however, no M-EID will be able to be inferred by the 124 receiving node. For example, if tunneling DTN bundles across some 125 portion of the DTN network, it is not possible for the node at the 126 receiving end of the tunnel to determine from the convergence layer 127 the M-EID of the node at the sending end of the tunnel. The node at 128 the receiving end of the tunnel will receive an encapsulating bundle 129 from one of its adjacent nodes and it may be able to tell the M-EID 130 of this adjacent node using the convergence layer protocol. However, 131 the node at the sending end of the tunnel is most likely not adjacent 132 to the node at the receiving end of the tunnel, so in order for the 133 node at the receiving end of the tunnel to be able to learn the M-EID 134 of the node at the sending end of the tunnel, which is the previous 135 hop node of the tunneled bundle, the M-EID must be provided within 136 the tunneled bundle. In this case, the PHIB is the vehicle for 137 enabling the node at the sending end of the tunnel to provide its 138 M-EID to the node at the receiving end of the tunnel. 140 EIDs may be presented in two ways within the PHIB. If the M-EID of 141 the forwarding node is already in the dictionary field of the 142 bundle's Primary Bundle Block, the PHIB MAY identify this EID using 143 its Block EID reference count and EID references field. Otherwise, 144 the PHIB MUST identify this EID by providing the EID in its block- 145 type-specific data field. These two alternative ways of presenting 146 EIDs in the PHIB are further discussed in Section 3. 148 The lifetime of the PHIB is always exactly one hop in the DTN. If a 149 bundle containing a PHIB is received, the receiving node is assured 150 that this PHIB was inserted by the previous node, assuming all nodes 151 are operating correctly; likewise, this PHIB is not retained with the 152 bundle when the bundle is forwarded. If the bundle is forwarded with 153 a PHIB, this PHIB MUST identify an M-EID of the forwarding node. 155 This document defines the format and processing of the PHIB. The 156 capabilities described in this document are OPTIONAL for deployment 157 with the Bundle Protocol. Bundle Protocol implementations claiming 158 to support the PHIB MUST be capable of: 160 -Generating a PHIB and inserting it into a bundle, 162 -Receiving bundles containing a PHIB and making the information 163 contained in this PHIB available for use, e.g., in forwarding 164 decisions. 166 -Deleting a PHIB from a bundle 168 as defined in this document. 170 2. Previous Hop Insertion Block Format 172 The PHIB uses the Canonical Bundle Block Format as defined in the 173 Bundle Protocol [RFC 5050]. That is, the PHIB is comprised of the 174 following elements, which are defined as in all bundle protocol 175 blocks except the primary bundle block. Note that SDNV encoding is 176 also described in the Bundle Protocol: 178 -Block-type code (one byte) - The block type code for the PHIB is 179 0x05. 181 -Block processing control flags (SDNV) - The following block 182 processing control flag MUST be set: 184 -Discard block if it can't be processed. 186 -Block EID reference count and EID references (optional) - 187 composite field defined in [RFC 5050] containing a count of EID 188 references (expressed as an SDNV) followed by an EID reference 189 (expressed as a pair of SDNVs). 191 Whether or not this field is allowed in the PHIB is determined by 192 whether or not an M-EID of the node inserting the PHIB is already 193 in the Dictionary Field of the Primary Bundle Block (e.g., whether 194 an M-EID of the inserting node is also an M-EID of the bundle's 195 source, current custodian, or report-to endpoint, or is the same 196 as some other endpoint in the dictionary that is referenced by 197 another block in the bundle). 199 If an M-EID of the inserting node is already in the dictionary, 200 this field MAY be present in the PHIB. If this field is present 201 in the PHIB, the value of the EID reference count MUST be one, 202 meaning that the field contains exactly one EID reference, which 203 MUST be a reference to an M-EID of the inserting node. Presence 204 of this field MUST be indicated by a set "block contains an EID 205 reference field" flag in the block processing control flags. 207 If no M-EID of the inserting node is in the dictionary, this field 208 MUST NOT be present in the PHIB, which MUST be indicated by an 209 unset "block contains an EID reference field" flag in the block 210 processing control flags 212 -Block data length (SDNV) - If this value is zero, there are no 213 block-type-specific data fields. In this case, the M-EID of the 214 inserting node must be in the dictionary and it MUST be referenced 215 in the Block EID reference count and EID references field as 216 described above. 218 -Block-type-specific data fields (optional) as follows: 220 -Inserting Node's EID Scheme Name - A null-terminated array of 221 bytes that comprises the scheme name of an M-EID of the node 222 inserting this PHIB. 224 -Inserting Node's EID SSP - A null-terminated array of bytes 225 that comprises the scheme-specific part (SSP) of an M-EID of 226 the node inserting this PHIB. 228 If the Block EID reference count and EID references field is not 229 present in the PHIB, the above two EID scheme name and SSP block- 230 type-specific data fields MUST be present. If the Block EID 231 reference count and EID references field is present in the PHIB, 232 the above two EID scheme name and SSP block-type-specific data 233 fields MUST NOT be present. 235 The Structure of a PHIB is as follows: 237 PHIB Format: 238 +----+------------+--------------------------------- -+-------------+ 239 |type|flags (SDNV)|EID ref count and list (comp) (opt)|length (SDNV)| 240 +----+------------+-----------------------------------+-------------+ 241 | Inserting Node EID Scheme Name (opt)| Inserting Node EID SSP (opt)| 242 +-------------------------------------------------------------------+ 244 Figure 1 246 3. Previous Hop Insertion Block Processing 248 The following are the processing steps that a bundle node must take 249 relative to generation, reception, and processing of a PHIB. 251 3.1. Bundle Transmission 253 When an outbound bundle is created per the parameters of the bundle 254 transmission request, this bundle MAY include one or more PHIBs. 255 Whether or not PHIBs are included is a local bundle agent 256 configuration option and may be influenced by other factors, such as 257 the routing protocol in use. 259 3.2. Bundle Forwarding 261 Before forwarding a bundle, the node SHALL delete all PHIBs that were 262 in the bundle when it was received (if any). As described in the 263 Bundle Protocol, the node MAY delete all strings (scheme names and 264 SSPs) in the bundle's dictionary to which no endpoint ID references 265 in the bundle currently refer (if any). 267 The node MAY insert one or more PHIBs into the bundle before 268 forwarding it, as dictated by local policy. If there are already 269 strings (scheme names and SSPs) in the bundle's dictionary that 270 denote the M-EID of the inserting node, the PHIB MAY reference these 271 strings and, if it does, it MUST NOT include any block-type-specific 272 data fields. The inserting node MUST NOT insert strings into the 273 bundle's dictionary in order that they may be referenced by only the 274 PHIB. If the PHIB is constructed such that it does not reference any 275 strings from the dictionary, the inserting node MUST include the 276 scheme name and SSP of one of its M-EIDs as the PHIB's block-type- 277 specific data fields. 279 The node that is inserting a PHIB into the bundle may have more than 280 one endpoint in which it is a member. The choice of which M-EID to 281 insert into the PIB SHALL be made as follows: 283 - If the inserting node is a member of exactly one singleton 284 endpoint, the node may insert at most one PHIB into the bundle and 285 the EID of this singleton endpoint is what MUST be inserted into 286 the PHIB. 288 - If the inserting node is a member of more than one singleton 289 endpoint, then: 291 If the inserting node has a priori knowledge of the URI schemes 292 supported by the next hop node and if the inserting node has 293 one or more singleton M-EIDs that are expressible in one or 294 more of those URI schemes, then the inserting node MAY insert 295 one or more PHIBs into the bundle being forwarded. The EIDs in 296 the inserted PHIBs MUST be unique, they MUST be singleton 297 M-EIDs of the inserting node, and they MUST be expressed in URI 298 schemes supported by the next hop node. Mechanisms for 299 determining what URI schemes are supported by particular next 300 hop neighbors are not defined here. 302 If the inserting node has one or more singleton M-EIDs that are 303 expressible in the same URI scheme as the destination of the 304 bundle that is being forwarded, then the inserting node MAY 305 insert one or more PHIBs into the bundle being forwarded. The 306 EIDs in the inserted PHIBs MUST be unique, they MUST be 307 singleton M-EIDs of the inserting node, and they MUST be 308 expressed in the destination URI scheme of the bundle. 310 Else if the inserting node has neither a singleton M-EID that 311 is expressible in a URI scheme known to be supported by the 312 next hop node nor a singleton M-EID that is expressible in the 313 same URI scheme as the destination of the bundle that is being 314 forwarded, then the inserting node MAY insert one or more PHIBs 315 into the bundle being forwarded. The EIDs in the inserted 316 PHIBs MUST be unique, and they MUST be singleton M-EIDs of the 317 inserting node. 319 3.3. Bundle Reception 321 If the bundle includes a PHIB, the EID identified in the PHIB SHALL 322 be made available for use at the receiving node (e.g., in forwarding 323 decisions or, if the receiving node is the bundle destination, the 324 EID may be made available to the receiving application; whether or 325 not it is made available to the receiving application is an 326 implementation matter). If the EID is identified both by a reference 327 in the PHIB's Block EID reference count and EID references field and 328 by a scheme name and SSP in the block-type-specific fields, the PHIB 329 is not considered to be well-formed. In the case of reception of 330 such an ill-formed PHIB, if the identified EIDs are the same, the 331 receiving node MAY process the PHIB as if it were well-formed. 332 However, if the identified EIDs differ, the receiving node MUST NOT 333 process the PHIB and must take action on the PHIB as specified by the 334 PHIB's Block Processing Control Flags. 336 4. Security Considerations 338 The DTN Bundle Security Protocol [DTNBSP] defines security-related 339 blocks to provide hop-by-hop bundle authentication and integrity, 340 end-to-end integrity, and end-to-end confidentiality of bundles or 341 parts of bundles, as well as a set of ciphersuites that may be used 342 to calculate security results carried in these security blocks. The 343 PHIB will not be encrypted when using the PCB-RSA-AES128-PAYLOAD-PIB- 344 PCB ciphersuite with the Payload Confidentiality Block (PCB) to 345 provide end-to-end confidentiality. This ciphersuite only allows for 346 payload and Payload Integrity Block (PIB) encryption. If encryption 347 of the PHIB block is desired, the Extension Security Block (ESB) 348 could be used for this purpose. 350 All ciphersuites that use the strict canonicalisation algorithm 351 [DTNBSP] to calculate and verify security results (e.g., many hop-by- 352 hop authentication ciphersuites) apply to all blocks in the bundle, 353 and so would apply to bundles that include an optional PHIB and would 354 include that block in the calculation of their security result. In 355 particular, bundles including the optional PHIB would have their 356 integrity protected in their entirety for the extent of a single hop, 357 from a forwarding node to an adjacent receiving node, using the 358 Bundle Authentication Block (BAB) with the BAB-HMAC ciphersuite 359 defined in the Bundle Security Protocol. 361 Ciphersuites that use the mutable canonicalisation algorithm to 362 calculate and verify security results (e.g., the PIB-RSA-SHA256 363 ciphersuite and most end-to-end authentication ciphersuites used with 364 the PIB) will (correctly) omit the PHIB from their calculation. The 365 fact that several different instantiations of this PHIB block may be 366 added to and deleted from the bundle as the bundle transits the 367 network will not interfere with end-to-end security protection when 368 using ciphersuites that use mutable canonicalisation. 370 As stated above, the BAB can be used to ensure the integrity of the 371 PHIB. Nodes receiving bundles with PHIBs should be aware, however, 372 that forwarding nodes that insert PHIBs might lie about the EIDs of 373 endpoints of which they are members. Lying in this way could provide 374 a mechanism for subverting routing strategies that base routing 375 decisions on EID information in the PHIB. 377 Note that if some Bundle Protocol implementation does not support the 378 PHIB but does not properly implement the "Discard block if it can't 379 be processed" flag, then a PHIB may unexpectedly persist for longer 380 than a single hop. 382 5. IANA Considerations 384 This specification allocates a codepoint from the Bundle Block Type 385 Codes registry defined in [ID.draft-irtf-dtnrg-iana-bp-registries] 386 (see Section 2): 388 Additional Entry for the Bundle Block Type Codes Registry: 389 +-------+----------------------------------------+----------------+ 390 | Value | Description + Reference | 391 +-------+----------------------------------------+----------------+ 392 | 5 | Previous Hop Insertion Block + This document | 393 +-------+----------------------------------------+----------------+ 395 6. References 397 6.1. Normative References 399 [RFC 2119] 400 Bradner, S. and J. Reynolds, "Key words for use in RFCs to 401 Indicate Requirement Levels", RFC 2119, October 1997. 403 [RFC 5050] 404 Scott, K. and S. Burleigh, "Bundle Protocol 405 Specification", RFC 5050, November 2007. 407 [ID.draft-irtf-dtnrg-iana-bp-registries] 408 Blanchet, M., "Delay-Tolerant Networks (DTN) Bundle 409 Protocol IANA Registries", draft-irtf-dtnrg-iana-bp- 410 registries-00.txt, work-in-progress, April 2010. 412 6.2. Informative References 414 [RFC 4838] 415 Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 416 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 417 Network Architecture", RFC 4838, April 2007. 419 [DTNBSP] Symington, S., Farrell, S., Weiss, H., and P. Lovell, 420 "Bundle Security Protocol Specification", 421 draft-irtf-dtnrg-bundle-security-15.txt, work-in-progress, 422 February 2010. 424 Author's Address 426 Susan Flynn Symington 427 The MITRE Corporation 428 7515 Colshire Drive 429 McLean, VA 22102 430 US 432 Phone: +1 (703) 983-7209 433 Email: susan@mitre.org 434 URI: http://mitre.org/