idnits 2.17.1 draft-ietf-decade-reqs-08.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 (August 13, 2012) is 4273 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-decade-arch-08 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DECADE Y. Gu 3 Internet-Draft Huawei 4 Intended status: Informational D. Bryan 5 Expires: February 14, 2013 Ethernot.org 6 Y. Yang 7 Yale University 8 P. Zhang 9 Tsinghua University/Yale 10 University 11 R. Alimi 12 Google 13 August 13, 2012 15 DECADE Requirements 16 draft-ietf-decade-reqs-08 18 Abstract 20 The target of the DECoupled Application Data Enroute (DECADE) system 21 is to provide an open and standard in-network storage system for 22 applications, primarily P2P (peer-to-peer) applications, to store, 23 retrieve and manage their data. This draft enumerates and explains 24 requirements, not only for storage and retrieval, but also for data 25 management, access control and resource control, that should be 26 considered during the design and implementation of a DECADE- 27 compatible system. These are requirements on the entire system; some 28 of the requirements may eventually be implemented by an existing 29 protocol with/without some extensions (e.g., a protocol used to read 30 and write data from the storage system). The requirements in this 31 document are intended to ensure that a DECADE-compatible system 32 architecture includes all of the desired functionality for intended 33 applications. 35 Requirements Language 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 39 document are to be interpreted as described in [RFC2119]. 41 Status of this Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on February 14, 2013. 58 Copyright Notice 60 Copyright (c) 2012 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 2.1. DECADE-compatible Client . . . . . . . . . . . . . . . . . 6 78 2.2. DECADE-compatible Server . . . . . . . . . . . . . . . . . 6 79 2.3. DECADE Storage Provider . . . . . . . . . . . . . . . . . 6 80 2.4. DECADE Account . . . . . . . . . . . . . . . . . . . . . . 6 81 2.5. Resource Provider . . . . . . . . . . . . . . . . . . . . 6 82 2.6. Resource Consumer . . . . . . . . . . . . . . . . . . . . 6 83 2.7. Content Distribution Application . . . . . . . . . . . . . 6 84 2.8. Target Application . . . . . . . . . . . . . . . . . . . . 7 85 2.9. Application End-Point . . . . . . . . . . . . . . . . . . 7 86 2.10. Data Object . . . . . . . . . . . . . . . . . . . . . . . 7 87 2.11. DECADE-compatible System . . . . . . . . . . . . . . . . . 7 88 2.12. DECADE Resource Protocol (DRP) Functions . . . . . . . . . 7 89 2.13. DECADE Standard Data Transfer Protocol (SDT) Functions . . 7 90 3. System and Protocol Components . . . . . . . . . . . . . . . . 8 91 4. Requirements Structure . . . . . . . . . . . . . . . . . . . . 9 92 5. Data Object Requirements . . . . . . . . . . . . . . . . . . . 9 93 5.1. Data Name Uniqueness . . . . . . . . . . . . . . . . . . . 9 94 5.2. Verifiable Name-Object Binding . . . . . . . . . . . . . . 10 95 5.3. Data Object Size . . . . . . . . . . . . . . . . . . . . . 10 96 5.4. Data Object Attributes . . . . . . . . . . . . . . . . . . 10 97 5.5. Application-defined Object Properties and Metadata . . . . 11 98 6. Access and Authorization Requirements . . . . . . . . . . . . 11 99 6.1. Provider Access . . . . . . . . . . . . . . . . . . . . . 11 100 6.2. Secure Authorization . . . . . . . . . . . . . . . . . . . 11 101 6.3. Consumer Access . . . . . . . . . . . . . . . . . . . . . 12 102 6.4. Provider Authorization When Offline . . . . . . . . . . . 12 103 6.5. Local Authorization . . . . . . . . . . . . . . . . . . . 12 104 6.6. Access Control Granularity . . . . . . . . . . . . . . . . 12 105 6.7. Default Access Permissions . . . . . . . . . . . . . . . . 12 106 6.8. Connectivity Supporting NAT and Firewall Traversal . . . . 13 107 6.9. DECADE Server Discovery . . . . . . . . . . . . . . . . . 13 108 7. Data Transfer Requirements . . . . . . . . . . . . . . . . . . 13 109 7.1. Negotiable Standard Data Transport Protocol . . . . . . . 13 110 7.2. Atomic or Partial Read/Write . . . . . . . . . . . . . . . 14 111 7.3. Secure Data Transport . . . . . . . . . . . . . . . . . . 14 112 7.4. Concurrent Read . . . . . . . . . . . . . . . . . . . . . 14 113 7.5. Concurrent Write . . . . . . . . . . . . . . . . . . . . . 14 114 7.6. Read Before Write Complete . . . . . . . . . . . . . . . . 15 115 7.7. Redirection of Transport . . . . . . . . . . . . . . . . . 15 116 8. Resource Control Requirements . . . . . . . . . . . . . . . . 16 117 8.1. Multiple Applications Sharing Resources . . . . . . . . . 16 118 8.2. Per-Client Resource Policy . . . . . . . . . . . . . . . . 16 119 8.3. Distributed Resource Sharing Specification . . . . . . . . 16 120 8.4. Resource Set . . . . . . . . . . . . . . . . . . . . . . . 17 122 9. Error and Failure Handling Requirements . . . . . . . . . . . 17 123 9.1. Illegal Data Object . . . . . . . . . . . . . . . . . . . 17 124 9.2. Invalid Access Authorization . . . . . . . . . . . . . . . 18 125 9.3. Insufficient Resources . . . . . . . . . . . . . . . . . . 18 126 9.4. Overload Condition . . . . . . . . . . . . . . . . . . . . 18 127 9.5. Attack Mitigation . . . . . . . . . . . . . . . . . . . . 19 128 10. Management Info Requirements . . . . . . . . . . . . . . . . . 19 129 10.1. Account Status . . . . . . . . . . . . . . . . . . . . . . 19 130 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 131 11.1. Authentication and Authorization . . . . . . . . . . . . . 20 132 11.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 20 133 11.3. Attack Mitigation . . . . . . . . . . . . . . . . . . . . 20 134 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 135 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 136 13.1. Normative References . . . . . . . . . . . . . . . . . . . 20 137 13.2. Informative References . . . . . . . . . . . . . . . . . . 20 138 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 21 139 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 141 1. Introduction 143 The object of the DECoupled Application Data Enroute (DECADE) system 144 is to provide an open and standard in-network storage for content 145 distribution applications, where data is typically broken into one or 146 more chunks and then distributed. This may already include many 147 types of applications including P2P applications, IPTV (Internet 148 Protocol Television), and VoD (Video on Demand). (For a precise 149 definition of the applications targeted in DECADE system, see the 150 definition for Target Application in Section 2.) Instead of always 151 transferring data directly from a source/owner client to a requesting 152 client, the source/owner client can write to and manage its content 153 on its in-network storage. The requesting client can get the address 154 of the in-network storage pertaining to the source/owner client and 155 read data from the storage. 157 This draft enumerates and explains the rationale behind specific 158 requirements on the protocol design and on any data store 159 implementation that may be used to implement DECADE servers that 160 should be considered during the design and implementation of a 161 DECADE-compatible system. As such, it does not include general 162 guiding principles. General design considerations, explanation of 163 the problem being addressed, and enumeration of the types of 164 applications to which a DECADE-compatible system may be suited is not 165 considered in this document. For general information, please see 166 [RFC6646] and [I-D.ietf-decade-arch]. 168 This document enumerates the requirements to enable target 169 applications to utilize in-network storage. In this context, using 170 storage resources includes not only basic capabilities such as 171 writing, reading, and managing data, but also controlling access for 172 particular remote clients with which it is sharing data. 173 Additionally, we also consider controlling the resources used by 174 remote clients when they access data as an integral part of utilizing 175 the network storage. 177 This document discusses requirements pertaining to DECADE-compatible 178 protocol(s). In certain deployments, several logical in-network 179 storage systems could be deployed (e.g., within the same 180 administrative domain). These in-network storage systems can 181 communicate and transfer data through internal or non-standard 182 communication messages that are outside of the scope of these 183 requirements, but they should use DECADE-compatible protocol(s) when 184 communicating with other DECADE-compatible in-network storage 185 systems. 187 2. Terminology 189 This document uses the term 'In-network storage' which is defined in 190 [RFC6646]. 192 This document also defines these additional terms: 194 2.1. DECADE-compatible Client 196 A DECADE-compatible client uploads and/or retrieves data from DECADE- 197 compatible servers. We use the shorter term "client" if there is no 198 ambiguity. 200 2.2. DECADE-compatible Server 202 A DECADE-compatible server stores data inside the network, and 203 thereafter manages both the stored data and access to those data. We 204 use the shorter term "server" if there is no ambiguity. 206 2.3. DECADE Storage Provider 208 A DECADE Storage Provider, or Storage Provider for short, deploys 209 and/or manages DECADE-compatible server(s) within a network. 211 2.4. DECADE Account 213 An account of a DECADE-compatible server has associated cryptographic 214 credentials for access control, and resource allocation attributes on 215 the server. 217 2.5. Resource Provider 219 A client which has the account cryptographic credentials of a DECADE 220 account at a DECADE-compatible server. We use the short term 221 "Provider" if there is no ambiguity. 223 2.6. Resource Consumer 225 A client which tries to access a DECADE account but does not have the 226 account's cryptographic credentials. We use the short term 227 "Consumer" if there is no ambiguity. 229 2.7. Content Distribution Application 231 A Content Distribution Application is an application (e.g., P2P, 232 traditional CDN, or hybrid P2P/CDN) designed for dissemination of a 233 large amounts of content (e.g., files, or video streams) to multiple 234 content consumers. Content Distribution Applications may divide 235 content into smaller blocks for dissemination. 237 2.8. Target Application 239 An application with that includes a DECADE-compatible client along 240 with other application functionalities to explicitly control the 241 usage of resources of DECADE-compatible servers to deliver content to 242 other users. A primary type of Target Application we consider is 243 Content Distribution Applications. A Target Application divides 244 content into smaller blocks for more flexible distribution (e.g., 245 over multiple application-level paths). We use the term Target 246 Application to refer to the type of applications that are explicitly 247 (but not exclusively) supported by DECADE system. 249 2.9. Application End-Point 251 An Application End-Point is an instance of a Target Application. A 252 particular Application End-Point might be a Provider, a Consumer, or 253 both. For example, an Application End-Point might be an instance of 254 a video streaming client, or it might be the source providing the 255 video to a set of clients. 257 2.10. Data Object 259 A data object is the unit of data stored and retrieved from a DECADE- 260 compatible server. The data object is a string of raw bytes. The 261 server maintains metadata associated with each data object, but the 262 metadata is not included in the data object. 264 2.11. DECADE-compatible System 266 A system which is composed of DECADE-compatible clients, DECADE- 267 compatible servers and in-network storage. A DECADE-compatible 268 system MUST obey all the requirements defined in this document. 270 2.12. DECADE Resource Protocol (DRP) Functions 272 A set of functions for communication of access control and resource 273 scheduling policies from a DECADE client to a server, as well as 274 between servers. 276 2.13. DECADE Standard Data Transfer Protocol (SDT) Functions 278 A set of functions to be used to transfer data objects to and from a 279 DECADE server. 281 3. System and Protocol Components 283 To organize requirements, we consider that a DECADE-compatible system 284 consists of two logical sets of functions, as shown in Figure 1. The 285 first set of functions, which we refer to as the DECADE Resource 286 Protocol (DRP) functions, is responsible for communication of access 287 control and resource scheduling policies from a client to a server, 288 as well as between servers. A DECADE-compatible system will include 289 exactly one DRP for interoperability and a common format through 290 which these policies can be communicated. 292 Native Application 293 .-------------. Protocol(s) .-------------. 294 | Application | <------------------> | Application | 295 | End-Point | | End-Point | 296 | | | | 297 | .--------. | | .--------. | 298 | | DECADE | | | | DECADE | | 299 | | Client | | | | Client | | 300 | `--------' | | `--------' | 301 `-------------' `-------------' 302 | ^ | ^ 303 DECADE | | Standard | | 304 Resource | | Data DRP | | SDT 305 Protocol | | Transfer | | 306 (DRP) | | (SDT) | | 307 | | | | 308 | | | | 309 | | | | 310 | | | | 311 | | | | 312 | | | | 313 v V v V 314 .=============. DRP .=============. 315 | DECADE | <------------------> | DECADE | 316 | Server | <------------------> | Server | 317 `=============' SDT `=============' 319 Figure 1: Protocol Components and Generic Flow 321 Second, the second set of functions, referred to as the Standard Data 322 Transfer (SDT) functions, will be used to transfer data objects to 323 and from a server. A DECADE-compatible system may support multiple 324 SDT's. If there are multiple SDT's, a negotiation mechanism will be 325 used to determine a suitable SDT between the client and server. 327 The two sets of functions (DRP and SDT) will be either separate or 328 combined on the wire. If they are combined, DRP messages can be 329 piggy-backed within some extension fields provided by certain SDT 330 protocols. In such a scenario, DRP is technically a data structure 331 (transported by other protocols), but it can still be considered as a 332 logical protocol that provides the services of configuring DECADE- 333 compatible resource usage. If the protocols are physically separate 334 on the wire, DRP can take the form of a separate control connection 335 open between the a DECADE-compatible client and server. Hence, this 336 document considers SDT and DRP as two separate, logical functional 337 components for clarity. 339 4. Requirements Structure 341 This document specifies the requirements for the DECADE DRP and SDT 342 functions, either existing ones or new ones, and storage system to 343 enable Target Applications to make use of storage within the network, 344 leaving specific storage system considerations to the implementation 345 of the storage servers as much as possible. For this reason, we 346 consider two primary categories of requirements: 348 o Protocol Requirements: Protocol requirements for Target 349 Applications to make use of in-network storage within their own 350 data dissemination schemes. Development of these requirements is 351 guided by a study of data access, search and management 352 capabilities used by Target Applications. These requirements may 353 be met by a combination of existing protocols and new protocols. 355 o Storage Requirements: Functional requirements necessary for the 356 back-end storage system employed by the DECADE server. 357 Development of these requirements is guided by a study of the data 358 access patterns used by Target Applications. These requirements 359 should be met by the underlying data transport used by DECADE 360 system. In this document, we use "data transport" to refer to a 361 protocol used to read and write data from in-network storage. 363 This specification discusses the requirements of functionality 364 implemented with a storage system and within applications, to permit 365 interoperable communications concerning the manipulation of stored 366 content. 368 5. Data Object Requirements 370 5.1. Data Name Uniqueness 371 REQUIREMENT(S): Each Data Object should be named to allow access. 372 DECADE-compatible protocol(s) MUST support a data object naming 373 scheme that ensures a high probability of uniqueness, with no 374 coordination among multiple Storage Providers. In other words, 375 two Data Objects with the same name should be the same content 376 with high probability. A DECADE-compatible server SHOULD be able 377 to respond to a DECADE-compatible client with an error indicating 378 potential name conflicts. 380 RATIONALE: Although the intention of unique names is to avoid name 381 collisions, it does not have to be an absolutely zero 382 possibility. Hence, it is required to provide a collision 383 handling mechanism. 385 EXCEPTION: While a DECADE-compatible server is overloaded or 386 consider a request as an attack, it does not to generate a 387 response to indicate name collisions. 389 5.2. Verifiable Name-Object Binding 391 5.3. Data Object Size 393 REQUIREMENT(S): DECADE MUST allow for efficient storage and data 394 transfer of small data objects (e.g., 16KB) without large control 395 overhead. 397 RATIONALE: Though Target Applications are frequently used to share 398 large amounts of data (e.g., continuous streams or large files), 399 the data itself is typically subdivided into smaller data objects 400 (chunks) for flexibility (e.g., reliability and multi-path 401 transmission). 403 5.4. Data Object Attributes 405 REQUIREMENT(S): DECADE MUST support the ability to associate a set 406 of system attributes with a data object with a scope local to a 407 DECADE-compatible server. In particular, the set MUST include 408 time-to-live (or expiration time), creation timestamp, object 409 size, and object type. A DECADE-compatible client, with access 410 permission, MUST be able to query the set of system attributes. 411 The transmission of the attributes MUST use an operating system- 412 independent and architecture-independent standard format. An 413 ability to extend the set of attributes MUST exist. 415 RATIONALE: The values of attributes associated with a data object 416 are local to a particular DECADE-compatible server. These 417 attributes may be used as hints to the storage system, internal 418 optimizations, or as additional information query-able by DECADE- 419 compatible clients. The particular requirement for including 420 time-to-live (TTL) is that a data object written by a DECADE- 421 compatible client may be usable only within a certain window of 422 time, such as in a live-streaming P2P application. Providing a 423 time-to-live value for a data object (e.g., at the time it is 424 written) can reduce management overhead by avoiding many 'delete' 425 commands sent to DECADE-compatible server. The server may still 426 retain a data object for bandwidth optimization, but this should 427 be guided by the privacy policy of the DECADE Storage Provider. 429 5.5. Application-defined Object Properties and Metadata 431 REQUIREMENT(S): DECADE-compatible clients and DECADE-compatible 432 servers MUST NOT be able to associate Application-defined 433 properties (metadata) with data objects beyond what is provided 434 by Section 5.4. 436 RATIONALE: Associating key-value pairs that are defined by Target 437 Applications with data objects introduces substantial complexity. 438 If Target Applications wish to associate additional metadata with 439 a data object, possible alternatives include (1) managing such 440 metadata within the Target Application itself, (2) storing 441 metadata inside the data object, or (3) storing metadata in a 442 different data object at the DECADE-compatible server. 444 6. Access and Authorization Requirements 446 6.1. Provider Access 448 REQUIREMENT(S): A Provider MUST be able to access the resources of 449 its account. 451 RATIONALE: After a DECADE-compatible client owns an account on a 452 DECADE-compatible server, it should be able to read data from and 453 write data to the server. 455 6.2. Secure Authorization 457 REQUIREMENT(S): Access to an account on a server MUST be granted to 458 a provider based on cryptographic security. 460 RATIONALE: DECADE-compatible clients may be operating on hosts 461 without constant network connectivity or without a permanent 462 attachment address (e.g., mobile devices). To support access 463 control with such hosts, DECADE-compatible servers must support 464 access control policies that use cryptographic credentials, not 465 simply by tying access to IP addresses. 467 6.3. Consumer Access 469 REQUIREMENT(S): A Provider MUST be able to indicate to its server on 470 whether a Consumer can access its subscribed resources. 472 RATIONALE: Endpoints in Target Applications may choose different 473 servers. Thus, to be useful by Target Applications, a DECADE- 474 compatible client must be able to specify policies on whether 475 other DECADE-compatible clients can access its resources. The 476 other clients may or may not be known to the server. 478 6.4. Provider Authorization When Offline 480 REQUIREMENT(S): A Provider MUST be able to grant access to a 481 Consumer even if the Provider is not actively running or 482 connected to its DECADE-compatible server. 484 RATIONALE: If an application desires, it can authorize other clients 485 to access its storage even after the application exits or network 486 connectivity is lost. An example use case is mobile scenarios, 487 where a client can lose and regain network connectivity often. 489 6.5. Local Authorization 491 REQUIREMENT(S): A Provider MUST be able to indicate, without 492 contacting its server, access control policies for Consumers. 493 DECADE-compatible server MUST be able to authenticate the access 494 control policies in this situation. 496 RATIONALE: This requirement is related with the preceding 497 requirement, but in a perspective (i.e., protocol design). See 498 discussions in Section 8.3. 500 6.6. Access Control Granularity 502 REQUIREMENT(S): A Provider MUST be able to control which individual 503 clients are authorized to read/write which particular data 504 objects from/to its in-network storage. 506 RATIONALE: A Target Application should able to conduct access 507 control on the granularity of individual clients, individual data 508 objects. 510 6.7. Default Access Permissions 511 REQUIREMENT(S): Unless read or write access is granted by a 512 Provider, the default permission MUST be no access. 514 RATIONALE: This requirement is to protect client privacy by default. 516 6.8. Connectivity Supporting NAT and Firewall Traversal 518 REQUIREMENT(S): A client that is authorized to access a server MUST 519 be supported to conduct NAT (Network Address Translation) and 520 firewall traversal. In particular, network connections between a 521 DECADE-compatible client and a DECADE-compatible server MUST be 522 initiated by the client (i.e., the server must not initiate a 523 connection to the client). 525 RATIONALE: Firewalls and NATs are widely used in the Internet today, 526 both in ISP (Internet Service Provider) and Enterprise networks 527 and by consumers. Many firewalls and NATs are configured by 528 default to block incoming connections, which helps to mitigate 529 security risks. Deployment of a DECADE-compatible system must 530 not require manual modifications to such devices. This 531 requirement applies to both potential new protocol that may be 532 developed by the DECADE Working Group and any data transport used 533 with DECADE protocol. 535 6.9. DECADE Server Discovery 537 REQUIREMENT(S): A mechanism for a Provider to discover and connect 538 to its assigned server MUST be supported. The discovery SHOULD 539 leverage existing mechanisms and protocols wherever possible. No 540 new discovery mechanism will be defined unless there is enough 541 evidence that no existing mechanism can work. 543 RATIONALE: Existing protocols such as DNS and DHCP are widespread. 544 Using existing protocols, or combinations of the protocols that 545 have been specified in other contexts, is strictly preferred over 546 developing a new discovery protocol. 548 7. Data Transfer Requirements 550 7.1. Negotiable Standard Data Transport Protocol 552 REQUIREMENT(S): A DECADE-compatible client MUST be able to negotiate 553 with a DECADE-compatible server about which protocol it can use 554 to read data from and write data. DECADE MUST specify at least 555 one mandatory transport protocol to be supported by 556 implementations; usage of a different protocol may be selected 557 via negotiation. 559 RATIONALE: Since typical data transport protocols (e.g., NFS and 560 WebDAV) already provide read and write operations for network 561 storage, it may not be necessary to define such operations in a 562 new DECADE protocol. However, because of the particular 563 application requirements and deployment considerations, different 564 applications may support different protocols. Thus, a DECADE 565 client must be able to select an appropriate protocol also 566 supported by the in-network storage. 568 7.2. Atomic or Partial Read/Write 570 REQUIREMENT(S): A DECADE-compatible server MUST support the ability 571 to read/write a complete data object in one request. It MAY 572 support range read/write. 574 RATIONALE: Depending on the object size (e.g., chunk size) used by a 575 Target Application, the application may need to send data to the 576 DECADE-compatible server in multiple round. 578 7.3. Secure Data Transport 580 REQUIREMENT(S): A secure transport MUST be implemented for all 581 communications between a DECADE-compatible client and DECADE- 582 compatible server. 584 RATIONALE: Target Applications may wish to write sensitive data. To 585 satisfy this use case, the communication between a DECADE- 586 compatible client and DECADE-compatible server must be 587 transported over a secure transport protocol (e.g., SSL/TLS). 589 7.4. Concurrent Read 591 REQUIREMENT(S): A DECADE-compatible server MUST allow for multiple 592 simultaneous readers for a data object. 594 RATIONALE: One characteristic of Target Applications is the ability 595 to upload an object to multiple clients. Thus, it is natural for 596 DECADE-compatible server to allow multiple readers to read the 597 same object concurrently. 599 7.5. Concurrent Write 601 REQUIREMENT(S): A DECADE-compatible server MUST NOT allow multiple 602 simultaneous writers for the same object. A DECADE-compatible 603 server SHOULD respond to each of the writers with an error. 605 RATIONALE: This avoids data corruption in a simple way while 606 remaining efficient. Alternately, the DECADE-compatible server 607 would need to either manage locking, handle write collisions, or 608 merge data, all of which reduce efficiency and increase 609 complexity. 611 EXCEPTION: While a DECADE-compatible server is overloaded or 612 considers a request as an attack, it does not generate a 613 response. 615 7.6. Read Before Write Complete 617 REQUIREMENT(S): A DECADE-compatible server MAY allow readers to read 618 a data object before it has been completely written. In case of 619 a write error in such a case, the DECADE-compatible server SHOULD 620 respond to the reading client with an error indicating that the 621 write has failed. 623 RATIONALE: Some Target Applications (in particular, P2P streaming) 624 can be sensitive to latency. A technique to reduce latency is to 625 remove store-and-forward delays for data objects (e.g., make the 626 object available before it is completely written). Appropriate 627 handling for error conditions (e.g., a disappearing writer) needs 628 to be specified. 630 EXCEPTION: While a DECADE-compatible server is overloaded or 631 considers a request as an attack, it does not generate a 632 response. 634 7.7. Redirection of Transport 636 REQUIREMENT(S): A DECADE-compatible server SHOULD be able to 637 redirect requests to another DECADE-compatible server. This may 638 either be in response to an error, failure, overload, or to 639 support capabilities such as load balancing. 641 RATIONALE: A DECADE-compatible server may opt to redirect requests 642 to another server to support capabilities such as load balancing, 643 or if the implementation decides that another DECADE-compatible 644 server is in a better position to handle the request due to 645 either its location in the network, server status, or other 646 consideration. 648 EXCEPTION: A DECADE-compatible server can be configured by its 649 service provider to support or not support redirection 650 functionality. 652 8. Resource Control Requirements 654 8.1. Multiple Applications Sharing Resources 656 REQUIREMENT(S): A client MUST be able to indicate to a DECADE- 657 compatible server about resource sharing policies among multiple 658 Target Applications being run/managed by the same client. 660 RATIONALE: A client owning a DECADE account may provide the 661 account's cryptographic credentials to multiple Providers of 662 multiple target applications. For example, the client may run 663 one or more video-on-demand application(s) and a live-streaming 664 application(s) which both make use of the client's in-network 665 storage. The concurrently running applications may be running on 666 different machines (e.g., multiple machines at the same home 667 network) and may not directly communicate, except through user 668 coordination 670 8.2. Per-Client Resource Policy 672 REQUIREMENT(S): A Provider MUST be able to specify resource policies 673 (bandwidth share, storage quota, and network connection quota) to 674 individual Consumers for reading from and writing data to its in- 675 network storage within a particular range of time. 677 RATIONALE: Target Applications can rely on control of resources on a 678 per-client basis. For example, application policy may indicate 679 that certain remote clients have a higher bandwidth share for 680 receiving data [LLSB08]. Additionally, bandwidth share for 681 receiving data [LLSB08]. Additionally, certain data (e.g., 682 chunks) may be distributed with a higher priority. As another 683 example, when allowing a remote client to write data to a user's 684 in-network storage, the remote client may be restricted to write 685 less than 100MB of data in total. Since the client may need to 686 manage multiple clients accessing its data, it should be able to 687 indicate the time over which the granted resources are usable. 688 For example, an expiration time for the access could be indicated 689 to the DECADE-compatible server after which no resources are 690 granted (e.g., indicate error as access denied). 692 8.3. Distributed Resource Sharing Specification 694 REQUIREMENT(S): A Provider MUST be able to indicate to its DECADE- 695 compatible server, without itself contacting the server, resource 696 control policies for a Consumer. The DECADE-compatible server 697 MUST be able to authenticate the resource control policies. 699 RATIONALE: One important consideration for a DECADE-compatible 700 server is scalability, since a single storage element may be used 701 to support many users. Many Target Applications use small chunk 702 sizes and frequent data exchanges. If such an application 703 employed resource control and contacted the DECADE-compatible 704 server for each data exchange, this could present a scalability 705 challenge for the server as well as additional latency for 706 clients. 708 The preferred way is to let requesting clients obtain signed 709 resource control policies (in the form of a token) from the 710 owning client, and then requesting clients can present the policy 711 to a DECADE-compatible server directly. This can result in 712 reduced messaging handled by the DECADE-compatible server. 714 8.4. Resource Set 716 REQUIREMENT(S): A DECADE-compatible server MUST allow specification 717 on the following resources: storage, bandwidth, and number of 718 connections, and MAY allow additional types of resources to be 719 specified. 721 RATIONALE: The minimum set of resources need to include the most 722 common resources. 724 9. Error and Failure Handling Requirements 726 9.1. Illegal Data Object 728 REQUIREMENT(S): A DECADE-compatible server SHOULD provide an error 729 indicating that (1) data was rejected from being written, (2) 730 deleted, or (3) marked unavailable. 732 RATIONALE: DECADE Storage Providers may require the ability to (1) 733 avoid storing, (2) delete, or (3) quarantine certain data that 734 has been identified as illegal (or otherwise prohibited). It is 735 not specified how such data is identified, but applications 736 employing DECADE-compatible servers should not break if a Storage 737 Provider is obligated to enforce such policies. Appropriate 738 error conditions should be indicated to applications. 740 EXCEPTION: A DECADE-compatible server should be able to be 741 configured to suppress Illegal Data Object responses for security 742 reasons. 744 9.2. Invalid Access Authorization 746 REQUIREMENT(S): A DECADE-compatible server SHOULD provide an error 747 indicating that the request does not have a valid access 748 authorization. 750 RATIONALE: DECADE-compatible clients may request data objects to 751 which they do not have a valid authorization, and DECADE- 752 compatible servers should be able to signal that this has 753 occurred. Invalid authorization may be due to a combination of 754 credential issues as well as additional policies defined by a 755 Storage Provider. 757 EXCEPTION: A DECADE-compatible server should be able to be 758 configured to suppress Invalid Authorization responses for 759 security reasons. 761 9.3. Insufficient Resources 763 REQUIREMENT(S): A DECADE-compatible server SHOULD provide a response 764 indicating to a DECADE-compatible client that resources (e.g., 765 storage space) were not available to service its request (e.g., 766 storage quota exceeded when attempting to write data). 768 RATIONALE: The Insufficient Resources response allows a client to 769 back off, free up necessary resources or waiting for such 770 resources to be freed. 772 EXCEPTION: A DECADE-compatible server may not provide such a 773 response if doing so increases the load or due to security 774 concerns. 776 9.4. Overload Condition 778 REQUIREMENT(S): A DECADE-compatible server, which is operating close 779 to its capacity limit (e.g., too busy servicing other requests), 780 MUST be permitted to reject requests and not be required to 781 generate response to additional requests. A DECADE-compatible 782 server MUST also be permitted to redirect requests as a load- 783 shedding technique. 785 RATIONALE: The Insufficient Resources response allows a client to 786 back off, free up necessary resources or waiting for such 787 resources to be freed. 789 EXCEPTION: A DECADE-compatible server may not provide such a 790 response if doing so increases the load or due to security 791 concerns. 793 9.5. Attack Mitigation 795 REQUIREMENT(S): A DECADE-compatible server MUST be permitted to 796 reject suspicious requests and not be required to generate 797 responses (e.g., if a client's rate of requests exceeds a pre- 798 defined threshold). 800 RATIONALE: Malicious clients may attempt to attack a DECADE- 801 compatible server by specifying many chunks to increase total 802 throughput or inciting overload conditions. A DECADE-compatible 803 server is permitted to reject or ignore requests that are deemed 804 suspicious according to policies set by its DECADE service 805 provider. 807 10. Management Info Requirements 809 10.1. Account Status 811 REQUIREMENT(S): A Provider MUST be able to query the resource quota 812 as well the current usage. The response from the server MUST 813 include resource usage resulting from both the client's own usage 814 and usage by other clients that have been authorized to read/ 815 write objects on that client's account. 817 RATIONALE: The resources used by a client are not necessarily 818 directly-attached (e.g., disk, network interface, etc). Thus, 819 the client cannot locally determine how much resources are being 820 used. Before storing and retrieving data, a client should be 821 able to determine which data is available (e.g., after an 822 application restart). 824 11. Security Considerations 826 The security model is an important component of a DECADE-compatible 827 system. It is crucial for users to be able to manage and limit 828 distribution of content to only authorized parties, and the mechanism 829 needs to work on the general Internet which spans multiple 830 administrative and security domains. Previous sections have 831 enumerated detailed requirements, but this section discusses the 832 overall approach and other considerations that do not merit 833 requirements. 835 11.1. Authentication and Authorization 837 A DECADE-compatible server must validate an request to access the in- 838 network storage. 840 11.2. Confidentiality 842 DECADE-compatible Servers provide the ability to write raw data 843 objects (subject to any policies instituted by the owner/ 844 administrator of the Storage Provider). Thus, DECADE-compatible 845 clients may opt to encrypt data before it is transported to the 846 server. 848 11.3. Attack Mitigation 850 The particular resource control policy may be open to certain attacks 851 by clients. For example by specifying many small chunks to increase 852 total throughput or inciting overload conditions are techniques that 853 may be used by a client. 855 12. IANA Considerations 857 There are no IANA considerations with this document. 859 13. References 861 13.1. Normative References 863 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 864 Requirement Levels", BCP 14, RFC 2119, March 1997. 866 [RFC6646] Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled 867 Application Data Enroute (DECADE) Problem Statement", 868 RFC 6646, July 2012. 870 13.2. Informative References 872 [I-D.ietf-decade-arch] 873 Alimi, R., Rahman, A., Kutscher, D., and Y. Yang, "DECADE 874 Architecture", draft-ietf-decade-arch-08 (work in 875 progress), July 2012. 877 [LLSB08] Levin, D., LaCurts, K., Spring, N., and B. Bhattacharjee, 878 "BitTorrent is an Auction: Analyzing and Improving 879 BitTorrent's Incentives", SIGCOMM 2008, August 2008. 881 Appendix A. Acknowledgments 883 We would also like to thank Haibin Song for substantial contributions 884 to earlier versions of this document. We would also like to thank 885 Reinaldo Penno, Alexey Melnikov, Rich Woundy, Ning Zong, Roni Even, 886 David McDysan, Borje Ohlman, Dirk Kutscher, Akbar Rahman, Xiao Zhu, 887 Yunfei Zhang, Peng Zhang and Jin Peng for contributions and general 888 feedback. 890 Authors' Addresses 892 Yingjie Gu 893 Huawei 894 No. 101 Software Avenue 895 Nanjing, Jiangsu Province 210012 896 P.R.China 898 Phone: +86-25-56624760 899 Email: guyingjie@huawei.com 901 David A. Bryan 902 Ethernot.org 904 Email: dbryan@ethernot.org 906 Yang Richard Yang 907 Yale University 909 Email: yry@cs.yale.edu 911 Peng Zhang 912 Tsinghua University/Yale University 914 Email: p.zhang@yale.edu 916 Richard Alimi 917 Google 919 Email: ralimi@google.com