idnits 2.17.1 draft-ietf-decade-reqs-06.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2012) is 4399 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'PPLive' is defined on line 971, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-decade-problem-statement-03 == Outdated reference: A later version (-10) exists of draft-ietf-decade-arch-02 Summary: 0 errors (**), 0 flaws (~~), 5 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: September 13, 2012 Polycom, Inc. 6 Y. Yang 7 Yale University 8 R. Alimi 9 Google 10 March 12, 2012 12 DECADE Requirements 13 draft-ietf-decade-reqs-06 15 Abstract 17 The target of the DECoupled Application Data Enroute (DECADE) system 18 is to provide an open and standard in-network storage system for 19 applications, primarily P2P (peer-to-peer) applications, to store, 20 retrieve and manage their data. This draft enumerates and explains 21 requirements, not only for storage and retrieval, but also for data 22 management, access control and resource control, that should be 23 considered during the design and implementation of a DECADE- 24 compatible system. These are requirements on the entire system; some 25 of the requirements may eventually be implemented by an existing 26 protocol with/without some extensions (e.g., a protocol used to read 27 and write data from the storage system). The requirements in this 28 document are intended to ensure that a DECADE-compatible system 29 architecture includes all of the desired functionality for intended 30 applications. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in [RFC2119]. 38 Status of this Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on September 13, 2012. 55 Copyright Notice 57 Copyright (c) 2012 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 6 74 3. Requirements Structure . . . . . . . . . . . . . . . . . . . . 7 75 4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 7 76 4.1. Overall Protocol Requirements . . . . . . . . . . . . . . 7 77 4.1.1. Connectivity Concerns . . . . . . . . . . . . . . . . 7 78 4.1.1.1. NATs and Firewalls . . . . . . . . . . . . . . . . 8 79 4.1.1.2. Connections to Clients . . . . . . . . . . . . . . 8 80 4.1.2. Security . . . . . . . . . . . . . . . . . . . . . . . 8 81 4.1.2.1. Secure Transport . . . . . . . . . . . . . . . . . 8 82 4.1.2.2. Gaming Prevention . . . . . . . . . . . . . . . . 8 83 4.1.3. Error and Failure Conditions . . . . . . . . . . . . . 9 84 4.1.3.1. Overload Condition . . . . . . . . . . . . . . . . 9 85 4.1.3.2. Insufficient Resources . . . . . . . . . . . . . . 9 86 4.1.3.3. Unavailable and Deleted Data . . . . . . . . . . . 10 87 4.1.3.4. Insufficient Permissions . . . . . . . . . . . . . 10 88 4.1.3.5. Redirection . . . . . . . . . . . . . . . . . . . 10 89 4.2. Transfer Requirements . . . . . . . . . . . . . . . . . . 11 90 4.2.1. Data Object Size . . . . . . . . . . . . . . . . . . . 11 91 4.3. Data Access Requirements . . . . . . . . . . . . . . . . . 11 92 4.3.1. Reading/Writing Own Storage . . . . . . . . . . . . . 11 93 4.3.2. Access by Remote Clients . . . . . . . . . . . . . . . 11 94 4.3.3. Negotiable Data Transport Protocol . . . . . . . . . . 12 95 4.3.4. Separation of Data and Control Policies . . . . . . . 12 96 4.4. Data Management Requirements . . . . . . . . . . . . . . . 12 97 4.4.1. Agnostic of reliability . . . . . . . . . . . . . . . 12 98 4.4.2. Data Object Attributes . . . . . . . . . . . . . . . . 13 99 4.4.3. Time-to-live for Written Data Objects . . . . . . . . 13 100 4.4.4. Application-defined Properties and Metadata . . . . . 13 101 4.4.5. Offline Usage . . . . . . . . . . . . . . . . . . . . 14 102 4.5. Data Naming Requirements . . . . . . . . . . . . . . . . . 14 103 4.5.1. Unique Names . . . . . . . . . . . . . . . . . . . . . 14 104 4.6. Resource Control . . . . . . . . . . . . . . . . . . . . . 15 105 4.6.1. Multiple Applications . . . . . . . . . . . . . . . . 15 106 4.6.2. Per-Remote-Client, Per-Data Control . . . . . . . . . 15 107 4.6.3. Resource Control Set . . . . . . . . . . . . . . . . . 16 108 4.6.4. Server Involvement . . . . . . . . . . . . . . . . . . 16 109 4.7. Authorization . . . . . . . . . . . . . . . . . . . . . . 16 110 4.7.1. Per-Remote-Client, Per-Data Read Access . . . . . . . 16 111 4.7.2. Per-User Write Access . . . . . . . . . . . . . . . . 17 112 4.7.3. Default Access Permissions . . . . . . . . . . . . . . 17 113 4.7.4. Authorization Checks . . . . . . . . . . . . . . . . . 17 114 4.7.5. Cryptographic Credentials . . . . . . . . . . . . . . 17 115 4.7.6. Server Involvement . . . . . . . . . . . . . . . . . . 18 116 4.7.7. Protocol Reuse . . . . . . . . . . . . . . . . . . . . 18 117 5. Storage Requirements . . . . . . . . . . . . . . . . . . . . . 18 118 5.1. Immutable Data . . . . . . . . . . . . . . . . . . . . . . 18 119 5.2. Explicit Deletion of Data . . . . . . . . . . . . . . . . 19 120 5.3. Multiple writing . . . . . . . . . . . . . . . . . . . . . 19 121 5.4. Multiple reading . . . . . . . . . . . . . . . . . . . . . 19 122 5.5. Reading before completely written . . . . . . . . . . . . 19 123 5.6. Writing model . . . . . . . . . . . . . . . . . . . . . . 20 124 5.7. Storage Status . . . . . . . . . . . . . . . . . . . . . . 20 125 6. Discovery Requirements . . . . . . . . . . . . . . . . . . . . 21 126 6.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 21 127 6.1.1. Support for Clients Behind NATs and Firewalls . . . . 21 128 6.1.2. Prefer Existing Protocols . . . . . . . . . . . . . . 21 129 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 130 7.1. Authentication and Authorization . . . . . . . . . . . . . 21 131 7.2. Encrypted Data . . . . . . . . . . . . . . . . . . . . . . 22 132 7.3. Protection against Gaming . . . . . . . . . . . . . . . . 22 133 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 134 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 135 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 136 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 137 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 23 138 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 140 1. Introduction 142 The object of the DECoupled Application Data Enroute (DECADE) system 143 is to provide an open and standard in-network storage for content 144 distribution applications, where data is typically broken into one or 145 more chunks and then distributed. This may already include many 146 types of applications including P2P applications, IPTV (Internet 147 Protocol Television), and VoD (Video on Demand). (For a precise 148 definition of the applications targeted in DECADE system, see the 149 definition for Target Application in Section 2.) Instead of always 150 transferring data directly from a source/owner client to a requesting 151 client, the source/owner client can write to and manage its content 152 on its in-network storage. The requesting client can get the address 153 of the in-network storage pertaining to the source/owner client and 154 read data from the storage. 156 This draft enumerates and explains the rationale behind specific 157 requirements on the protocol design and on any data store 158 implementation that may be used to implement DECADE servers that 159 should be considered during the design and implementation of a 160 DECADE-compatible system. As such, it does not include general 161 guiding principles. General design considerations, explanation of 162 the problem being addressed, and enumeration of the types of 163 applications to which a DECADE-compatible system may be suited is not 164 considered in this document. For general information, please see 165 [I-D.ietf-decade-problem-statement] and [I-D.ietf-decade-arch]. 167 This document enumerates the requirements to enable target 168 applications to utilize in-network storage. In this context, using 169 storage resources includes not only basic capabilities such as 170 writing, reading, and managing data, but also controlling access for 171 particular remote clients with which it is sharing data. 172 Additionally, we also consider controlling the resources used by 173 remote clients when they access data as an integral part of utilizing 174 the network storage. 176 This document discusses requirements pertaining to DECADE-compatible 177 protocol(s). In certain deployments, several logical in-network 178 storage systems could be deployed (e.g., within the same 179 administrative domain). These in-network storage systems can 180 communicate and transfer data through internal or non-standard 181 communication messages that are outside of the scope of these 182 requirements, but they should use DECADE-compatible protocol(s) when 183 communicating with other DECADE-compatible in-network storage 184 systems. 186 2. Terminology and Concepts 188 This document uses the term 'In-network storage' which is defined in 189 [I-D.ietf-decade-problem-statement]. 191 This document also defines additional terminology: 193 Target Application: An application (typically installed at end-hosts) 194 with the ability to explicitly control usage of network and/or 195 storage resources to deliver content to a large number of users. 196 This includes scenarios where multiple applications or entities 197 cooperate, such as with P2P, CDN, and hybrid P2P/CDN architectures. 198 Such applications distribute large amounts of content (e.g., a large 199 file, or video stream) by dividing the content into smaller blocks 200 for more flexible distribution (e.g., over multiple application-level 201 paths). The distributed content is immutable (though it may be 202 deleted and replaced). We use the term Target Application to refer 203 to the type of applications that are explicitly (but not exclusively) 204 supported by DECADE system. 206 DECADE-compatible server: A physical entity that can control and 207 manage in-network storage or a logical control and management 208 component on in-network storage. 210 DECADE-compatible client: An interface for target applications to 211 make use of in-network storage in DECADE system. DECADE client is 212 usually a software hosted on a end device, such as a PC or laptop. A 213 DECADE-compatible client be employed by a target applications to 214 communicate with DECADE server to make use of in-network storage. 216 DECADE-compatible protocol: A protocol between a DECADE-compatible 217 client and a DECADE-compatible server. In this document, a DECADE- 218 compatible protocol represents the protocols, both existing and 219 potential new protocols, that can be used by a DECADE-compatible 220 client and DECADE-compatible server to communicate with each other. 222 DECADE service provider: the provider who provides DECADE service to 223 a DECADE-compatible client. DECADE service provider can be an in- 224 network storage provider, or service provider who serve users of 225 DECADE-compatible clients by renting or purchasing in-network storage 226 from in-network storage provider. 228 DECADE-compatible system: a system which is composed of DECADE- 229 compatible clients, DECADE-compatible servers and in-network storage. 230 A DECADE-compatible protocol is used for communication between 231 DECADE-compatible clients and DECADE-compatible servers. A DECADE- 232 compatible system MUST obey all the requirements defined in this 233 document. 235 3. Requirements Structure 237 A DECADE-compatible protocol is intended to sit between Target 238 Applications and a storage system. This document does not intend to 239 develop yet another storage system or a new protocol, but rather to 240 explore the requirements for the DECADE protocols, either existing 241 ones or a potential new one, and storage system to enable Target 242 Applications to make use of storage within the network, leaving 243 specific storage system considerations to the implementation of the 244 storage servers as much as possible. For this reason, we have 245 divided the requirements into two primary categories: 247 o Protocol Requirements: Protocol requirements for Target 248 Applications to make use of in-network storage within their own 249 data dissemination schemes. Development of these requirements is 250 guided by a study of data access, search and management 251 capabilities used by Target Applications. These requirements may 252 be met by a combination of existing protocols and new protocols. 254 o Storage Requirements: Functional requirements necessary for the 255 back-end storage system employed by the DECADE server. 256 Development of these requirements is guided by a study of the data 257 access patterns used by Target Applications. These requirements 258 should be met by the underlying data transport used by DECADE 259 system. In this document, we use "data transport" to refer to a 260 protocol used to read and write data from in-network storage. 262 This specification discusses the requirements of functionality 263 implemented with a storage system and within applications, to permit 264 interoperable communications concerning the manipulation of stored 265 content. 267 4. Protocol Requirements 269 This section details the requirements of DECADE-compatible 270 protocol(s) that can be used in a DECADE-compatible system 271 implementation. The DECADE protocols can be existing protocols, as 272 long as they satisfy the requirements specified in this document, or 273 a new protocol which must obey all the requirements too. 275 4.1. Overall Protocol Requirements 277 4.1.1. Connectivity Concerns 278 4.1.1.1. NATs and Firewalls 280 REQUIREMENT(S): DECADE-compatible protocol(s) MUST be usable across 281 firewalls and NAT (Network Address Translation) devices. DECADE 282 protocol MUST NOT pass literal IP addresses in messages. 284 RATIONALE: Firewalls and NATs are widely used in the Internet today, 285 both in ISP (Internet Service Provider) and Enterprise networks 286 and by consumers. Deployment of a DECADE-compatible system must 287 not require modifications to such devices (beyond, perhaps, 288 reconfiguration). This requirement applies to both potential new 289 protocol that may be developed by the DECADE Working Group and 290 any data transport used with DECADE protocol. 292 4.1.1.2. Connections to Clients 294 REQUIREMENT(S): Network connections between DECADE-compatible client 295 and DECADE-compatible server MUST be initiated by the client 296 (i.e., the server must not initiate a connection with the 297 client). 299 RATIONALE: Many household networks and operating systems have 300 firewalls and NATs configured by default to block incoming 301 connections. To ease deployment by avoiding configuration 302 changes and help mitigate security risks, a DECADE-compatible 303 client must not be required to listen for any incoming network 304 connections (beyond what is required by any other already- 305 deployed application). 307 4.1.2. Security 309 4.1.2.1. Secure Transport 311 REQUIREMENT(S): A secure transport MUST be implemented for all 312 communications between a DECADE-compatible client and DECADE- 313 compatible server. 315 RATIONALE: Target Applications may wish to write sensitive data. To 316 satisfy this use case, the communication between a DECADE- 317 compatible client and DECADE-compatible server must be 318 transported over a secure transport protocol (e.g., SSL/TLS). 320 4.1.2.2. Gaming Prevention 321 REQUIREMENT(S): A DECADE-compatible server MUST be permitted to 322 reject suspicious requests and not be required to generate 323 responses (e.g., if a client's rate of requests exceeds a pre- 324 defined threshold). 326 RATIONALE: Malicious clients may attempt to attack a DECADE- 327 compatible server by specifying many chunks to increase total 328 throughput or inciting overload conditions. A DECADE-compatible 329 server is permitted to reject or ignore requests that are deemed 330 suspicious according to policies set by its DECADE service 331 provider. 333 4.1.3. Error and Failure Conditions 335 4.1.3.1. Overload Condition 337 REQUIREMENT(S): A DECADE-compatible server, which is operating close 338 to its capacity limit (e.g., too busy servicing other requests), 339 MUST be permitted to reject requests and not be required to 340 generate response to additional requests. A DECADE-compatible 341 server MUST also be permitted to redirect requests (see Section 342 4.1.3.5) as a load- shedding technique. 344 RATIONALE: Forcing a DECADE-compatible server to respond to requests 345 when operating close to its capacity can impair its ability to 346 service existing requests, and thus is permitted to avoid 347 generating response to additional requests. 349 4.1.3.2. Insufficient Resources 351 REQUIREMENT(S): A DECADE-compatible server SHOULD be able to provide 352 an error condition indicating to a DECADE-compatible client that 353 resources (e.g., storage space) were not available to service a 354 request (e.g., storage quota exceeded when attempting to write 355 data). 357 RATIONALE: The currently-used resource levels within the in-network 358 storage may not be locally-discoverable. In order to allocate 359 resources appropriately amongst remote clients, a DECADE- 360 compatible client must be able to determine when resource limits 361 have been reached. The DECADE-compatible client can then respond 362 by explicitly freeing necessary resources or waiting for such 363 resources to be freed. 365 EXCEPTION: While a DECADE-compatible server is in the situation that 366 is described in Section 4.1.2.2 or Section 4.1.3.1, it need not 367 to respond with error condition. 369 4.1.3.3. Unavailable and Deleted Data 371 REQUIREMENT(S): A DECADE-compatible server SHOULD be able to provide 372 error conditions indicating that (1) data was rejected from being 373 written, (2) deleted, or (3) marked unavailable by a storage 374 provider. 376 RATIONALE: DECADE service providers may require the ability to (1) 377 avoid storing, (2) delete, or (3) quarantine certain data that 378 has been identified as illegal (or otherwise prohibited). It is 379 not specified how such data is identified, but applications 380 employing DECADE-compatible servers should not break if a storage 381 provider is obligated to enforce such policies. Appropriate 382 error conditions should be indicated to applications. 384 EXCEPTION: A DECADE-compatible server should be able to configured 385 as not respond to any request to access unavailable or deleted 386 data on the in- network storage, for example, for security 387 reasons. 389 4.1.3.4. Insufficient Permissions 391 REQUIREMENT(S): A DECADE-compatible server MUST be able to provide 392 error conditions indicating that the requesting client does not 393 have sufficient permissions to access requested data objects. 395 RATIONALE: DECADE-compatible clients may request objects to which 396 they do not have sufficient access permissions, and DECADE- 397 compatible servers must be able to signal that this has occurred. 398 Access permissions may be insufficient due to a combination of 399 the credentials presented by a client as well as additional 400 policies defined by the storage provider. 402 4.1.3.5. Redirection 404 REQUIREMENT(S): A DECADE-compatible server SHOULD be able to 405 redirect requests to another DECADE-compatible server. This may 406 either be in response to an error, failure, or overload 407 condition, or to support capabilities such as load balancing. 409 RATIONALE: A DECADE-compatible server may opt to redirect requests 410 to another server to support capabilities such as load balancing, 411 or if the implementation decides that another DECADE-compatible 412 server is in a better position to handle the request due to 413 either its location in the network, server status, or other 414 consideration. 416 EXCEPTION: A DECADE-compatible server can be configured by its 417 service provider to support or not support redirection 418 functionality. 420 4.2. Transfer Requirements 422 4.2.1. Data Object Size 424 REQUIREMENT(S): DECADE-compatible protocol(s) MUST allow for 425 efficient data transfer of small objects (e.g., 16KB) between a 426 DECADE-compatible client and in-network storage with minimal 427 additional latency imposed by the protocol(s). 429 RATIONALE: Though Target Applications are frequently used to share 430 large amounts of data (e.g., continuous streams or large files), 431 the data itself is typically subdivided into smaller chunks that 432 are transferred between clients. Additionally, clients may be 433 sensitive to the delivery time of chunks (e.g., in a live- 434 streaming application). DECADE-compatible protocol(s) must 435 enable data to be efficiently transferred amongst DECADE- 436 compatible clients at this granularity. 438 4.3. Data Access Requirements 440 4.3.1. Reading/Writing Own Storage 442 REQUIREMENT(S): DECADE-compatible protocol(s) MUST enable a DECADE- 443 compatible client to read data from and write data to its own in- 444 network storage. 446 RATIONALE: Two basic capabilities for any storage system are reading 447 and writing data. A DECADE-compatible client can read data from 448 and write data to in-network storage space that it owns. 450 4.3.2. Access by Remote Clients 452 REQUIREMENT(S): A DECADE-compatible client MUST be able to apply 453 access control policies to remote DECADE-compatible clients other 454 than itself for its storage. The remote DECADE-compatible 455 clients with whom access is being shared can be under a different 456 administrative domain than the DECADE-compatible client who owns 457 the in-network storage. 459 RATIONALE: Endpoints in Target Applications may be located across 460 multiple ISPs under multiple administrative domains. Thus, to be 461 useful by Target Applications, a DECADE-compatible client must be 462 able to specify access control policies for remote DECADE- 463 compatible clients that may or may not be known to the client's 464 own DECADE service provider. 466 4.3.3. Negotiable Data Transport Protocol 468 REQUIREMENT(S): DECADE-compatible client MUST be able to negotiate 469 with DECADE server about which protocol it can use to read data 470 from and write data to its in-network storage. DECADE system 471 MUST specify at least one mandatory protocol to be supported by 472 implementations; usage of a different protocol may be selected 473 via negotiation. 475 RATIONALE: Since typical data transport protocols (e.g., NFS and 476 WebDAV) already provide read and write operations for network 477 storage, it may not be necessary to define such operations in a 478 new DECADE protocol. However, because of the particular 479 application requirements and deployment considerations, different 480 applications may support different protocols. Thus, a DECADE 481 client must be able to select an appropriate protocol also 482 supported by the in-network storage. This requirement also 483 follows as a result of the requirement of Separation of Control 484 and Data Operations (Section 4.3.4). 486 4.3.4. Separation of Data and Control Policies 488 REQUIREMENT(S): DECADE-compatible protocol(s) MUST provide a minimal 489 set of core operations to support diverse policies implemented 490 and desired by Target Applications, and MAY provide additional 491 operations. 493 RATIONALE: Target Applications support many complex behaviors and 494 diverse policies to control and distribute data, such as (e.g., 495 search, index, setting permissions/passing authorization tokens). 496 Thus, to support such Target Applications, these behaviors must 497 be logically separated from the data transfer operations (e.g., 498 read, write). Some minimal overlap (for example obtaining 499 credentials needed to encrypt or authorize data transfer using 500 control operations) is required to be supported by DECADE- 501 compatible protocol(s). 503 4.4. Data Management Requirements 505 4.4.1. Agnostic of reliability 507 REQUIREMENT(S): DECADE-compatible protocol(s) MUST remain agnostic 508 of reliability/ fault-tolerance level offered by DECADE service 509 provider. 511 RATIONALE: Providers of a DECADE service may wish to offer varying 512 levels of service for different applications/users. However, a 513 single DECADE-compatible client must be able to use multiple 514 DECADE services with differing levels of service. 516 4.4.2. Data Object Attributes 518 REQUIREMENT(S): DECADE-compatible protocol(s) MUST support the 519 ability to associate attributes with data objects with a scope 520 local to a DECADE-compatible server, and for DECADE-compatible 521 clients to query these attributes. DECADE-compatible protocol(s) 522 MUST transmit any attributes using an operating system- 523 independent and architecture-independent standard format. If 524 there is a need to design any DECADE protocols, they MUST be 525 designed such that new attributes can be added by later protocol 526 revisions or extensions. 528 RATIONALE: A DECADE-compatible client can associate attributes 529 (e.g., a time-to- live, creation timestamp, or object size) with 530 a data object. These attributes are local to a data object 531 stored by a particular DECADE-compatible server, and are thus not 532 applied to any DECADE-compatible server or client to which the 533 data object is copied. These attributes may be used as hints to 534 the storage system, internal optimizations, or as additional 535 information query-able by DECADE-compatible clients. 537 4.4.3. Time-to-live for Written Data Objects 539 REQUIREMENT(S): A DECADE-compatible client MUST be able to indicate 540 a time-to- live value (or expiration time) indicating a length of 541 time until particular data can be deleted by a DECADE-compatible 542 server. 544 RATIONALE: Some data objects written by a DECADE-compatible client 545 may be usable only within a certain window of time, such as in 546 live- streaming P2P applications. Providing a time-to-live value 547 for data objects (e.g., at the time they are written) can reduce 548 management overhead by avoiding many 'delete' commands sent to 549 DECADE-compatible server. The in-network storage may still keep 550 the data in cache for bandwidth optimization. But this is guided 551 by the privacy policy of the DECADE service provider. 553 4.4.4. Application-defined Properties and Metadata 554 REQUIREMENT(S): DECADE-compatible clients and DECADE-compatible 555 servers MUST NOT be able to associate Application-defined 556 properties (metadata) with data objects beyond what is provided 557 by Section 4.4.2. 559 RATIONALE: Associating key-value pairs that are defined by Target 560 Applications with data objects introduces substantial complexity 561 to the protocol(s). If Target Applications wish to associate 562 additional metadata with a data object, possible alternatives 563 include (1) managing such metadata within the Target Application 564 itself, (2) storing metadata inside of the data object, or (3) 565 storing metadata in a different data object at the DECADE- 566 compatible server. 568 4.4.5. Offline Usage 570 REQUIREMENT(S): A DECADE-compatible client MAY provide authorized 571 access from remote clients to its in-network storage even if the 572 DECADE client is actively running or connected to a DECADE- 573 compatible server. 575 RATIONALE: If an application desires, it can authorize remote 576 clients to access its storage even after the application exits or 577 network connectivity is lost. An example use case is mobile 578 scenarios, where a client can lose and regain network 579 connectivity very often. 581 4.5. Data Naming Requirements 583 4.5.1. Unique Names 585 REQUIREMENT(S): DECADE-compatible protocol(s) MUST support a data 586 object naming scheme that ensures a high probability of 587 uniqueness and supports the operation of DECADE-compatible 588 servers under diverse administrative domains with no 589 coordination. DECADE-compatible server SHOULD be able to respond 590 to DECADE-compatible client with error condition indicating the 591 name of the object conflicts with other object. 593 RATIONALE: When writing a data object, a DECADE-compatible Client 594 should be able to write it without being concerned over whether 595 an object of the same name already exists, unless the existing 596 object contains the exact same data. Although the intention is 597 to avoid name collision, it's not absolutely zero possibility. 598 As a result, it is required to provide a collision handling 599 mechanism. 601 EXCEPTION: While a DECADE-compatible server is in situations 602 described in Section 4.1.2.2 or Section 4.1.3.1, it need not to 603 generate a response to the client. 605 4.6. Resource Control 607 4.6.1. Multiple Applications 609 REQUIREMENT(S): A DECADE-compatible client MUST be able to indicate 610 to a DECADE-compatible server about resource sharing policies for 611 multiple target applications being run/managed by the same user. 613 RATIONALE: A user may own in-network storage and share the in- 614 network storage resources amongst multiple target applications. 615 For example, the user may run one or more video-on-demand 616 application(s) and a live-streaming application(s) which both 617 make use of the user's in-network storage. The applications may 618 be running on different machines and may not directly 619 communicate. Thus, user should be able to determine resource 620 sharing policies between the applications. 622 One possibility is for a user to indicate the particular resource 623 sharing policies between applications out-of-band (not using a 624 standard protocol), but this requirement may manifest itself in 625 passing values within DECADE-compatible protocol(s) to identify 626 individual applications. Such identifiers can be either user- 627 generated or server-generated and do not need to be registered by 628 IANA. 630 4.6.2. Per-Remote-Client, Per-Data Control 632 REQUIREMENT(S): A DECADE-compatible client MUST be able to assign 633 resource policies (bandwidth share, storage quota, and network 634 connection quota) to individual remote clients for reading from 635 and writing particular data to its in-network storage within a 636 particular range of time. 638 RATIONALE: Target Applications can rely on control of resources on a 639 per-remote-client or per-data basis. For example, application 640 policy may indicate that certain remote clients have a higher 641 bandwidth share for receiving data [LLSB08]. Additionally, 642 bandwidth share for receiving data [LLSB08]. Additionally, 643 certain data (e.g., chunks) may be distributed with a higher 644 priority. As another example, when allowing a remote client to 645 write data to a user's in-network storage, the remote client may 646 be restricted to write less than 100MB of data in total. Since 647 the client may need to manage multiple clients accessing its 648 data, it should be able to indicate the time over which the 649 granted resources are usable. For example, an expiration time 650 for the access could be indicated to the DECADE-compatible server 651 after which no resources are granted (e.g., indicate error as 652 access denied). 654 4.6.3. Resource Control Set 656 REQUIREMENT(S): DECADE-compatible protocol(s) MUST define a minimum 657 set of resource control methods, and MAY add additional set of 658 resource control methods. 660 RATIONALE: The minimum set of resource control methods need to 661 include the most common resource control methods. Implementors 662 can add proprietary set of resource control methods in their own 663 implementation. 665 4.6.4. Server Involvement 667 REQUIREMENT(S): A DECADE-compatible client MUST be able to indicate 668 to a DECADE-compatible server, without itself contacting the 669 server, resource control policies for remote clients' requests. 670 A DECADE-compatible server MUST be able to authenticate the 671 resource control policies in this situation. 673 RATIONALE: One important consideration for a DECADE-compatible 674 server is scalability, since a single storage element may be used 675 to support many users. Many Target Applications use small chunk 676 sizes and frequent data exchanges. If such an application 677 employed resource control and contacted the DECADE-compatible 678 server for each data exchange, this could present a scalability 679 challenge for the server as well as additional latency for 680 clients. 682 The preferred way is to let requesting clients obtain signed 683 resource control policies (in the form of a token) from the 684 owning client, and then requesting clients can present the policy 685 to a DECADE-compatible server directly. This can result in 686 reduced messaging handled by the DECADE-compatible server. 688 4.7. Authorization 690 4.7.1. Per-Remote-Client, Per-Data Read Access 692 REQUIREMENT(S): A DECADE-compatible Client MUST be able to control 693 which individual remote clients are authorized to read particular 694 data from its in-network storage. 696 RATIONALE: A Target Application can control certain application- 697 level policies by sending particular data (e.g., chunks) to 698 certain remote clients. 700 4.7.2. Per-User Write Access 702 REQUIREMENT(S): A DECADE-compatible Client MUST be able to control 703 which individual remote clients are authorized to write data into 704 its in-network storage. 706 RATIONALE: The space managed by a user in in-network storage can be 707 a limited resource. At the same time, it can be useful to allow 708 remote clients to write data directly to a user's in-network 709 storage. Thus, a DECADE-compatible client should be able to 710 grant only certain remote clients this privilege. 712 4.7.3. Default Access Permissions 714 REQUIREMENT(S): Unless read or write access is granted by a DECADE 715 Client to a remote client, the default access MUST be no access. 717 RATIONALE: The current leading proposal for an access control model 718 in DECADE working group is via token passing, resulting in a 719 system with little state on the server side. 721 4.7.4. Authorization Checks 723 REQUIREMENT(S): A DECADE-compatible server MUST check the 724 authorization of a client before it executes a supplied request. 726 RATIONALE: The data stored at a DECADE-compatible server is assumed 727 to be private, and thus not accessible to a DECADE-enabled client 728 unless it is explicitly granted permission. 730 4.7.5. Cryptographic Credentials 732 REQUIREMENT(S): Access MUST be able to be granted using 733 cryptographic credentials. 735 RATIONALE: DECADE-compatible clients may be operating on hosts 736 without constant network connectivity or without a permanent 737 attachment address (e.g., mobile devices). To support access 738 control with such hosts, DECADE-compatible servers must support 739 access control policies that use cryptographic credentials, not 740 simply by tying access to IP addresses. 742 4.7.6. Server Involvement 744 REQUIREMENT(S): A DECADE-compatible client MUST be able to indicate, 745 without contacting the server itself, access control policies for 746 remote clients' requests. DECADE-compatible server MUST be able 747 to authenticate the access control policies in this situation. 749 RATIONALE: See discussion in Section 4.6.4. 751 4.7.7. Protocol Reuse 753 REQUIREMENT(S): DECADE SHOULD reuse existing protocol and mechanisms 754 for Authentication, Access, and Authorization (AAA). No new AAA 755 protocol and mechanism are going to be defined unless there is 756 explicit proof that existing protocol and mechanisms are not 757 applicable. 759 RATIONALE: If possible, reusing an existing AAA protocol/mechanism 760 will minimize the development required by applications, and will 761 maximize interoperability of the DECADE-compatible protocol(s) 762 with existing infrastructure. 764 5. Storage Requirements 766 This section details the requirements of the underlying storage used 767 to support DECADE-compatible protocol(s). 769 5.1. Immutable Data 771 REQUIREMENT(S): The data objects MUST be immutable once they are 772 written to storage. 774 RATIONALE: Immutable data objects are an important simplification in 775 DECADE-compatible system. Reasonable consistency models for 776 updating existing objects would significantly complicate 777 implementation (especially if implementation chooses to replicate 778 data across multiple servers). If the content owners have to 779 modify the written data objects, there are many ways to do so. 780 First, they can use different data names for different object 781 versions. Secondly, they can split single monolithic files into 782 fragments, so that new fragment versions could be substituted 783 later (e.g. corrections or updated advertising) via a play list. 785 5.2. Explicit Deletion of Data 787 REQUIREMENT(S): A DECADE-compatible client MUST be able to 788 explicitly delete data from its own in-network storage. 790 RATIONALE: A DECADE-compatible client may continually be writing 791 data to its in-network storage. Since there may be a limit 792 (e.g., imposed by the storage provider) to how much total storage 793 can be used, some data may need to be removed to make room for 794 additional data. A DECADE-compatible client should be able to 795 explicitly remove particular data. This may be implemented using 796 existing protocols. 798 5.3. Multiple writing 800 REQUIREMENT(S): A DECADE-compatible server MUST NOT allow multiple 801 simultaneous writers for the same object. A DECADE-compatible 802 server SHOULD respond to each of the writers with error condition 803 indicating the attempt of simultaneous writing. 805 RATIONALE: This avoids data corruption in a simple way while 806 remaining efficient. Alternately, the DECADE-compatible server 807 would need to either manage locking, handle write collisions, or 808 merge data, all of which reduce efficiency and increase 809 complexity. 811 EXCEPTION: While a DECADE-compatible server is in the situation that 812 is described in Section 4.1.2.2 or Section 4.1.3.1, it need not 813 generate a response. 815 5.4. Multiple reading 817 REQUIREMENT(S): A DECADE-compatible server MUST allow for multiple 818 simultaneous readers for an object. 820 RATIONALE: One characteristic of Target Applications is the ability 821 to upload an object to multiple clients. Thus, it is natural for 822 DECADE-compatible server to allow multiple readers to read the 823 content concurrently. 825 5.5. Reading before completely written 827 REQUIREMENT(S): A DECADE-compatible server MAY allow readers to read 828 from objects before they have been completely written. In case 829 of object writing error, DECADE-compatible server SHOULD be able 830 to respond to the reading DECADE-compatible client with error 831 condition indicating that the object writing is failed. 833 RATIONALE: Some Target Applications (in particular, P2P streaming) 834 can be sensitive to latency. A technique to reduce latency is to 835 remove store-and-forward delays for data objects (e.g., make the 836 object available before it is completely written). Appropriate 837 handling for error conditions (e.g., a disappearing writer) needs 838 to be specified. 840 EXCEPTION: While a DECADE-compatible server is in the situation that 841 is described in Section 4.1.2.2 or Section 4.1.3.1, it need not 842 generate a response. 844 5.6. Writing model 846 REQUIREMENT(S): A DECADE-compatible server MUST provide at least a 847 writing model (while writing an object) that appends data to data 848 already written. 850 RATIONALE: Depending on the object size (e.g., chunk size) used by a 851 Target Application, the application may need to send data to the 852 DECADE-compatible server in multiple packets. To keep 853 implementation simple, the DECADE-compatible server must at least 854 support the ability to write the data sequentially in the order 855 received. Implementations MAY allow application to write data in 856 an object out-of-order (but MUST NOT overwrite ranges of the 857 object that have already been written). 859 5.7. Storage Status 861 REQUIREMENT(S): A DECADE-compatible server MUST be able to respond 862 resource usage and resource quotas. A minimum set of storage 863 status supported by DECADE-compatible server MUST include 864 resource usage resulting from the client's own usage (including 865 list of written data objects) and usage by other clients that 866 have been authorized to read/write objects on that client's 867 storage. A DECADE-compatible server MUST be able to authenticate 868 the request. 870 RATIONALE: The resources used by a client are not necessarily 871 directly-attached (e.g., disk, network interface, etc). Thus, 872 the client cannot locally determine how such resources are being 873 used. Before storing and retrieving data, a client should be 874 able to determine which data is available (e.g., after an 875 application restart). 877 6. Discovery Requirements 879 6.1. Requirements 881 6.1.1. Support for Clients Behind NATs and Firewalls 883 REQUIREMENT(S): The mechanism for discovering a DECADE-compatible 884 server MUST be operable by DECADE-compatible clients operating 885 behind NATs and Firewalls. 887 RATIONALE: NATs and Firewalls are prevalent in network deployments, 888 and it is common for Target Applications that include a DECADE- 889 compatible client to be deployed behind these devices. 891 6.1.2. Prefer Existing Protocols 893 REQUIREMENT(S): The mechanism for discovering a DECADE-compatible 894 server SHOULD leverage existing mechanisms and protocols wherever 895 possible. No new discovery mechanism will be defined unless 896 there is enough evidence that no existing mechanism can work. 898 RATIONALE: Existing protocols such as DNS and DHCP are widespread. 899 Using existing protocols, or combinations of the protocols that 900 have been specified in other contexts, is strictly preferred over 901 developing a new discovery protocol. 903 7. Security Considerations 905 The security model is an important component of a DECADE-compatible 906 system. It is crucial for users to be able to manage and limit 907 distribution of content to only authorized parties, and the mechanism 908 needs to work on the general Internet which spans multiple 909 administrative and security domains. Previous sections have 910 enumerated detailed requirements, but this section discusses the 911 overall approach and other considerations that do not merit 912 requirements. 914 7.1. Authentication and Authorization 916 A DECADE-compatible server must authenticate any DECADE-compatible 917 client that attempts to access the in-network storage. DECADE- 918 compatible server is not involved in the authorization between DECADE 919 clients and remote clients, or the authorization between DECADE 920 system user and DECADE service provider. In order to authenticate an 921 accessing DECADE client, a DECADE-compatible server may need to 922 accept the authentication and authorization referral by another 923 DECADE-compatible client. 925 7.2. Encrypted Data 927 DECADE-compatible Servers provide the ability to write raw data 928 objects (subject to any policies instituted by the owner/ 929 administrator of the service provider). Thus, DECADE-compatible 930 clients may opt to encrypt data before it is transported to the 931 server. However, DECADE-compatible protocol(s) do not provide 932 encryption of data objects other than that provided by 933 Section 4.1.2.1. 935 7.3. Protection against Gaming 937 The particular resource control policy communicated by DECADE- 938 compatible protocol(s) and enforced on DECADE-compatible server may 939 be open to certain gaming by clients. For example by specifying many 940 small chunks to increase total throughput or inciting overload 941 conditions are techniques that may be used by a client. 943 8. IANA Considerations 945 There are no IANA considerations with this document. 947 9. References 949 9.1. Normative References 951 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 952 Requirement Levels", BCP 14, RFC 2119, March 1997. 954 [I-D.ietf-decade-problem-statement] 955 Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled 956 Application Data Enroute (DECADE) Problem Statement", 957 draft-ietf-decade-problem-statement-03 (work in progress), 958 March 2011. 960 9.2. Informative References 962 [I-D.ietf-decade-arch] 963 Alimi, R., Yang, Y., Rahman, A., Kutscher, D., and H. Liu, 964 "DECADE Architecture", draft-ietf-decade-arch-02 (work in 965 progress), July 2011. 967 [LLSB08] Levin, D., LaCurts, K., Spring, N., and B. Bhattacharjee, 968 "BitTorrent is an Auction: Analyzing and Improving 969 BitTorrent's Incentives", SIGCOMM 2008, August 2008. 971 [PPLive] "PPLive", . 973 Appendix A. Acknowledgments 975 We would also like to thank Haibin Song for substantial contributions 976 to earlier versions of this document. We would also like to thank 977 Reinaldo Penno, Alexey Melnikov, Rich Woundy, Ning Zong, Roni Even, 978 David McDysan, Borje Ohlman, Dirk Kutscher, Akbar Rahman, Xiao Zhu, 979 Yunfei Zhang, and Jin Peng for contributions and general feedback. 981 Authors' Addresses 983 Yingjie Gu 984 Huawei 985 No. 101 Software Avenue 986 Nanjing, Jiangsu Province 210012 987 P.R.China 989 Phone: +86-25-56624760 990 Email: guyingjie@huawei.com 992 David A. Bryan 993 Polycom, Inc. 995 Email: dbryan@ethernot.org 997 Yang Richard Yang 998 Yale University 1000 Email: yry@cs.yale.edu 1002 Richard Alimi 1003 Google 1005 Email: ralimi@google.com