draft-ietf-decade-reqs-06.txt   draft-ietf-decade-reqs-07.txt 
DECADE Y. Gu DECADE Y. Gu
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Informational D. Bryan Intended status: Informational D. Bryan
Expires: September 13, 2012 Polycom, Inc. Expires: February 7, 2013 Polycom, Inc.
Y. Yang Y. Yang
Yale University Yale University
P. Zhang
Tsinghua University/Yale
University
R. Alimi R. Alimi
Google Google
March 12, 2012 August 6, 2012
DECADE Requirements DECADE Requirements
draft-ietf-decade-reqs-06 draft-ietf-decade-reqs-07
Abstract Abstract
The target of the DECoupled Application Data Enroute (DECADE) system The target of the DECoupled Application Data Enroute (DECADE) system
is to provide an open and standard in-network storage system for is to provide an open and standard in-network storage system for
applications, primarily P2P (peer-to-peer) applications, to store, applications, primarily P2P (peer-to-peer) applications, to store,
retrieve and manage their data. This draft enumerates and explains retrieve and manage their data. This draft enumerates and explains
requirements, not only for storage and retrieval, but also for data requirements, not only for storage and retrieval, but also for data
management, access control and resource control, that should be management, access control and resource control, that should be
considered during the design and implementation of a DECADE- considered during the design and implementation of a DECADE-
skipping to change at page 2, line 8 skipping to change at page 2, line 11
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 13, 2012. This Internet-Draft will expire on February 7, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Requirements Structure . . . . . . . . . . . . . . . . . . . . 7 2.1. DECADE-compatible Client . . . . . . . . . . . . . . . . . 6
4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 7 2.2. DECADE-compatible Server . . . . . . . . . . . . . . . . . 6
4.1. Overall Protocol Requirements . . . . . . . . . . . . . . 7 2.3. DECADE Storage Provider . . . . . . . . . . . . . . . . . 6
4.1.1. Connectivity Concerns . . . . . . . . . . . . . . . . 7 2.4. DECADE Account . . . . . . . . . . . . . . . . . . . . . . 6
4.1.1.1. NATs and Firewalls . . . . . . . . . . . . . . . . 8 2.5. Resource Provider . . . . . . . . . . . . . . . . . . . . 6
4.1.1.2. Connections to Clients . . . . . . . . . . . . . . 8 2.6. Resource Consumer . . . . . . . . . . . . . . . . . . . . 6
4.1.2. Security . . . . . . . . . . . . . . . . . . . . . . . 8 2.7. Content Distribution Application . . . . . . . . . . . . . 6
4.1.2.1. Secure Transport . . . . . . . . . . . . . . . . . 8 2.8. Target Application . . . . . . . . . . . . . . . . . . . . 7
4.1.2.2. Gaming Prevention . . . . . . . . . . . . . . . . 8 2.9. Application End-Point . . . . . . . . . . . . . . . . . . 7
4.1.3. Error and Failure Conditions . . . . . . . . . . . . . 9 2.10. Data Object . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.3.1. Overload Condition . . . . . . . . . . . . . . . . 9 2.11. DECADE-compatible System . . . . . . . . . . . . . . . . . 7
4.1.3.2. Insufficient Resources . . . . . . . . . . . . . . 9 2.12. DECADE Resource Protocol (DRP) Functions . . . . . . . . . 7
4.1.3.3. Unavailable and Deleted Data . . . . . . . . . . . 10 2.13. DECADE Standard Data Transfer Protocol (SDT) Functions . . 7
4.1.3.4. Insufficient Permissions . . . . . . . . . . . . . 10 3. System and Protocol Components . . . . . . . . . . . . . . . . 8
4.1.3.5. Redirection . . . . . . . . . . . . . . . . . . . 10 4. Requirements Structure . . . . . . . . . . . . . . . . . . . . 9
4.2. Transfer Requirements . . . . . . . . . . . . . . . . . . 11 5. Data Object Requirements . . . . . . . . . . . . . . . . . . . 9
4.2.1. Data Object Size . . . . . . . . . . . . . . . . . . . 11 5.1. Data Name Uniqueness . . . . . . . . . . . . . . . . . . . 9
4.3. Data Access Requirements . . . . . . . . . . . . . . . . . 11 5.2. Verifiable Name-Object Binding . . . . . . . . . . . . . . 10
4.3.1. Reading/Writing Own Storage . . . . . . . . . . . . . 11 5.3. Data Object Size . . . . . . . . . . . . . . . . . . . . . 10
4.3.2. Access by Remote Clients . . . . . . . . . . . . . . . 11 5.4. Data Object Attributes . . . . . . . . . . . . . . . . . . 10
4.3.3. Negotiable Data Transport Protocol . . . . . . . . . . 12 5.5. Application-defined Object Properties and Metadata . . . . 11
4.3.4. Separation of Data and Control Policies . . . . . . . 12 6. Access and Authorization Requirements . . . . . . . . . . . . 11
4.4. Data Management Requirements . . . . . . . . . . . . . . . 12 6.1. Provider Access . . . . . . . . . . . . . . . . . . . . . 11
4.4.1. Agnostic of reliability . . . . . . . . . . . . . . . 12 6.2. Secure Authorization . . . . . . . . . . . . . . . . . . . 11
4.4.2. Data Object Attributes . . . . . . . . . . . . . . . . 13 6.3. Consumer Access . . . . . . . . . . . . . . . . . . . . . 12
4.4.3. Time-to-live for Written Data Objects . . . . . . . . 13 6.4. Provider Authorization When Offline . . . . . . . . . . . 12
4.4.4. Application-defined Properties and Metadata . . . . . 13 6.5. Local Authorization . . . . . . . . . . . . . . . . . . . 12
4.4.5. Offline Usage . . . . . . . . . . . . . . . . . . . . 14 6.6. Access Control Granularity . . . . . . . . . . . . . . . . 12
4.5. Data Naming Requirements . . . . . . . . . . . . . . . . . 14 6.7. Default Access Permissions . . . . . . . . . . . . . . . . 12
4.5.1. Unique Names . . . . . . . . . . . . . . . . . . . . . 14 6.8. Connectivity Supporting NAT and Firewall Traversal . . . . 13
4.6. Resource Control . . . . . . . . . . . . . . . . . . . . . 15 6.9. DECADE Server Discovery . . . . . . . . . . . . . . . . . 13
4.6.1. Multiple Applications . . . . . . . . . . . . . . . . 15 7. Data Transfer Requirements . . . . . . . . . . . . . . . . . . 13
4.6.2. Per-Remote-Client, Per-Data Control . . . . . . . . . 15 7.1. Negotiable Standard Data Transport Protocol . . . . . . . 13
4.6.3. Resource Control Set . . . . . . . . . . . . . . . . . 16 7.2. Atomic or Partial Read/Write . . . . . . . . . . . . . . . 14
4.6.4. Server Involvement . . . . . . . . . . . . . . . . . . 16 7.3. Secure Data Transport . . . . . . . . . . . . . . . . . . 14
4.7. Authorization . . . . . . . . . . . . . . . . . . . . . . 16 7.4. Concurrent Read . . . . . . . . . . . . . . . . . . . . . 14
4.7.1. Per-Remote-Client, Per-Data Read Access . . . . . . . 16 7.5. Concurrent Write . . . . . . . . . . . . . . . . . . . . . 14
4.7.2. Per-User Write Access . . . . . . . . . . . . . . . . 17 7.6. Read Before Write Complete . . . . . . . . . . . . . . . . 15
4.7.3. Default Access Permissions . . . . . . . . . . . . . . 17 7.7. Redirection of Transport . . . . . . . . . . . . . . . . . 15
4.7.4. Authorization Checks . . . . . . . . . . . . . . . . . 17 8. Resource Control Requirements . . . . . . . . . . . . . . . . 16
4.7.5. Cryptographic Credentials . . . . . . . . . . . . . . 17 8.1. Multiple Applications Sharing Resources . . . . . . . . . 16
4.7.6. Server Involvement . . . . . . . . . . . . . . . . . . 18 8.2. Per-Client Resource Policy . . . . . . . . . . . . . . . . 16
4.7.7. Protocol Reuse . . . . . . . . . . . . . . . . . . . . 18 8.3. Distributed Resource Sharing Specification . . . . . . . . 16
5. Storage Requirements . . . . . . . . . . . . . . . . . . . . . 18 8.4. Resource Set . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Immutable Data . . . . . . . . . . . . . . . . . . . . . . 18
5.2. Explicit Deletion of Data . . . . . . . . . . . . . . . . 19 9. Error and Failure Handling Requirements . . . . . . . . . . . 17
5.3. Multiple writing . . . . . . . . . . . . . . . . . . . . . 19 9.1. Illegal Data Object . . . . . . . . . . . . . . . . . . . 17
5.4. Multiple reading . . . . . . . . . . . . . . . . . . . . . 19 9.2. Invalid Access Authorization . . . . . . . . . . . . . . . 18
5.5. Reading before completely written . . . . . . . . . . . . 19 9.3. Insufficient Resources . . . . . . . . . . . . . . . . . . 18
5.6. Writing model . . . . . . . . . . . . . . . . . . . . . . 20 9.4. Overload Condition . . . . . . . . . . . . . . . . . . . . 18
5.7. Storage Status . . . . . . . . . . . . . . . . . . . . . . 20 9.5. Attack Mitigation . . . . . . . . . . . . . . . . . . . . 19
6. Discovery Requirements . . . . . . . . . . . . . . . . . . . . 21 10. Management Info Requirements . . . . . . . . . . . . . . . . . 19
6.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 21 10.1. Account Status . . . . . . . . . . . . . . . . . . . . . . 19
6.1.1. Support for Clients Behind NATs and Firewalls . . . . 21 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6.1.2. Prefer Existing Protocols . . . . . . . . . . . . . . 21 11.1. Authentication and Authorization . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 11.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 20
7.1. Authentication and Authorization . . . . . . . . . . . . . 21 11.3. Attack Mitigation . . . . . . . . . . . . . . . . . . . . 20
7.2. Encrypted Data . . . . . . . . . . . . . . . . . . . . . . 22 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7.3. Protection against Gaming . . . . . . . . . . . . . . . . 22 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 13.1. Normative References . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 13.2. Informative References . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
The object of the DECoupled Application Data Enroute (DECADE) system The object of the DECoupled Application Data Enroute (DECADE) system
is to provide an open and standard in-network storage for content is to provide an open and standard in-network storage for content
distribution applications, where data is typically broken into one or distribution applications, where data is typically broken into one or
more chunks and then distributed. This may already include many more chunks and then distributed. This may already include many
types of applications including P2P applications, IPTV (Internet types of applications including P2P applications, IPTV (Internet
Protocol Television), and VoD (Video on Demand). (For a precise Protocol Television), and VoD (Video on Demand). (For a precise
definition of the applications targeted in DECADE system, see the definition of the applications targeted in DECADE system, see the
skipping to change at page 6, line 5 skipping to change at page 6, line 5
This document discusses requirements pertaining to DECADE-compatible This document discusses requirements pertaining to DECADE-compatible
protocol(s). In certain deployments, several logical in-network protocol(s). In certain deployments, several logical in-network
storage systems could be deployed (e.g., within the same storage systems could be deployed (e.g., within the same
administrative domain). These in-network storage systems can administrative domain). These in-network storage systems can
communicate and transfer data through internal or non-standard communicate and transfer data through internal or non-standard
communication messages that are outside of the scope of these communication messages that are outside of the scope of these
requirements, but they should use DECADE-compatible protocol(s) when requirements, but they should use DECADE-compatible protocol(s) when
communicating with other DECADE-compatible in-network storage communicating with other DECADE-compatible in-network storage
systems. systems.
2. Terminology and Concepts 2. Terminology
This document uses the term 'In-network storage' which is defined in This document uses the term 'In-network storage' which is defined in
[I-D.ietf-decade-problem-statement]. [I-D.ietf-decade-problem-statement].
This document also defines additional terminology: This document also defines these additional terms:
Target Application: An application (typically installed at end-hosts) 2.1. DECADE-compatible Client
with the ability to explicitly control usage of network and/or
storage resources to deliver content to a large number of users.
This includes scenarios where multiple applications or entities
cooperate, such as with P2P, CDN, and hybrid P2P/CDN architectures.
Such applications distribute large amounts of content (e.g., a large
file, or video stream) by dividing the content into smaller blocks
for more flexible distribution (e.g., over multiple application-level
paths). The distributed content is immutable (though it may be
deleted and replaced). We use the term Target Application to refer
to the type of applications that are explicitly (but not exclusively)
supported by DECADE system.
DECADE-compatible server: A physical entity that can control and A DECADE-compatible client uploads and/or retrieves data from DECADE-
manage in-network storage or a logical control and management compatible servers. We use the shorter term "client" if there is no
component on in-network storage. ambiguity.
DECADE-compatible client: An interface for target applications to 2.2. DECADE-compatible Server
make use of in-network storage in DECADE system. DECADE client is
usually a software hosted on a end device, such as a PC or laptop. A
DECADE-compatible client be employed by a target applications to
communicate with DECADE server to make use of in-network storage.
DECADE-compatible protocol: A protocol between a DECADE-compatible A DECADE-compatible server stores data inside the network, and
client and a DECADE-compatible server. In this document, a DECADE- thereafter manages both the stored data and access to those data. We
compatible protocol represents the protocols, both existing and use the shorter term "server" if there is no ambiguity.
potential new protocols, that can be used by a DECADE-compatible
client and DECADE-compatible server to communicate with each other.
DECADE service provider: the provider who provides DECADE service to 2.3. DECADE Storage Provider
a DECADE-compatible client. DECADE service provider can be an in-
network storage provider, or service provider who serve users of
DECADE-compatible clients by renting or purchasing in-network storage
from in-network storage provider.
DECADE-compatible system: a system which is composed of DECADE- A DECADE Storage Provider, or Storage Provider for short, deploys
compatible clients, DECADE-compatible servers and in-network storage. and/or manages DECADE-compatible server(s) within a network.
A DECADE-compatible protocol is used for communication between
DECADE-compatible clients and DECADE-compatible servers. A DECADE-
compatible system MUST obey all the requirements defined in this
document.
3. Requirements Structure 2.4. DECADE Account
A DECADE-compatible protocol is intended to sit between Target An account of a DECADE-compatible server has associated cryptographic
Applications and a storage system. This document does not intend to credentials for access control, and resource allocation attributes on
develop yet another storage system or a new protocol, but rather to the server.
explore the requirements for the DECADE protocols, either existing
ones or a potential new one, and storage system to enable Target 2.5. Resource Provider
Applications to make use of storage within the network, leaving
specific storage system considerations to the implementation of the A client which has the account cryptographic credentials of a DECADE
storage servers as much as possible. For this reason, we have account at a DECADE-compatible server. We use the short term
divided the requirements into two primary categories: "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
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.
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
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 o Protocol Requirements: Protocol requirements for Target
Applications to make use of in-network storage within their own Applications to make use of in-network storage within their own
data dissemination schemes. Development of these requirements is data dissemination schemes. Development of these requirements is
guided by a study of data access, search and management guided by a study of data access, search and management
capabilities used by Target Applications. These requirements may capabilities used by Target Applications. These requirements may
be met by a combination of existing protocols and new protocols. be met by a combination of existing protocols and new protocols.
o Storage Requirements: Functional requirements necessary for the o Storage Requirements: Functional requirements necessary for the
back-end storage system employed by the DECADE server. back-end storage system employed by the DECADE server.
skipping to change at page 7, line 37 skipping to change at page 9, line 43
access patterns used by Target Applications. These requirements access patterns used by Target Applications. These requirements
should be met by the underlying data transport used by DECADE should be met by the underlying data transport used by DECADE
system. In this document, we use "data transport" to refer to a system. In this document, we use "data transport" to refer to a
protocol used to read and write data from in-network storage. protocol used to read and write data from in-network storage.
This specification discusses the requirements of functionality This specification discusses the requirements of functionality
implemented with a storage system and within applications, to permit implemented with a storage system and within applications, to permit
interoperable communications concerning the manipulation of stored interoperable communications concerning the manipulation of stored
content. content.
4. Protocol Requirements 5. Data Object Requirements
This section details the requirements of DECADE-compatible
protocol(s) that can be used in a DECADE-compatible system
implementation. The DECADE protocols can be existing protocols, as
long as they satisfy the requirements specified in this document, or
a new protocol which must obey all the requirements too.
4.1. Overall Protocol Requirements
4.1.1. Connectivity Concerns
4.1.1.1. NATs and Firewalls
REQUIREMENT(S): DECADE-compatible protocol(s) MUST be usable across 5.1. Data Name Uniqueness
firewalls and NAT (Network Address Translation) devices. DECADE REQUIREMENT(S): Each Data Object should be named to allow access.
protocol MUST NOT pass literal IP addresses in messages. 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: Firewalls and NATs are widely used in the Internet today, RATIONALE: Although the intention of unique names is to avoid name
both in ISP (Internet Service Provider) and Enterprise networks collisions, it does not have to be an absolutely zero
and by consumers. Deployment of a DECADE-compatible system must possibility. Hence, it is required to provide a collision
not require modifications to such devices (beyond, perhaps, handling mechanism.
reconfiguration). 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.
4.1.1.2. Connections to Clients 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.
REQUIREMENT(S): Network connections between DECADE-compatible client 5.2. Verifiable Name-Object Binding
and DECADE-compatible server MUST be initiated by the client
(i.e., the server must not initiate a connection with the
client).
RATIONALE: Many household networks and operating systems have 5.3. Data Object Size
firewalls and NATs configured by default to block incoming
connections. To ease deployment by avoiding configuration
changes and help mitigate security risks, a DECADE-compatible
client must not be required to listen for any incoming network
connections (beyond what is required by any other already-
deployed application).
4.1.2. Security REQUIREMENT(S): DECADE MUST allow for efficient storage and data
transfer of small data objects (e.g., 16KB) without large control
overhead.
4.1.2.1. Secure Transport 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).
REQUIREMENT(S): A secure transport MUST be implemented for all 5.4. Data Object Attributes
communications between a DECADE-compatible client and DECADE-
compatible server.
RATIONALE: Target Applications may wish to write sensitive data. To REQUIREMENT(S): DECADE MUST support the ability to associate a set
satisfy this use case, the communication between a DECADE- of system attributes with a data object with a scope local to a
compatible client and DECADE-compatible server must be DECADE-compatible server. In particular, the set MUST include
transported over a secure transport protocol (e.g., SSL/TLS). 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.
4.1.2.2. Gaming Prevention RATIONALE: The values of attributes associated with a data object
REQUIREMENT(S): A DECADE-compatible server MUST be permitted to are local to a particular DECADE-compatible server. These
reject suspicious requests and not be required to generate attributes may be used as hints to the storage system, internal
responses (e.g., if a client's rate of requests exceeds a pre- optimizations, or as additional information query-able by DECADE-
defined threshold). 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.
RATIONALE: Malicious clients may attempt to attack a DECADE- 5.5. Application-defined Object Properties and Metadata
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.
4.1.3. Error and Failure Conditions 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.
4.1.3.1. Overload Condition 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.
REQUIREMENT(S): A DECADE-compatible server, which is operating close 6. Access and Authorization Requirements
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 (see Section
4.1.3.5) as a load- shedding technique.
RATIONALE: Forcing a DECADE-compatible server to respond to requests 6.1. Provider Access
when operating close to its capacity can impair its ability to
service existing requests, and thus is permitted to avoid
generating response to additional requests.
4.1.3.2. Insufficient Resources REQUIREMENT(S): A Provider MUST be able to access the resources of
its account.
REQUIREMENT(S): A DECADE-compatible server SHOULD be able to provide RATIONALE: After a DECADE-compatible client owns an account on a
an error condition indicating to a DECADE-compatible client that DECADE-compatible server, it should be able to read data from and
resources (e.g., storage space) were not available to service a write data to the server.
request (e.g., storage quota exceeded when attempting to write
data).
RATIONALE: The currently-used resource levels within the in-network 6.2. Secure Authorization
storage may not be locally-discoverable. In order to allocate
resources appropriately amongst remote clients, a DECADE-
compatible client must be able to determine when resource limits
have been reached. The DECADE-compatible client can then respond
by explicitly freeing necessary resources or waiting for such
resources to be freed.
EXCEPTION: While a DECADE-compatible server is in the situation that REQUIREMENT(S): Access to an account on a server MUST be granted to
is described in Section 4.1.2.2 or Section 4.1.3.1, it need not a provider based on cryptographic security.
to respond with error condition.
4.1.3.3. Unavailable and Deleted Data 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.
REQUIREMENT(S): A DECADE-compatible server SHOULD be able to provide 6.3. Consumer Access
error conditions indicating that (1) data was rejected from being
written, (2) deleted, or (3) marked unavailable by a storage
provider.
RATIONALE: DECADE service providers may require the ability to (1) REQUIREMENT(S): A Provider MUST be able to indicate to its server on
avoid storing, (2) delete, or (3) quarantine certain data that whether a Consumer can access its subscribed resources.
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 configured RATIONALE: Endpoints in Target Applications may choose different
as not respond to any request to access unavailable or deleted servers. Thus, to be useful by Target Applications, a DECADE-
data on the in- network storage, for example, for security compatible client must be able to specify policies on whether
reasons. other DECADE-compatible clients can access its resources. The
other clients may or may not be known to the server.
4.1.3.4. Insufficient Permissions 6.4. Provider Authorization When Offline
REQUIREMENT(S): A DECADE-compatible server MUST be able to provide REQUIREMENT(S): A Provider MUST be able to grant access to a
error conditions indicating that the requesting client does not Consumer even if the Provider is not actively running or
have sufficient permissions to access requested data objects. connected to its DECADE-compatible server.
RATIONALE: DECADE-compatible clients may request objects to which RATIONALE: If an application desires, it can authorize other clients
they do not have sufficient access permissions, and DECADE- to access its storage even after the application exits or network
compatible servers must be able to signal that this has occurred. connectivity is lost. An example use case is mobile scenarios,
Access permissions may be insufficient due to a combination of where a client can lose and regain network connectivity often.
the credentials presented by a client as well as additional
policies defined by the storage provider.
4.1.3.5. Redirection 6.5. Local Authorization
REQUIREMENT(S): A DECADE-compatible server SHOULD be able to REQUIREMENT(S): A Provider MUST be able to indicate, without
redirect requests to another DECADE-compatible server. This may contacting its server, access control policies for Consumers.
either be in response to an error, failure, or overload DECADE-compatible server MUST be able to authenticate the access
condition, or to support capabilities such as load balancing. control policies in this situation.
RATIONALE: A DECADE-compatible server may opt to redirect requests RATIONALE: This requirement is related with the preceding
to another server to support capabilities such as load balancing, requirement, but in a perspective (i.e., protocol design). See
or if the implementation decides that another DECADE-compatible discussions in Section 8.3.
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 6.6. Access Control Granularity
service provider to support or not support redirection
functionality.
4.2. Transfer Requirements 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.
4.2.1. Data Object Size RATIONALE: A Target Application should able to conduct access
control on the granularity of individual clients, individual data
objects.
REQUIREMENT(S): DECADE-compatible protocol(s) MUST allow for 6.7. Default Access Permissions
efficient data transfer of small objects (e.g., 16KB) between a REQUIREMENT(S): Unless read or write access is granted by a
DECADE-compatible client and in-network storage with minimal Provider, the default permission MUST be no access.
additional latency imposed by the protocol(s).
RATIONALE: Though Target Applications are frequently used to share RATIONALE: This requirement is to protect client privacy by default.
large amounts of data (e.g., continuous streams or large files),
the data itself is typically subdivided into smaller chunks that
are transferred between clients. Additionally, clients may be
sensitive to the delivery time of chunks (e.g., in a live-
streaming application). DECADE-compatible protocol(s) must
enable data to be efficiently transferred amongst DECADE-
compatible clients at this granularity.
4.3. Data Access Requirements 6.8. Connectivity Supporting NAT and Firewall Traversal
4.3.1. Reading/Writing Own Storage 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).
REQUIREMENT(S): DECADE-compatible protocol(s) MUST enable a DECADE- RATIONALE: Firewalls and NATs are widely used in the Internet today,
compatible client to read data from and write data to its own in- both in ISP (Internet Service Provider) and Enterprise networks
network storage. 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.
RATIONALE: Two basic capabilities for any storage system are reading 6.9. DECADE Server Discovery
and writing data. A DECADE-compatible client can read data from
and write data to in-network storage space that it owns.
4.3.2. Access by Remote Clients 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.
REQUIREMENT(S): A DECADE-compatible client MUST be able to apply RATIONALE: Existing protocols such as DNS and DHCP are widespread.
access control policies to remote DECADE-compatible clients other Using existing protocols, or combinations of the protocols that
than itself for its storage. The remote DECADE-compatible have been specified in other contexts, is strictly preferred over
clients with whom access is being shared can be under a different developing a new discovery protocol.
administrative domain than the DECADE-compatible client who owns
the in-network storage.
RATIONALE: Endpoints in Target Applications may be located across 7. Data Transfer Requirements
multiple ISPs under multiple administrative domains. Thus, to be
useful by Target Applications, a DECADE-compatible client must be
able to specify access control policies for remote DECADE-
compatible clients that may or may not be known to the client's
own DECADE service provider.
4.3.3. Negotiable Data Transport Protocol 7.1. Negotiable Standard Data Transport Protocol
REQUIREMENT(S): DECADE-compatible client MUST be able to negotiate REQUIREMENT(S): A DECADE-compatible client MUST be able to negotiate
with DECADE server about which protocol it can use to read data with a DECADE-compatible server about which protocol it can use
from and write data to its in-network storage. DECADE system to read data from and write data. DECADE MUST specify at least
MUST specify at least one mandatory protocol to be supported by one mandatory transport protocol to be supported by
implementations; usage of a different protocol may be selected implementations; usage of a different protocol may be selected
via negotiation. via negotiation.
RATIONALE: Since typical data transport protocols (e.g., NFS and RATIONALE: Since typical data transport protocols (e.g., NFS and
WebDAV) already provide read and write operations for network WebDAV) already provide read and write operations for network
storage, it may not be necessary to define such operations in a storage, it may not be necessary to define such operations in a
new DECADE protocol. However, because of the particular new DECADE protocol. However, because of the particular
application requirements and deployment considerations, different application requirements and deployment considerations, different
applications may support different protocols. Thus, a DECADE applications may support different protocols. Thus, a DECADE
client must be able to select an appropriate protocol also client must be able to select an appropriate protocol also
supported by the in-network storage. This requirement also supported by the in-network storage.
follows as a result of the requirement of Separation of Control
and Data Operations (Section 4.3.4).
4.3.4. Separation of Data and Control Policies
REQUIREMENT(S): DECADE-compatible protocol(s) MUST provide a minimal
set of core operations to support diverse policies implemented
and desired by Target Applications, and MAY provide additional
operations.
RATIONALE: Target Applications support many complex behaviors and
diverse policies to control and distribute data, such as (e.g.,
search, index, setting permissions/passing authorization tokens).
Thus, to support such Target Applications, these behaviors must
be logically separated from the data transfer operations (e.g.,
read, write). Some minimal overlap (for example obtaining
credentials needed to encrypt or authorize data transfer using
control operations) is required to be supported by DECADE-
compatible protocol(s).
4.4. Data Management Requirements 7.2. Atomic or Partial Read/Write
4.4.1. Agnostic of reliability 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.
REQUIREMENT(S): DECADE-compatible protocol(s) MUST remain agnostic RATIONALE: Depending on the object size (e.g., chunk size) used by a
of reliability/ fault-tolerance level offered by DECADE service Target Application, the application may need to send data to the
provider. DECADE-compatible server in multiple round.
RATIONALE: Providers of a DECADE service may wish to offer varying 7.3. Secure Data Transport
levels of service for different applications/users. However, a
single DECADE-compatible client must be able to use multiple
DECADE services with differing levels of service.
4.4.2. Data Object Attributes REQUIREMENT(S): A secure transport MUST be implemented for all
communications between a DECADE-compatible client and DECADE-
compatible server.
REQUIREMENT(S): DECADE-compatible protocol(s) MUST support the RATIONALE: Target Applications may wish to write sensitive data. To
ability to associate attributes with data objects with a scope satisfy this use case, the communication between a DECADE-
local to a DECADE-compatible server, and for DECADE-compatible compatible client and DECADE-compatible server must be
clients to query these attributes. DECADE-compatible protocol(s) transported over a secure transport protocol (e.g., SSL/TLS).
MUST transmit any attributes using an operating system-
independent and architecture-independent standard format. If
there is a need to design any DECADE protocols, they MUST be
designed such that new attributes can be added by later protocol
revisions or extensions.
RATIONALE: A DECADE-compatible client can associate attributes 7.4. Concurrent Read
(e.g., a time-to- live, creation timestamp, or object size) with
a data object. These attributes are local to a data object
stored by a particular DECADE-compatible server, and are thus not
applied to any DECADE-compatible server or client to which the
data object is copied. These attributes may be used as hints to
the storage system, internal optimizations, or as additional
information query-able by DECADE-compatible clients.
4.4.3. Time-to-live for Written Data Objects REQUIREMENT(S): A DECADE-compatible server MUST allow for multiple
simultaneous readers for a data object.
REQUIREMENT(S): A DECADE-compatible client MUST be able to indicate RATIONALE: One characteristic of Target Applications is the ability
a time-to- live value (or expiration time) indicating a length of to upload an object to multiple clients. Thus, it is natural for
time until particular data can be deleted by a DECADE-compatible DECADE-compatible server to allow multiple readers to read the
server. same object concurrently.
RATIONALE: Some data objects written by a DECADE-compatible client 7.5. Concurrent Write
may be usable only within a certain window of time, such as in
live- streaming P2P applications. Providing a time-to-live value
for data objects (e.g., at the time they are written) can reduce
management overhead by avoiding many 'delete' commands sent to
DECADE-compatible server. The in-network storage may still keep
the data in cache for bandwidth optimization. But this is guided
by the privacy policy of the DECADE service provider.
4.4.4. Application-defined Properties and Metadata REQUIREMENT(S): A DECADE-compatible server MUST NOT allow multiple
REQUIREMENT(S): DECADE-compatible clients and DECADE-compatible simultaneous writers for the same object. A DECADE-compatible
servers MUST NOT be able to associate Application-defined server SHOULD respond to each of the writers with an error.
properties (metadata) with data objects beyond what is provided
by Section 4.4.2.
RATIONALE: Associating key-value pairs that are defined by Target RATIONALE: This avoids data corruption in a simple way while
Applications with data objects introduces substantial complexity remaining efficient. Alternately, the DECADE-compatible server
to the protocol(s). If Target Applications wish to associate would need to either manage locking, handle write collisions, or
additional metadata with a data object, possible alternatives merge data, all of which reduce efficiency and increase
include (1) managing such metadata within the Target Application complexity.
itself, (2) storing metadata inside of the data object, or (3)
storing metadata in a different data object at the DECADE-
compatible server.
4.4.5. Offline Usage EXCEPTION: While a DECADE-compatible server is overloaded or
considers a request as an attack, it does not generate a
response.
REQUIREMENT(S): A DECADE-compatible client MAY provide authorized 7.6. Read Before Write Complete
access from remote clients to its in-network storage even if the
DECADE client is actively running or connected to a DECADE-
compatible server.
RATIONALE: If an application desires, it can authorize remote REQUIREMENT(S): A DECADE-compatible server MAY allow readers to read
clients to access its storage even after the application exits or a data object before it has been completely written. In case of
network connectivity is lost. An example use case is mobile a write error in such a case, the DECADE-compatible server SHOULD
scenarios, where a client can lose and regain network respond to the reading client with an error indicating that the
connectivity very often. write has failed.
4.5. Data Naming Requirements 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.
4.5.1. Unique Names EXCEPTION: While a DECADE-compatible server is overloaded or
considers a request as an attack, it does not generate a
response.
REQUIREMENT(S): DECADE-compatible protocol(s) MUST support a data 7.7. Redirection of Transport
object naming scheme that ensures a high probability of
uniqueness and supports the operation of DECADE-compatible
servers under diverse administrative domains with no
coordination. DECADE-compatible server SHOULD be able to respond
to DECADE-compatible client with error condition indicating the
name of the object conflicts with other object.
RATIONALE: When writing a data object, a DECADE-compatible Client REQUIREMENT(S): A DECADE-compatible server SHOULD be able to
should be able to write it without being concerned over whether redirect requests to another DECADE-compatible server. This may
an object of the same name already exists, unless the existing either be in response to an error, failure, overload, or to
object contains the exact same data. Although the intention is support capabilities such as load balancing.
to avoid name collision, it's not absolutely zero possibility.
As a result, it is required to provide a collision handling
mechanism.
EXCEPTION: While a DECADE-compatible server is in situations RATIONALE: A DECADE-compatible server may opt to redirect requests
described in Section 4.1.2.2 or Section 4.1.3.1, it need not to to another server to support capabilities such as load balancing,
generate a response to the client. 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.
4.6. Resource Control EXCEPTION: A DECADE-compatible server can be configured by its
service provider to support or not support redirection
functionality.
4.6.1. Multiple Applications 8. Resource Control Requirements
REQUIREMENT(S): A DECADE-compatible client MUST be able to indicate 8.1. Multiple Applications Sharing Resources
to a DECADE-compatible server about resource sharing policies for
multiple target applications being run/managed by the same user.
RATIONALE: A user may own in-network storage and share the in- REQUIREMENT(S): A client MUST be able to indicate to a DECADE-
network storage resources amongst multiple target applications. compatible server about resource sharing policies among multiple
For example, the user may run one or more video-on-demand Target Applications being run/managed by the same client.
application(s) and a live-streaming application(s) which both
make use of the user's in-network storage. The applications may
be running on different machines and may not directly
communicate. Thus, user should be able to determine resource
sharing policies between the applications.
One possibility is for a user to indicate the particular resource RATIONALE: A client owning a DECADE account may provide the
sharing policies between applications out-of-band (not using a account's cryptographic credentials to multiple Providers of
standard protocol), but this requirement may manifest itself in multiple target applications. For example, the client may run
passing values within DECADE-compatible protocol(s) to identify one or more video-on-demand application(s) and a live-streaming
individual applications. Such identifiers can be either user- application(s) which both make use of the client's in-network
generated or server-generated and do not need to be registered by storage. The concurrently running applications may be running on
IANA. different machines (e.g., multiple machines at the same home
network) and may not directly communicate, except through user
coordination
4.6.2. Per-Remote-Client, Per-Data Control 8.2. Per-Client Resource Policy
REQUIREMENT(S): A DECADE-compatible client MUST be able to assign REQUIREMENT(S): A Provider MUST be able to specify resource policies
resource policies (bandwidth share, storage quota, and network (bandwidth share, storage quota, and network connection quota) to
connection quota) to individual remote clients for reading from individual Consumers for reading from and writing data to its in-
and writing particular data to its in-network storage within a network storage within a particular range of time.
particular range of time.
RATIONALE: Target Applications can rely on control of resources on a RATIONALE: Target Applications can rely on control of resources on a
per-remote-client or per-data basis. For example, application per-client basis. For example, application policy may indicate
policy may indicate that certain remote clients have a higher that certain remote clients have a higher bandwidth share for
bandwidth share for receiving data [LLSB08]. Additionally, receiving data [LLSB08]. Additionally, bandwidth share for
bandwidth share for receiving data [LLSB08]. Additionally, receiving data [LLSB08]. Additionally, certain data (e.g.,
certain data (e.g., chunks) may be distributed with a higher chunks) may be distributed with a higher priority. As another
priority. As another example, when allowing a remote client to example, when allowing a remote client to write data to a user's
write data to a user's in-network storage, the remote client may in-network storage, the remote client may be restricted to write
be restricted to write less than 100MB of data in total. Since less than 100MB of data in total. Since the client may need to
the client may need to manage multiple clients accessing its manage multiple clients accessing its data, it should be able to
data, it should be able to indicate the time over which the indicate the time over which the granted resources are usable.
granted resources are usable. For example, an expiration time For example, an expiration time for the access could be indicated
for the access could be indicated to the DECADE-compatible server to the DECADE-compatible server after which no resources are
after which no resources are granted (e.g., indicate error as granted (e.g., indicate error as access denied).
access denied).
4.6.3. Resource Control Set
REQUIREMENT(S): DECADE-compatible protocol(s) MUST define a minimum
set of resource control methods, and MAY add additional set of
resource control methods.
RATIONALE: The minimum set of resource control methods need to
include the most common resource control methods. Implementors
can add proprietary set of resource control methods in their own
implementation.
4.6.4. Server Involvement 8.3. Distributed Resource Sharing Specification
REQUIREMENT(S): A DECADE-compatible client MUST be able to indicate REQUIREMENT(S): A Provider MUST be able to indicate to its DECADE-
to a DECADE-compatible server, without itself contacting the compatible server, without itself contacting the server, resource
server, resource control policies for remote clients' requests. control policies for a Consumer. The DECADE-compatible server
A DECADE-compatible server MUST be able to authenticate the MUST be able to authenticate the resource control policies.
resource control policies in this situation.
RATIONALE: One important consideration for a DECADE-compatible RATIONALE: One important consideration for a DECADE-compatible
server is scalability, since a single storage element may be used server is scalability, since a single storage element may be used
to support many users. Many Target Applications use small chunk to support many users. Many Target Applications use small chunk
sizes and frequent data exchanges. If such an application sizes and frequent data exchanges. If such an application
employed resource control and contacted the DECADE-compatible employed resource control and contacted the DECADE-compatible
server for each data exchange, this could present a scalability server for each data exchange, this could present a scalability
challenge for the server as well as additional latency for challenge for the server as well as additional latency for
clients. clients.
The preferred way is to let requesting clients obtain signed The preferred way is to let requesting clients obtain signed
resource control policies (in the form of a token) from the resource control policies (in the form of a token) from the
owning client, and then requesting clients can present the policy owning client, and then requesting clients can present the policy
to a DECADE-compatible server directly. This can result in to a DECADE-compatible server directly. This can result in
reduced messaging handled by the DECADE-compatible server. reduced messaging handled by the DECADE-compatible server.
4.7. Authorization 8.4. Resource Set
4.7.1. Per-Remote-Client, Per-Data Read Access
REQUIREMENT(S): A DECADE-compatible Client MUST be able to control
which individual remote clients are authorized to read particular
data from its in-network storage.
RATIONALE: A Target Application can control certain application-
level policies by sending particular data (e.g., chunks) to
certain remote clients.
4.7.2. Per-User Write Access
REQUIREMENT(S): A DECADE-compatible Client MUST be able to control
which individual remote clients are authorized to write data into
its in-network storage.
RATIONALE: The space managed by a user in in-network storage can be
a limited resource. At the same time, it can be useful to allow
remote clients to write data directly to a user's in-network
storage. Thus, a DECADE-compatible client should be able to
grant only certain remote clients this privilege.
4.7.3. Default Access Permissions
REQUIREMENT(S): Unless read or write access is granted by a DECADE
Client to a remote client, the default access MUST be no access.
RATIONALE: The current leading proposal for an access control model
in DECADE working group is via token passing, resulting in a
system with little state on the server side.
4.7.4. Authorization Checks
REQUIREMENT(S): A DECADE-compatible server MUST check the
authorization of a client before it executes a supplied request.
RATIONALE: The data stored at a DECADE-compatible server is assumed
to be private, and thus not accessible to a DECADE-enabled client
unless it is explicitly granted permission.
4.7.5. Cryptographic Credentials
REQUIREMENT(S): Access MUST be able to be granted using
cryptographic credentials.
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.
4.7.6. Server Involvement
REQUIREMENT(S): A DECADE-compatible client MUST be able to indicate,
without contacting the server itself, access control policies for
remote clients' requests. DECADE-compatible server MUST be able
to authenticate the access control policies in this situation.
RATIONALE: See discussion in Section 4.6.4.
4.7.7. Protocol Reuse
REQUIREMENT(S): DECADE SHOULD reuse existing protocol and mechanisms
for Authentication, Access, and Authorization (AAA). No new AAA
protocol and mechanism are going to be defined unless there is
explicit proof that existing protocol and mechanisms are not
applicable.
RATIONALE: If possible, reusing an existing AAA protocol/mechanism REQUIREMENT(S): A DECADE-compatible server MUST allow specification
will minimize the development required by applications, and will on the following resources: storage, bandwidth, and number of
maximize interoperability of the DECADE-compatible protocol(s) connections, and MAY allow additional types of resources to be
with existing infrastructure. specified.
5. Storage Requirements RATIONALE: The minimum set of resources need to include the most
common resources.
This section details the requirements of the underlying storage used 9. Error and Failure Handling Requirements
to support DECADE-compatible protocol(s).
5.1. Immutable Data 9.1. Illegal Data Object
REQUIREMENT(S): The data objects MUST be immutable once they are REQUIREMENT(S): A DECADE-compatible server SHOULD provide an error
written to storage. indicating that (1) data was rejected from being written, (2)
deleted, or (3) marked unavailable.
RATIONALE: Immutable data objects are an important simplification in RATIONALE: DECADE Storage Providers may require the ability to (1)
DECADE-compatible system. Reasonable consistency models for avoid storing, (2) delete, or (3) quarantine certain data that
updating existing objects would significantly complicate has been identified as illegal (or otherwise prohibited). It is
implementation (especially if implementation chooses to replicate not specified how such data is identified, but applications
data across multiple servers). If the content owners have to employing DECADE-compatible servers should not break if a Storage
modify the written data objects, there are many ways to do so. Provider is obligated to enforce such policies. Appropriate
First, they can use different data names for different object error conditions should be indicated to applications.
versions. Secondly, they can split single monolithic files into
fragments, so that new fragment versions could be substituted
later (e.g. corrections or updated advertising) via a play list.
5.2. Explicit Deletion of Data EXCEPTION: A DECADE-compatible server should be able to be
configured to suppress Illegal Data Object responses for security
reasons.
REQUIREMENT(S): A DECADE-compatible client MUST be able to 9.2. Invalid Access Authorization
explicitly delete data from its own in-network storage.
RATIONALE: A DECADE-compatible client may continually be writing REQUIREMENT(S): A DECADE-compatible server SHOULD provide an error
data to its in-network storage. Since there may be a limit indicating that the request does not have a valid access
(e.g., imposed by the storage provider) to how much total storage authorization.
can be used, some data may need to be removed to make room for
additional data. A DECADE-compatible client should be able to
explicitly remove particular data. This may be implemented using
existing protocols.
5.3. Multiple writing 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.
REQUIREMENT(S): A DECADE-compatible server MUST NOT allow multiple EXCEPTION: A DECADE-compatible server should be able to be
simultaneous writers for the same object. A DECADE-compatible configured to suppress Invalid Authorization responses for
server SHOULD respond to each of the writers with error condition security reasons.
indicating the attempt of simultaneous writing.
RATIONALE: This avoids data corruption in a simple way while 9.3. Insufficient Resources
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 in the situation that REQUIREMENT(S): A DECADE-compatible server SHOULD provide a response
is described in Section 4.1.2.2 or Section 4.1.3.1, it need not indicating to a DECADE-compatible client that resources (e.g.,
generate a response. storage space) were not available to service its request (e.g.,
storage quota exceeded when attempting to write data).
5.4. Multiple reading RATIONALE: The Insufficient Resources response allows a client to
back off, free up necessary resources or waiting for such
resources to be freed.
REQUIREMENT(S): A DECADE-compatible server MUST allow for multiple EXCEPTION: A DECADE-compatible server may not provide such a
simultaneous readers for an object. response if doing so increases the load or due to security
concerns.
RATIONALE: One characteristic of Target Applications is the ability 9.4. Overload Condition
to upload an object to multiple clients. Thus, it is natural for
DECADE-compatible server to allow multiple readers to read the
content concurrently.
5.5. Reading before completely written 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 (see Section
4.1.3.5) as a load-shedding technique.
REQUIREMENT(S): A DECADE-compatible server MAY allow readers to read RATIONALE: The Insufficient Resources response allows a client to
from objects before they have been completely written. In case back off, free up necessary resources or waiting for such
of object writing error, DECADE-compatible server SHOULD be able resources to be freed.
to respond to the reading DECADE-compatible client with error
condition indicating that the object writing is failed.
RATIONALE: Some Target Applications (in particular, P2P streaming) EXCEPTION: A DECADE-compatible server may not provide such a
can be sensitive to latency. A technique to reduce latency is to response if doing so increases the load or due to security
remove store-and-forward delays for data objects (e.g., make the concerns.
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 in the situation that 9.5. Attack Mitigation
is described in Section 4.1.2.2 or Section 4.1.3.1, it need not
generate a response.
5.6. Writing model 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).
REQUIREMENT(S): A DECADE-compatible server MUST provide at least a RATIONALE: Malicious clients may attempt to attack a DECADE-
writing model (while writing an object) that appends data to data compatible server by specifying many chunks to increase total
already written. 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.
RATIONALE: Depending on the object size (e.g., chunk size) used by a 10. Management Info Requirements
Target Application, the application may need to send data to the
DECADE-compatible server in multiple packets. To keep
implementation simple, the DECADE-compatible server must at least
support the ability to write the data sequentially in the order
received. Implementations MAY allow application to write data in
an object out-of-order (but MUST NOT overwrite ranges of the
object that have already been written).
5.7. Storage Status 10.1. Account Status
REQUIREMENT(S): A DECADE-compatible server MUST be able to respond REQUIREMENT(S): A Provider MUST be able to query the resource quota
resource usage and resource quotas. A minimum set of storage as well the current usage. The response from the server MUST
status supported by DECADE-compatible server MUST include include resource usage resulting from both the client's own usage
resource usage resulting from the client's own usage (including and usage by other clients that have been authorized to read/
list of written data objects) and usage by other clients that write objects on that client's account.
have been authorized to read/write objects on that client's
storage. A DECADE-compatible server MUST be able to authenticate
the request.
RATIONALE: The resources used by a client are not necessarily RATIONALE: The resources used by a client are not necessarily
directly-attached (e.g., disk, network interface, etc). Thus, directly-attached (e.g., disk, network interface, etc). Thus,
the client cannot locally determine how such resources are being the client cannot locally determine how much resources are being
used. Before storing and retrieving data, a client should be used. Before storing and retrieving data, a client should be
able to determine which data is available (e.g., after an able to determine which data is available (e.g., after an
application restart). application restart).
6. Discovery Requirements 11. Security Considerations
6.1. Requirements
6.1.1. Support for Clients Behind NATs and Firewalls
REQUIREMENT(S): The mechanism for discovering a DECADE-compatible
server MUST be operable by DECADE-compatible clients operating
behind NATs and Firewalls.
RATIONALE: NATs and Firewalls are prevalent in network deployments,
and it is common for Target Applications that include a DECADE-
compatible client to be deployed behind these devices.
6.1.2. Prefer Existing Protocols
REQUIREMENT(S): The mechanism for discovering a DECADE-compatible
server 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. Security Considerations
The security model is an important component of a DECADE-compatible The security model is an important component of a DECADE-compatible
system. It is crucial for users to be able to manage and limit system. It is crucial for users to be able to manage and limit
distribution of content to only authorized parties, and the mechanism distribution of content to only authorized parties, and the mechanism
needs to work on the general Internet which spans multiple needs to work on the general Internet which spans multiple
administrative and security domains. Previous sections have administrative and security domains. Previous sections have
enumerated detailed requirements, but this section discusses the enumerated detailed requirements, but this section discusses the
overall approach and other considerations that do not merit overall approach and other considerations that do not merit
requirements. requirements.
7.1. Authentication and Authorization 11.1. Authentication and Authorization
A DECADE-compatible server must authenticate any DECADE-compatible A DECADE-compatible server must validate an request to access the in-
client that attempts to access the in-network storage. DECADE- network storage.
compatible server is not involved in the authorization between DECADE
clients and remote clients, or the authorization between DECADE
system user and DECADE service provider. In order to authenticate an
accessing DECADE client, a DECADE-compatible server may need to
accept the authentication and authorization referral by another
DECADE-compatible client.
7.2. Encrypted Data 11.2. Confidentiality
DECADE-compatible Servers provide the ability to write raw data DECADE-compatible Servers provide the ability to write raw data
objects (subject to any policies instituted by the owner/ objects (subject to any policies instituted by the owner/
administrator of the service provider). Thus, DECADE-compatible administrator of the Storage Provider). Thus, DECADE-compatible
clients may opt to encrypt data before it is transported to the clients may opt to encrypt data before it is transported to the
server. However, DECADE-compatible protocol(s) do not provide server.
encryption of data objects other than that provided by
Section 4.1.2.1.
7.3. Protection against Gaming 11.3. Attack Mitigation
The particular resource control policy communicated by DECADE- The particular resource control policy may be open to certain attacks
compatible protocol(s) and enforced on DECADE-compatible server may by clients. For example by specifying many small chunks to increase
be open to certain gaming by clients. For example by specifying many total throughput or inciting overload conditions are techniques that
small chunks to increase total throughput or inciting overload may be used by a client.
conditions are techniques that may be used by a client.
8. IANA Considerations 12. IANA Considerations
There are no IANA considerations with this document. There are no IANA considerations with this document.
9. References 13. References
9.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.ietf-decade-problem-statement] [I-D.ietf-decade-problem-statement]
Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled
Application Data Enroute (DECADE) Problem Statement", Application Data Enroute (DECADE) Problem Statement",
draft-ietf-decade-problem-statement-03 (work in progress), draft-ietf-decade-problem-statement-03 (work in progress),
March 2011. March 2011.
9.2. Informative References 13.2. Informative References
[I-D.ietf-decade-arch] [I-D.ietf-decade-arch]
Alimi, R., Yang, Y., Rahman, A., Kutscher, D., and H. Liu, Alimi, R., Yang, Y., Rahman, A., Kutscher, D., and H. Liu,
"DECADE Architecture", draft-ietf-decade-arch-02 (work in "DECADE Architecture", draft-ietf-decade-arch-02 (work in
progress), July 2011. progress), July 2011.
[LLSB08] Levin, D., LaCurts, K., Spring, N., and B. Bhattacharjee, [LLSB08] Levin, D., LaCurts, K., Spring, N., and B. Bhattacharjee,
"BitTorrent is an Auction: Analyzing and Improving "BitTorrent is an Auction: Analyzing and Improving
BitTorrent's Incentives", SIGCOMM 2008, August 2008. BitTorrent's Incentives", SIGCOMM 2008, August 2008.
[PPLive] "PPLive", <http://www.pplive.com>. [PPLive] "PPLive", <http://www.pplive.com>.
Appendix A. Acknowledgments Appendix A. Acknowledgments
We would also like to thank Haibin Song for substantial contributions We would also like to thank Haibin Song for substantial contributions
to earlier versions of this document. We would also like to thank to earlier versions of this document. We would also like to thank
Reinaldo Penno, Alexey Melnikov, Rich Woundy, Ning Zong, Roni Even, Reinaldo Penno, Alexey Melnikov, Rich Woundy, Ning Zong, Roni Even,
David McDysan, Borje Ohlman, Dirk Kutscher, Akbar Rahman, Xiao Zhu, David McDysan, Borje Ohlman, Dirk Kutscher, Akbar Rahman, Xiao Zhu,
Yunfei Zhang, and Jin Peng for contributions and general feedback. Yunfei Zhang, Peng Zhang and Jin Peng for contributions and general
feedback.
Authors' Addresses Authors' Addresses
Yingjie Gu Yingjie Gu
Huawei Huawei
No. 101 Software Avenue No. 101 Software Avenue
Nanjing, Jiangsu Province 210012 Nanjing, Jiangsu Province 210012
P.R.China P.R.China
Phone: +86-25-56624760 Phone: +86-25-56624760
skipping to change at page 23, line 36 skipping to change at page 21, line 38
David A. Bryan David A. Bryan
Polycom, Inc. Polycom, Inc.
Email: dbryan@ethernot.org Email: dbryan@ethernot.org
Yang Richard Yang Yang Richard Yang
Yale University Yale University
Email: yry@cs.yale.edu Email: yry@cs.yale.edu
Peng Zhang
Tsinghua University/Yale University
Email: p.zhang@yale.edu
Richard Alimi Richard Alimi
Google Google
Email: ralimi@google.com Email: ralimi@google.com
 End of changes. 132 change blocks. 
648 lines changed or deleted 565 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/