DECADE R. Alimi
Internet-Draft Google
Intended status: Informational A. Rahman
Expires: September 13, 2012 InterDigital Communications, LLC
D. Kutscher
NEC
Y. Yang
Yale University
March 12, 2012
DECADE Architecture
draft-ietf-decade-arch-05
Abstract
Content Distribution Applications (e.g., P2P applications) are widely
used on the Internet and make up a large portion of the traffic in
many networks. One technique to improve the network efficiency of
these applications is to introduce storage capabilities within the
networks; this is the capability to be provided by a DECADE
(DECoupled Application Data Enroute) compliant system. This document
presents an architecture for DECADE, discusses the underlying
principles, and identifies key functionalities required for
introducing in-network storage for these applications. In addition,
some examples are given to illustrate these concepts in an
informative manner.
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 RFC 2119 [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-
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."
Alimi, et al. Expires September 13, 2012 [Page 1]
Internet-Draft DECADE Architecture March 2012
This Internet-Draft will expire on September 13, 2012.
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.
Alimi, et al. Expires September 13, 2012 [Page 2]
Internet-Draft DECADE Architecture March 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Functional Entities . . . . . . . . . . . . . . . . . . . . . 5
2.1. DECADE Server . . . . . . . . . . . . . . . . . . . . . . 6
2.2. DECADE Client . . . . . . . . . . . . . . . . . . . . . . 6
2.3. DECADE Storage Provider . . . . . . . . . . . . . . . . . 6
2.4. Content Provider Using DECADE . . . . . . . . . . . . . . 6
2.5. Content Consumer Using DECADE . . . . . . . . . . . . . . 6
2.6. Content Distribution Application . . . . . . . . . . . . . 7
3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. An Example . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Architectural Principles . . . . . . . . . . . . . . . . . . . 9
4.1. Decoupled Control/Metadata and Data Planes . . . . . . . . 10
4.2. Immutable Data Objects . . . . . . . . . . . . . . . . . . 10
4.3. Data Object Identifiers . . . . . . . . . . . . . . . . . 11
4.4. DECADE Data Object Naming Scheme . . . . . . . . . . . . . 12
4.5. Explicit Control . . . . . . . . . . . . . . . . . . . . . 13
4.6. Resource and Data Access Control through User
Delegation . . . . . . . . . . . . . . . . . . . . . . . . 14
5. System Components . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Content Distribution Application . . . . . . . . . . . . . 15
5.2. DECADE Server . . . . . . . . . . . . . . . . . . . . . . 17
5.3. Data Sequencing and Naming . . . . . . . . . . . . . . . . 19
5.4. Token-based Authentication and Resource Control . . . . . 22
5.5. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 23
6. DECADE Protocols . . . . . . . . . . . . . . . . . . . . . . . 24
6.1. DECADE Resource Protocol (DRP) . . . . . . . . . . . . . . 24
6.2. Standard Data Transfer (SDT) . . . . . . . . . . . . . . . 27
6.3. Server-to-Server Protocols . . . . . . . . . . . . . . . . 29
7. Security Considerations . . . . . . . . . . . . . . . . . . . 31
7.1. Threat: System Denial of Service Attacks . . . . . . . . . 31
7.2. DECADE Protocol Security Threats . . . . . . . . . . . . . 32
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
10.1. Normative References . . . . . . . . . . . . . . . . . . . 34
10.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. In-Network Storage Components Mapped to DECADE
Architecture . . . . . . . . . . . . . . . . . . . . 35
A.1. Data Access Interface . . . . . . . . . . . . . . . . . . 35
A.2. Data Management Operations . . . . . . . . . . . . . . . . 35
A.3. Data Search Capability . . . . . . . . . . . . . . . . . . 35
A.4. Access Control Authorization . . . . . . . . . . . . . . . 36
A.5. Resource Control Interface . . . . . . . . . . . . . . . . 36
A.6. Discovery Mechanism . . . . . . . . . . . . . . . . . . . 36
A.7. Storage Mode . . . . . . . . . . . . . . . . . . . . . . . 36
Alimi, et al. Expires September 13, 2012 [Page 3]
Internet-Draft DECADE Architecture March 2012
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Alimi, et al. Expires September 13, 2012 [Page 4]
Internet-Draft DECADE Architecture March 2012
1. Introduction
Content Distribution Applications (e.g., P2P applications) are widely
used on the Internet today to distribute data, and they contribute a
large portion of the traffic in many networks. The DECADE-compatible
architecture described in this document enables such applications to
leverage in-network storage to achieve more efficient content
distribution. Specifically, in many subscriber networks, it can be
expensive to upgrade network equipment in the "last-mile", because it
can involve replacing equipment and upgrading wiring at individual
homes, businesses, and devices such as DSLAMs (Digital Subscriber
Line Access Multiplexers) and CMTSs (Cable Modem Termination Systems)
in remote locations. Therefore, it may be cheaper to upgrade the
core infrastructure, which involves fewer components that are shared
by many subscribers. See [I-D.ietf-decade-problem-statement] for a
more complete discussion of the problem domain and general
discussions of the capabilities to be provided by a DECADE-compatible
system.
This document presents an architecture for providing in-network
storage that can be integrated into Content Distribution
Applications. The primary focus is P2P-based content distribution,
but the architecture may be useful to other applications with similar
characteristics and requirements. See [I-D.ietf-decade-reqs] for a
definition of the target applications supported by a DECADE-
compatible system.
The approach of this document is to define the core functionalities
and protocol requirements that are needed to support in-network
storage in a DECADE-compatible system. The protocol themselves are
not selected or designed. Also, if more complex functionalities are
needed, they should be layered on top of the DECADE-compatible system
in an application specific manner.
Some illustrative examples are given to help the reader understand
certain concepts. These examples are purely informational and are
not meant to guide or constrain future protocol design or selection.
2. Functional Entities
This section defines the functional entities involved in a DECADE
system. Functional entities are classified as follows:
o A physical or logical component in the DECADE architecture: DECADE
Client, DECADE Server, Content Distribution Application and
Application End Point;
Alimi, et al. Expires September 13, 2012 [Page 5]
Internet-Draft DECADE Architecture March 2012
o Operator of a physical or logical component in the DECADE
architecture: DECADE Storage Provider; and
o Source or sink of content distributed via the DECADE architecture:
DECADE Content Provider, and DECADE Content Consumer.
2.1. DECADE Server
A DECADE server stores DECADE data inside the network, and thereafter
manages both the stored data and access to that data. To reinforce
that these servers are responsible for storage of raw data, this
document also refers to them as storage servers.
2.2. DECADE Client
A DECADE client stores and retrieves data at DECADE Servers.
2.3. DECADE Storage Provider
A DECADE storage provider deploys and/or manages DECADE storage
server(s) within a network. A storage provider may also own or
manage the network in which the DECADE servers are deployed, but this
is not mandatory.
A DECADE storage provider, possibly in cooperation with one or more
network providers, determines deployment locations for DECADE servers
and determines the available resources for each.
2.4. Content Provider Using DECADE
A content provider using DECADE accesses DECADE storage servers (by
way of a DECADE client) to upload and manage data. Such a content
provider can access one or more storage servers. Such a content
provider may be a single process or a distributed application (e.g.,
in a P2P scenario), and may be either fixed or mobile.
2.5. Content Consumer Using DECADE
A content consumer using DECADE accesses DECADE storage servers (by
way of a DECADE client). A content consumer can access one or more
DECADE storage servers. A content consumer may be a single process
or a distributed application (e.g., in a P2P scenario), and may be
either fixed or mobile. An instance of a distributed application,
such as a P2P application, may both provide content to and consume
content from DECADE storage servers.
Alimi, et al. Expires September 13, 2012 [Page 6]
Internet-Draft DECADE Architecture March 2012
2.6. Content Distribution Application
A content distribution application (as a target application for
DECADE as described in [I-D.ietf-decade-reqs]) is a distributed
application designed for dissemination of a possibly-large data set
to multiple consumers. Content Distribution Applications typically
divide content into smaller blocks for dissemination.
2.6.1. Application End-Point
An Application End-Point is an instance of a Content Distribution
Application that makes use of DECADE server(s). A particular
Application End-Point may be a DECADE Content Provider, a DECADE
Content Consumer, or both. For example, an Application End-Point may
be an instance of a video streaming client, or it may be the source
providing the video to a set of clients.
An Application End-Point need not be actively transferring data with
other Application End-Points to interact with the DECADE storage
system. That is, an End-Point may interact with the DECADE storage
servers as an offline activity.
3. Protocol Flow
3.1. Overview
A DECADE-compatible system supports two logical protocols, as shown
in Figure 1. First, the DECADE Resource Protocol (DRP) is
responsible for communication of access control and resource
scheduling policies from a DECADE Client to a DECADE Server, as well
as between DECADE Servers. A DECADE-compatible system includes
exactly one DRP for interoperability and a common format through
which these policies can be communicated.
Alimi, et al. Expires September 13, 2012 [Page 7]
Internet-Draft DECADE Architecture March 2012
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: Generic Protocol Flow
Second, a Standard Data Transport protocol (SDT) is used to transfer
data objects to and from a DECADE Server. A DECADE-compatible system
may support multiple SDT's. If there are multiple SDT's, a
negotiation mechanism is used to determine a suitable data transfer
protocol between a DECADE Client and DECADE Server.
The two protocols (DRP and SDT) may or may not be seperate on the
wire. For example, DRP messages may be piggy-backed within some
extension fields provided by certain data transfer 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 resource
usage. Hence, this document considers SDT and DRP as two separate,
logical functional components for clarity. The abstract properties
of the SDT and DRP are oultined but the final selection of these
protocols is left to future steps.
Alimi, et al. Expires September 13, 2012 [Page 8]
Internet-Draft DECADE Architecture March 2012
3.2. An Example
This section provides an example of steps in a data transfer scenario
involving an in-network storage system. We assume that Application
End-Point B (the receiver) is requesting a data object from
Application End-Point A (the sender). Let S(A) denote A's DECADE-
compatible storage server. There are multiple usage scenarios (by
choice of the Content Distribution Application). For simplicity of
introduction, we design this example to use only a single DECADE-
compatible Server; Section 6.3 details a case when both A and B wish
to employ DECADE-compatible Servers.
When an Application End-Point wishes to use its DECADE-compatible
storage server, it provides a token to the other Application End-
Point. The token is sent using the Content Distribution
Application's native protocol.
The steps of the example are illustrated in Figure 2. First, B
requests a data object from A using their native protocol. Next, A
uses the DECADE-compatible Resource Protocol (DRP) to obtain a token.
There are multiple ways for A to obtain the token: compute locally,
or request from its DECADE-compatible storage server, S(A). See
Section 6.1.2 for details. A then provides the token to B (again,
using their native protocol). Finally, B provides the token to S(A)
via DRP, and requests and downloads the data object via a Standard
Data Transport (SDT).
.----------.
2. Obtain --------> | S(A) | <------
Token / `----------' \ 4. Request and
(DRP) / \ Download Object
Locally / \ (DRP + SDT)
or From / \
S(A) v 1. App Request v
.-------------. <--------------------------- .-------------.
| End-Point A | | End-Point B |
`-------------' ---------------------------> `-------------'
3. App Response (token)
Figure 2: Download from Storage Server
4. Architectural Principles
We identify the following key principles.
Alimi, et al. Expires September 13, 2012 [Page 9]
Internet-Draft DECADE Architecture March 2012
4.1. Decoupled Control/Metadata and Data Planes
A DECADE-compatible system will support multiple content distribution
applications. A complete content distribution application implements
a set of "control plane" functions including content search, indexing
and collection, access control, ad insertion, replication, request
routing, and QoS scheduling. Different content distribution
applications will have unique considerations designing the control
plane functions:
o Metadata Management Scheme: Traditional file systems provide a
standard metadata abstraction: a recursive structure of
directories to offer namespace management; each file is an opaque
byte stream. In content distribution, applications may use
different metadata management schemes. For example, one
application may use a sequence of blocks (e.g., for file sharing),
while another application may use a sequence of frames (with
different sizes) indexed by time.
o Resource Scheduling Algorithms: a major competitive advantage of
many successful P2P systems is their substantial expertise in
achieving highly efficient utilization of peer and infrastructural
resources. For instance, many streaming P2P systems have their
specific algorithms in constructing topologies to achieve low-
latency, high-bandwidth streaming. They continue to fine-tune
such algorithms.
Given the diversity of control plane functions, in-network storage
should export basic mechanisms and allow as much flexibility as
possible to the control plane to implement specific policies. This
conforms to the end-to-end systems principle and allows innovation
and satisfaction of specific business goals.
Decoupling control plane and data plane is not new. For example,
OpenFlow [OpenFlow] is an implementation of this principle for
Internet routing, where the computation of the forwarding table and
the application of the forwarding table are separated. Google File
System [GoogleFileSystem] applies the principle to file system
design, by utilizing the Master to handle the meta-data management,
and the Chunk Servers to handle the data plane functions (i.e., read
and write of chunks of data). NFSv4.1's pNFS extension [RFC5661]
also implements this principle.
4.2. Immutable Data Objects
A property of bulk contents to be broadly distributed is that they
typically are immutable -- once content is generated, it is typically
not modified. It is not common that bulk contents such as video
Alimi, et al. Expires September 13, 2012 [Page 10]
Internet-Draft DECADE Architecture March 2012
frames and images need to be modified after distribution.
Focusing on immutable data in the data plane can substantially
simplify the data plane design, since consistency requirements can be
relaxed. It also allows effective reuse of data and de-duplication
of redundant content.
Depending on its specific requirements, an application may store
immutable data objects in DECADE-compatible servers such that each
data object is completely self-contained (e.g., a complete,
independently decodable video segment). An application may also
divide data into blocks that require application level assembly.
Many content distribution applications divide bulk content into
blocks for two reasons: (1) multipath: different blocks may be
fetched from different sources in parallel, and (2) faster recovery
and verification: individual blocks may be recovered and verified.
Typically, applications use a block size larger than a single packet
in order to reduce control overhead.
A DECADE-compatible system is agnostic to the nature of the data
objects and does not specify a fixed size for them, though a protocol
specification based on this architecture may prescribe requirements
on minimum and maximum sizes by compliant implementatations.
Applications may consider existing blocks as data objects, or they
may adjust block sizes before storing in the DECADE-compatible
server.
Immutable content may still be deleted. Applications may support
modification of existing data stored at a DECADE-compatible server
through a combination of storing new data objects and deleting
existing data objects. For example, a meta-data management function
of the control plane may associate a name with a sequence of
immutable blocks. If one of the blocks is modified, the meta-data
management function changes the mapping of the name to a new sequence
of immutable blocks.
Throughout this document, all data objects/blocks are referred to as
immutable data objects/blocks.
4.3. Data Object Identifiers
Objects that are stored in a DECADE-compatible storage server can be
accessed by content consumers via a data object identifier that has
been assigned within a certain application context and that is unique
within that application context.
A content consumer may be able to access more than one storage server
within a single application context. A data object that is
Alimi, et al. Expires September 13, 2012 [Page 11]
Internet-Draft DECADE Architecture March 2012
replicated across different storage servers managed by a DECADE-
compatible storage provider can still be accessed by a single
identifier.
Since data objects are immutable, it is possible to support
persistent identifiers for data objects.
Data object identifiers for data objects MUST be created by content
providers that upload the objects to DECADE servers.
For some applications it is important that DECADE clients and servers
are able to validate the name-object binding for a data object, i.e.,
by verifying that a received object really corresponds to the name
that was used for requesting it (or that was provided by a sender).
Data object identifiers can support name-content binding validation
by providing message digests or so-called self-certifying naming
information -- if a specific application has this requirement.
4.4. DECADE Data Object Naming Scheme
The DECADE architecture is based on the data object identifier
properties as described in Section 4.3, but does neither specify a
specific scheme nor specific name-object binding validation functions
(for example, hash functions). Different applications will have
specific requirements regarding security (for example, cryptographic
strength of hash functions), performance (for example, larger static
objects vs streaming) etc.
The details of such naming schemes will be provided by DECADE
protocol/naming specifications. This documents describes the scheme
on a semantic level will but specific SDTs and DRPs may use specific
representations. The naming scheme meets the following general
requirements:
o Different name-object binding validation mechanisms are supported;
o an application (DECADE content provider) can decide what mechanism
to use (or to not provide name-object validation -- for example if
authenticity and integrity can be ascertained by alternative
means);
o simple (digest hash based) name-object binding validation is
supported; and
o applications are able to construct unique names (with high
probability) without requiring a registry or other forms of
coordination; and
Alimi, et al. Expires September 13, 2012 [Page 12]
Internet-Draft DECADE Architecture March 2012
o names are self-describing so that a receiving entity (DECADE
content consumer) knows what hash function (for example) to use
for validating name-object binding.
For most content distribution scenarios, it will be appropriate to
derive the name of a data object from the hash over the data object's
content (the raw bytes), which is made possible by the fact that
DECADE-compatible objects are immutable. But there maybe other
applications such as live streaming where object/chunk names are not
based on hashes but rather on a enumeration scheme. The DECADE
naming scheme also enables those applications to construct unique
names.
In order to enable the uniqueness, flexibility and self-describing
properties, the DECADE naming scheme provides the following name
elements:
o a "type" field that indicates the name-object validation function
type (for example, "sha-256");
o cryptographic data (such as an object hash) that corresponds to
the type information; and
o (optionally) additional information such as application context or
publisher information.
The specific format of the name (e.g., encoding, hash algorithms,
etc) is out of scope of this document, and left for protocol
specification.
The DECADE naming scheme can be used in scenarios where a client
knows the name of a data object before it is completely stored at the
server. This allows for particular optimizations, such as
advertising data object while the data object is being stored,
removing store-and-forward delays. For example, a client A may
simultaneously begin storing an object to a server, and advertise
that the object is available to client B. If it is supported by the
server, client B may begin downloading the object before A is
finished storing the object.
If object names are not based on content hashes, DECADE names can
also be used in scenarios, where a client knows the name of a data
object before it is locally created.
4.5. Explicit Control
To support the functions of an application's control plane,
applications must be able to know and coordinate which data is stored
Alimi, et al. Expires September 13, 2012 [Page 13]
Internet-Draft DECADE Architecture March 2012
at particular servers. Thus, in contrast with content caches,
applications are given explicit control over the placement (selection
of a DECADE-compatible server), deletion (or expiration policy), and
access control for stored data.
Consider deletion/expiration policy as a simple example. An
application may require that a server store content for a relatively
short period of time (e.g., for live-streaming data). Another
application may need to store content for a longer duration (e.g.,
for video-on-demand).
4.6. Resource and Data Access Control through User Delegation
A DECADE-compatible system provides a shared infrastructure to be
used by multiple tenants of multiple content distribution
applications. Thus, it needs to provide both resource and data
access control.
4.6.1. Resource Allocation
There are two primary interacting entities in a DECADE-compatible
system. First, Storage Providers coordinate where storage servers
are provisioned and their total available resources. Second,
Applications coordinate data transfers amongst available servers and
between servers and end-points. A form of isolation is required to
enable concurrently-running Applications to each explicitly manage
its own content and share of resources at the available servers.
The Storage Provider delegates the management of the resources on a
server to applications. It means applications are able to explicitly
and independently manage their own shares of resources on a DECADE
server.
4.6.2. User Delegations
Storage providers have the ability to explicitly manage the entities
allowed to utilize the resources at a DECADE-compatible server. This
capability is needed for reasons such as capacity-planning and legal
considerations in certain deployment scenarios.
The server grants a share of the resources to a user. The user may
in turn share the granted resources amongst multiple applications.
The share of resources granted by a storage provider is called a User
Delegation.
As a simple example, a DECADE-compatible Server operated by an ISP
may be configured to grant each ISP Subscriber 1.5 Mbps of bandwidth.
The ISP Subscriber may in turn divide this share of resources amongst
Alimi, et al. Expires September 13, 2012 [Page 14]
Internet-Draft DECADE Architecture March 2012
a video streaming application and file-sharing application which are
running concurrently.
In general, a User Delegation may be granted to an end-user (e.g., an
ISP subscriber), a Content Provider, or an application. A particular
instance of an application may make use of the storage resources:
o granted to the end-user (with the end-user's permission),
o granted to the Content Provider (with the Content Provider's
permission), and/or
o granted to the application.
5. System Components
The primary focus of this document is the architectural principles
and the system components that implement them. While certain system
components might differ amongst implementations, the document details
the major components and their overall roles in the architecture.
To keep the scope narrow, we only discuss the primary components
related to protocol development. Particular deployments may require
additional components (e.g., monitoring and accounting at a server),
but they are intentionally omitted from this document.
5.1. Content Distribution Application
Content Distribution Applications have many functional components.
For example, many P2P applications have components and algorithms to
manage overlay topology management, rate allocation, piece selection,
etc. In this document, we focus on the components directly employed
to support a DECADE-compatible system.
Figure 3 illustrates the components discussed in this section from
the perspective of a single Application End-Point.
Alimi, et al. Expires September 13, 2012 [Page 15]
Internet-Draft DECADE Architecture March 2012
Native Protocol(s)
(with other Application End-Points)
.--------------------->
|
|
.----------------------------------------------------------.
| Application End-Point |
| .------------. .-------------------. |
| | App-Layer | ... | App Data Assembly | |
| | Algorithms | | Sequencing | |
| `------------' `-------------------' |
| |
| .------------------------------------------------------. |
| | DECADE Client | |
| | | |
| | .-------------------------. .----------------------. | |
| | | Resource Controller | | Data Controller | | |
| | | .--------. .----------. | | .--------. .-------. | | |
| | | | Data | | Resource | | | | Data | | Data | | | |
| | | | Access | | Sharing | | | | Sched. | | Index | | | |
| | | | Policy | | Policy | | | | | | | | | |
| | | '--------' `----------' | | `--------' `-------' | | |
| | `-------------------------' `----------------------' | |
| | | ^ | |
| `------------ | ----------------- | -------------------' |
`-------------- | ----------------- | ---------------------'
| |
| DECADE | Standard
| Resource | Data
| Protocol | Transfer
| (DRP) | (SDT)
v V
Figure 3: Application Components
5.1.1. Data Assembly
A DECADE-compatible system is geared towards supporting applications
that can divide distributed contents into data objects. To
accomplish this, applications include a component responsible for
creating the individual data objects before distribution and then re-
assembling data objects at the Content Consumer. We call this
component Application Data Assembly.
In producing and assembling the data objects, two important
considerations are sequencing and naming. A DECADE-compatible system
assumes that applications implement this functionality themselves.
See Section 5.3 for further discussion.
Alimi, et al. Expires September 13, 2012 [Page 16]
Internet-Draft DECADE Architecture March 2012
5.1.2. Native Protocols
Applications may still use existing protocols. In particular, an
application may reuse existing protocols primarily for control/
signaling. However, an application may still retain its existing
data transfer protocols in addition to employing a data transfer
protocol with DECADE-complliant support. This is important for
applications that are designed to be highly robust (e.g., if in-
network servers are unavailable).
5.1.3. DECADE Client
An application needs to be modified to support a DECADE-compatible
system. The DECADE Client provides the local support to an
application. A DECADE Client need not be embedded into the
application. It could be implemented alone, or could be integrated
in other entities such as network devices themselves.
5.1.3.1. Resource Controller
Applications may have different Resource Sharing Policies and Data
Access Policies to control their resource and data in DECADE-
compatible servers. These policies can be existing policies of
applications (e.g., tit-for-tat) or custom policies. The specific
implementation is decided by the application.
5.1.3.2. Data Controller
A DECADE-compatible system decouples the control and the data
transfer of applications. A Data Scheduling component schedules data
transfers according to network conditions, available Servers, and/or
available Server resources. The Data Index indicates data available
at remote servers. The Data Index (or a subset of it) may be
advertised to other Application End-Points. A common use case for
this is to provide the ability to locate data amongst a distributed
set of Application End-Points (i.e., a data search mechanism).
5.2. DECADE Server
A DECADE-compatible Server stores data from Application End-Points,
and provides control and access of those data to Application End-
Points. A Server is not necessarily a single physical machine, it
could also be implemented as a cluster of machines.
Alimi, et al. Expires September 13, 2012 [Page 17]
Internet-Draft DECADE Architecture March 2012
| |
| DECADE | Standard
| Resource | Data
| Protocol | Transfer
| (DRP) | (SDT)
| |
.= | ================= | ======================.
| | v |
| | .----------------. |
| |----> | Access Control | <--------. |
| | `----------------' | |
| | ^ | |
| | | | |
| | v | |
| | .---------------------. | |
| `-> | Resource Scheduling | <------| |
| `---------------------' | |
| ^ | |
| | | |
| v .------------. |
| .-----------------. | User | |
| | Data Store | | Delegation | |
| `-----------------' | Management | |
| DECADE Server `------------' |
`=============================================='
Figure 4: DECADE Server Components
5.2.1. Access Control
An Application End-Point can access its own data or other Application
End-Point's data (provided sufficient authorization) in DECADE-
compatible servers. Application End-Points may also authorize other
End-Points to store data. If an access is authorized by an
Application End-Point, the Server will provide access.
Even if a request is authorized, it may still fail to complete due to
insufficient resources by either the requesting Application End-
Point, the providing Application End-Point, or the Server itself.
5.2.2. Resource Scheduling
Applications apply resource sharing policies or use a custom policy.
Servers perform resource scheduling according to the resource sharing
policies indicated by Application End-Points as well as configured
User Delegations.
Alimi, et al. Expires September 13, 2012 [Page 18]
Internet-Draft DECADE Architecture March 2012
5.2.3. Data Store
Data from applications may be stored at a DECADE-compatible Server.
Data can be deleted from storage either explicitly or automatically
(e.g., after a TTL expiration). It may be possible to perform
optimizations in certain cases, such as avoiding writing temporary
data (e.g., live streaming) to persistent storage, if appropriate
storage hints are supported by the SDT.
5.3. Data Sequencing and Naming
In order to provide a simple and generic interface, the DECADE-
compatible Server is only responsible for storing and retrieving
individual data objects. Furthermore, a DECADE-compatible system
uses its own simple naming scheme that provides uniqueness (with high
probability) between data objects, even across multiple applications.
5.3.1. DECADE Data Object Naming Scheme
The name of a data object is derived from the hash over the data
object's content (the raw bytes), which is made possible by the fact
that bjects are immutable. This scheme has multiple appealing
properties:
o Simple integrity verification
o Unique names (with high probability)
o Application independent, without a new IANA-maintained registry
The DECADE-compatible naming scheme also includes a "type" field, the
"type" identifier indicates that the name is the hash of the data
object's content and the particular hashing algorithm used. This
allows it to evolve by either changing the hashing algorithm (e.g.,
if security vulnerabilities with an existing hashing algorithm are
discovered), or moving to a different naming scheme altogether.
The specific format of the name (e.g., encoding, hash algorithms,
etc) is out of scope of this document, and left for protocol
specification.
Another advantage of this scheme is that a DECADE-compatible client
knows the name of a data object before it is completely stored at the
server. This allows for particular optimizations, such as
advertising data object while the data object is being stored,
removing store-and-forward delays. For example, a client A may
simultaneously begin storing an object to a server, and advertise
that the object is available to client B. If it is supported by the
Alimi, et al. Expires September 13, 2012 [Page 19]
Internet-Draft DECADE Architecture March 2012
server, client B may begin downloading the object before A is
finished storing the object.
In certain scenarios (e.g., where a client has limited computational
power), it may be advantageous to offload the computation of a data
object's name to the Server. This possibility is not considered in
the current architecture, but may be a topic for future extensions.
5.3.2. Application Usage
Recall from Section 5.1.1 that an Application typically includes its
own naming and sequencing scheme. The DECADE-compatible naming
format does not attempt to replace any naming or sequencing of data
objects already performed by an Application; instead, the naming is
intended to apply only to data objects referenced by DECADE-specific
purposes .
DECADE-compatible names are not necessarily correlated with the
naming or sequencing used by the Application using a DECADE-
compatible client. The DECADE-compatible client is expected to
maintain a mapping from its own data objects and their names to the
DECADE-specific data objects and names. Furthermore, the DECADE-
compatible naming scheme implies no sequencing or grouping of
objects, even if this is done at the application layer.
Not only does an Application retain its own naming scheme, it may
also decide the sizes of data objects to be distributed via the
DECADE-compatible system. This is desirable since sizes of data
objects may impact Application performance (e.g., overhead vs. data
distribution delay), and the particular tradeoff is application-
dependent.
5.3.3. Application Usage Example
To illustrate these properties, this section presents multiple
examples.
5.3.3.1. Application with Fixed-Size Chunks
Similar to the example in Section 5.1.1, consider an Application in
which each individual application-layer segment of data is called a
"chunk" and has a name of the form: "CONTENT_ID:SEQUENCE_NUMBER".
Furthermore, assume that the application's native protocol uses
chunks of size 16KB.
Now, assume that this application wishes to store data in DECADE-
compatible servers in data objects of size 64KB. To accomplish this,
it can map a sequence of 4 chunks into a single object, as shown in
Alimi, et al. Expires September 13, 2012 [Page 20]
Internet-Draft DECADE Architecture March 2012
Figure 5.
Application Chunks
.---------.---------.---------.---------.---------.---------.--------
| | | | | | |
| Chunk_0 | Chunk_1 | Chunk_2 | Chunk_3 | Chunk_4 | Chunk_5 | Chunk_6
| | | | | | |
`---------`---------`---------`---------`---------`---------`--------
DECADE Data Objects
.---------------------------------------.----------------------------
| |
| Object_0 | Object_1
| |
`---------------------------------------`----------------------------
Figure 5: Mapping Application Chunks to DECADE Data Objects
In this example, the Application might maintain a logical mapping
that is able to determine the name of a DECADE-compatible data object
given the chunks contained within that data object. The name might
be learned from either the original source, another endpoint with
which the it is communicating, a tracker, etc.
As long as the data contained within each sequence of chunks is
unique, the corresponding data objects have unique names. This is
desired, and happens automatically if particular Application segments
the same stream of data in a different way, including different chunk
sizes or different padding schemes.
5.3.3.2. Application with Continuous Streaming Data
Next, consider an Application whose native protocol retrieves a
continuous data stream (e.g., an MPEG2 stream) instead of downloading
and redistributing chunks of data. Such an application could segment
the continuous data stream to produce either fixed-sized or variable-
sized data objects.
Figure 6 shows how a video streaming application might produce
variable-sized data objects such that each data object contains 10
seconds of video data.
Alimi, et al. Expires September 13, 2012 [Page 21]
Internet-Draft DECADE Architecture March 2012
Application's Video Stream
.--------------------------------------------------------------------
|
|
|
`--------------------------------------------------------------------
^ ^ ^ ^ ^
| | | | |
0 Seconds 10 Seconds 20 Seconds 30 Seconds 40 Seconds
0 B 400 KB 900 KB 1200 KB 1500 KB
DECADE Data Objects
.--------------.--------------.--------------.--------------.--------
| | | | |
| Object_0 | Object_1 | Object_2 | Object_3 |
| (400 KB) | (500 KB) | (300 KB) | (300 KB) |
`--------------`--------------`--------------`--------------`--------
Figure 6: Mapping a Continuous Data Stream to DECADE Data Objects
Similar to the previous example, the Application might maintain a
mapping that is able to determine the name of a DECADE data object
given the time offset of the video chunk.
5.4. Token-based Authentication and Resource Control
A key feature of a DECADE-compatible system is that a Client can
authorize other Clients to store or retrieve data objects from the
in-network storage. A token-based authentication scheme is used to
accomplish this.
Specifically, an entity trusted by a Client generates a digitally-
signed token with particular properties (see Section 6.1.2 for
details). The Client distributes this token to other Clients which
then use the token when sending requests to the DECADE-compatible
Server. Upon receiving a token, the Server validates the signature
and the operation being performed.
This is a simple scheme, but has some important advantages over an
alternate approach in which a Client explicitly manipulates an Access
Control List (ACL) associated with each data object. In particular,
it has the following advantages when applied to DECADE-compliant
target applications:
o Authorization policies are implemented within the Application; an
Application explicitly controls when tokens are generated and to
Alimi, et al. Expires September 13, 2012 [Page 22]
Internet-Draft DECADE Architecture March 2012
whom they are distributed.
o Fine-grained access and resource control can be applied to data
objects; see Section 6.1.2 for the list of restrictions that can
be enforced with a token.
o There is no messaging between a Client and Server to manipulate
data object permissions. This can simplify, in particular,
Applications which share data objects with many dynamic peers and
need to frequently adjust access control policies attached to data
objects.
o Tokens can provide anonymous access, in which a Server does not
need to know the identity of each Client that accesses it. This
enables a Client to send tokens to Clients in other administrative
or security domains, and allow them to read or write data objects
from its storage.
In addition to Clients applying access control policies to data
objects, the Server may be configured to apply additional policies
based on user, object, geographic location, etc. A Client may thus
be denied access even though it possess a valid token.
Existing protocols (e.g., OAuth [RFC5849]) implement similar referral
mechanisms using tokens. A protocol specification of this
architecture will prefer to use existing mechanisms wherever
possible.
5.5. Discovery
A DECADE-compatible systme includes a discovery mechanism through
which clients locate an appropriate Server. [I-D.ietf-decade-reqs]
details specific requirements of the discovery mechanism; this
section discusses how they relate to other principles outlined in
this document.
A discovery mechanism allows a client to determine an IP address or
some other identifier that can be resolved to locate the server for
which the client will be authorized to generate tokens (via DRP).
(The discovery mechanism may also result in an error if no such
servers can be located.) After discovering one or more servers, a
client may distribute load and requests across them (subject to
resource limitations and policies of the servers themselves)
according to the policies of the Application End-Point in which it is
embedded.
The particular protocol used for discovery is out of scope of this
document, but any specification will re-use standard protocols
Alimi, et al. Expires September 13, 2012 [Page 23]
Internet-Draft DECADE Architecture March 2012
wherever possible.
The discovery mechanism outlined here does not provide the ability to
locate arbitrary DECADE-compatible servers to which a client might
obtain tokens from others. To do so requires application-level
knowledge, and it is assumed that this functionality is implemented
in the Content Distribution Application, or if desired and needed, as
an extension to a DECADE-compatible system.
6. DECADE Protocols
This section presents the DECADE Resource Protocol (DRP) and the
Standard Data Transfer (SDT) in terms of abstract protocol
interactions that are intended to mapped to specific protocols. In
general, the DRP/SDT functionality between a DECADE-compatible
client-server are very similiar to the DRP/SDT functionality between
running between server-server. Any differences are highlighted
below.
The DRP is the protocol used by a DECADE-compatible client to
configure the resources and authorization used to satisfy requests
(reading, writing, and management operations concerning objects) at a
server. The SDT is used to send the operations to the server.
Necessary DRP metadata is supplied using mechanisms in the SDT that
are provided for extensibility (e.g., additional request parameters
or extension headers).
6.1. DECADE Resource Protocol (DRP)
DRP provides configuration of access control and resource sharing
policies on DECADE-compatible servers. A content distribution
application, e.g., a live P2P streaming session, may have permission
to manage data at several servers, for instance, servers in different
operator domains, and DRP allows one instance of such an application,
e.g., an application endpoint, to apply access control and resource
sharing policies on each of them.
6.1.1. Controlled Resources
On a single DECADE-compatible server, the following resources may be
managed:
communication resources: Servers have limited communication
resources in terms of bandwidth (upload/download) but also in
terms of number of connected clients (connections) at a time.
Alimi, et al. Expires September 13, 2012 [Page 24]
Internet-Draft DECADE Architecture March 2012
storage resources: Servers have limited storage resources.
6.1.2. Access and Resource Control Token
A token includes the following information:
Permitted operations (e.g., read, write)
Permitted objects (e.g., names of data objects that may be read or
written)
Expiration time
Priority for bandwidth given to requested operation (e.g., a
weight used in a weighted bandwidth sharing scheme)
Amount of data that may be read or written
The particular format for the token is out of scope of this document.
The tokens are generated by a trusted entity at the request of a
DECADE-compatible Client. It is out of scope of this document to
identify which entity serves this purpose, but examples include the
Client itself, a Server trusted by the Client, or another server
managed by a Storage Provider trusted by the Client.
Upon generating a token, a Client may distribute it to another Client
(e.g., via their native Application protocol). The receiving Client
may then connect to the sending Client's Server and perform any
operation permitted by the token. The token must be sent along with
the operation. The Server validates the token to identify the Client
that issued it and whether the requested operation is permitted by
the contents of the token. If the token is successfully validated,
the Server applies the resource control policies indicated in the
token while performing the operation.
Tokens include a unique identifier to allow a Server to detect when a
token is used multiple times.
It is possible for DRP to allow tokens to apply to a batch of
operations to reduce communication overhead required between Clients.
6.1.3. Status Information
DRP provides a request service for status information that clients
can use to request information from a server.
Alimi, et al. Expires September 13, 2012 [Page 25]
Internet-Draft DECADE Architecture March 2012
status information per application context on a specific server:
Access to such status information requires client authorization,
i.e., clients need to be authorized to access status information
for a specific application context. This authorization (and the
mapping to application contexts) is based on the user delegation
concept as described in Section 4.6. The following status
information elements can be obtained:
* list of associated objects (with properties)
* resources used/available
* list of servers to which objects have been distributed (in a
certain time-frame)
* list of clients to which objects have been distributed (in a
certain time-frame)
For the list of servers/clients to which objects have been
distributed to, the server can decide on time bounds for which
this information is stored and specify the corresponding time
frame in the response to such requests. Some of this information
can be used for accounting purposes, e.g., the list of clients to
which objects have been distributed.
access information per application context on a specific server:
Access information can be provided for accounting purposes, for
example, when application service providers are interested to
maintain access statistics for resources and/or to perform
accounting per user. Again, access to such information requires
client authorization based on the user delegation concept as
described in Section 4.6. The following access information
elements can be requested:
* what objects have been accessed how many times
* access tokens that a server as seen for a given object
The server can decide on time bounds for which this information is
stored and specify the corresponding time frame in the response to
such requests.
6.1.4. Object Attributes
Objects that are stored on a DECADE-compatible server may have
associated attributes (in addition to the object identifier and the
actual content) that relate to the data storage and its management.
These attributes may be used by the server (and possibly the
Alimi, et al. Expires September 13, 2012 [Page 26]
Internet-Draft DECADE Architecture March 2012
underlying storage system) to perform specialized processing or
handling for the data object, or to attach related server or storage-
layer properties to the data object. These attributes have a scope
local to a server. In particular, these attributes are not applied
to a server or client to which a data object is copied.
Depending on authorization, clients may get or set such attributes.
This authorization (and the mapping to application contexts) is based
on the user delegation concept as described in Section 4.6. The
architecture does not limit the set of permissible attributes, but
rather specifies a set of baseline attributes that should be
supported by implementations.
Suggested attributes are the following:
Expiration Time: Time at which the object may be deleted
object size: in bytes
Media type
access statistics: how often the object has been accessed (and what
tokens have been used)
The Object Attributes defined here are distinct from application
metadata (see Section 4.1). Application metadata is custom
information that an application may wish to associate with a data
object to understand its semantic meaning (e.g., whether it is video
and/or audio, its playback length in time, or its index in a stream).
If an application wishes to store such metadata persistently, it can
be stored within data objects themselves.
6.2. Standard Data Transfer (SDT)
A DECADE-compatible server provide a data access interface, and SDT
is used to write objects to a server and to read (download) objects
from a server. Semantically, SDT is a client-server protocol, i.e.,
the server always responds to client requests.
6.2.1. Writing/Uploading Objects
To write an object, a client first generates the object's name (see
Section 5.3), and then uploads the object to a server and supplies
the generated name. The name can be used to access (download) the
object later, e.g., the client can pass the name as a reference to
other client that can then refer to the object.
Objects can be self-contained objects such as multimedia resources,
Alimi, et al. Expires September 13, 2012 [Page 27]
Internet-Draft DECADE Architecture March 2012
files etc., but also chunks, such as chunks of a P2P distribution
protocol that can be part of a containing object or a stream.
A server may accept download requests for an object that is still
being uploaded.
The application that originates the objects generates DECADE-
compatible object names according to the naming specification in
Section 5.3. The naming scheme provides that the name is unique.
Clients (as parts of application entities) upload a named object to a
server. A server may verify the integrity and other security
properties of uploaded objects.
In the following we provide an abstract specification of the upload
operation that we name 'PUT METHOD'.
Method PUT:
Parameters:
NAME: The naming of the object according to Section 5.3
OBJECT: The object itself.
Description: The PUT method is used by a DECADE-compatible client to
upload an object with an associated name 'NAME' to a DECADE-
compatible server.
RESPONSES: The server responds with one the following response
messages:
CREATED: The object has been uploaded successfully and is now
available under the specified name.
ERRORs:
VALIDATION_FAILED: The contents of the data object received by
the server did not match the provided name (i.e., hash
validation failed).
PERMISSION_DENIED: The client lacked sufficient permission to
store the object.
Specifics regarding error handling, including additional error
conditions, precedence for returned errors and its relation
with server policy, are deferred to eventual protocol
specification.
Alimi, et al. Expires September 13, 2012 [Page 28]
Internet-Draft DECADE Architecture March 2012
6.2.2. Downloading Objects
A client can request named objects from a server. In the following,
we provide an abstract specification of the download operation that
we name 'GET METHOD'.
Method GET:
Parameters:
NAME: The naming of the object according to Section 5.3.
Description: The GET method is used by a client to download an
object with an associated name 'NAME' from a server.
RESPONSES: The server responds with one the following response
messages:
OK: The request has succeeded, and an entity corresponding to the
requested resource is sent in the response.
ERRORs:
NOT_FOUND: The server has not found anything matching the
request object name.
PERMISSION_DENIED: The client lacked sufficient permission to
read the object.
NOT_AVAILABLE: The data object exists but is currently
unavailable for download (e.g., due to server policy).
Specifics regarding error handling, including additional error
conditions (e.g. overload), precedence for returned errors and
its relation with server policy, are deferred to eventual
protocol specification.
6.3. Server-to-Server Protocols
An important feature of a DECADE-compatible system is the capability
for one server to directly download objects from another server.
This capability allows Applications to directly replicate data
objects between servers without requiring end-hosts to use uplink
capacity to upload data objects to a different server.
DRP and SDT support operations directly between servers. Servers are
not assumed to trust each other nor are configured to do so. All
data operations are performed on behalf of clients via explicit
Alimi, et al. Expires September 13, 2012 [Page 29]
Internet-Draft DECADE Architecture March 2012
instruction. However, the objects being processed do not necessarily
have to originate or terminate at the client (i.e. the object may be
limited to being exchanged between servers even if the instruction is
triggered by the client). clients thus must be able to indicate to a
server the following additional parameters:
o which remote server(s) to access;
o the operation to be performed (e.g. PUT, GET); and
o Credentials indicating permission to perform the operation at the
remote server.
In this way, a server acts as a proxy for a client, and a client may
instantiate requests via that proxy. The operations are performed as
if the original requester had its own client co-located with the
server. It is this mode of operation that provides substantial
savings in uplink capacity. This mode of operation may also be
triggered by an administrative/management application outside the
architecture.
6.3.1. Operational Overview
Server-to-server support is focused on reading and writing data
objects between servers. A DECADE-compatible GET or PUT request may
supply the following additional parameters:
REMOTE_SERVER: Address of the remote server. The format of the
address is out-of-scope of this document.
REMOTE_USER: The account at the remote server from which to retrieve
the object (for a GET), or in which the object is to be stored
(for a PUT).
TOKEN: Credentials to be used at the remote server.
These parameters are used by the server to instantiate a request to
the specified remote server. It is assumed that the data object
referred to at the remote server is the same as the original request.
Object attributes (see Section 6.1.4) may also be specified in the
request to the remote server.
When a client sends a request to a server with these additional
parameters, it is giving the server permission to act (proxy) on its
behalf. Thus, it would be prudent for the supplied token to have
narrow privileges (e.g., limited to only the necessary data objects)
or validity time (e.g., a small expiration time).
Alimi, et al. Expires September 13, 2012 [Page 30]
Internet-Draft DECADE Architecture March 2012
In the case of a GET operation, the server is to retrieve the data
object from the remote server using the specified credentials (via a
GET request to the remote server), and then optionally return the
object to a client. In the case of a PUT operation, the server is to
store the object to the remote server using the specified credentials
(via a PUT request to the remote server). The object may optionally
be uploaded from the client or may already exist at the proxying
server.
7. Security Considerations
In general, the security considerations mentioned in
[I-D.ietf-decade-problem-statement] apply to this document as well.
A DECADE-compatible system provides a distributed storage service for
content distribution and similar applications. The system consists
of servers and clients that use these servers to upload data objects,
to request distribution of data objects, and to download data
objects. Such a system is employed in an overall application context
-- for example in a P2P content distribution application, and it is
generally expected that DECADE-compatible clients take part in
application-specific communication sessions.
The security considerations here focus on threats related to the
DECADE-compatible system and its communication services, i.e., the
DRP/SDT protocols that have been described in an abstract fashion in
this document.
7.1. Threat: System Denial of Service Attacks
A DECADE-compatible network of servers may be used to distribute data
objects from one client to a set of servers using the server-to-
server communication feature that a client can request when uploading
an object. Multiple clients uploading many objects at different
servers at the same time and requesting server-to-server distribution
for them could thus mount massive distributed denial of service
(DDOS) attacks, overloading a network of servers.
This threat is addressed by its access control and resource control
framework. Servers can require application endpoints to be
authorized to store and to download objects, and application
endpoints can delegate authorization to other application endpoints
using the token mechanism.
Of course the effective security of this approach depends on the
strength of the token mechanism. See below for a discussion of this
and related communication security threats.
Alimi, et al. Expires September 13, 2012 [Page 31]
Internet-Draft DECADE Architecture March 2012
Denial of Service Attacks against a single server (directing many
requests to that server) may still lead to considerable load for
processing requests and invalidating tokens. A SDT therefore MUST
provide a redirection mechanism as described as a requirement in
[I-D.ietf-decade-reqs].
7.2. DECADE Protocol Security Threats
7.2.1. Threat: Authorization Mechanisms Compromised
A DECADE-compatible system does not require application endpoints to
authenticate in order to access a server for downloading objects,
since authorization is not based on endpoint or user identities but
on the delegation-based authorization mechanism. Hence, most
protocol security threats are related to the authorization scheme.
The security of the token mechanism depends on the strength of the
token mechanism and on the secrecy of the tokens. A token can
represent authorization to store a certain amount of data, to
download certain objects, to download a certain amount of data per
time etc. If it is possible for an attacker to guess, construct or
simply obtain tokens, the integrity of the data maintained by the
servers, or at least the affected application context on servers, is
compromised.
This is a general security threat that applies to authorization
delegation schemes. Specifications of existing delegation schemes
such as OAuth [RFC5849] discuss these general threats in detail. We
can say that the DRP has to specify appropriate algorithms for token
generation. Moreover, authorization tokens should have a limited
validity period that should be specified by the application. Token
confidentiality should be provided by application protocols that
carry tokens, and the SDT and DRP should provide secure
(confidential) communication modes.
7.2.2. Threat: Object Spoofing
In a DECADE-compliant system, an application endpoint is referring
other application endpoints to servers to download a specified data
objects. An attacker could "inject" a faked version of the object
into this process, so that the downloading endpoint effectively
receives a different object (compared to what the uploading endpoint
provided). As result, the downloading endpoint believes that is has
received an object that corresponds to the name it was provided
earlier, whereas in fact it is a faked object. Corresponding attacks
could be mounted against the application protocol (that is used for
referring other endpoints to servers), servers themselves (and their
storage sub-systems), and the SDT by which the object is uploaded,
Alimi, et al. Expires September 13, 2012 [Page 32]
Internet-Draft DECADE Architecture March 2012
distributed and downloaded.
A DECADE-compliant systems fundamental mechanism against object
spoofing is name-content binding validation, i.e., the ability of a
receiver to check whether the name he was provided and that he used
to request an object, actually corresponds to the bits he received.
As described above, this allows for different forms of name-content
binding, for example using content hashes, with different hash
functions (different algorithms, different digest lengths). For
those application scenarios where content hashes are not applicable
(for example live-streaming) other forms of name-content binding can
be used (see Section 5.3. This flexibility also addresses
cryptographic algorithm evolvability: hash functions may get
deprecated, better alternatives may be invented etc., so that
applications can choose appropriate mechanisms meeting their security
requirements.
DECADE-compliant servers MAY perform name-content binding validation
on stored objects, but application endpoints MUST NOT rely on that.
In other forms: application endpoints SHOULD perform name-content
binding validation on received objects.
8. IANA Considerations
This document does not have any IANA considerations.
9. Acknowledgments
We thank the following people for their contributions to this
document:
David Bryan
Hongqiang (Harry) Liu
Yingjie Gu
David McDysan
Borje Ohlman
Haibin Song
Martin Stiemerling
Richard Woundy
Alimi, et al. Expires September 13, 2012 [Page 33]
Internet-Draft DECADE Architecture March 2012
Ning Zong
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web
Distributed Authoring and Versioning (WebDAV)
Access Control Protocol", RFC 3744, May 2004.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4331] Korver, B. and L. Dusseault, "Quota and Size Properties fo
r Distributed Authoring and Versioning (DAV) Collections",
RFC 4331, February 2006.
[RFC4709] Reschke, J., "Mounting Web Distributed Authoring and
Versioning (WebDAV) Servers", RFC 4709, October 2006.
[RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed
Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
[RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File
System (NFS) Version 4 Minor Version 1 Protocol",
RFC 5661, January 2010.
[RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849,
April 2010.
[RFC6392] Alimi, R., Rahman, A., and Y. Yang, "A Survey of In-
Network Storage Systems", RFC 6392, October 2011.
[I-D.ietf-decade-problem-statement]
Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled
Application Data Enroute (DECADE) Problem Statement",
draft-ietf-decade-problem-statement-05 (work in progress),
February 2012.
Alimi, et al. Expires September 13, 2012 [Page 34]
Internet-Draft DECADE Architecture March 2012
[I-D.ietf-decade-reqs]
Yingjie, G., Bryan, D., Yang, Y., and R. Alimi, "DECADE
Requirements", draft-ietf-decade-reqs-05 (work in
progress), October 2011.
[GoogleStorageDevGuide]
"Google Storage Developer Guide", <http://code.google.com/
apis/storage/docs/developer-guide.html>.
[OpenFlow]
"OpenFlow Organization", <http://www.openflow.org/>.
[GoogleFileSystem]
Ghemawat, S., Gobioff, H., and S. Leung, "The Google File
System", SOSP 2003, October 2003.
Appendix A. In-Network Storage Components Mapped to DECADE Architecture
In this section we evaluate how the basic components of an in-network
storage system identified in Section 3 of [RFC6392] map into a
DECADE-compatible system.
It is important to note that complex and/or application-specific
behavior is delegated to applications instead of tuning the storage
system wherever possible.
A.1. Data Access Interface
Users can read and write objects of arbitrary size through the
Client's Data Controller, making use of a SDT.
A.2. Data Management Operations
Users can move or delete previously stored objects via the Client's
Data Controller, making use of a SDT.
A.3. Data Search Capability
Users can enumerate or search contents of Servers to find objects
matching desired criteria through services provided by the Content
Distribution Application (e.g., buffer-map exchanges, a DHT, or peer-
exchange). In doing so, End-Points may consult their local Data
Index in the Client's Data Controller.
Alimi, et al. Expires September 13, 2012 [Page 35]
Internet-Draft DECADE Architecture March 2012
A.4. Access Control Authorization
All methods of access control are supported: public-unrestricted,
public-restricted and private. Access Control Policies are generated
by a Content Distribution Application and provided to the Client's
Resource Controller. The Server is responsible for implementing the
access control checks.
A.5. Resource Control Interface
Users can manage the resources (e.g. bandwidth) on the DECADE server
that can be used by other Application End-Points. Resource Sharing
Policies are generated by a Content Distribution Application and
provided to the Client's Resource Controller. The Server is
responsible for implementing the resource sharing policies.
A.6. Discovery Mechanism
The particular protocol used for discovery is outside the scope of
this document. However, options and considerations have been
discussed in Section 5.5.
A.7. Storage Mode
Servers provide an object-based storage mode. Immutable data objects
may be stored at a Server. Applications may consider existing blocks
as data objects, or they may adjust block sizes before storing in a
Server.
Authors' Addresses
Richard Alimi
Google
Email: ralimi@google.com
Akbar Rahman
InterDigital Communications, LLC
Email: akbar.rahman@interdigital.com
Alimi, et al. Expires September 13, 2012 [Page 36]
Internet-Draft DECADE Architecture March 2012
Dirk Kutscher
NEC
Email: dirk.kutscher@neclab.eu
Y. Richard Yang
Yale University
Email: yry@cs.yale.edu
Alimi, et al. Expires September 13, 2012 [Page 37]