idnits 2.17.1 draft-alimi-decade-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1377 has weird spacing: '...acement regio...' == Line 1380 has weird spacing: '..._period time ...' == Line 1382 has weird spacing: '...odelete wheth...' -- The document date (September 27, 2013) is 3857 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 5661 (Obsoleted by RFC 8881) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 APPSAWG R. Alimi 3 Internet-Draft Google 4 Intended status: Informational A. Rahman 5 Expires: March 31, 2014 InterDigital Communications, LLC 6 D. Kutscher 7 NEC 8 Y. Yang 9 Yale University 10 H. Song 11 Huawei Technologies 12 K. Pentikousis 13 EICT 14 September 27, 2013 16 DECoupled Application Data Enroute (DECADE) 17 draft-alimi-decade-05 19 Abstract 21 Content distribution applications, such as those those employing 22 peer-to-peer (P2P) technologies, are widely used on the Internet and 23 make up a large portion of the traffic in many networks. Often, 24 however, content distribution applications use network resources in a 25 counter-productive manner. One way to improve efficiency is to 26 introduce storage capabilities within the network and enable 27 cooperation between end-host and in-network content distribution 28 mechanisms. This is the capability provided by a DECADE system, 29 which is introduced in this document. DECADE enables applications to 30 take advantage of in-network storage when distributing data objects 31 as opposed to using solely end-to-end resources. This document 32 presents the underlying principles and key functionalities of such a 33 system and illustrates operation through a set of examples. 35 Requirements Language 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 39 document are to be interpreted as described in RFC 2119 [RFC2119]. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on March 31, 2014. 58 Copyright Notice 60 Copyright (c) 2013 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 4. Architectural Principles . . . . . . . . . . . . . . . . . . 7 79 4.1. Data and Control Plane Decoupling . . . . . . . . . . . . 7 80 4.2. Immutable Data Objects . . . . . . . . . . . . . . . . . 8 81 4.3. Data Object Identifiers . . . . . . . . . . . . . . . . . 9 82 4.4. Explicit Control . . . . . . . . . . . . . . . . . . . . 10 83 4.5. Resource and Data Access Control through Delegation . . . 10 84 5. System Components . . . . . . . . . . . . . . . . . . . . . . 11 85 5.1. Application End-Point . . . . . . . . . . . . . . . . . . 11 86 5.2. DECADE Client . . . . . . . . . . . . . . . . . . . . . . 12 87 5.3. DECADE Server . . . . . . . . . . . . . . . . . . . . . . 13 88 5.4. Data Sequencing and Naming . . . . . . . . . . . . . . . 14 89 5.5. Token-based Authorization and Resource Control . . . . . 16 90 5.6. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 17 91 6. DECADE Protocol Considerations . . . . . . . . . . . . . . . 17 92 6.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 18 93 6.2. Resource Protocol . . . . . . . . . . . . . . . . . . . . 18 94 6.3. Data Transfer . . . . . . . . . . . . . . . . . . . . . . 21 95 6.4. Server-to-Server Protocols . . . . . . . . . . . . . . . 21 96 6.5. Potential DRP/SDT Candidates . . . . . . . . . . . . . . 22 97 7. In-Network Storage Components Mapping to DECADE . . . . . . . 23 98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 99 8.1. Threat: System Denial of Service Attacks . . . . . . . . 24 100 8.2. Threat: Authorization Mechanisms Compromised . . . . . . 24 101 8.3. Threat: Data Object Spoofing . . . . . . . . . . . . . . 25 102 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 103 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 104 11. Informative References . . . . . . . . . . . . . . . . . . . 26 105 Appendix A. Evaluation of Candidate Protocols for DECADE DRP/SDT 27 106 A.1. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . 27 107 A.2. CDMI . . . . . . . . . . . . . . . . . . . . . . . . . . 29 108 A.3. OAUTH . . . . . . . . . . . . . . . . . . . . . . . . . . 32 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 111 1. Terminology 113 This document uses the following terminology: 115 Application End-Point 116 A host that includes a DECADE Client along with other application 117 functionalities (e.g., Peer-to-Peer (P2P) client, video streaming 118 client). 120 Content Distribution Application 121 A specific type of application that may exist in an Application 122 End-Point. A Content Distribution Application is an application 123 (e.g., P2P) designed for dissemination of a large amounts of 124 content (e.g., files or video streams) to multiple peers. Content 125 Distribution Applications may divide content into smaller blocks 126 for dissemination. 128 Data Object 129 A data object is the unit of data stored and retrieved from a 130 DECADE server. The data object is a sequence of raw bytes. The 131 server maintains metadata associated with each data object, but 132 the metadata is physically and logically separate from the data 133 object. 135 DECADE Client 136 A DECADE client uploads and/or retrieves data from a DECADE 137 server. 139 DECADE Resource Protocol (DRP) 140 A logical protocol for communication of access control and 141 resource scheduling policies from a DECADE client to a DECADE 142 server, or between DECADE servers. In practice, the functionality 143 of the DRP may be distributed over one or more actual protocols. 145 DECADE Server 146 A DECADE server stores data inside the network for a DECADE client 147 or another DECADE server, and thereafter manages both the stored 148 data and access to that data by other DECADE Clients. 150 DECADE Storage Provider 151 A DECADE Storage Provider deploys and/or manages DECADE servers 152 within a network. 154 DECADE System 155 An in-network storage system which is composed of DECADE clients 156 and DECADE servers. The DECADE servers may be deployed by one or 157 more DECADE Storage Providers. 159 In-network Storage 160 A service inside a network that provides storage to applications. 161 In-network storage may reduce upload/tansit/backbone traffic and 162 improve application performance. In-network storage may, for 163 example, be co-located with the border router (network attached 164 storage) or inside a data center. A DECADE System is an example 165 of an In-Network Storage system. 167 Standard Data Transfer Protocol (SDT) 168 A logical protocol used to transfer data objects between a DECADE 169 client and DECADE server, or between DECADE servers. The intent 170 is that in practice the SDT should map to an existing, well-known 171 protocol already in use over the Internet for transporting data. 173 2. Introduction 175 Content distribution applications, such as peer-to-peer (P2P) 176 applications, are widely used on the Internet to distribute data 177 objects, and comprise a large portion of the traffic in many 178 networks. Said applications can often introduce performance 179 bottlenecks in otherwise well-provisioned networks. In some cases, 180 operators are forced to invest substantially in infrastructure to 181 accommodate the use of such applications. For instance, in many 182 subscriber networks, it can be expensive to upgrade network equipment 183 in the "last-mile", because it can involve replacing equipment and 184 upgrading wiring and devices at individual homes, businesses, DSLAMs 185 (Digital Subscriber Line Access Multiplexers) and CMTSs (Cable Modem 186 Termination Systems) in remote locations. It may be more practical 187 and economical to upgrade the core infrastructure, instead of the 188 "last-mile" of the network, as this involves fewer components that 189 are shared by many subscribers. See [RFC6646] and [RFC6392] for a 190 more complete discussion of the problem domain and general 191 discussions of the capabilities envisioned for a DECADE system. As a 192 historical point, it should be noted that [RFC6646] and [RFC6392] 193 came out of the now closed DECADE Working Group. This document aims 194 to advance some of the valuable concepts from that now closed Working 195 Group. 197 This document presents mechanisms for providing in-network storage 198 that can be integrated into content distribution applications. The 199 primary focus is P2P-based content distribution, but DECADE may be 200 useful to other applications with similar characteristics and 201 requirements (e.g., Content Distribution Networks (CDNs), or hybrid 202 P2P/CDNs). The approach we adopt in this document is to define the 203 core functionalities and protocol functions that are needed to 204 support a DECADE system. This document provides illustrative 205 examples so that implementers can understand the main concepts in 206 DECADE, but it is generally assumed that readers are also familiar 207 with the terms and concepts used in [RFC6646] and [RFC6392]. 209 3. Overview 211 A DECADE system provides a distributed storage service for content 212 distribution applications (e.g., P2P). The system consists of 213 clients and servers. A client first uploads data objects to a 214 selected server(s), and optionally requests distribution of these 215 data objects to other servers. The client then selectively 216 authorizes other clients to download these data objects. Such a 217 system is employed in an overall application context (e.g., P2P file 218 sharing) and it is expected that DECADE clients take part in 219 application-specific communication sessions. 221 Figure 1 is a schematic of a simple DECADE system with two DECADE 222 clients and two DECADE servers. As illustrated, a DECADE client, 223 which is part of an Application End-Point, uses the DECADE Resource 224 Protocol (DRP) to convey to a server information related to access 225 control and resource scheduling policies. DRP can also be used 226 between servers for exchanging this type of information. A DECADE 227 system employs standard data transfer (SDT) protocol to transfer data 228 objects to and from a server, as we will explain later. 230 Native Application 231 Protocol(s) 232 .-------------. (e.g., P2P) .-------------. 233 | Application | <------------------> | Application | 234 | End-Point | | End-Point | 235 | | | | 236 | .--------. | | .--------. | 237 | | DECADE | | | | DECADE | | 238 | | Client | | | | Client | | 239 | `--------' | | `--------' | 240 `-------------' `-------------' 241 | ^ | ^ 242 DECADE | | Standard | | 243 Resource | | Data DRP | | SDT 244 Protocol | | Transfer | | 245 (DRP) | | (SDT) | | 246 | | | | 247 | | | | 248 | | | | 249 | | | | 250 | | | | 251 | | | | 252 v v v v 253 .=============. DRP .=============. 254 | DECADE | <------------------> | DECADE | 255 | Server | <------------------> | Server | 256 `=============' SDT `=============' 258 Figure 1: DECADE Overview 260 With Figure 1 at hand, assume that Application End-Point B requests a 261 data object from Application End-Point A using their native 262 application protocols (e.g., P2P protocol) as in Figure 2. In this 263 case, End-Point A will act as the sender and End-Point B as the 264 receiver for said data object. S(A) is the DECADE storage server 265 which is access controlled. This means, first, that End-Point A has 266 a right to store the data object in S(A). Secondly, End-Point B 267 needs to obtain authorization before being able to retrieve the data 268 object from S(A). 270 The four steps involved in a DECADE session is illustrated in Figure 271 2. The sequence starts with the initial contact between End-Point B 272 and End-Point A, where End-Point B requests a data object using their 273 native application protocol (e.g., P2P). Next, End-Point A uses DRP 274 to obtain a token corresponding to the data object that was requested 275 by End-Point B. There may be several ways for End-Point A to obtain 276 such a token, e.g., compute it locally or request one from its DECADE 277 storage server, S(A). Once obtained, End-Point A then provides the 278 token to End-Point B (again, using their native application 279 protocol). Finally, End-Point B provides the received token to S(A) 280 via DRP, and subsequently requests and downloads the data object via 281 SDT. Again, it is assumed that DECADE is employed in an overall 282 application context (e.g., P2P file sharing session). 284 For completeness, note that there is an important pre-cursor step 285 (not shown) to Figure 2 where End-Point A first discovers and then 286 stores the data object(s) of interest in S(A). 288 .----------. 289 2. Obtain --------> | S(A) | <------ 290 Token / `----------' \ 4. Request and 291 (DRP) / \ Download Data 292 Locally / \ Object 293 or From / \ (DRP + SDT) 294 S(A) v 1. App Request v 295 .-------------. <--------------------------- .-------------. 296 | Application | | Application | 297 | End-Point A | | End-Point B | 298 `-------------' ---------------------------> `-------------' 299 3. App Response (token) 301 Figure 2: Download from Storage Server 303 4. Architectural Principles 305 This section presents the key principles followed by any DECADE 306 system. 308 4.1. Data and Control Plane Decoupling 310 DECADE SDT and DRP can be classified as belonging to data plane 311 functionality. The algorithms and signaling for a P2P application, 312 for example, would belong to control plane functionality. 314 A DECADE system aims to be application-independent and should support 315 multiple content distribution applications. Typically, a complete 316 content distribution application implements a set of control plane 317 functions including content search, indexing and collection, access 318 control, replication, request routing, and QoS scheduling. 319 Implementers of different content distribution applications may have 320 unique considerations when designing the control plane functions. 321 For example, with respect to the metadata management scheme, 322 traditional file systems provide a standard metadata abstraction: a 323 recursive structure of directories to offer namespace management 324 where each file is an opaque byte stream. Content distribution 325 applications may use different metadata management schemes. For 326 instance, one application might use a sequence of blocks (e.g., for 327 file sharing), while another application might use a sequence of 328 frames (with different sizes) indexed by time. 330 With respect to resource scheduling algorithms, a major advantage of 331 many successful P2P systems is their substantial expertise in 332 achieving efficient utilization of peer resources. For instance, 333 many streaming P2P systems include optimization algorithms for 334 constructing overlay topologies that can support low-latency, high- 335 bandwidth streaming. The research community as well as implementers 336 of such systems continuously fine-tune existing algorithms and invent 337 new ones. A DECADE system should be able to accommodate and benefit 338 from all new developments. 340 In short, given the diversity of control plane functions, a DECADE 341 system should allow for as much flexibility as possible to the 342 control plane to implement specific policies (and be decoupled from 343 data plane DRP/SDT). Decoupling the control plane from the data 344 plane is not new, of course. For example, OpenFlow [OpenFlow] is an 345 implementation of this principle for Internet routing, where the 346 computation of the forwarding table and the application of the 347 forwarding table are separated. The Google File System 348 [GoogleFileSystem] applies the same principle to file system design 349 by utilizing a Master to handle meta-data management and several 350 Chunk servers to handle data plane functions (i.e., read and write of 351 chunks of data). Finally, NFSv4.1's pNFS extension [RFC5661] also 352 adheres to this principle. 354 4.2. Immutable Data Objects 356 A common property of bulk content to be broadly distributed is that 357 it is immutable -- once content is generated, it is typically not 358 modified. For example, once a movie has been edited and released for 359 distribution it is very uncommon that the corresponding video frames 360 and images need to be modified. The same applies to document 361 distribution, such as RFCs, audio files, such as podcasts, and 362 program patches. Focusing on immutable data can substantially 363 simplify data plane design, since consistency requirements can be 364 relaxed. It also simplifies data reuse and implementation of de- 365 duplication. 367 Depending on its specific requirements, an application may store 368 immutable data objects in DECADE servers such that each data object 369 is completely self-contained (e.g., a complete, independently 370 decodable video segment). An application may also divide data into 371 data objects that require application level assembly. Many content 372 distribution applications divide bulk content into data objects for 373 multiple reasons, including (a) fetching different data objects from 374 different sources in parallel; and (b) faster recovery and 375 verification as individual data objects might be recovered and 376 verified. Typically, applications use a data object size larger than 377 a single packet in order to reduce control overhead. 379 A DECADE system should be agnostic to the nature of the data objects 380 and should not specify a fixed size for them. A protocol 381 specification based on this architecture may prescribe requirements 382 on minimum and maximum sizes for compliant implementations. 384 Note that immutable data objects can still be deleted. Applications 385 can support modification of existing data stored at a DECADE server 386 through a combination of storing new data objects and deleting 387 existing data objects. For example, a meta-data management function 388 of the control plane might associate a name with a sequence of 389 immutable data objects. If one of the data objects is modified, the 390 meta-data management function changes the mapping of the name to a 391 new sequence of immutable data objects. 393 4.3. Data Object Identifiers 395 A data object stored in a DECADE server shall be accessed by DECADE 396 clients via a data object identifier. Each DECADE client may be able 397 to access more than one storage server. A data object that is 398 replicated across different storage servers managed by a storage 399 provider may be accessed through a single identifier. Since data 400 objects are immutable, it shall be possible to support persistent 401 identifiers for data objects. 403 Data object identifiers should be created by DECADE clients when 404 uploading the corresponding objects to a DECADE server. The scheme 405 for the assignment/derivation of the data object identifier to a data 406 object depends as the data object naming scheme and is out of scope 407 of this document. One possibility is to name data objects using 408 hashes as described in [RFC6920]. Note that [RFC6920] describes 409 naming schemes on a semantic level only but specific SDTs and DRPs 410 will use specific representations. 412 In particular, for some applications it is important that clients and 413 servers are able to validate the name-object binding, i.e., by 414 verifying that a received object really corresponds to the name 415 (identifier) that was used for requesting it (or that was provided by 416 a sender). Data object identifiers can support name-object binding 417 validation by providing message digests or so-called self-certifying 418 naming information -- if a specific application has this requirement. 420 Different name-object binding validation mechanisms may be supported 421 in a single DECADE system. Content distribution applications can 422 decide what mechanism to use, or to not provide name-object 423 validation (e.g., if authenticity and integrity can by ascertained by 424 alternative means). We expect that applications may be able to 425 construct unique names (with high probability) without requiring a 426 registry or other forms of coordination. Names may be self- 427 describing so that a receiving DECADE client understands, for 428 example, which hash function to use for validating name-object 429 binding. 431 Some content distribution applications will derive the name of a data 432 object from the hash over the data object, which is made possible by 433 the fact that DECADE objects are immutable. But there may be other 434 applications such as live streaming where object names will not based 435 on hashes but rather on an enumeration scheme. The naming scheme 436 will also enable those applications to construct unique names. 438 In order to enable the uniqueness, flexibility and self-describing 439 properties, the naming scheme used in a DECADE system should provide 440 a "type" field that indicates the name-object validation function 441 type (for example, "sha-256" [RFC5754]) and the cryptographic data 442 (such as an object hash) that corresponds to the type information. 443 Moreover, the naming scheme may additionally provide application or 444 publisher information. 446 4.4. Explicit Control 448 To support the functions of an application's control plane, 449 applications should be able to keep track and coordinate which data 450 is stored at particular servers. Thus, in contrast with traditional 451 caches, applications are given explicit control over the placement 452 (selection of a DECADE server), deletion (or expiration policy), and 453 access control for stored data objects. Consider deletion/expiration 454 policy as a simple example. An application might require that a 455 DECADE server stores data objects for a relatively short period of 456 time (e.g., for live-streaming data). Another application might need 457 to store data objects for a longer duration (e.g., for video-on- 458 demand), and so on. 460 4.5. Resource and Data Access Control through Delegation 462 A DECADE system provides a shared infrastructure to be used by 463 multiple Application End-Points. Thus, it needs to provide both 464 resource and data access control, as discussed in the following 465 subsections. 467 4.5.1. Resource Allocation 469 There are two primary interacting entities in a DECADE system. 470 First, storage providers coordinate DECADE server provisioning, 471 including their total available resources. Second, applications 472 coordinate data transfers amongst available DECADE servers and 473 between servers and clients. A form of isolation is required to 474 enable concurrently-running applications to each explicitly manage 475 its own data objects and share of resources at the available servers. 476 Therefore, a storage provider should delegate resource management on 477 a DECADE server to uploading DECADE clients, enabling them to 478 explicitly and independently manage their own share of resources on a 479 server. 481 4.5.2. User Delegation 483 DECADE Storage Providers will have the ability to explicitly manage 484 the entities allowed to utilize the resources available on a DECADE 485 server. This is needed for reasons such as capacity-planning and 486 legal considerations in certain deployment scenarios. The DECADE 487 server should grant a share of the resources to a DECADE client. The 488 client can in turn share the granted resources amongst its (possibly) 489 multiple applications. The share of resources granted by a server is 490 called a User Delegation. As a simple example, a DECADE server 491 operated by an ISP might be configured to grant each ISP subscriber 492 1.5 Mb/s of network capacity and 1 GB of memory. The ISP subscriber 493 might in turn divide this share of resources amongst a video 494 streaming application and file-sharing application which are running 495 concurrently. 497 5. System Components 499 As noted earlier, the primary focus of this document is the 500 architectural principles and the system components that implement 501 them. While specific system components might differ between 502 implementations, this document details the major components and their 503 overall roles in the architecture. To keep the scope narrow, we only 504 discuss the primary components related to protocol development. 505 Particular deployments will require additional components (e.g., 506 monitoring and accounting at a server), but they are intentionally 507 omitted from this document. 509 5.1. Application End-Point 511 Content distribution applications have many functional components. 512 For example, many P2P applications have components and algorithms to 513 manage overlay topology, rate allocation, piece selection, and so on. 514 In this document, we focus on the components directly engaged in a 515 DECADE system. Figure 3 illustrates the components discussed in this 516 section from the perspective of a single Application End-Point. 518 Native Application Protocol(s) 519 (with other Application End-Points) 520 .---------------------> 521 | 522 V 524 .----------------------------------------------------------------. 525 | Application End-Point | 526 | .-------------------. .-------------------. | 527 | | Application-Layer | ... | App Data Assembly | | 528 | | Algorithms | | Sequencing | | 529 | `-------------------' `-------------------' | 530 | | 531 | .==========================================================. | 532 | | DECADE Client | | 533 | | .-------------------------. .--------------------------. | | 534 | | | Resource Controller | | Data Controller | | | 535 | | | .--------. .----------. | | .------------. .-------. | | | 536 | | | | Data | | Resource | | | | Data | | Data | | | | 537 | | | | Access | | Sharing | | | | Scheduling | | Index | | | | 538 | | | | Policy | | Policy | | | | | | | | | | 539 | | | `--------' `----------' | | `------------' `-------' | | | 540 | | `-------------------------' `--------------------------' | | 541 | | | ^ | | 542 | `== | ============================== | ====================' | 543 `----- | ------------------------------ | -----------------------' 544 | | 545 | DECADE Resource Protocol | Standard Data Transfer 546 | (DRP) | (SDT) 547 v V 549 Figure 3: Application and DECADE Client Components 551 A DECADE system is geared towards supporting applications that can 552 distribute content using data objects (e.g., P2P). To accomplish 553 this, applications can include a component responsible for creating 554 the individual data objects before distribution and then re-assembly 555 of data objects. We call this component Application Data Assembly. 556 In producing and assembling data objects, two important 557 considerations are sequencing and naming. A DECADE system assumes 558 that applications implement this functionality themselves. In 559 addition to DECADE DRP/SDT, applications will most likely also 560 support other, native application protocols (e.g., P2P control and 561 data transfer protocols). 563 5.2. DECADE Client 564 The DECADE client provides the local support to an application, and 565 can be implemented standalone, embedded into the application, or 566 integrated in other software entities within network devices (i.e. 567 hosts). In general, applications may have different Resource Sharing 568 Policies and Data Access Policies to control their resource and data 569 in DECADE servers. These policies may be existing policies of 570 applications or custom policies. The specific implementation is 571 decided by the application. 573 Recall that DECADE decouples the control and the data transfer of 574 applications. A Data Scheduling component schedules data transfers 575 according to network conditions, available servers, and/or available 576 server resources. The Data Index indicates data available at remote 577 servers. The Data Index (or a subset of it) can be advertised to 578 other clients. A common use case for this is to provide the ability 579 to locate data amongst distributed Application End-Points (i.e., a 580 data search mechanism such as a Distributed Hash Table). 582 5.3. DECADE Server 584 Figure 4 illustrates the primary components of a DECADE server. Note 585 that the description below does not assume a single-host or 586 centralized implementation: a DECADE server is not necessarily a 587 single physical machine but can also be implemented in a distributed 588 manner on a cluster of machines. 590 | DECADE Resource | Standard Data 591 | Protocol (DRP) | Transfer (SDT) 592 | | 593 .= | ================= | ===========================. 594 | | v DECADE Server | 595 | | .----------------. | 596 | |----> | Access Control | <--------. | 597 | | `----------------' | | 598 | | ^ | | 599 | | | | | 600 | | v | | 601 | | .---------------------. | | 602 | `-> | Resource Scheduling | <------| | 603 | `---------------------' | | 604 | ^ | | 605 | | | | 606 | v .-----------------. | 607 | .-----------------. | User Delegation | | 608 | | Data Store | | Management | | 609 | `-----------------' `-----------------' | 610 `===================================================' 612 Figure 4: DECADE Server Components 614 Provided sufficient authorization, a client shall be able to access 615 its own data or other client's data in a DECADE server. Clients may 616 also authorize other clients to store data. If access is authorized 617 by a client, the server should provide access. Applications may 618 apply resource sharing policies or use a custom policy. DECADE 619 Servers will then perform resource scheduling according to the 620 resource sharing policies indicated by the client as well as any 621 other previously configured User Delegations. Data from applications 622 will be stored at a DECADE server. Data may be deleted from storage 623 either explicitly or automatically (e.g., after a Time To Live (TTL) 624 expiration). 626 5.4. Data Sequencing and Naming 628 The DECADE naming scheme implies no sequencing or grouping of 629 objects, even if this is done at the application layer. To 630 illustrate these properties, this section presents several 631 illustrative examples of use. 633 5.4.1. Application with Fixed-Size Chunks 635 Consider an application in which each individual application-layer 636 segment of data is called a "chunk" and has a name of the form: 637 "CONTENT_ID:SEQUENCE_NUMBER". Furthermore, assume that the 638 application's native protocol uses chunks of size 16 KB. Now, assume 639 that this application wishes to store data in a DECADE server in data 640 objects of size 64 KB. To accomplish this, it can map a sequence of 641 4 chunks into a single data object, as shown in Figure 5. 643 Application Chunks 644 .---------.---------.---------.---------.---------.---------.-------- 645 | | | | | | | 646 | Chunk_0 | Chunk_1 | Chunk_2 | Chunk_3 | Chunk_4 | Chunk_5 | Chunk_6 647 | | | | | | | 648 `---------`---------`---------`---------`---------`---------`-------- 650 DECADE Data Objects 651 .---------------------------------------.---------------------------- 652 | | 653 | Object_0 | Object_1 654 | | 655 `---------------------------------------`---------------------------- 657 Figure 5: Mapping Application Chunks to DECADE Data Objects 659 In this example, the application maintains a logical mapping that is 660 able to determine the name of a DECADE data object given the chunks 661 contained within that data object. The name may be conveyed from 662 either the original uploading DECADE client, another End-Point with 663 which the application is communicating, etc. As long as the data 664 contained within each sequence of chunks is globally unique, the 665 corresponding data objects have globally unique names. 667 5.4.2. Application with Continuous Streaming Data 669 Consider an application whose native protocol retrieves a continuous 670 data stream (e.g., an MPEG2 stream) instead of downloading and 671 redistributing chunks of data. Such an application could segment the 672 continuous data stream to produce either fixed-sized or variable- 673 sized data objects. Figure 6 depicts how a video streaming 674 application might produce variable-sized data objects such that each 675 data object contains 10 seconds of video data. Similarly with the 676 previous example, the application may maintain a mapping that is able 677 to determine the name of a data object given the time offset of the 678 video chunk. 680 Application's Video Stream 681 .-------------------------------------------------------------------- 682 | 683 | 684 | 685 `-------------------------------------------------------------------- 686 ^ ^ ^ ^ ^ 687 | | | | | 688 0 Seconds 10 Seconds 20 Seconds 30 Seconds 40 Seconds 689 0 B 400 KB 900 KB 1200 KB 1500 KB 691 DECADE Data Objects 692 .--------------.--------------.--------------.--------------.-------- 693 | | | | | 694 | Object_0 | Object_1 | Object_2 | Object_3 | 695 | (400 KB) | (500 KB) | (300 KB) | (300 KB) | 696 `--------------`--------------`--------------`--------------`-------- 698 Figure 6: Mapping a Continuous Data Stream to DECADE Data Objects 700 5.5. Token-based Authorization and Resource Control 702 A key feature of a DECADE system is that an application endpoint can 703 authorize other application endpoints to store or retrieve data 704 objects from it's in-network storage via tokens. The peer client 705 then uses the token when sending requests to the DECADE server. Upon 706 receiving a token, the server validates the signature and the 707 operation being performed. 709 This is a simple scheme, but has some important advantages over an 710 alternative approach, for example, in which a client explicitly 711 manipulates an Access Control List (ACL) associated with each data 712 object. In particular, it has the following advantages when applied 713 to DECADE systems. First, authorization policies are implemented 714 within the application, thus it explicitly controls when tokens are 715 generated and to whom they are distributed and for how long they will 716 be valid. Second, fine-grained access and resource control can be 717 applied to data objects. Third, there is no messaging between a 718 client and server to manipulate data object permissions. This can 719 simplify, in particular, applications which share data objects with 720 many dynamic peers and need to frequently adjust access control 721 policies attached to data objects. Finally, tokens can provide 722 anonymous access, in which a server does not need to know the 723 identity of each client that accesses it. This enables a client to 724 send tokens to clients belonging to other storage providers, and 725 allow them to read or write data objects from the storage of its own 726 storage provider. In addition to clients applying access control 727 policies to data objects, the server may be configured to apply 728 additional policies based on user, object properties, geographic 729 location, etc. A client might thus be denied access even though it 730 possesses a valid token. 732 5.6. Discovery 734 A DECADE system should include a discovery mechanism through which 735 DECADE clients locate an appropriate DECADE server. A discovery 736 mechanism should allow a client to determine an IP address or some 737 other identifier that can be resolved to locate the server for which 738 the client will be authorized to generate tokens (via DRP). (The 739 discovery mechanism might also result in an error if no such servers 740 can be located.) After discovering one or more servers, a DECADE 741 client can distribute load and requests across them (subject to 742 resource limitations and policies of the servers themselves) 743 according to the policies of the Application End-Point in which it is 744 embedded. The discovery mechanism outlined here does not provide the 745 ability to locate arbitrary DECADE servers to which a client might 746 obtain tokens from others. To do so will require application-level 747 knowledge, and it is assumed that this functionality is implemented 748 in the content distribution application. 750 As noted above, the discovered DECADE server should be authorized to 751 allow the client to store data objects and then generate tokens to 752 allow other clients to retrieve these data objects. This 753 authorization may be: 755 - a result of off-line administrative procedures; 757 - access network dependent (e.g., all the subscribers to a 758 particular ISP may be allowed by the ISP); 760 - due to a prior subscription; 762 - etc. 764 The particular protocol used for discovery is out of scope of this 765 document, but any specification should re-use well-known protocols 766 wherever possible. 768 6. DECADE Protocol Considerations 770 This section presents the DRP and the SDT protocol in terms of 771 abstract protocol interactions that are intended to be mapped to 772 specific protocols in an implementation. In general, the DRP/SDT 773 functionality between a DECADE client-server are very similar to the 774 DRP/SDT functionality between server-server. Any differences are 775 highlighted below. DRP is used by a DECADE client to configure the 776 resources and authorization used to satisfy requests (reading, 777 writing, and management operations concerning data objects) at a 778 server. SDT will be used to transport data between a client and a 779 server, as illustrated in Figure 1. 781 6.1. Naming 783 A DECADE system SHOULD use [RFC6920] as the recommended and default 784 naming scheme. Other naming schemes that meet the guidelines in 785 Section 4.3 MAY alternatively be used. In order to provide a simple 786 and generic interface, the DECADE server will be responsible only for 787 storing and retrieving individual data objects. 789 The DECADE naming format SHOULD NOT attempt to replace any naming or 790 sequencing of data objects already performed by an Application. 791 Instead, naming is intended to apply only to data objects referenced 792 by DECADE-specific purposes. An application using a DECADE client 793 may use a naming and sequencing scheme independent of DECADE names. 794 The DECADE client SHOULD maintain a mapping from its own data objects 795 and their names to the DECADE-specific data objects and names. 796 Furthermore, the DECADE naming scheme implies no sequencing or 797 grouping of objects, even if this is done at the application layer. 799 6.2. Resource Protocol 801 DRP will provide configuration of access control and resource sharing 802 policies on DECADE servers. A content distribution application 803 (e.g., a live P2P streaming session) can have permission to manage 804 data at several servers, for instance, servers belonging to different 805 storage providers. DRP allows one instance of such an application, 806 i.e., an Application End-Point, to apply access control and resource 807 sharing policies on each of them. 809 On a single DECADE server, the following resources SHOULD be managed: 810 a) communication resources in terms of bandwidth (upload/download) 811 and also in terms of number of active clients (simultaneous 812 connections); and b) storage resources. 814 6.2.1. Access and Resource Control Token 815 The tokens SHOULD be generated by an entity trusted by both the 816 DECADE client and the server at the request of a DECADE client. For 817 example, this entity could be the client, a server trusted by the 818 client, or another server managed by a storage provider and trusted 819 by the client. It is important for a server to trust the entity 820 generating the tokens since each token may incur a resource cost on 821 the server when used. Likewise, it is important for a client to 822 trust the entity generating the tokens since the tokens grant access 823 to the data stored at the server. 825 The token does not normally include information about the identity of 826 the authorized client (i.e. it is typically an anonymous token). 827 However, it is not prohibited to have a binding of the token to an 828 identity if desired (e.g., binding of token to IP address of the 829 authorized party). 831 Upon generating a token, a DECADE client can distribute it to another 832 client. Token confidentiality SHOULD be provided by whatever 833 protocol it is carried in (i.e. Application Protocol, DRP, or SDT). 834 The receiving client can then connect to the server specified in the 835 token and perform any operation permitted by the token. The token 836 SHOULD be sent along with the operation. The server SHOULD validate 837 the token to identify the client that issued it and whether the 838 requested operation is permitted by the contents of the token. If 839 the token is successfully validated, the server SHOULD apply the 840 resource control policies indicated in the token while performing the 841 operation. 843 Tokens SHOULD include a unique identifier to allow a server to detect 844 when a token is used multiple times and reject the additional usage 845 attempts. Since usage of a token incurs resource costs to a server 846 (e.g., bandwidth and storage) and a uploading DECADE client may have 847 a limited budget, the uploading DECADE client should be able to 848 indicate if a token may be used multiple times. 850 It SHOULD be possible to revoke tokens after they are generated. 851 This could be accomplished by supplying the server the unique 852 identifiers of the tokens which are to be revoked. 854 6.2.2. Status Information 856 DRP SHOULD provide a status request service that clients can use to 857 request status information of a server. Access to such status 858 information SHOULD require client authorization; that is, clients 859 need to be authorized to access the requested status information. 860 This authorization is based on the user delegation concept as 861 described in Section 4.5. The following status information elements 862 SHOULD be obtained: a) list of associated data objects (with 863 properties); and b) resources used/available. In addition, the 864 following information elements MAY be available: c) list of servers 865 to which data objects have been distributed (in a certain time- 866 frame); and d) list of clients to which data objects have been 867 distributed (in a certain time-frame). 869 For the list of servers/clients to which data objects have been 870 distributed to, the server SHOULD be able to decide on time bounds 871 for which this information is stored and specify the corresponding 872 time frame in the response to such requests. Some of this 873 information may be used for accounting purposes, e.g., the list of 874 clients to which data objects have been distributed. 876 Access information MAY be provided for accounting purposes, for 877 example, when uploading DECADE clients are interested in access 878 statistics for resources and/or to perform accounting per user. 879 Again, access to such information requires client authorization and 880 SHOULD based on the delegation concept as described in Section 4.5. 881 The following type of access information elements MAY be requested: 882 a) what data objects have been accessed by whom and for how many 883 times; and b) access tokens that a server as seen for a given data 884 object. 886 The server SHOULD decide on time bounds for which this information is 887 stored and specify the corresponding time frame in the response to 888 such requests. 890 6.2.3. Data Object Attributes 892 Data Objects that are stored on a DECADE server SHOULD have 893 associated attributes (in addition to the object identifier and data 894 object) that relate to the data storage and its management. These 895 attributes may be used by the server (and possibly the underlying 896 storage system) to perform specialized processing or handling for the 897 data object, or to attach related server or storage-layer properties 898 to the data object. These attributes have a scope local to a server. 899 In particular, these attributes SHOULD NOT be applied to a server or 900 client to which a data object is copied. 902 Depending on authorization, clients SHOULD be permitted to get or set 903 such attributes. This authorization is based on the delegation as 904 per Section 4.5. DECADE does not limit the set of permissible 905 attributes, but rather specifies a set of baseline attributes that 906 SHOULD be supported: 908 Expiration Time: Time at which the data object can be deleted; 910 Data Object size: In bytes; 911 Media type Labelling of type as per [RFC6838]; 913 Access statistics: How often the data object has been accessed (and 914 what tokens have been used). 916 The data object attributes defined here are distinct from application 917 metadata. Application metadata is custom information that an 918 application might wish to associate with a data object to understand 919 its semantic meaning (e.g., whether it is video and/or audio, its 920 playback length in time, or its index in a stream). If an 921 application wishes to store such metadata persistently, it can be 922 stored within data objects themselves. 924 6.3. Data Transfer 926 A DECADE server will provide a data access interface, and SDT will be 927 used to write data objects to a server and to read (download) data 928 objects from a server. Semantically, SDT is a client-server 929 protocol; that is, the server always responds to client requests. 931 To write a data object, a client first generates the object's name 932 (see Section 6.1), and then uploads the object to a server and 933 supplies the generated name. The name can be used to access 934 (download) the object later; for example, the client can pass the 935 name as a reference to other clients that can then refer to the 936 object. Data objects can be self-contained objects such as 937 multimedia resources, files etc., but also chunks, such as chunks of 938 a P2P distribution protocol that can be part of a containing object 939 or a stream. If supported, a server can verify the integrity and 940 other security properties of uploaded objects. 942 A client can request named data objects from a server. In a 943 corresponding request message, a client specifies the object name and 944 a suitable access and resource control token. The server checks the 945 validity of the received token and its associated resource usage- 946 related properties. If the named data object exists on the server 947 and the token can be validated, the server delivers the requested 948 object in a response message. If the data object cannot be delivered 949 the server provides a corresponding status/reason information in a 950 response message. Specifics regarding error handling, including 951 additional error conditions (e.g., overload), precedence for returned 952 errors and its relation with server policy, are deferred to eventual 953 protocol specification. 955 6.4. Server-to-Server Protocols 957 An important feature of a DECADE system is the capability for one 958 server to directly download data objects from another server. This 959 capability allows applications to directly replicate data objects 960 between servers without requiring end-hosts to use uplink capacity to 961 upload data objects to a different server. 963 DRP and SDT SHOULD support operations directly between servers. 964 Servers are not assumed to trust each other nor are configured to do 965 so. All data operations are performed on behalf of clients via 966 explicit instruction. However, the objects being processed do not 967 necessarily have to originate or terminate at the client (i.e., the 968 data object might be limited to being exchanged between servers even 969 if the instruction is triggered by the client). Clients thus will be 970 able to indicate to a server which remote server(s) to access, what 971 operation is to be performed, or in which the object is to be stored, 972 and the credentials indicating access and resource control to perform 973 the operation at the remote server. 975 Server-to-server support is focused on reading and writing data 976 objects between servers. The data object referred to at the remote 977 server is the same as the original data object requested by the 978 client. Object attributes might also be specified in the request to 979 the remote server. In this way, a server acts as a proxy for a 980 client, and a client can instantiate requests via that proxy. The 981 operations will be performed as if the original requester had its own 982 client co-located with the server. When a client sends a request to 983 a server with these additional parameters, it is giving the server 984 permission to act (proxy) on its behalf. Thus, it would be prudent 985 for the supplied token to have narrow privileges (e.g., limited to 986 only the necessary data objects) or validity time (e.g., a small 987 expiration time). 989 In the case of a retrieval operation, the server is to retrieve the 990 data object from the remote server using the specified credentials, 991 and then optionally return the object to a client. In the case of a 992 storage operation, the server is to store the object to the remote 993 server using the specified credentials. The object might optionally 994 be uploaded from the client or might already exist at the server. 996 6.5. Potential DRP/SDT Candidates 998 Having covered the key DRP/SDT functionalities above, it is useful to 999 consider some potential DRP/SDT candidates as guidance for future 1000 DECADE protocol implementations. To recap, the DRP is a protocol for 1001 communication of access control and resource scheduling policies from 1002 a DECADE client to a DECADE server, or between DECADE servers. The 1003 SDT is a protocol used to transfer data objects between a DECADE 1004 client and DECADE server, or between DECADE servers. An evaluation 1005 of existing protocols for their suitability for DRP and SDT is given 1006 in Appendix A. Also [I-D.zong-integration-example] provides some 1007 experimental examples of how to integrate DECADE-like in-network 1008 storage infrastructure into P2P applications. 1010 7. In-Network Storage Components Mapping to DECADE 1012 This section evaluates how the basic components of an in-network 1013 storage system (see Section 3 of [RFC6392]) map into a DECADE system. 1015 With respect to Data Access Interface, DECADE clients can read and 1016 write objects of arbitrary size through the client's Data Controller, 1017 making use of standard data transfer (SDT). With respect to Data 1018 Management Operations, clients can move or delete previously stored 1019 objects via the client's Data Controller, making use of SDT. Clients 1020 can enumerate or search contents of servers to find objects matching 1021 desired criteria through services provided by the Content 1022 Distribution Application (e.g., buffer-map exchanges, a DHT, or peer- 1023 exchange). In doing so, Application End-Points might consult their 1024 local Data Index in the client's Data Controller (Data Search 1025 Capability). 1027 With respect to Access Control Authorization, all methods of access 1028 control are supported: public-unrestricted, public-restricted and 1029 private. Access Control Policies are generated by a content 1030 distribution application and provided to the client's Resource 1031 Controller. The server is responsible for implementing the access 1032 control checks. Clients can manage the resources (e.g., bandwidth) 1033 on the DECADE server that can be used by other Application End-Points 1034 (Resource Control Interface). Resource Sharing Policies are 1035 generated by a content distribution application and provided to the 1036 client's Resource Controller. The server is responsible for 1037 implementing the resource sharing policies. 1039 Although the particular protocol used for discovery is outside the 1040 scope of this document, different options and considerations have 1041 been discussed in Section 5.6. Finally with respect to the storage 1042 mode, DECADE servers provide an object-based storage mode. Immutable 1043 data objects might be stored at a server. Applications might 1044 consider existing blocks as data objects, or they might adjust block 1045 sizes before storing in a server. 1047 8. Security Considerations 1049 In general, the security considerations mentioned in [RFC6646] apply 1050 to this document as well. A DECADE system provides a distributed 1051 storage service for content distribution and similar applications. 1052 The system consists of servers and clients that use these servers to 1053 upload data objects, to request distribution of data objects, and to 1054 download data objects. Such a system is employed in an overall 1055 application context -- for example in a P2P application, and it is 1056 expected that DECADE clients take part in application-specific 1057 communication sessions. The security considerations here focus on 1058 threats related to the DECADE system and its communication services, 1059 i.e., the DRP/SDT protocols that have been described in an abstract 1060 fashion in this document. 1062 8.1. Threat: System Denial of Service Attacks 1064 A DECADE network might be used to distribute data objects from one 1065 client to a set of servers using the server-to-server communication 1066 feature that a client can request when uploading an object. Multiple 1067 clients uploading many objects at different servers at the same time 1068 and requesting server-to-server distribution for them could thus 1069 mount massive distributed denial of service (DDOS) attacks, 1070 overloading a network of servers. This threat is addressed by the 1071 server's access control and resource control framework. Servers can 1072 require Application End-Points to be authorized to store and to 1073 download objects, and Application End-Points can delegate 1074 authorization to other Application End-Points using the token 1075 mechanism. Of course the effective security of this approach depends 1076 on the strength of the token mechanism. See below for a discussion 1077 of this and related communication security threats. 1079 Denial of Service Attacks against a single server (directing many 1080 requests to that server) might still lead to considerable load for 1081 processing requests and invalidating tokens. SDT therefore MUST 1082 provide a redirection mechanism to allow requests to other servers. 1083 Analogous to how an HTTP reverse proxy can re-direct and load balance 1084 across multiple HTTP origin servers [RFC2616]. 1086 8.2. Threat: Authorization Mechanisms Compromised 1088 A DECADE system does not require Application End-Points to 1089 authenticate in order to access a server for downloading objects, 1090 since authorization is not based on End-Point or user identities but 1091 on a delegation-based authorization mechanism. Hence, most protocol 1092 security threats are related to the authorization scheme. The 1093 security of the token mechanism depends on the strength of the token 1094 mechanism and on the secrecy of the tokens. A token can represent 1095 authorization to store a certain amount of data, to download certain 1096 objects, to download a certain amount of data per time etc. If it is 1097 possible for an attacker to guess, construct or simply obtain tokens, 1098 the integrity of the data maintained by the servers is compromised. 1100 This is a general security threat that applies to authorization 1101 delegation schemes. Specifications of existing delegation schemes 1102 such as [RFC6749] discuss these general threats in detail. We can 1103 say that the DRP has to specify appropriate algorithms for token 1104 generation. Moreover, authorization tokens should have a limited 1105 validity period that should be specified by the application. Token 1106 confidentiality should be provided by application protocols that 1107 carry tokens, and the SDT and DRP should provide secure 1108 (confidential) communication modes. 1110 8.3. Threat: Data Object Spoofing 1112 In a DECADE system, an Application End-Point is referring other 1113 Application End-Points to servers to download a specified data 1114 objects. An attacker could "inject" a faked version of the object 1115 into this process, so that the downloading End-Point effectively 1116 receives a different object (compared to what the uploading End-Point 1117 provided). As result, the downloading End-Point believes that is has 1118 received an object that corresponds to the name it was provided 1119 earlier, whereas in fact it is a faked object. Corresponding attacks 1120 could be mounted against the application protocol (that is used for 1121 referring other End-Points to servers), servers themselves (and their 1122 storage sub-systems), and the SDT by which the object is uploaded, 1123 distributed and downloaded. 1125 A DECADE systems fundamental mechanism against object spoofing is 1126 name-object binding validation, i.e., the ability of a receiver to 1127 check whether the name it was provided and that it used to request an 1128 object, actually corresponds to the bits it received. As described 1129 above, this allows for different forms of name-object binding, for 1130 example using hashes of data objects, with different hash functions 1131 (different algorithms, different digest lengths). For those 1132 application scenarios where hashes of data objects are not applicable 1133 (for example live-streaming) other forms of name-object binding can 1134 be used. This flexibility also addresses cryptographic algorithm 1135 evolution: hash functions might get deprecated, better alternatives 1136 might be invented etc., so that applications can choose appropriate 1137 mechanisms meeting their security requirements. 1139 DECADE servers MAY perform name-object binding validation on stored 1140 objects, but Application End-Points MUST NOT rely on that. In other 1141 words, Application End-Points SHOULD perform name-object binding 1142 validation on received objects. 1144 9. IANA Considerations 1146 This document does not have any IANA considerations. 1148 10. Acknowledgments 1149 We thank the following people for their contributions to and/or 1150 detailed reviews of this or earlier versions of this document: Carlos 1151 Bernardos, Carsten Bormann, David Bryan, Dave Crocker, Yingjie Gu, 1152 David Harrington, Hongqiang (Harry) Liu, David McDysan, Borje Ohlman, 1153 Martin Stiemerling, Richard Woundy, and Ning Zong. 1155 11. Informative References 1157 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1158 Requirement Levels", BCP 14, RFC 2119, March 1997. 1160 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1161 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1162 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1164 [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File 1165 System (NFS) Version 4 Minor Version 1 Protocol", RFC 1166 5661, January 2010. 1168 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 1169 Message Syntax", RFC 5754, January 2010. 1171 [RFC6392] Alimi, R., Rahman, A., and Y. Yang, "A Survey of In- 1172 Network Storage Systems", RFC 6392, October 2011. 1174 [RFC6646] Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled 1175 Application Data Enroute (DECADE) Problem Statement", RFC 1176 6646, July 2012. 1178 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 1179 6749, October 2012. 1181 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1182 Specifications and Registration Procedures", BCP 13, RFC 1183 6838, January 2013. 1185 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 1186 Keranen, A., and P. Hallam-Baker, "Naming Things with 1187 Hashes", RFC 6920, April 2013. 1189 [I-D.zong-integration-example] 1190 Zong, N., Chen, X., Huang, Z., Chen, L., and H. Liu, 1191 "Integration Examples of DECADE System", draft-zong- 1192 integration-example-02 (work in progress), August 2013. 1194 [GoogleFileSystem] 1195 Ghemawat, S., Gobioff, H., and S. Leung, "The Google File 1196 System", SOSP 2003, October 2003. 1198 [GoogleStorageDevGuide] 1199 Google, ., "Google Storage Developer Guide", July 2013, 1200 . 1203 [OpenFlow] 1204 Open Networking Foundation, ., "Sofware-Defined 1205 Networking: The New Norm for Networks", April 2013, 1206 . 1209 [CDMI] SNIA, ., "Cloud Data Management Interface (CDMI)", July 1210 2013, . 1212 Appendix A. Evaluation of Candidate Protocols for DECADE DRP/SDT 1214 In this section we evaluate how well the abstract protocol 1215 interactions specified in this document for DECADE DRP and SDT can be 1216 fulfilled by the existing protocols of HTTP, CDMI and OAUTH. 1218 A.1. HTTP 1220 HTTP [RFC2616] is a key protocol for the Internet in general and 1221 especially for the World Wide Web. HTTP is a request-response 1222 protocol. A typical transaction involves a client (e.g., web 1223 browser) requesting content (resources) from a web server. Another 1224 example is when a client stores or deletes content from a server. 1226 A.1.1. HTTP Support for DRP Primitives 1228 DRP provides configuration of access control and resource sharing 1229 policies on DECADE servers. 1231 A.1.1.1. Access Control Primitives 1233 Access control requires mechanisms for defining the access policies 1234 for the server, and then checking the authorization of a user before 1235 it stores or retrieves content. HTTP supports a rudimentary access 1236 control via "HTTP Secure" (HTTPS). HTTPS is a combination of HTTP 1237 with SSL/TLS. The main use of HTTPS is to authenticate the server 1238 and encrypt all traffic between the client and the server. There is 1239 also a mode to support client authentication though this is less 1240 frequently used. 1242 A.1.1.2. Communication Resource Control Primitives 1244 Communication resources include bandwidth (upload/download) and 1245 number of simultaneous connected clients (connections). HTTP 1246 supports bandwidth control indirectly through "persistent" HTTP 1247 connections. Persistent HTTP connections allows a client to keep 1248 open the underlying TCP connection to the server to allow streaming 1249 and pipe-lining (multiple simultaneous requests for a given client). 1251 HTTP does not define protocol operation to allow limiting the 1252 communication resources to a client. However servers typically 1253 perform this function via implementation algorithms. 1255 A.1.1.3. Storage Resource Control Primitives 1257 Storage resources include amount of memory and lifetime of storage. 1258 HTTP does not allow direct control of storage at the server end 1259 point. However HTTP supports caching at intermediate points such as 1260 a web proxy. For this purpose, HTTP defines cache control mechanisms 1261 that define how long and in what situations the intermediate point 1262 may store and use the content. 1264 A.1.2. HTTP Support for SDT Primitives 1266 SDT is used to write objects and read (download) objects from a 1267 DECADE server. The object can be either a self-contained object such 1268 as a multimedia file or a chunk from a P2P system. 1270 A.1.2.1. Writing Primitives 1272 Writing involves uploading objects to the server. HTTP supports two 1273 methods of writing called PUT and POST. In HTTP the object is called 1274 a resource and is identified by a URI. PUT uploads a resource to a 1275 specific location on the server. POST, on the other hand, submits 1276 the object to the server and the server decides whether to update an 1277 existing resource or to create a new resource. 1279 For DECADE, the choice of whether to use PUT or POST will be 1280 influenced by which entity is responsible for the naming. If the 1281 client performs the naming, then PUT is appropriate. If the server 1282 performs the naming, then POST should be used (to allow the server to 1283 define the URI). 1285 A.1.2.2. Downloading Primitives 1287 Downloading involves fetching of an object from the server. HTTP 1288 supports downloading through the GET and HEAD methods. GET fetches a 1289 specific resource as identified by the URL. HEAD is similar but only 1290 fetches the metadata ("header") associated with the resource but not 1291 the resource itself. 1293 A.1.3. Traffic De-duplication Primitives 1295 To challenge a remote entity for an object, the DECADE server should 1296 provide a seed number, which is generated by the server randomly, and 1297 ask the remote entity to return a hash calculated from the seed 1298 number and the content of the object. The server may also specify 1299 the hash function which the remote entity should use. HTTP supports 1300 the challenge message through the GET methods. The message type 1301 ("challenge"), the seed number and the hash function name are put in 1302 URL. In the reply, the hash is sent in an Entity Tag (ETag) header. 1304 A.1.4. Other Operations 1306 HTTP supports deleting of content on the server through the DELETE 1307 method. 1309 A.1.5. Conclusions 1311 HTTP can provide a rudimentary DRP and SDT for some aspects of 1312 DECADE, but will not be able to satisfy all the DECADE requirements. 1313 For example, HTTP does not provide a complete access control 1314 mechanism, nor does it support storage resource controls at the end 1315 point server. 1317 It is possible, however, to envision combining HTTP with a custom 1318 suite of other protocols to fulfill most of the DECADE requirements 1319 for DRP and SDT. For example, Google Storage for Developers is built 1320 using HTTP (with extensive proprietary extensions such as custom HTTP 1321 headers). Google Storage also uses OAUTH [RFC6749] (for access 1322 control) in combination with HTTP [GoogleStorageDevGuide]. An 1323 example of using OAUTH for DRP is given in Appendix A.3. 1325 A.2. CDMI 1327 The Cloud Data Management Interface (CDMI) specification defines a 1328 functional interface through which applications can store and manage 1329 data objects in a cloud storage environment. The CDMI interface for 1330 reading/writing data is based on standard HTTP requests, with CDMI- 1331 specific encodings using JavaScript Object Notation (JSON). CDMI is 1332 specified by the Storage Networking Industry Association (SNIA) 1333 [CDMI]. 1335 A.2.1. CDMI Support for DRP Primitives 1337 DRP provides configuration of access control and resource sharing 1338 policies on DECADE servers. 1340 A.2.1.1. Access Control Primitives 1342 Access control includes mechanisms for defining the access policies 1343 for the server, and then checking the authorization of a user before 1344 it stores or retrieves content. CDMI defines an Access Control List 1345 (ACL) per data object, and thus supports access control (read and/or 1346 write) at the data object granularity. An ACL contains a set of 1347 Access Control Entries (ACEs), where each ACE specifies a principal 1348 (i.e. user or group of users) and a set of privileges that are 1349 granted to that principal. 1351 CDMI requires that an HTTP authentication mechanism be available for 1352 the server to validate the identity of a principal (client). 1353 Specifically, CDMI requires that either HTTP Basic Authentication or 1354 HTTP Digest Authentication be supported. CDMI recommends that HTTP 1355 over TLS (HTTPS) is supported to encrypt the data sent over the 1356 network. 1358 A.2.1.2. Communication Resource Control Primitives 1360 Communication resources include bandwidth (upload/download) and 1361 number of simultaneous connected clients (connections). CDMI 1362 supports two key data attributes which provide control over the 1363 communication resources to a client: "cdmi_max_throughput" and 1364 "cdmi_max_latency". These attributes are defined in the metadata for 1365 data objects and indicate the desired bandwidth or delay for 1366 transmission of the data object from the cloud server to the client. 1368 A.2.1.3. Storage Resource Control Primitives 1370 Storage resources include amount of quantity and lifetime of storage. 1371 CDMI defines metadata for individual data objects and general storage 1372 system configuration which can be used for storage resource control. 1373 In particular, CDMI defines the following metadata fields: 1375 -cdmi_data_redundancy: desired number of copies to be maintained; 1377 -cdmi_geographic_placement region where object is permitted to be 1378 stored; 1380 -cdmi_retention_period time interval object is to be retained; 1382 -cdmi_retention_autodelete whether object should be auto deleted 1383 after retention period. 1385 A.2.2. CDMI Support for SDT Primitives 1386 SDT is used to write objects and read (download) objects from a 1387 DECADE server. The object can be either a self-contained object such 1388 as a multimedia file or a chunk from a P2P system. 1390 A.2.2.1. Writing Primitives 1392 Writing involves uploading objects to the server. CDMI supports 1393 standard HTTP methods for PUT and POST as described in 1394 Appendix A.1.2.1. 1396 A.2.2.2. Downloading Primitives 1398 Downloading involves fetching of an object from the server. CDMI 1399 supports the standard HTTP GET method as described in 1400 Appendix A.1.2.2. 1402 A.2.3. Other Operations 1404 CDMI supports DELETE as described in Appendix A.1.4. CDMI also 1405 supports COPY and MOVE operations. 1407 CDMI supports the concept of containers of data objects to support 1408 joint operations on related objects. For example, GET may be done on 1409 a single data object or on an entire container. 1411 CDMI supports a global naming scheme. Every object stored within a 1412 CDMI system will have a globally unique object string identifier 1413 (ObjectID) assigned at creation time. 1415 A.2.4. Conclusions 1417 CDMI has a rich array of features that can provide a good base for 1418 DRP and SDT for DECADE. An initial analysis finds that the following 1419 CDMI features may be useful for DECADE: 1421 - access control 1423 - storage resource control 1425 - communication resource control 1427 - COPY/MOVE operations 1429 - data containers 1431 - naming scheme 1433 A.3. OAUTH 1435 As mentioned in Appendix A.1, OAuth [RFC6749] may be used as part of 1436 the access and resource control of a DECADE system. In this section, 1437 we provide an example of how to configure OAuth requests and 1438 responses for DRP. 1440 An OAuth request to access DECADE data objects should include the 1441 following fields: 1443 Response_type: Value should be set to "token". 1445 Client_id: The client_id indicates either the application that is 1446 using the DECADE service or the end user who is using the DECADE 1447 service from a DECADE storage service provider. DECADE storage 1448 service providers should provide the ID distribution and 1449 management function. 1451 Scope: Data object names that are requested. 1453 An OAuth response should include the following information: 1455 Token_type: "Bearer" 1457 Expires_in: The lifetime in seconds of the access token. 1459 Access_token: A token denotes the following information. 1461 Service URI: The server address or URI which is providing the 1462 service; 1464 Permitted operations (e.g., read, write) and objects (e.g., names 1465 of data objects that might be read or written); 1467 Priority: Value should be set to be either "Urgent", "High", 1468 "Normal" or "Low". 1470 Bandwidth: Given to requested operation, a weight value used in a 1471 weighted bandwidth sharing scheme, or a integer in number of bps; 1473 Amount: Data size in number of bytes that might be read or 1474 written. 1476 Token_signature: The signature of the access token. 1478 Authors' Addresses 1479 Richard Alimi 1480 Google 1482 Email: ralimi@google.com 1484 Akbar Rahman 1485 InterDigital Communications, LLC 1487 Email: akbar.rahman@interdigital.com 1489 Dirk Kutscher 1490 NEC 1492 Email: dirk.kutscher@neclab.eu 1494 Y. Richard Yang 1495 Yale University 1497 Email: yry@cs.yale.edu 1499 Haibin Song 1500 Huawei Technologies 1502 Email: haibin.song@huawei.com 1504 Kostas Pentikousis 1505 EICT 1507 Email: k.pentikousis@eict.de