idnits 2.17.1 draft-wood-dtnrg-http-dtn-delivery-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 12, 2009) is 5460 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-09) exists of draft-irtf-dtnrg-bundle-checksum-05 == Outdated reference: A later version (-02) exists of draft-natarajan-http-over-sctp-01 == Outdated reference: A later version (-08) exists of draft-wood-tae-specifying-uri-transports-06 == Outdated reference: A later version (-22) exists of draft-wood-tsvwg-saratoga-03 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Wood 3 Internet-Draft P. Holliday 4 Intended status: Experimental Cisco Systems 5 Expires: November 13, 2009 May 12, 2009 7 Using HTTP for delivery in Delay/Disruption-Tolerant Networks 8 draft-wood-dtnrg-http-dtn-delivery-03 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on November 13, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document describes how to use the Hypertext Transfer Protocol, 47 HTTP, for communication across delay- and disruption-tolerant 48 networks, by making every transit node in the network HTTP-capable, 49 and doing peer HTTP transfers between nodes to move data hop-by-hop 50 or subnet-by-subnet towards its final destination. HTTP is well- 51 known and straightforward to implement in these networks. 53 Table of Contents 55 1. Background and Introduction . . . . . . . . . . . . . . . . . 3 56 2. Adapting the HTTP delivery mechanism for DTNs . . . . . . . . 5 57 3. Other useful proposed additional HTTP headers . . . . . . . . 7 58 4. Other suggestions on HTTP for use in DTN networks . . . . . . 8 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 64 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 67 1. Background and Introduction 69 Delay- and Disruption-Tolerant Networks (DTNs) are networks where 70 conditions are such that links between nodes are not always 71 permanent, may be of very long delay or exist only during very short 72 contact periods where the link is up, and may change over time 73 [RFC4838]. Some DTNs can be thought of as sparse ad-hoc networks, 74 with nodes communicating intermittently only when they come into 75 contact. Store-and-forward delivery of data is a useful way of 76 communicating across these networks. 78 A specialised store-and-forward protocol for DTN delivery has been 79 proposed in the IRTF DTN research group (DTNRG) - the Bundle Protocol 80 [RFC5050]. Criticisms of the Bundle Protocol's lack of reliability 81 and its complexity have been made [I-D.irtf-dtnrg-bundle-checksum]. 82 The Bundle Protocol is itself intended to be a routable data format, 83 but the supporting architectures for node and application naming/ 84 addressing, automated routing, security, QoS, and resource discovery 85 have not yet been agreed upon or in some cases even significantly 86 worked on. These things already exist for the Internet Protocol, and 87 can in many cases be easily leveraged for DTN networks [Wood08]. 89 This document outlines how the well-known Hypertext Transfer Protocol 90 (HTTP) [RFC2616] can be used for store-and-forward communication 91 across DTNs. HTTP is not used end-to-end as it is on the web. 92 Instead, applications running on each node in the network communicate 93 with their neighbours using dedicated hop-by-hop or subnet-by-subnet 94 HTTP transfers to effect local data delivery. Additional HTTP header 95 information adds context for onward forwarding and delivery to 96 destination endpoints, and provides the reliability and support for 97 error-detection currently missing from the alternative Bundle 98 Protocol. 100 It must be stressed that this proposed use is distinct from proxy 101 caching methods prevalent in the traditional web. Caching commands 102 are not used; end-to-end HTTP requests are not intercepted by 103 intermediate caches that attempt to fulfil them in the traditional 104 web caching sense. 106 Although HTTP-DTN use as as a hop-by-hop message carrier between 107 caches implementing some form of routing protocol between them, the 108 distinction between client, server and proxy is replaced by peer 109 intermediate caches using HTTP to communicate in separate sessions 110 that together combine over time to make the full path between 111 original source and final destination for the data. 113 HTTP is a session layer, running over a transport layer providing 114 reliable delivery of the HTTP stream between hops. This transport 115 layer is commonly (and almost universally) TCP in the terrestrial 116 Internet, although alternative transport layers, such as SCTP, can 117 also be used under HTTP [I-D.natarajan-http-over-sctp]. For long- 118 delay networks, or for network conditions where TCP or an equivalent 119 is not suitable, an alternative transport layer such as Saratoga 120 [I-D.wood-tsvwg-saratoga] can be used under HTTP instead in hop-by- 121 hop communications between nodes. HTTP requires only reliable 122 streaming that can be used to provide ordered delivery; how that 123 reliable streaming is provided is up to the local transport layer in 124 the local subnet, and multiple different transport layers can be used 125 across the multiple hops between nodes to transfer data from source 126 to final destination. 128 Steve Deering has often described IP as 'the waist in the hourglass' 129 [Deering98] - what is above and touching on IP can be changed, what 130 is below and touching on IP can be changed, but provided the new 131 elements continue to interface to and work with IP, the hourglass 132 remains complete and the network stack remains functional. Here, 133 HTTP is the waist in this particular hourglass; applications can use 134 HTTP to communicate, provided HTTP runs over a reliable transport 135 stream. The applications can vary. The transport stream can be 136 changed; HTTP does not have to run over TCP/IP, but could even be 137 made to run directly over e.g. HDLC or a CCSDS reliable bitstream. 138 Given the prevalence of IP in many networks, it is likely that two 139 waists exist; IP and HTTP are likely choices, but the transport 140 protocol and physical enviroment will vary more. 142 Separation of HTTP from the underlying transport layer to make HTTP a 143 layer in its own right is increasingly likely to happen; this is 144 analogous to the use of different "convergence layers" under the 145 Bundle Protocol. Being able to set what transport layer to use 146 depending on conditions is useful, and a simple configuration 147 specification to do this that supports HTTP-DTN is described in 148 [I-D.wood-tae-specifying-uri-transports]. 150 HTTP use here relies on the three P's - Persistence, Pipelining and 151 the PUT directive. These are all present in the HTTP/1.1 152 specification. 154 This document contains an overview of how HTTP can be simply adapted 155 to the DTN environment by the use of HTTP/1.1 with persistence and 156 pipelining, the PUT and GET directives, and some trivial extra HTTP 157 headers needed to indicate e.g. a destination in the DTN network. 159 The remainder of this specification uses 'file' as a shorthand for 160 'binary object', which may be an HTTP 'object', file with an 161 associated MIMEtype, or other type of contiguous binary data. 163 A significant benefit to use of HTTP is that the well-known MIMEtype 164 mechanism, integral to HTTP, provides hints on what received files 165 are, and what applications should do with them [RFC2045]. The Bundle 166 Protocol does not support MIMEtypes, or any similar mechanism. 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in RFC 2119. [RFC2119] 172 2. Adapting the HTTP delivery mechanism for DTNs 174 Here, HTTP is used as a peer-to-peer protocol in the sense that 175 multiple files may be transferred in both directions simultaneously 176 between two communicating nodes using HTTP for DTN use. There is not 177 intended to be a strict client/user-agent to server relationship as 178 there is in the web. Instead, sending data across a path of six 179 nodes, four nodes between source and destination, will require a 180 minimum of five separate per-hop HTTP transactions between each pair 181 of nodes to move the data onwards to the next node. This breaks the 182 traditional end-to-end control loop and transfer into separate 183 control loops and transfers suitable for the DTN environment. 185 When two nodes come into contact across a local hop or a subnet, a 186 request for files to be copied, stored, and carried onwards can be 187 made by the receiving node issuing an HTTP GET request. 188 Alternatively, the sending node can simply issue a series of HTTP PUT 189 requests once a connection is established, if it believes that 190 putting the data to the receiving node moves it closer to its 191 eventual destination. The receiving node can always reject transfers 192 with error codes. 194 HTTP-DTN is a superset of HTTP/1.1. HTTP/1.1 pipelining and 195 persistence permits multiple PUTs to be made in sequence. Support 196 for these in implementations is crucial to the mechanisms outlined 197 here. (Note that [I-D.natarajan-http-over-sctp] also takes advantage 198 of HTTP pipelining and persistence.) 200 The key to enabling HTTP use for DTN networking is an added Content- 201 Destination: header, which specifies the final destination of the 202 file, and can be used by routing in the HTTP-using applications to 203 decide over which available links the file should be sent. Content-* 204 headers are special, in that they may not be ignored (section 9.6 of 205 [RFC2119]). Recipients not understanding Content-Destination: will 206 generate a "501 (Not Implemented)" error code. This separates HTTP 207 use in DTNs described here from normal end-to-end HTTP web use. HTTP 208 DTN nodes MUST support Content-Destination:. Files that are PUT are 209 cached and then relayed onwards by intermediate peers to the Content- 210 Destination:. GET requests for files can be forwarded by 211 intermediate peers to the Content-Destination:. 213 The information provided in Content-Destination: identifying the 214 destination may be an IP address, DNS name, Bundle Endpoint 215 Identifier (EID) or other text-string identifier useful to the local 216 DTN routing mechanisms being used. 218 Similarly, a Content-Source: header provides a textual identification 219 of the original source of the data. HTTP-DTN nodes MUST support 220 Content-Source:. 222 For DTN use, DTN HTTP nodes MUST also implement and use Content- 223 Length: and Content-Range: headers. These permit partial delivery of 224 files and resends of missing pieces of files. The Content-MD5: 225 header must be supported. This provides a simple end-to-end 226 reliability check. The Content-MD5: header is intended to be 227 generated by the source node first sending the data, and is not 228 recomputed at other nodes. 230 DTN HTTP nodes MUST implement the Host: header, in line with current 231 HTTP specifications. This header field MAY be left blank to request 232 available files from the peer node, rather than identifying a desired 233 file from a distant source by hostname matching the advertised 234 Content-Source: header. A sender placing a new file into the DTN 235 network for onward transmission MUST have the Content-Source: field 236 of the data being sent match its Host: field. 238 Hop-by-hop HTTP headers MAY be implemented between peer nodes talking 239 directly. The headers described in section 13.5.1 of [RFC2616] are 240 available. New hop-by-hop headers MUST use the Connection: header 241 approach described in section 14.10 of [RFC2616]. 243 DTN HTTP nodes may optionally GET from and PUT to link-local IP 244 multicast addresses when used over IP subnets. This permits 245 efficient sharing of files on shared LANs, with recipients requesting 246 resends via Content-Range: and checking assembly of file pieces using 247 the Content-MD5: header. A GET to multicast can request a specific 248 file from any available node that has it. The response to a 249 multicast GET SHOULD be unicast, but a multicast HEAD MAY also be 250 sent to inform other nodes that the sender has the file of interest. 251 If other nodes also express interest in the file with GET requests to 252 the sender, that file may later be PUT to a multicast address. 254 (Note that in the alternative Bundle Protocol, the Bundle Endpoint 255 Identifier (EID) can identify a group of endpoints, rather than just 256 one; mapping the Bundle EID onto multicast IP adddresses on IP 257 subnets is possible. Placing textual EIDs directly in HTTP-DTN's 258 Content-Source: and Content-Destination: headers, or in a Host: 259 field, would be possible to interwork HTTP-DTN and bundling.) 261 The utility of HTTP with multicast has been recognised previously as 262 a method of simple service discovery later adopted for the universal 263 plug and play (UPnP) protocol [I-D.draft-goland-http-udp] 264 [I-D.draft-cai-ssdp-v1]. Rather than call out multicast and unicast 265 separately as different protocols to be used by HTTP, recognising 266 that a given destination or address indicates multicast or broadcast 267 use should suffice. 269 Many existing HTTP/1.1 headers are directly useful with HTTP-DTN. 270 For example, ETag: headers are useful for identifying unique copies 271 of files in the network, and can be used to provide globally unique 272 identifiers (GUIDs) for each version of a file. Age: headers are 273 useful for estimating the amount of time a MIME object has been in 274 the network - indicating both transmission and storage times. Last- 275 Modified: times refer to the times on the origin server - that is, 276 the Content-Source: - and should be preserved during onward 277 forwarding. Max-Forwards: provides a TTL hop count and propagation 278 limitation mechanism. 280 3. Other useful proposed additional HTTP headers 282 A number of other additional HTTP headers are proposed here, as 283 likely to be useful. These SHOULD be implemented. These would 284 benefit from being specified more completely, in line with the 285 suggestions in [RFC2774]. 287 An HTTP object is just one binary file; the ability to group objects 288 together is useful (and is done in bundles by the Bundle Protocol). 289 If we call a group of related objects sent from the same source to 290 the same destination a 'package' (a name chosen to avoid any 291 confusion with the Bundle Protocol specification), we can then define 292 simple headers to be sent before each object: 294 Package-ID: - provides a unique textual identifier for the package 296 Package-Item: n of m (e.g. 1 of 7) - order of this HTTP file in the 297 package 299 Package-MD5: - MD5 hash across all Content-MD5: headers added 300 together in order of Package-Item: precedence. 302 A way to request missing Package-Items (from the previous node or 303 from the source) is likely to be very useful. 305 Precedence: headers could set importance of objects - very-high, 306 high, normal low, very-low - to give simple quality of service and 307 prioritization. 309 Some sort of header protection may be a good idea; Content-MD5: 310 covers the message body (entity-body), but not the headers. Header- 311 MD5: could cover some important HTTP headers. Header-MD5 could be 312 preserved across hops if possible, avoiding unnecessary header 313 reordering. Changing timestamps would invalidate the Header-MD5: 314 end-to-end, however - this needs more thought, particularly on where 315 timestamps are placed in HTTP headers. 317 For larger files, stronger mechanisms than MD5 should be examined. 319 Timestamps and how they are handled needs to be examined here in 320 greater detail. HTTP has the same basic assumption as the Bundle 321 Protocol - that all nodes are expected to know the current UTC time. 323 4. Other suggestions on HTTP for use in DTN networks 325 x-application-dtn has previously been proposed as a MIMEtype 326 identifying Bundle Protocol bundles delivered by HTTP. This provides 327 a way to support Bundle Protocol implementations in an HTTP 328 infrastructure. 330 Moving HTTP transfers over DTN networks using the Bundle Protocol has 331 already been proposed [Ott06]. By changing how HTTP is used - hop- 332 by-hop rather than end-to-end - HTTP can be used directly in DTN 333 networks without using the Bundle Protocol at all. 335 5. Security Considerations 337 Better-Than-Nothing Security [RFC5386][RFC5387] is likely to be 338 useful here for ad-hoc communications without the availability of an 339 existing authentication infrastructure. 341 Security considerations and detailed examination of HTTP over TLS 342 (HTTPS) [RFC2817][RFC2818] and secure HTTP [RFC2660] are required 343 here. 345 Many existing security mechanism for HTTP could be used unchanged for 346 HTTP-DTN, if local conditions permit and the supporting 347 infrastructure, .e.g. DNS, is available. However, reusing these 348 directly protects a single-hop transfer between peer nodes. To 349 protect an end-to-end transfer, the security mechanisms would need to 350 be applied using the information used in the Content-Source: and 351 Content-Destination: headers, before applying the local security 352 mechanism for the first peer-peer HTTP transfer. 354 6. IANA Considerations 356 Despite the Content-* rule for rejecting unfamiliar headers that 357 separates HTTP-DTN peers from traditional HTTP servers, it may make 358 sense to use a non-standard port for DTN HTTP use over IP, rather 359 than the well-known port 80. If so, such a port should be requested 360 from IANA. 362 It may be necessary to request a dedicated IPv4 all-hosts multicast 363 address and a dedicated IPv6 link-local multicast addresses for local 364 HTTP DTN use, if local HTTP multicast is considered a desirable 365 feature. 367 7. Acknowledgements 369 Work on the Saratoga protocol inspired some of the concepts that are 370 reused here, and we thank everyone involved in Saratoga's development 371 and implementation. We thank Wes Eddy and Kevin Fall for their 372 review comments. 374 8. References 376 8.1. Normative References 378 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 379 Extensions (MIME) Part One: Format of Internet Message 380 Bodies", RFC 2045, November 1996. 382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 383 Requirement Levels", BCP 14, RFC 2119, March 1997. 385 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 386 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 387 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 389 [RFC2774] Nielsen, H., Leach, P., and S. Lawrence, "An HTTP 390 Extension Framework", RFC 2774, February 2000. 392 8.2. Informative References 394 [Deering98] 395 Deering, S., "Watching the Waist of the Protocol 396 Hourglass", keynote, IEEE International Conference on 397 Network Protocols (ICNP), Austin Texas, October 1998. 399 [I-D.draft-cai-ssdp-v1] 400 Goland, Y., Cai, T., Leach, P., Gu, Y., and S. Albright, 401 "Simple Service Discovery Protocol/1.0 Operating without 402 an Arbiter", draft-cai-ssdp-v1-03 (expired) , 403 October 1999. 405 [I-D.draft-goland-http-udp] 406 Goland, Y., "Multicast and Unicast UDP HTTP Messages", 407 draft-goland-http-udp-01 (expired) , November 1999. 409 [I-D.irtf-dtnrg-bundle-checksum] 410 Eddy, W., Wood, L., and W. Ivancic, "Reliability-only 411 Ciphersuites for the Bundle Protocol", 412 draft-irtf-dtnrg-bundle-checksum-05 (work in progress) , 413 May 2009. 415 [I-D.natarajan-http-over-sctp] 416 Natarajan, P., Amer, P., Leighton, J., and F. Baker, 417 "Using SCTP as a Transport Layer Protocol for HTTP", 418 draft-natarajan-http-over-sctp-01 (work in progress), 419 March 2009. 421 [I-D.wood-tae-specifying-uri-transports] 422 Wood, L., "Specifying transport mechanisms in Uniform 423 Resource Identifiers", 424 draft-wood-tae-specifying-uri-transports-06 (work in 425 progress) , May 2009. 427 [I-D.wood-tsvwg-saratoga] 428 Wood, L., McKim, J., Eddy, W., Ivancic, W., and C. 429 Jackson, "Saratoga: A Scalable File Transfer Protocol", 430 draft-wood-tsvwg-saratoga-03 (work in progress) , 431 May 2009. 433 [Ott06] Ott, J. and D. Kutscher, "Bundling the Web: HTTP over 434 DTN", WNEPT 2006 Workshop on Networking in Public 435 Transport, QShine Conference, Ontario, August 2006. 437 [RFC2660] Rescorla, E. and A. Schiffman, "The Secure HyperText 438 Transfer Protocol", RFC 2660, August 1999. 440 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 441 HTTP/1.1", RFC 2817, May 2000. 443 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 445 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 446 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 447 Networking Architecture", RFC 4838, April 2007. 449 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 450 Specification", RFC 5050, November 2007. 452 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing 453 Security: An Unauthenticated Mode of IPsec", RFC 5386, 454 November 2008. 456 [RFC5387] Touch, J., Black, D., and Y. Wang, "Problem and 457 Applicability Statement for Better-Than-Nothing Security 458 (BTNS)", RFC 5387, November 2008. 460 [Wood08] Wood, L., Eddy, W., and P. Holliday, "A Bundle of 461 Problems", IEEE Aerospace Conference, Big Sky, Montana, 462 March 2009. 464 Authors' Addresses 466 Lloyd Wood 467 Cisco Systems 468 11 New Square Park, Bedfont Lakes 469 Feltham, Middlesex TW14 8HA 470 United Kingdom 472 Phone: +44-20-8824-4236 473 Email: lwood@cisco.com 475 Peter Holliday 476 Cisco Systems 477 Level 12 478 300 Adelaide Street 479 Brisbane, Queensland 4000 480 Australia 482 Phone: +61-2-6216-0604 483 Email: phollida@cisco.com