DECADE Y. Gu Internet-Draft Huawei Intended status: Informational D. Bryan Expires: February 14, 2013 Ethernot.org Y. Yang Yale University P. Zhang Tsinghua University/Yale University R. Alimi Google August 13, 2012 DECADE Requirements draft-ietf-decade-reqs-08 Abstract The target of the DECoupled Application Data Enroute (DECADE) system is to provide an open and standard in-network storage system for applications, primarily P2P (peer-to-peer) applications, to store, retrieve and manage their data. This draft enumerates and explains requirements, not only for storage and retrieval, but also for data management, access control and resource control, that should be considered during the design and implementation of a DECADE- compatible system. These are requirements on the entire system; some of the requirements may eventually be implemented by an existing protocol with/without some extensions (e.g., a protocol used to read and write data from the storage system). The requirements in this document are intended to ensure that a DECADE-compatible system architecture includes all of the desired functionality for intended applications. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Gu, et al. Expires February 14, 2013 [Page 1] Internet-Draft DECADE Requirements August 2012 Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 14, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Gu, et al. Expires February 14, 2013 [Page 2] Internet-Draft DECADE Requirements August 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. DECADE-compatible Client . . . . . . . . . . . . . . . . . 6 2.2. DECADE-compatible Server . . . . . . . . . . . . . . . . . 6 2.3. DECADE Storage Provider . . . . . . . . . . . . . . . . . 6 2.4. DECADE Account . . . . . . . . . . . . . . . . . . . . . . 6 2.5. Resource Provider . . . . . . . . . . . . . . . . . . . . 6 2.6. Resource Consumer . . . . . . . . . . . . . . . . . . . . 6 2.7. Content Distribution Application . . . . . . . . . . . . . 6 2.8. Target Application . . . . . . . . . . . . . . . . . . . . 7 2.9. Application End-Point . . . . . . . . . . . . . . . . . . 7 2.10. Data Object . . . . . . . . . . . . . . . . . . . . . . . 7 2.11. DECADE-compatible System . . . . . . . . . . . . . . . . . 7 2.12. DECADE Resource Protocol (DRP) Functions . . . . . . . . . 7 2.13. DECADE Standard Data Transfer Protocol (SDT) Functions . . 7 3. System and Protocol Components . . . . . . . . . . . . . . . . 8 4. Requirements Structure . . . . . . . . . . . . . . . . . . . . 9 5. Data Object Requirements . . . . . . . . . . . . . . . . . . . 9 5.1. Data Name Uniqueness . . . . . . . . . . . . . . . . . . . 9 5.2. Verifiable Name-Object Binding . . . . . . . . . . . . . . 10 5.3. Data Object Size . . . . . . . . . . . . . . . . . . . . . 10 5.4. Data Object Attributes . . . . . . . . . . . . . . . . . . 10 5.5. Application-defined Object Properties and Metadata . . . . 11 6. Access and Authorization Requirements . . . . . . . . . . . . 11 6.1. Provider Access . . . . . . . . . . . . . . . . . . . . . 11 6.2. Secure Authorization . . . . . . . . . . . . . . . . . . . 11 6.3. Consumer Access . . . . . . . . . . . . . . . . . . . . . 12 6.4. Provider Authorization When Offline . . . . . . . . . . . 12 6.5. Local Authorization . . . . . . . . . . . . . . . . . . . 12 6.6. Access Control Granularity . . . . . . . . . . . . . . . . 12 6.7. Default Access Permissions . . . . . . . . . . . . . . . . 12 6.8. Connectivity Supporting NAT and Firewall Traversal . . . . 13 6.9. DECADE Server Discovery . . . . . . . . . . . . . . . . . 13 7. Data Transfer Requirements . . . . . . . . . . . . . . . . . . 13 7.1. Negotiable Standard Data Transport Protocol . . . . . . . 13 7.2. Atomic or Partial Read/Write . . . . . . . . . . . . . . . 14 7.3. Secure Data Transport . . . . . . . . . . . . . . . . . . 14 7.4. Concurrent Read . . . . . . . . . . . . . . . . . . . . . 14 7.5. Concurrent Write . . . . . . . . . . . . . . . . . . . . . 14 7.6. Read Before Write Complete . . . . . . . . . . . . . . . . 15 7.7. Redirection of Transport . . . . . . . . . . . . . . . . . 15 8. Resource Control Requirements . . . . . . . . . . . . . . . . 16 8.1. Multiple Applications Sharing Resources . . . . . . . . . 16 8.2. Per-Client Resource Policy . . . . . . . . . . . . . . . . 16 8.3. Distributed Resource Sharing Specification . . . . . . . . 16 8.4. Resource Set . . . . . . . . . . . . . . . . . . . . . . . 17 Gu, et al. Expires February 14, 2013 [Page 3] Internet-Draft DECADE Requirements August 2012 9. Error and Failure Handling Requirements . . . . . . . . . . . 17 9.1. Illegal Data Object . . . . . . . . . . . . . . . . . . . 17 9.2. Invalid Access Authorization . . . . . . . . . . . . . . . 18 9.3. Insufficient Resources . . . . . . . . . . . . . . . . . . 18 9.4. Overload Condition . . . . . . . . . . . . . . . . . . . . 18 9.5. Attack Mitigation . . . . . . . . . . . . . . . . . . . . 19 10. Management Info Requirements . . . . . . . . . . . . . . . . . 19 10.1. Account Status . . . . . . . . . . . . . . . . . . . . . . 19 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 11.1. Authentication and Authorization . . . . . . . . . . . . . 20 11.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 20 11.3. Attack Mitigation . . . . . . . . . . . . . . . . . . . . 20 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 13.1. Normative References . . . . . . . . . . . . . . . . . . . 20 13.2. Informative References . . . . . . . . . . . . . . . . . . 20 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Gu, et al. Expires February 14, 2013 [Page 4] Internet-Draft DECADE Requirements August 2012 1. Introduction The object of the DECoupled Application Data Enroute (DECADE) system is to provide an open and standard in-network storage for content distribution applications, where data is typically broken into one or more chunks and then distributed. This may already include many types of applications including P2P applications, IPTV (Internet Protocol Television), and VoD (Video on Demand). (For a precise definition of the applications targeted in DECADE system, see the definition for Target Application in Section 2.) Instead of always transferring data directly from a source/owner client to a requesting client, the source/owner client can write to and manage its content on its in-network storage. The requesting client can get the address of the in-network storage pertaining to the source/owner client and read data from the storage. This draft enumerates and explains the rationale behind specific requirements on the protocol design and on any data store implementation that may be used to implement DECADE servers that should be considered during the design and implementation of a DECADE-compatible system. As such, it does not include general guiding principles. General design considerations, explanation of the problem being addressed, and enumeration of the types of applications to which a DECADE-compatible system may be suited is not considered in this document. For general information, please see [RFC6646] and [I-D.ietf-decade-arch]. This document enumerates the requirements to enable target applications to utilize in-network storage. In this context, using storage resources includes not only basic capabilities such as writing, reading, and managing data, but also controlling access for particular remote clients with which it is sharing data. Additionally, we also consider controlling the resources used by remote clients when they access data as an integral part of utilizing the network storage. This document discusses requirements pertaining to DECADE-compatible protocol(s). In certain deployments, several logical in-network storage systems could be deployed (e.g., within the same administrative domain). These in-network storage systems can communicate and transfer data through internal or non-standard communication messages that are outside of the scope of these requirements, but they should use DECADE-compatible protocol(s) when communicating with other DECADE-compatible in-network storage systems. Gu, et al. Expires February 14, 2013 [Page 5] Internet-Draft DECADE Requirements August 2012 2. Terminology This document uses the term 'In-network storage' which is defined in [RFC6646]. This document also defines these additional terms: 2.1. DECADE-compatible Client A DECADE-compatible client uploads and/or retrieves data from DECADE- compatible servers. We use the shorter term "client" if there is no ambiguity. 2.2. DECADE-compatible Server A DECADE-compatible server stores data inside the network, and thereafter manages both the stored data and access to those data. We use the shorter term "server" if there is no ambiguity. 2.3. DECADE Storage Provider A DECADE Storage Provider, or Storage Provider for short, deploys and/or manages DECADE-compatible server(s) within a network. 2.4. DECADE Account An account of a DECADE-compatible server has associated cryptographic credentials for access control, and resource allocation attributes on the server. 2.5. Resource Provider A client which has the account cryptographic credentials of a DECADE account at a DECADE-compatible server. We use the short term "Provider" if there is no ambiguity. 2.6. Resource Consumer A client which tries to access a DECADE account but does not have the account's cryptographic credentials. We use the short term "Consumer" if there is no ambiguity. 2.7. Content Distribution Application A Content Distribution Application is an application (e.g., P2P, traditional CDN, or hybrid P2P/CDN) designed for dissemination of a large amounts of content (e.g., files, or video streams) to multiple content consumers. Content Distribution Applications may divide Gu, et al. Expires February 14, 2013 [Page 6] Internet-Draft DECADE Requirements August 2012 content into smaller blocks for dissemination. 2.8. Target Application An application with that includes a DECADE-compatible client along with other application functionalities to explicitly control the usage of resources of DECADE-compatible servers to deliver content to other users. A primary type of Target Application we consider is Content Distribution Applications. A Target Application divides content into smaller blocks for more flexible distribution (e.g., over multiple application-level paths). We use the term Target Application to refer to the type of applications that are explicitly (but not exclusively) supported by DECADE system. 2.9. Application End-Point An Application End-Point is an instance of a Target Application. A particular Application End-Point might be a Provider, a Consumer, or both. For example, an Application End-Point might be an instance of a video streaming client, or it might be the source providing the video to a set of clients. 2.10. Data Object A data object is the unit of data stored and retrieved from a DECADE- compatible server. The data object is a string of raw bytes. The server maintains metadata associated with each data object, but the metadata is not included in the data object. 2.11. DECADE-compatible System A system which is composed of DECADE-compatible clients, DECADE- compatible servers and in-network storage. A DECADE-compatible system MUST obey all the requirements defined in this document. 2.12. DECADE Resource Protocol (DRP) Functions A set of functions for communication of access control and resource scheduling policies from a DECADE client to a server, as well as between servers. 2.13. DECADE Standard Data Transfer Protocol (SDT) Functions A set of functions to be used to transfer data objects to and from a DECADE server. Gu, et al. Expires February 14, 2013 [Page 7] Internet-Draft DECADE Requirements August 2012 3. System and Protocol Components To organize requirements, we consider that a DECADE-compatible system consists of two logical sets of functions, as shown in Figure 1. The first set of functions, which we refer to as the DECADE Resource Protocol (DRP) functions, is responsible for communication of access control and resource scheduling policies from a client to a server, as well as between servers. A DECADE-compatible system will include exactly one DRP for interoperability and a common format through which these policies can be communicated. Native Application .-------------. Protocol(s) .-------------. | Application | <------------------> | Application | | End-Point | | End-Point | | | | | | .--------. | | .--------. | | | DECADE | | | | DECADE | | | | Client | | | | Client | | | `--------' | | `--------' | `-------------' `-------------' | ^ | ^ DECADE | | Standard | | Resource | | Data DRP | | SDT Protocol | | Transfer | | (DRP) | | (SDT) | | | | | | | | | | | | | | | | | | | | | | | | | | v V v V .=============. DRP .=============. | DECADE | <------------------> | DECADE | | Server | <------------------> | Server | `=============' SDT `=============' Figure 1: Protocol Components and Generic Flow Second, the second set of functions, referred to as the Standard Data Transfer (SDT) functions, will be used to transfer data objects to and from a server. A DECADE-compatible system may support multiple SDT's. If there are multiple SDT's, a negotiation mechanism will be used to determine a suitable SDT between the client and server. The two sets of functions (DRP and SDT) will be either separate or combined on the wire. If they are combined, DRP messages can be Gu, et al. Expires February 14, 2013 [Page 8] Internet-Draft DECADE Requirements August 2012 piggy-backed within some extension fields provided by certain SDT protocols. In such a scenario, DRP is technically a data structure (transported by other protocols), but it can still be considered as a logical protocol that provides the services of configuring DECADE- compatible resource usage. If the protocols are physically separate on the wire, DRP can take the form of a separate control connection open between the a DECADE-compatible client and server. Hence, this document considers SDT and DRP as two separate, logical functional components for clarity. 4. Requirements Structure This document specifies the requirements for the DECADE DRP and SDT functions, either existing ones or new ones, and storage system to enable Target Applications to make use of storage within the network, leaving specific storage system considerations to the implementation of the storage servers as much as possible. For this reason, we consider two primary categories of requirements: o Protocol Requirements: Protocol requirements for Target Applications to make use of in-network storage within their own data dissemination schemes. Development of these requirements is guided by a study of data access, search and management capabilities used by Target Applications. These requirements may be met by a combination of existing protocols and new protocols. o Storage Requirements: Functional requirements necessary for the back-end storage system employed by the DECADE server. Development of these requirements is guided by a study of the data access patterns used by Target Applications. These requirements should be met by the underlying data transport used by DECADE system. In this document, we use "data transport" to refer to a protocol used to read and write data from in-network storage. This specification discusses the requirements of functionality implemented with a storage system and within applications, to permit interoperable communications concerning the manipulation of stored content. 5. Data Object Requirements 5.1. Data Name Uniqueness Gu, et al. Expires February 14, 2013 [Page 9] Internet-Draft DECADE Requirements August 2012 REQUIREMENT(S): Each Data Object should be named to allow access. DECADE-compatible protocol(s) MUST support a data object naming scheme that ensures a high probability of uniqueness, with no coordination among multiple Storage Providers. In other words, two Data Objects with the same name should be the same content with high probability. A DECADE-compatible server SHOULD be able to respond to a DECADE-compatible client with an error indicating potential name conflicts. RATIONALE: Although the intention of unique names is to avoid name collisions, it does not have to be an absolutely zero possibility. Hence, it is required to provide a collision handling mechanism. EXCEPTION: While a DECADE-compatible server is overloaded or consider a request as an attack, it does not to generate a response to indicate name collisions. 5.2. Verifiable Name-Object Binding 5.3. Data Object Size REQUIREMENT(S): DECADE MUST allow for efficient storage and data transfer of small data objects (e.g., 16KB) without large control overhead. RATIONALE: Though Target Applications are frequently used to share large amounts of data (e.g., continuous streams or large files), the data itself is typically subdivided into smaller data objects (chunks) for flexibility (e.g., reliability and multi-path transmission). 5.4. Data Object Attributes REQUIREMENT(S): DECADE MUST support the ability to associate a set of system attributes with a data object with a scope local to a DECADE-compatible server. In particular, the set MUST include time-to-live (or expiration time), creation timestamp, object size, and object type. A DECADE-compatible client, with access permission, MUST be able to query the set of system attributes. The transmission of the attributes MUST use an operating system- independent and architecture-independent standard format. An ability to extend the set of attributes MUST exist. RATIONALE: The values of attributes associated with a data object are local to a particular DECADE-compatible server. These attributes may be used as hints to the storage system, internal optimizations, or as additional information query-able by DECADE- Gu, et al. Expires February 14, 2013 [Page 10] Internet-Draft DECADE Requirements August 2012 compatible clients. The particular requirement for including time-to-live (TTL) is that a data object written by a DECADE- compatible client may be usable only within a certain window of time, such as in a live-streaming P2P application. Providing a time-to-live value for a data object (e.g., at the time it is written) can reduce management overhead by avoiding many 'delete' commands sent to DECADE-compatible server. The server may still retain a data object for bandwidth optimization, but this should be guided by the privacy policy of the DECADE Storage Provider. 5.5. Application-defined Object Properties and Metadata REQUIREMENT(S): DECADE-compatible clients and DECADE-compatible servers MUST NOT be able to associate Application-defined properties (metadata) with data objects beyond what is provided by Section 5.4. RATIONALE: Associating key-value pairs that are defined by Target Applications with data objects introduces substantial complexity. If Target Applications wish to associate additional metadata with a data object, possible alternatives include (1) managing such metadata within the Target Application itself, (2) storing metadata inside the data object, or (3) storing metadata in a different data object at the DECADE-compatible server. 6. Access and Authorization Requirements 6.1. Provider Access REQUIREMENT(S): A Provider MUST be able to access the resources of its account. RATIONALE: After a DECADE-compatible client owns an account on a DECADE-compatible server, it should be able to read data from and write data to the server. 6.2. Secure Authorization REQUIREMENT(S): Access to an account on a server MUST be granted to a provider based on cryptographic security. RATIONALE: DECADE-compatible clients may be operating on hosts without constant network connectivity or without a permanent attachment address (e.g., mobile devices). To support access control with such hosts, DECADE-compatible servers must support access control policies that use cryptographic credentials, not simply by tying access to IP addresses. Gu, et al. Expires February 14, 2013 [Page 11] Internet-Draft DECADE Requirements August 2012 6.3. Consumer Access REQUIREMENT(S): A Provider MUST be able to indicate to its server on whether a Consumer can access its subscribed resources. RATIONALE: Endpoints in Target Applications may choose different servers. Thus, to be useful by Target Applications, a DECADE- compatible client must be able to specify policies on whether other DECADE-compatible clients can access its resources. The other clients may or may not be known to the server. 6.4. Provider Authorization When Offline REQUIREMENT(S): A Provider MUST be able to grant access to a Consumer even if the Provider is not actively running or connected to its DECADE-compatible server. RATIONALE: If an application desires, it can authorize other clients to access its storage even after the application exits or network connectivity is lost. An example use case is mobile scenarios, where a client can lose and regain network connectivity often. 6.5. Local Authorization REQUIREMENT(S): A Provider MUST be able to indicate, without contacting its server, access control policies for Consumers. DECADE-compatible server MUST be able to authenticate the access control policies in this situation. RATIONALE: This requirement is related with the preceding requirement, but in a perspective (i.e., protocol design). See discussions in Section 8.3. 6.6. Access Control Granularity REQUIREMENT(S): A Provider MUST be able to control which individual clients are authorized to read/write which particular data objects from/to its in-network storage. RATIONALE: A Target Application should able to conduct access control on the granularity of individual clients, individual data objects. 6.7. Default Access Permissions Gu, et al. Expires February 14, 2013 [Page 12] Internet-Draft DECADE Requirements August 2012 REQUIREMENT(S): Unless read or write access is granted by a Provider, the default permission MUST be no access. RATIONALE: This requirement is to protect client privacy by default. 6.8. Connectivity Supporting NAT and Firewall Traversal REQUIREMENT(S): A client that is authorized to access a server MUST be supported to conduct NAT (Network Address Translation) and firewall traversal. In particular, network connections between a DECADE-compatible client and a DECADE-compatible server MUST be initiated by the client (i.e., the server must not initiate a connection to the client). RATIONALE: Firewalls and NATs are widely used in the Internet today, both in ISP (Internet Service Provider) and Enterprise networks and by consumers. Many firewalls and NATs are configured by default to block incoming connections, which helps to mitigate security risks. Deployment of a DECADE-compatible system must not require manual modifications to such devices. This requirement applies to both potential new protocol that may be developed by the DECADE Working Group and any data transport used with DECADE protocol. 6.9. DECADE Server Discovery REQUIREMENT(S): A mechanism for a Provider to discover and connect to its assigned server MUST be supported. The discovery SHOULD leverage existing mechanisms and protocols wherever possible. No new discovery mechanism will be defined unless there is enough evidence that no existing mechanism can work. RATIONALE: Existing protocols such as DNS and DHCP are widespread. Using existing protocols, or combinations of the protocols that have been specified in other contexts, is strictly preferred over developing a new discovery protocol. 7. Data Transfer Requirements 7.1. Negotiable Standard Data Transport Protocol REQUIREMENT(S): A DECADE-compatible client MUST be able to negotiate with a DECADE-compatible server about which protocol it can use to read data from and write data. DECADE MUST specify at least one mandatory transport protocol to be supported by implementations; usage of a different protocol may be selected via negotiation. Gu, et al. Expires February 14, 2013 [Page 13] Internet-Draft DECADE Requirements August 2012 RATIONALE: Since typical data transport protocols (e.g., NFS and WebDAV) already provide read and write operations for network storage, it may not be necessary to define such operations in a new DECADE protocol. However, because of the particular application requirements and deployment considerations, different applications may support different protocols. Thus, a DECADE client must be able to select an appropriate protocol also supported by the in-network storage. 7.2. Atomic or Partial Read/Write REQUIREMENT(S): A DECADE-compatible server MUST support the ability to read/write a complete data object in one request. It MAY support range read/write. RATIONALE: Depending on the object size (e.g., chunk size) used by a Target Application, the application may need to send data to the DECADE-compatible server in multiple round. 7.3. Secure Data Transport REQUIREMENT(S): A secure transport MUST be implemented for all communications between a DECADE-compatible client and DECADE- compatible server. RATIONALE: Target Applications may wish to write sensitive data. To satisfy this use case, the communication between a DECADE- compatible client and DECADE-compatible server must be transported over a secure transport protocol (e.g., SSL/TLS). 7.4. Concurrent Read REQUIREMENT(S): A DECADE-compatible server MUST allow for multiple simultaneous readers for a data object. RATIONALE: One characteristic of Target Applications is the ability to upload an object to multiple clients. Thus, it is natural for DECADE-compatible server to allow multiple readers to read the same object concurrently. 7.5. Concurrent Write REQUIREMENT(S): A DECADE-compatible server MUST NOT allow multiple simultaneous writers for the same object. A DECADE-compatible server SHOULD respond to each of the writers with an error. Gu, et al. Expires February 14, 2013 [Page 14] Internet-Draft DECADE Requirements August 2012 RATIONALE: This avoids data corruption in a simple way while remaining efficient. Alternately, the DECADE-compatible server would need to either manage locking, handle write collisions, or merge data, all of which reduce efficiency and increase complexity. EXCEPTION: While a DECADE-compatible server is overloaded or considers a request as an attack, it does not generate a response. 7.6. Read Before Write Complete REQUIREMENT(S): A DECADE-compatible server MAY allow readers to read a data object before it has been completely written. In case of a write error in such a case, the DECADE-compatible server SHOULD respond to the reading client with an error indicating that the write has failed. RATIONALE: Some Target Applications (in particular, P2P streaming) can be sensitive to latency. A technique to reduce latency is to remove store-and-forward delays for data objects (e.g., make the object available before it is completely written). Appropriate handling for error conditions (e.g., a disappearing writer) needs to be specified. EXCEPTION: While a DECADE-compatible server is overloaded or considers a request as an attack, it does not generate a response. 7.7. Redirection of Transport REQUIREMENT(S): A DECADE-compatible server SHOULD be able to redirect requests to another DECADE-compatible server. This may either be in response to an error, failure, overload, or to support capabilities such as load balancing. RATIONALE: A DECADE-compatible server may opt to redirect requests to another server to support capabilities such as load balancing, or if the implementation decides that another DECADE-compatible server is in a better position to handle the request due to either its location in the network, server status, or other consideration. EXCEPTION: A DECADE-compatible server can be configured by its service provider to support or not support redirection functionality. Gu, et al. Expires February 14, 2013 [Page 15] Internet-Draft DECADE Requirements August 2012 8. Resource Control Requirements 8.1. Multiple Applications Sharing Resources REQUIREMENT(S): A client MUST be able to indicate to a DECADE- compatible server about resource sharing policies among multiple Target Applications being run/managed by the same client. RATIONALE: A client owning a DECADE account may provide the account's cryptographic credentials to multiple Providers of multiple target applications. For example, the client may run one or more video-on-demand application(s) and a live-streaming application(s) which both make use of the client's in-network storage. The concurrently running applications may be running on different machines (e.g., multiple machines at the same home network) and may not directly communicate, except through user coordination 8.2. Per-Client Resource Policy REQUIREMENT(S): A Provider MUST be able to specify resource policies (bandwidth share, storage quota, and network connection quota) to individual Consumers for reading from and writing data to its in- network storage within a particular range of time. RATIONALE: Target Applications can rely on control of resources on a per-client basis. For example, application policy may indicate that certain remote clients have a higher bandwidth share for receiving data [LLSB08]. Additionally, bandwidth share for receiving data [LLSB08]. Additionally, certain data (e.g., chunks) may be distributed with a higher priority. As another example, when allowing a remote client to write data to a user's in-network storage, the remote client may be restricted to write less than 100MB of data in total. Since the client may need to manage multiple clients accessing its data, it should be able to indicate the time over which the granted resources are usable. For example, an expiration time for the access could be indicated to the DECADE-compatible server after which no resources are granted (e.g., indicate error as access denied). 8.3. Distributed Resource Sharing Specification REQUIREMENT(S): A Provider MUST be able to indicate to its DECADE- compatible server, without itself contacting the server, resource control policies for a Consumer. The DECADE-compatible server MUST be able to authenticate the resource control policies. Gu, et al. Expires February 14, 2013 [Page 16] Internet-Draft DECADE Requirements August 2012 RATIONALE: One important consideration for a DECADE-compatible server is scalability, since a single storage element may be used to support many users. Many Target Applications use small chunk sizes and frequent data exchanges. If such an application employed resource control and contacted the DECADE-compatible server for each data exchange, this could present a scalability challenge for the server as well as additional latency for clients. The preferred way is to let requesting clients obtain signed resource control policies (in the form of a token) from the owning client, and then requesting clients can present the policy to a DECADE-compatible server directly. This can result in reduced messaging handled by the DECADE-compatible server. 8.4. Resource Set REQUIREMENT(S): A DECADE-compatible server MUST allow specification on the following resources: storage, bandwidth, and number of connections, and MAY allow additional types of resources to be specified. RATIONALE: The minimum set of resources need to include the most common resources. 9. Error and Failure Handling Requirements 9.1. Illegal Data Object REQUIREMENT(S): A DECADE-compatible server SHOULD provide an error indicating that (1) data was rejected from being written, (2) deleted, or (3) marked unavailable. RATIONALE: DECADE Storage Providers may require the ability to (1) avoid storing, (2) delete, or (3) quarantine certain data that has been identified as illegal (or otherwise prohibited). It is not specified how such data is identified, but applications employing DECADE-compatible servers should not break if a Storage Provider is obligated to enforce such policies. Appropriate error conditions should be indicated to applications. EXCEPTION: A DECADE-compatible server should be able to be configured to suppress Illegal Data Object responses for security reasons. Gu, et al. Expires February 14, 2013 [Page 17] Internet-Draft DECADE Requirements August 2012 9.2. Invalid Access Authorization REQUIREMENT(S): A DECADE-compatible server SHOULD provide an error indicating that the request does not have a valid access authorization. RATIONALE: DECADE-compatible clients may request data objects to which they do not have a valid authorization, and DECADE- compatible servers should be able to signal that this has occurred. Invalid authorization may be due to a combination of credential issues as well as additional policies defined by a Storage Provider. EXCEPTION: A DECADE-compatible server should be able to be configured to suppress Invalid Authorization responses for security reasons. 9.3. Insufficient Resources REQUIREMENT(S): A DECADE-compatible server SHOULD provide a response indicating to a DECADE-compatible client that resources (e.g., storage space) were not available to service its request (e.g., storage quota exceeded when attempting to write data). RATIONALE: The Insufficient Resources response allows a client to back off, free up necessary resources or waiting for such resources to be freed. EXCEPTION: A DECADE-compatible server may not provide such a response if doing so increases the load or due to security concerns. 9.4. Overload Condition REQUIREMENT(S): A DECADE-compatible server, which is operating close to its capacity limit (e.g., too busy servicing other requests), MUST be permitted to reject requests and not be required to generate response to additional requests. A DECADE-compatible server MUST also be permitted to redirect requests as a load- shedding technique. RATIONALE: The Insufficient Resources response allows a client to back off, free up necessary resources or waiting for such resources to be freed. Gu, et al. Expires February 14, 2013 [Page 18] Internet-Draft DECADE Requirements August 2012 EXCEPTION: A DECADE-compatible server may not provide such a response if doing so increases the load or due to security concerns. 9.5. Attack Mitigation REQUIREMENT(S): A DECADE-compatible server MUST be permitted to reject suspicious requests and not be required to generate responses (e.g., if a client's rate of requests exceeds a pre- defined threshold). RATIONALE: Malicious clients may attempt to attack a DECADE- compatible server by specifying many chunks to increase total throughput or inciting overload conditions. A DECADE-compatible server is permitted to reject or ignore requests that are deemed suspicious according to policies set by its DECADE service provider. 10. Management Info Requirements 10.1. Account Status REQUIREMENT(S): A Provider MUST be able to query the resource quota as well the current usage. The response from the server MUST include resource usage resulting from both the client's own usage and usage by other clients that have been authorized to read/ write objects on that client's account. RATIONALE: The resources used by a client are not necessarily directly-attached (e.g., disk, network interface, etc). Thus, the client cannot locally determine how much resources are being used. Before storing and retrieving data, a client should be able to determine which data is available (e.g., after an application restart). 11. Security Considerations The security model is an important component of a DECADE-compatible system. It is crucial for users to be able to manage and limit distribution of content to only authorized parties, and the mechanism needs to work on the general Internet which spans multiple administrative and security domains. Previous sections have enumerated detailed requirements, but this section discusses the overall approach and other considerations that do not merit requirements. Gu, et al. Expires February 14, 2013 [Page 19] Internet-Draft DECADE Requirements August 2012 11.1. Authentication and Authorization A DECADE-compatible server must validate an request to access the in- network storage. 11.2. Confidentiality DECADE-compatible Servers provide the ability to write raw data objects (subject to any policies instituted by the owner/ administrator of the Storage Provider). Thus, DECADE-compatible clients may opt to encrypt data before it is transported to the server. 11.3. Attack Mitigation The particular resource control policy may be open to certain attacks by clients. For example by specifying many small chunks to increase total throughput or inciting overload conditions are techniques that may be used by a client. 12. IANA Considerations There are no IANA considerations with this document. 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6646] Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled Application Data Enroute (DECADE) Problem Statement", RFC 6646, July 2012. 13.2. Informative References [I-D.ietf-decade-arch] Alimi, R., Rahman, A., Kutscher, D., and Y. Yang, "DECADE Architecture", draft-ietf-decade-arch-08 (work in progress), July 2012. [LLSB08] Levin, D., LaCurts, K., Spring, N., and B. Bhattacharjee, "BitTorrent is an Auction: Analyzing and Improving BitTorrent's Incentives", SIGCOMM 2008, August 2008. Gu, et al. Expires February 14, 2013 [Page 20] Internet-Draft DECADE Requirements August 2012 Appendix A. Acknowledgments We would also like to thank Haibin Song for substantial contributions to earlier versions of this document. We would also like to thank Reinaldo Penno, Alexey Melnikov, Rich Woundy, Ning Zong, Roni Even, David McDysan, Borje Ohlman, Dirk Kutscher, Akbar Rahman, Xiao Zhu, Yunfei Zhang, Peng Zhang and Jin Peng for contributions and general feedback. Authors' Addresses Yingjie Gu Huawei No. 101 Software Avenue Nanjing, Jiangsu Province 210012 P.R.China Phone: +86-25-56624760 Email: guyingjie@huawei.com David A. Bryan Ethernot.org Email: dbryan@ethernot.org Yang Richard Yang Yale University Email: yry@cs.yale.edu Peng Zhang Tsinghua University/Yale University Email: p.zhang@yale.edu Richard Alimi Google Email: ralimi@google.com Gu, et al. Expires February 14, 2013 [Page 21]