idnits 2.17.1 draft-ietf-decade-arch-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 31, 2012) is 4345 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4288 (Obsoleted by RFC 6838) -- Obsolete informational reference (is this intentional?): RFC 5661 (Obsoleted by RFC 8881) -- Obsolete informational reference (is this intentional?): RFC 5849 (Obsoleted by RFC 6749) == Outdated reference: A later version (-08) exists of draft-ietf-decade-reqs-06 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DECADE R. Alimi 3 Internet-Draft Google 4 Intended status: Informational A. Rahman 5 Expires: December 2, 2012 InterDigital Communications, LLC 6 D. Kutscher 7 NEC 8 Y. Yang 9 Yale University 10 May 31, 2012 12 DECADE Architecture 13 draft-ietf-decade-arch-06 15 Abstract 17 Content Distribution Applications (e.g., P2P applications) are widely 18 used on the Internet and make up a large portion of the traffic in 19 many networks. One technique to improve the network efficiency of 20 these applications is to introduce storage capabilities within the 21 networks; this is the capability provided by a DECADE (DECoupled 22 Application Data Enroute) compatible system. This document presents 23 an architecture, discusses the underlying principles, and identifies 24 key functionalities required for introducing a DECADE-compatible in- 25 network storage system. In addition, some examples are given to 26 illustrate these concepts. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on December 2, 2012. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2.1. DECADE-compatible Client . . . . . . . . . . . . . . . . . 5 70 2.2. DECADE-compatible Server . . . . . . . . . . . . . . . . . 5 71 2.3. Content Provider . . . . . . . . . . . . . . . . . . . . . 6 72 2.4. Content Consumer . . . . . . . . . . . . . . . . . . . . . 6 73 2.5. Storage Provider . . . . . . . . . . . . . . . . . . . . . 6 74 2.6. Content Distribution Application . . . . . . . . . . . . . 6 75 2.7. Application End-Point . . . . . . . . . . . . . . . . . . 6 76 2.8. Data Object . . . . . . . . . . . . . . . . . . . . . . . 6 77 3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 6 78 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 3.2. An Example . . . . . . . . . . . . . . . . . . . . . . . . 8 80 4. Architectural Principles . . . . . . . . . . . . . . . . . . . 9 81 4.1. Decoupled Control/Metadata and Data Planes . . . . . . . . 9 82 4.2. Immutable Data Objects . . . . . . . . . . . . . . . . . . 10 83 4.3. Data Objects With Identifiers . . . . . . . . . . . . . . 10 84 4.4. Data Object Naming Scheme . . . . . . . . . . . . . . . . 11 85 4.5. Explicit Control . . . . . . . . . . . . . . . . . . . . . 12 86 4.6. Resource and Data Access Control . . . . . . . . . . . . . 13 87 5. System Components . . . . . . . . . . . . . . . . . . . . . . 14 88 5.1. Content Distribution Application . . . . . . . . . . . . . 14 89 5.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 16 90 5.3. Data Sequencing and Naming . . . . . . . . . . . . . . . . 18 91 5.4. Token-based Authentication and Resource Control . . . . . 20 92 5.5. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 21 93 6. DECADE Protocols . . . . . . . . . . . . . . . . . . . . . . . 22 94 6.1. DECADE Resource Protocol (DRP) . . . . . . . . . . . . . . 22 95 6.2. Standard Data Transfer (SDT) Protocol . . . . . . . . . . 25 96 6.3. Server-to-Server Protocols . . . . . . . . . . . . . . . . 26 97 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 98 7.1. Threat: System Denial of Service Attacks . . . . . . . . . 28 99 7.2. Threat: Protocol Security . . . . . . . . . . . . . . . . 29 100 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 101 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 102 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 103 10.1. Normative References . . . . . . . . . . . . . . . . . . . 31 104 10.2. Informative References . . . . . . . . . . . . . . . . . . 31 105 Appendix A. In-Network Storage Components Mapped to DECADE 106 Architecture . . . . . . . . . . . . . . . . . . . . 31 107 A.1. Data Access Interface . . . . . . . . . . . . . . . . . . 32 108 A.2. Data Management Operations . . . . . . . . . . . . . . . . 32 109 A.3. Data Search Capability . . . . . . . . . . . . . . . . . . 32 110 A.4. Access Control Authorization . . . . . . . . . . . . . . . 32 111 A.5. Resource Control Interface . . . . . . . . . . . . . . . . 32 112 A.6. Discovery Mechanism . . . . . . . . . . . . . . . . . . . 32 113 A.7. Storage Mode . . . . . . . . . . . . . . . . . . . . . . . 32 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 116 1. Introduction 118 Content Distribution Applications, such as Peer-to-Peer (P2P) 119 applications, are widely used on the Internet to distribute data, and 120 they contribute a large portion of the traffic in many networks. The 121 DECADE-compatible architecture described in this document enables 122 such applications to leverage in-network storage to achieve more 123 efficient content distribution. Specifically, in many subscriber 124 networks, it can be expensive to upgrade network equipment in the 125 "last-mile", because it can involve replacing equipment and upgrading 126 wiring at individual homes, businesses, and devices such as DSLAMs 127 (Digital Subscriber Line Access Multiplexers) and CMTSs (Cable Modem 128 Termination Systems) in remote locations. Therefore, it may be 129 cheaper to upgrade the core infrastructure, which involves fewer 130 components that are shared by many subscribers. See 131 [I-D.ietf-decade-problem-statement] for a more complete discussion of 132 the problem domain and general discussions of the capabilities to be 133 provided by a DECADE-compatible system. 135 This document presents an architecture for providing in-network 136 storage that can be integrated into Content Distribution 137 Applications. The primary focus is P2P-based content distribution, 138 but the architecture may be useful to other applications with similar 139 characteristics and requirements. See [I-D.ietf-decade-reqs] for a 140 definition of the target applications supported by a DECADE- 141 compatible system. 143 The approach of this document is to define the core functionalities 144 and protocol behaviour that are needed to support in-network storage 145 in a DECADE-compatible system. The protocol themselves are not 146 selected or designed in this document. Some illustrative examples 147 are given to help the reader understand certain concepts. These 148 examples are purely informational and are not meant to constrain 149 future protocol design or selection. 151 2. Terminology 153 2.1. DECADE-compatible Client 155 A DECADE-compatible client uploads and/or retrieves data from DECADE- 156 compatible servers. We simply use the term "client" if there is no 157 ambiguity. 159 2.2. DECADE-compatible Server 161 A DECADE-compatible server stores data inside the network, and 162 thereafter manages both the stored data and access to that data. We 163 simply use the term "server" if there is no ambiguity. 165 2.3. Content Provider 167 A client which owns (i.e. uploads and manages) storage at a DECADE- 168 compatible server. 170 2.4. Content Consumer 172 A client which has been granted permission to retrieve data from a 173 DECADE-compatible server by a Content Provider. 175 2.5. Storage Provider 177 A Storage Provider deploys and/or manages DECADE-compatible server(s) 178 within a network. 180 2.6. Content Distribution Application 182 A Content Distribution Application is an application (e.g., P2P) 183 designed for dissemination of a large amounts of data to multiple 184 consumers. Content Distribution Applications typically divide 185 content into smaller blocks for dissemination. 187 We consider Content Distribution Applications that include a DECADE- 188 compatible client along with other application functionality (e.g., 189 P2P video streaming client). 191 2.7. Application End-Point 193 An Application End-Point is an instance of a Content Distribution 194 Application. A particular Application End-Point might be a Content 195 Provider, a Content Consumer, or both. For example, an Application 196 End-Point might be an instance of a video streaming client, or it 197 might be the source providing the video to a set of clients. 199 2.8. Data Object 201 A data object is the unit of data stored and retrieved from a DECADE- 202 compatible server. The data object is a string of raw bytes. The 203 server maintains metadata associated with each data object, but the 204 metadata is not included in the data object. 206 3. Protocol Flow 207 3.1. Overview 209 A DECADE-compatible system will support two logical protocols, as 210 shown in Figure 1. First, the DECADE Resource Protocol (DRP) is 211 responsible for communication of access control and resource 212 scheduling policies between a client and a server, as well as between 213 servers. A DECADE-compatible system will include exactly one DRP for 214 interoperability and a common format through which these policies can 215 be communicated. 217 Native Application 218 .-------------. Protocol(s) .-------------. 219 | Application | <------------------> | Application | 220 | End-Point | | End-Point | 221 | | | | 222 | .--------. | | .--------. | 223 | | DECADE | | | | DECADE | | 224 | | Client | | | | Client | | 225 | `--------' | | `--------' | 226 `-------------' `-------------' 227 | ^ | ^ 228 DECADE | | Standard | | 229 Resource | | Data DRP | | SDT 230 Protocol | | Transfer | | 231 (DRP) | | (SDT) | | 232 | | | | 233 | | | | 234 | | | | 235 | | | | 236 | | | | 237 | | | | 238 v V v V 239 .=============. DRP .=============. 240 | DECADE | <------------------> | DECADE | 241 | Server | <------------------> | Server | 242 `=============' SDT `=============' 244 Figure 1: Generic Protocol Flow 246 Second, a Standard Data Transfer (SDT) protocol will be used to 247 transfer data objects to and from a server. A DECADE-compatible 248 system may support multiple SDT's. If there are multiple SDT's, a 249 negotiation mechanism will be used to determine a suitable SDT 250 between the client and server. 252 The two protocols (DRP and SDT) will be either separate or combined 253 on the wire. If they are combined, DRP messages can be piggy-backed 254 within some extension fields provided by certain SDT protocols. In 255 such a scenario, DRP is technically a data structure (transported by 256 other protocols), but it can still be considered as a logical 257 protocol that provides the services of configuring DECADE-compatible 258 resource usage. If the protocols are physically separate on the 259 wire, DRP can take the form of a separate control connection open 260 between the a DECADE-compatible client and server. Hence, this 261 document considers SDT and DRP as two separate, logical functional 262 components for clarity. The abstract properties of the SDT and DRP 263 are outlined below but the final selection of these protocols is 264 outside the scope of this document. 266 3.2. An Example 268 This section provides an example of steps in a data transfer scenario 269 involving an in-network storage system. We assume that Application 270 End-Point B (the receiver) is requesting a data object from 271 Application End-Point A (the sender). Let S(A) denote the DECADE- 272 compatible storage server to which A has access. There are multiple 273 usage scenarios (by choice of the Content Distribution Application). 274 For simplicity of introduction, we design this example to use only a 275 single DECADE-compatible server. 277 The steps of the example are illustrated in Figure 2. First, B 278 requests a data object from A using their native application protocol 279 (see Section 5.1.2). Next, A uses the DRP to obtain a token. There 280 are multiple ways for A to obtain the token: compute locally, or 281 request from its DECADE-compatible storage server, S(A). See 282 Section 6.1.2 for details. A then provides the token to B (again, 283 using their native application protocol). Finally, B provides the 284 token to S(A) via DRP, and requests and downloads the data object via 285 a SDT. 287 .----------. 288 2. Obtain --------> | S(A) | <------ 289 Token / `----------' \ 4. Request and 290 (DRP) / \ Download Object 291 Locally / \ (DRP + SDT) 292 or From / \ 293 S(A) v 1. App Request v 294 .-------------. <--------------------------- .-------------. 295 | Application | | Application | 296 | End-Point A | | End-Point B | 297 `-------------' ---------------------------> `-------------' 298 3. App Response (token) 300 Figure 2: Download from Storage Server 302 4. Architectural Principles 304 We identify the following key principles that will be followed in any 305 DECADE-compatible system: 307 4.1. Decoupled Control/Metadata and Data Planes 309 A DECADE-compatible system SHOULD be able to support multiple Content 310 Distribution Applications. A complete Content Distribution 311 Application implements a set of "control plane" functions including 312 content search, indexing and collection, access control, ad 313 insertion, replication, request routing, and QoS scheduling. 314 Different Content Distribution Applications will have unique 315 considerations designing the control plane functions: 317 o Metadata Management Scheme: Traditional file systems provide a 318 standard metadata abstraction: a recursive structure of 319 directories to offer namespace management; each file is an opaque 320 byte stream. Content Distribution Applications may use different 321 metadata management schemes. For example, one application might 322 use a sequence of blocks (e.g., for file sharing), while another 323 application might use a sequence of frames (with different sizes) 324 indexed by time. 326 o Resource Scheduling Algorithms: A major advantage of many 327 successful P2P systems is their substantial expertise in achieving 328 highly efficient utilization of peer and infrastructural 329 resources. For instance, many streaming P2P systems have their 330 specific algorithms in constructing topologies to achieve low- 331 latency, high-bandwidth streaming. They continuously fine-tune 332 such algorithms. 334 Given the diversity of control plane functions, a DECADE-compatible 335 system SHOULD allow as much flexibility as possible to the control 336 plane to implement specific policies. This conforms to the end-to- 337 end systems principle and allows innovation and satisfaction of 338 specific performance goals. 340 Decoupling control plane and data plane is not new. For example, 341 OpenFlow [OpenFlow] is an implementation of this principle for 342 Internet routing, where the computation of the forwarding table and 343 the application of the forwarding table are separated. Google File 344 System [GoogleFileSystem] applies the principle to file system 345 design, by utilizing the Master to handle the meta-data management, 346 and the Chunk servers to handle the data plane functions (i.e., read 347 and write of chunks of data). NFSv4.1's pNFS extension [RFC5661] 348 also implements this principle. 350 4.2. Immutable Data Objects 352 A property of bulk content to be broadly distributed is that they 353 typically are immutable -- once content is generated, it is typically 354 not modified. It is not common that bulk content such as video 355 frames and images need to be modified after distribution. 357 Focusing on immutable data in the data plane can substantially 358 simplify the data plane design, since consistency requirements can be 359 relaxed. It also simplifies reuse of data and implementation of de- 360 duplication. 362 Depending on its specific requirements, an application may store 363 immutable data objects in DECADE-compatible servers such that each 364 data object is completely self-contained (e.g., a complete, 365 independently decodable video segment). An application may also 366 divide data into blocks that require application level assembly. 367 Many Content Distribution Applications divide bulk content into 368 blocks for multiple reasons, including (1) multipath: different 369 blocks might be fetched from different sources in parallel; and (2) 370 faster recovery and verification: individual blocks might be 371 recovered and verified. Typically, applications use a block size 372 larger than a single packet in order to reduce control overhead. 374 A DECADE-compatible system SHOULD be agnostic to the nature of the 375 data objects and SHOULD NOT specify a fixed size for them. Though a 376 protocol specification based on this architecture MAY prescribe 377 requirements on minimum and maximum sizes by compliant 378 implementations. Applications may consider existing blocks as data 379 objects, or they may adjust block sizes before storing in the DECADE- 380 compatible server. 382 Immutable data objects can still be deleted. Applications may 383 support modification of existing data stored at a DECADE-compatible 384 server through a combination of storing new data objects and deleting 385 existing data objects. For example, a meta-data management function 386 of the control plane might associate a name with a sequence of 387 immutable blocks. If one of the blocks is modified, the meta-data 388 management function changes the mapping of the name to a new sequence 389 of immutable blocks. 391 Throughout this document, all data objects/blocks are assumed to be 392 immutable. 394 4.3. Data Objects With Identifiers 396 An object that is stored in a DECADE-compatible storage server SHOULD 397 be accessed by Content Consumers via a data object identifier. 399 A Content Consumer may be able to access more than one storage 400 server. A data object that is replicated across different storage 401 servers managed by a DECADE-compatible Storage Provider MAY still be 402 accessed by a single identifier. 404 Since data objects are immutable, it SHALL be possible to support 405 persistent identifiers for data objects. 407 Data object identifiers for data objects SHOULD be created by Content 408 Providers that upload the objects to servers. 410 4.4. Data Object Naming Scheme 412 The DECADE architecture is based on data object identifiers as 413 described above, and the assignment/derivation of the data object 414 identifier to a data object depends on the data object naming scheme. 415 The details of data naming schemes will be provided by future DECADE- 416 compatible protocol/naming specifications. This document describes 417 naming schemes on a semantic level and specific SDTs and DRPs SHOULD 418 use specific representations. 420 In particular, for some applications it is important that clients and 421 servers SHOULD be able to validate the name-object binding for a data 422 object, i.e., by verifying that a received object really corresponds 423 to the name (identifier) that was used for requesting it (or that was 424 provided by a sender). Data object identifiers can support name- 425 object binding validation by providing message digests or so-called 426 self-certifying naming information -- if a specific application has 427 this requirement. 429 A DECADE-compatible naming scheme follows the following general 430 requirements: 432 o Different name-object binding validation mechanisms MAY be 433 supported; 435 o Content Distribution Applications will decide what mechanism to 436 use, or to not provide name-object validation (e.g., if 437 authenticity and integrity can by ascertained by alternative 438 means); 440 o Applications MAY be able to construct unique names (with high 441 probability) without requiring a registry or other forms of 442 coordination; and 444 o Names MAY be self-describing so that a receiving entity (Content 445 Consumer) knows what hash function (for example) to use for 446 validating name-object binding. 448 Some Content Distribution Applications will derive the name of a data 449 object from the hash over the data object, which is made possible by 450 the fact that DECADE-compatible objects are immutable. But there 451 maybe other applications such as live streaming where object/chunk 452 names will not based on hashes but rather on an enumeration scheme. 453 The naming scheme will also enable those applications to construct 454 unique names. 456 In order to enable the uniqueness, flexibility and self-describing 457 properties, the naming scheme SHOULD provide the following name 458 elements: 460 o A "type" field that indicates the name-object validation function 461 type (for example, "sha-256"); 463 o Cryptographic data (such as an object hash) that corresponds to 464 the type information; and 466 The naming scheme MAY additionally provide the following name 467 elements: 469 o Application or publisher information. 471 The specific format of the name (e.g., encoding, hash algorithms, 472 etc) is out of scope of this document, and is left for protocol 473 specification. 475 The DECADE-compatible naming scheme SHOULD be used in scenarios where 476 a client knows the name of a data object before it is completely 477 stored at the server. This allows for particular optimizations, such 478 as advertising data object while the data object is being stored, 479 removing store-and-forward delays. For example, a client A might 480 simultaneously begin storing an object to a server, and advertise 481 that the object is available to client B. If it is supported by the 482 server, client B might begin downloading the object before A is 483 finished storing the object. 485 If object names are not based on hashes of the data objects 486 themselves, names can also be used in scenarios where a client knows 487 the name of a data object before it is locally created. 489 4.5. Explicit Control 491 To support the functions of an application's control plane, 492 applications SHOULD be able to know and coordinate which data is 493 stored at particular servers. Thus, in contrast with traditional 494 caches, applications are given explicit control over the placement 495 (selection of a DECADE-compatible server), deletion (or expiration 496 policy), and access control for stored data. 498 Consider deletion/expiration policy as a simple example. An 499 application might require that a server store data objects for a 500 relatively short period of time (e.g., for live-streaming data). 501 Another application might need to store data objects for a longer 502 duration (e.g., for video-on-demand). 504 4.6. Resource and Data Access Control 506 A DECADE-compatible system will provide a shared infrastructure to be 507 used by multiple Content Consumers and Content Providers spanning 508 multiple Content Distribution Applications. Thus, it needs to 509 provide both resource and data access control. 511 4.6.1. Resource Allocation 513 There are two primary interacting entities in a DECADE-compatible 514 system. First, Storage Providers SHOULD coordinate where storage 515 servers are provisioned and their total available resources. Second, 516 Applications will coordinate data transfers amongst available servers 517 and between servers and clients. A form of isolation is required to 518 enable concurrently-running Applications to each explicitly manage 519 its own data objects and share of resources at the available servers. 521 The Storage Provider SHOULD delegate the management of the resources 522 on a server to DECADE Content Providers. This means that Content 523 Providers are able to explicitly and independently manage their own 524 shares of resources on a server. 526 4.6.2. User Delegations 528 Storage Providers will have the ability to explicitly manage the 529 entities allowed to utilize the resources at a DECADE-compatible 530 server. This capability is needed for reasons such as capacity- 531 planning and legal considerations in certain deployment scenarios. 533 The server SHOULD grant a share of the resources to a Content 534 Provider or Content Consumer. The client can in turn share the 535 granted resources amongst its multiple applications. The share of 536 resources granted by a server is called a User Delegation. 538 As a simple example, a DECADE-compatible server operated by an ISP 539 might be configured to grant each ISP Subscriber 1.5 Mbit/s of 540 bandwidth. The ISP Subscriber might in turn divide this share of 541 resources amongst a video streaming application and file-sharing 542 application which are running concurrently. 544 5. System Components 546 The primary focus of this document is the architectural principles 547 and the system components that implement them. While certain system 548 components might differ amongst implementations, the document details 549 the major components and their overall roles in the architecture. 551 To keep the scope narrow, we only discuss the primary components 552 related to protocol development. Particular deployments will require 553 additional components (e.g., monitoring and accounting at a server), 554 but they are intentionally omitted from this document. 556 5.1. Content Distribution Application 558 Content Distribution Applications have many functional components. 559 For example, many P2P applications have components and algorithms to 560 manage overlay topology management, rate allocation, piece selection, 561 etc. In this document, we focus on the components directly employed 562 to support a DECADE-compatible system. 564 Figure 3 illustrates the components discussed in this section from 565 the perspective of a single Application End-Point. 567 Native Protocol(s) 568 (with other Application End-Points) 569 .---------------------> 570 | 571 | 572 .----------------------------------------------------------. 573 | Application End-Point | 574 | .------------. .-------------------. | 575 | | App-Layer | ... | App Data Assembly | | 576 | | Algorithms | | Sequencing | | 577 | `------------' `-------------------' | 578 | | 579 | .------------------------------------------------------. | 580 | | DECADE Client | | 581 | | | | 582 | | .-------------------------. .----------------------. | | 583 | | | Resource Controller | | Data Controller | | | 584 | | | .--------. .----------. | | .--------. .-------. | | | 585 | | | | Data | | Resource | | | | Data | | Data | | | | 586 | | | | Access | | Sharing | | | | Sched. | | Index | | | | 587 | | | | Policy | | Policy | | | | | | | | | | 588 | | | '--------' `----------' | | `--------' `-------' | | | 589 | | `-------------------------' `----------------------' | | 590 | | | ^ | | 591 | `------------ | ----------------- | -------------------' | 592 `-------------- | ----------------- | ---------------------' 593 | | 594 | DECADE | Standard 595 | Resource | Data 596 | Protocol | Transfer 597 | (DRP) | (SDT) 598 v V 600 Figure 3: Application Components 602 5.1.1. Data Assembly 604 A DECADE-compatible system is geared towards supporting applications 605 that can divide distributed content into data objects. To accomplish 606 this, applications can include a component responsible for creating 607 the individual data objects before distribution and then re- 608 assembling data objects at the Content Consumer. We call this 609 component the Application Data Assembly. 611 In producing and assembling the data objects, two important 612 considerations are sequencing and naming. A DECADE-compatible system 613 assumes that applications implement this functionality themselves. 614 See Section 5.3 for further discussion. 616 5.1.2. Native Application Protocols 618 In addition to the DECADE-compatible DRP/SDT, applications will also 619 support their existing native application protocols (e.g., P2P 620 control and data transfer protocols). 622 5.1.3. DECADE Client 624 An application needs to be modified to support a DECADE-compatible 625 system. The client provides the local support to an application, and 626 can standalone, embedded into the application, or integrated in other 627 entities such as network devices themselves. 629 5.1.3.1. Resource Controller 631 Applications may have different Resource Sharing Policies and Data 632 Access Policies to control their resource and data in DECADE- 633 compatible servers. These policies may be existing policies of 634 applications or custom policies. The specific implementation is 635 decided by the application. 637 5.1.3.2. Data Controller 639 A DECADE-compatible system decouples the control and the data 640 transfer of applications. A Data Scheduling component schedules data 641 transfers according to network conditions, available servers, and/or 642 available server resources. The Data Index indicates data available 643 at remote servers. The Data Index (or a subset of it) can be 644 advertised to other clients. A common use case for this is to 645 provide the ability to locate data amongst distributed Application 646 End-Points (i.e., a data search mechanism such as a Distributed Hash 647 Table). 649 5.2. Server 651 Figure 4 illustrates the components discussed in a DECADE-compatible 652 server. A server is not necessarily a single physical machine, it 653 can also be implemented as a cluster of machines. 655 | | 656 | DECADE | Standard 657 | Resource | Data 658 | Protocol | Transfer 659 | (DRP) | (SDT) 660 | | 661 .= | ================= | ======================. 662 | | v | 663 | | .----------------. | 664 | |----> | Access Control | <--------. | 665 | | `----------------' | | 666 | | ^ | | 667 | | | | | 668 | | v | | 669 | | .---------------------. | | 670 | `-> | Resource Scheduling | <------| | 671 | `---------------------' | | 672 | ^ | | 673 | | | | 674 | v .------------. | 675 | .-----------------. | User | | 676 | | Data Store | | Delegation | | 677 | `-----------------' | Management | | 678 | DECADE Server `------------' | 679 `==============================================' 681 Figure 4: DECADE Server Components 683 5.2.1. Access Control 685 A client SHALL be able to access its own data or other client's data 686 (provided sufficient authorization) in DECADE-compatible servers. 687 Clients MAY also authorize other Clients to store data. If an access 688 is authorized by a Client, the server SHOULD provide access. Even if 689 a request is authorized, it MAY still fail to complete due to 690 insufficient resources at the server. 692 5.2.2. Resource Scheduling 694 Applications will apply resource sharing policies or use a custom 695 policy. Servers perform resource scheduling according to the 696 resource sharing policies indicated by Clients as well as configured 697 User Delegations. 699 5.2.3. Data Store 701 Data from applications will be stored at a DECADE-compatible server. 702 Data SHOULD be deleted from storage either explicitly or 703 automatically (e.g., after a TTL expiration). It SHOULD be possible 704 to perform optimizations in certain cases, such as avoiding writing 705 temporary data (e.g., live streaming) to persistent storage, if 706 appropriate storage hints are supported by the SDT. 708 5.3. Data Sequencing and Naming 710 In order to provide a simple and generic interface, the DECADE- 711 compatible server will only be responsible for storing and retrieving 712 individual data objects. Furthermore, a DECADE-compatible system 713 will use its own naming scheme that provides uniqueness (with high 714 probability) between data objects, even across multiple applications. 716 5.3.1. Data Object Naming Scheme 718 Details of the naming scheme are discussed in Section 4.4. 720 5.3.2. Application Usage 722 Recall from Section 5.1.1 that an Application typically includes its 723 own naming and sequencing scheme. The DECADE-compatible naming 724 format SHOULD NOT attempt to replace any naming or sequencing of data 725 objects already performed by an Application; instead, the naming is 726 intended to apply only to data objects referenced by DECADE-specific 727 purposes. 729 An Application using a DECADE-compatible client may use a naming and 730 sequencing scheme independent of DECADE-compatible names. The 731 DECADE-compatible client SHOULD maintain a mapping from its own data 732 objects and their names to the DECADE-specific data objects and 733 names. 735 5.3.3. Application Usage Example 737 To illustrate these properties, this section presents multiple 738 examples. 740 5.3.3.1. Application with Fixed-Size Chunks 742 Similar to the example in Section 5.1.1, consider an Application in 743 which each individual application-layer segment of data is called a 744 "chunk" and has a name of the form: "CONTENT_ID:SEQUENCE_NUMBER". 745 Furthermore, assume that the application's native protocol uses 746 chunks of size 16 KiloByte (KB). 748 Now, assume that this application wishes to store data in DECADE- 749 compatible servers in data objects of size 64 KB. To accomplish 750 this, it can map a sequence of 4 chunks into a single object, as 751 shown in Figure 5. 753 Application Chunks 754 .---------.---------.---------.---------.---------.---------.-------- 755 | | | | | | | 756 | Chunk_0 | Chunk_1 | Chunk_2 | Chunk_3 | Chunk_4 | Chunk_5 | Chunk_6 757 | | | | | | | 758 `---------`---------`---------`---------`---------`---------`-------- 760 DECADE Data Objects 761 .---------------------------------------.---------------------------- 762 | | 763 | Object_0 | Object_1 764 | | 765 `---------------------------------------`---------------------------- 767 Figure 5: Mapping Application Chunks to DECADE Data Objects 769 In this example, the Application might maintain a logical mapping 770 that is able to determine the name of a DECADE-compatible data object 771 given the chunks contained within that data object. The name might 772 be learned from either the original source, another End-Point with 773 which the Application is communicating, a tracker, etc. 775 As long as the data contained within each sequence of chunks is 776 globally unique, the corresponding data objects have globally unique 777 names. This is desired, and happens automatically if particular 778 Application segments the same stream of data in a different way, 779 including different chunk sizes or different padding schemes. 781 5.3.3.2. Application with Continuous Streaming Data 783 Consider an Application whose native protocol retrieves a continuous 784 data stream (e.g., an MPEG2 stream) instead of downloading and 785 redistributing chunks of data. Such an application could segment the 786 continuous data stream to produce either fixed-sized or variable- 787 sized data objects. 789 Figure 6 shows how a video streaming application might produce 790 variable-sized data objects such that each data object contains 10 791 seconds of video data. 793 Application's Video Stream 794 .-------------------------------------------------------------------- 795 | 796 | 797 | 798 `-------------------------------------------------------------------- 799 ^ ^ ^ ^ ^ 800 | | | | | 801 0 Seconds 10 Seconds 20 Seconds 30 Seconds 40 Seconds 802 0 B 400 KB 900 KB 1200 KB 1500 KB 804 DECADE Data Objects 805 .--------------.--------------.--------------.--------------.-------- 806 | | | | | 807 | Object_0 | Object_1 | Object_2 | Object_3 | 808 | (400 KB) | (500 KB) | (300 KB) | (300 KB) | 809 `--------------`--------------`--------------`--------------`-------- 811 Figure 6: Mapping a Continuous Data Stream to DECADE Data Objects 813 Similar to the previous example, the Application might maintain a 814 mapping that is able to determine the name of a data object given the 815 time offset of the video chunk. 817 5.4. Token-based Authentication and Resource Control 819 A key feature of a DECADE-compatible system is that a client can 820 authorize other Clients to store or retrieve data objects from the 821 in-network storage. A token-based authentication scheme is used to 822 accomplish this. 824 Specifically, an entity trusted by a client generates a signed token 825 with particular properties (see Section 6.1.2 for details). The 826 client then distributes this token to other Clients which then use 827 the token when sending requests to the DECADE-compatible server. 828 Upon receiving a token, the server validates the signature and the 829 operation being performed (e.g. PUT, GET). 831 This is a simple scheme, but has some important advantages over an 832 alternate approach in which a client explicitly manipulates an Access 833 Control List (ACL) associated with each data object. In particular, 834 it has the following advantages when applied to DECADE-compatible 835 target applications: 837 o Authorization policies are implemented within the Application; an 838 Application explicitly controls when tokens are generated and to 839 whom they are distributed. 841 o Fine-grained access and resource control can be applied to data 842 objects; see Section 6.1.2 for the list of restrictions that can 843 be enforced with a token. 845 o There is no messaging between a client and server to manipulate 846 data object permissions. This can simplify, in particular, 847 Applications which share data objects with many dynamic peers and 848 need to frequently adjust access control policies attached to data 849 objects. 851 o Tokens can provide anonymous access, in which a server does not 852 need to know the identity of each client that accesses it. This 853 enables a client to send tokens to clients in other administrative 854 or security domains, and allow them to read or write data objects 855 from its storage. 857 In addition to clients applying access control policies to data 858 objects, the server MAY be configured to apply additional policies 859 based on user, object, geographic location, etc. A client might thus 860 be denied access even though it possess a valid token. 862 Existing protocols (e.g., OAuth [RFC5849]) implement similar referral 863 mechanisms using tokens. A protocol specification of this 864 architecture SHOULD endeavor to use existing mechanisms wherever 865 possible. 867 5.5. Discovery 869 A DECADE-compatible system SHOULD include a discovery mechanism 870 through which clients locate an appropriate server. 871 [I-D.ietf-decade-reqs] details specific requirements of the discovery 872 mechanism; this section discusses how they relate to other principles 873 outlined in this document. 875 A discovery mechanism SHOULD allow a client to determine an IP 876 address or some other identifier that can be resolved to locate the 877 server for which the client will be authorized to generate tokens 878 (via DRP). (The discovery mechanism might also result in an error if 879 no such servers can be located.) After discovering one or more 880 servers, a client can distribute load and requests across them 881 (subject to resource limitations and policies of the servers 882 themselves) according to the policies of the Application End-Point in 883 which it is embedded. 885 The particular protocol used for discovery is out of scope of this 886 document, but any specification SHOULD re-use standard protocols 887 wherever possible. 889 The discovery mechanism outlined here does not provide the ability to 890 locate arbitrary DECADE-compatible servers to which a client might 891 obtain tokens from others. To do so requires application-level 892 knowledge, and it is assumed that this functionality is implemented 893 in the Content Distribution Application. 895 6. DECADE Protocols 897 This section presents the DRP and the SDT protocol in terms of 898 abstract protocol interactions that are intended to be mapped to 899 specific protocols. In general, the DRP/SDT functionality between a 900 DECADE-compatible client-server are very similar to the DRP/SDT 901 functionality between running between server-server. Any differences 902 are highlighted below. 904 The DRP will be the protocol used by a DECADE-compatible client to 905 configure the resources and authorization used to satisfy requests 906 (reading, writing, and management operations concerning objects) at a 907 server. The SDT will be used to send the data to the server. 909 6.1. DECADE Resource Protocol (DRP) 911 DRP will provide configuration of access control and resource sharing 912 policies on DECADE-compatible servers. A Content Distribution 913 Application, e.g., a live P2P streaming session, can have permission 914 to manage data at several servers, for instance, servers in different 915 operator domains, and DRP allows one instance of such an application, 916 e.g., an Application End-Point, to apply access control and resource 917 sharing policies on each of them. 919 6.1.1. Controlled Resources 921 On a single DECADE-compatible server, the following resources SHOULD 922 be managed: 924 o Communication resources in terms of bandwidth (upload/download) 925 and also in terms of number of connected clients (connections) at 926 a time. 928 o Storage resources. 930 6.1.2. Access and Resource Control Token 932 A token SHOULD include the following information: 934 o Permitted operations (e.g., read, write) 936 o Permitted objects (e.g., names of data objects that might be read 937 or written) 939 o Expiration time 941 o Priority for bandwidth given to requested operation (e.g., a 942 weight used in a weighted bandwidth sharing scheme) 944 o Amount of data that might be read or written 946 The tokens SHOULD be generated by an entity trusted by both the 947 DECADE-compatible client and server at the request of a DECADE- 948 compatible client. For example this entity could be the client, a 949 server trusted by the client, or another server managed by a Storage 950 Provider trusted by the client. It is important for a server to 951 trust the entity generating the tokens since each token may incur a 952 resource cost on the server when used. Likewise, it is important for 953 a client to trust the entity generating the tokens since the tokens 954 grant access to the data stored at the server. 956 Upon generating a token, a client MAY distribute it to another client 957 (e.g., via their native application protocol). The receiving client 958 MAY then connect to the sending client's server and perform any 959 operation permitted by the token. The token SHOULD be sent along 960 with the operation. The server SHOULD validate the token to identify 961 the client that issued it and whether the requested operation is 962 permitted by the contents of the token. If the token is successfully 963 validated, the server SHOULD apply the resource control policies 964 indicated in the token while performing the operation. 966 Tokens SHOULD include a unique identifier to allow a server to detect 967 when a token is used multiple times and reject the additional usage 968 attempts. Since usage of a token incurs resource costs to a server 969 (e.g., bandwidth and storage) and a Content Provider may have a 970 limited budget (see Section 4.6), the a Content Provider should be 971 able to indicate if a token may be used multiple times. 973 It SHOULD be possible for DRP to allow tokens to apply to a batch of 974 operations to reduce communication overhead required between clients. 975 A request sent in this way explicitly denotes the objects to which it 976 applies. 978 It SHOULD be possible to revoke tokens after they are generated. 979 This could be accomplished by supplying the server the unique 980 identifiers of the tokens which are to be revoked. 982 6.1.3. Status Information 984 DRP SHOULD provide a request service for status information that 985 clients can use to request information from a server. 987 Status information on a specific server: Access to such status 988 information SHOULD require client authorization, i.e., clients 989 need to be authorized to access the requested status information. 990 This authorization is based on the user delegation concept as 991 described in Section 4.6. The following status information 992 elements SHOULD be obtained: 994 * List of associated objects (with properties) 996 * Resources used/available 998 The following information elements MAY additionally be available: 1000 * List of servers to which objects have been distributed (in a 1001 certain time-frame) 1003 * List of clients to which objects have been distributed (in a 1004 certain time-frame) 1006 For the list of servers/clients to which objects have been 1007 distributed to, the server SHOULD be able to decide on time bounds 1008 for which this information is stored and specify the corresponding 1009 time frame in the response to such requests. Some of this 1010 information may be used for accounting purposes, e.g., the list of 1011 clients to which objects have been distributed. 1013 Access information on a specific server: Access information MAY be 1014 provided for accounting purposes, for example, when Content 1015 Providers are interested in access statistics for resources and/or 1016 to perform accounting per user. Again, access to such information 1017 requires client authorization SHOULD based on the delegation 1018 concept as described in Section 4.6. The following type of access 1019 information elements MAY be requested: 1021 * What objects have been accessed how many times 1023 * Access tokens that a server as seen for a given object 1025 The server SHOULD decide on time bounds for which this information 1026 is stored and specify the corresponding time frame in the response 1027 to such requests. 1029 6.1.4. Object Attributes 1031 Objects that are stored on a DECADE-compatible server SHOULD have 1032 associated attributes (in addition to the object identifier and data 1033 object) that relate to the data storage and its management. These 1034 attributes may be used by the server (and possibly the underlying 1035 storage system) to perform specialized processing or handling for the 1036 data object, or to attach related server or storage-layer properties 1037 to the data object. These attributes have a scope local to a server. 1038 In particular, these attributes SHOULD NOT be applied to a server or 1039 client to which a data object is copied. 1041 Depending on authorization, clients SHOULD be permitted to get or set 1042 such attributes. This authorization is based on the delegation 1043 concept as described in Section 4.6. The architecture does not limit 1044 the set of permissible attributes, but rather specifies a set of 1045 baseline attributes that SHOULD be supported: 1047 Expiration Time: Time at which the object might be deleted 1049 Object size: In bytes 1051 Media type Labelling of type as per [RFC4288] 1053 Access statistics: How often the object has been accessed (and what 1054 tokens have been used) 1056 The Object Attributes defined here are distinct from application 1057 metadata (see Section 4.1). Application metadata is custom 1058 information that an application might wish to associate with a data 1059 object to understand its semantic meaning (e.g., whether it is video 1060 and/or audio, its playback length in time, or its index in a stream). 1061 If an application wishes to store such metadata persistently, it can 1062 be stored within data objects themselves. 1064 6.2. Standard Data Transfer (SDT) Protocol 1066 A DECADE-compatible server will provide a data access interface, and 1067 the SDT will be used to write objects to a server and to read 1068 (download) objects from a server. Semantically, SDT is a client- 1069 server protocol, i.e., the server always responds to client requests. 1071 6.2.1. Writing/Uploading Objects 1073 To write an object, a client first generates the object's name (see 1074 Section 5.3), and then uploads the object to a server and supplies 1075 the generated name. The name can be used to access (download) the 1076 object later, e.g., the client can pass the name as a reference to 1077 other client that can then refer to the object. 1079 Objects can be self-contained objects such as multimedia resources, 1080 files etc., but also chunks, such as chunks of a P2P distribution 1081 protocol that can be part of a containing object or a stream. 1083 If supported, a server can accept download requests for an object 1084 that is still being uploaded. 1086 The application that originates the objects generates DECADE- 1087 compatible object names according to the naming specification in 1088 Section 5.3. Clients (as parts of application entities) upload a 1089 named object to a server. If supported, a server can verify the 1090 integrity and other security properties of uploaded objects. 1092 6.2.2. Downloading Objects 1094 A client can request named objects from a server. In a corresponding 1095 request message, a client specifies the object name and a suitable 1096 access and resource control token. The server checks the validity of 1097 the received token and its associated resource usage-related 1098 properties. 1100 If the named object exists on the server and then token has been 1101 validated, the server delivers the requested object in a response 1102 message. 1104 If the object cannot be delivered the server provides an 1105 corresponding status/reason information in a response message. 1107 Specifics regarding error handling, including additional error 1108 conditions (e.g. overload), precedence for returned errors and its 1109 relation with server policy, are deferred to eventual protocol 1110 specification. 1112 6.3. Server-to-Server Protocols 1114 An important feature of a DECADE-compatible system is the capability 1115 for one server to directly download objects from another server. 1116 This capability allows Applications to directly replicate data 1117 objects between servers without requiring end-hosts to use uplink 1118 capacity to upload data objects to a different server. 1120 DRP and SDT will support operations directly between servers. 1121 Servers are not assumed to trust each other nor are configured to do 1122 so. All data operations are performed on behalf of clients via 1123 explicit instruction. However, the objects being processed do not 1124 necessarily have to originate or terminate at the client (i.e. the 1125 object might be limited to being exchanged between servers even if 1126 the instruction is triggered by the client). Clients thus will be 1127 able to indicate to a server the following additional parameters: 1129 o Which remote server(s) to access; 1131 o The operation to be performed (e.g. PUT, GET); and 1133 o The Content Provider at the remote server from which to retrieve 1134 the object (for a GET), or in which the object is to be stored 1135 (for a PUT). 1137 o Credentials indicating permission to perform the operation at the 1138 remote server. 1140 Server-to-server support is focused on reading and writing data 1141 objects between servers. The data object referred to at the remote 1142 server is the same as the original request. Object attributes (see 1143 Section 6.1.4) might also be specified in the request to the remote 1144 server. 1146 In this way, a server acts as a proxy for a client, and a client can 1147 instantiate requests via that proxy. The operations will be 1148 performed as if the original requester had its own client co-located 1149 with the server. It is this mode of operation that provides 1150 substantial savings in uplink capacity. This mode of operation can 1151 also be triggered by an administrative/management application outside 1152 the architecture. 1154 When a client sends a request to a server with these additional 1155 parameters, it is giving the server permission to act (proxy) on its 1156 behalf. Thus, it would be prudent for the supplied token to have 1157 narrow privileges (e.g., limited to only the necessary data objects) 1158 or validity time (e.g., a small expiration time). 1160 In the case of a GET operation, the server is to retrieve the data 1161 object from the remote server using the specified credentials (via a 1162 GET request to the remote server), and then optionally return the 1163 object to a client. In the case of a PUT operation, the server is to 1164 store the object to the remote server using the specified credentials 1165 (via a PUT request to the remote server). The object might 1166 optionally be uploaded from the client or might already exist at the 1167 proxy server. 1169 7. Security Considerations 1171 In general, the security considerations mentioned in 1172 [I-D.ietf-decade-problem-statement] apply to this document as well. 1174 A DECADE-compatible system provides a distributed storage service for 1175 content distribution and similar applications. The system consists 1176 of servers and clients that use these servers to upload data objects, 1177 to request distribution of data objects, and to download data 1178 objects. Such a system is employed in an overall application context 1179 -- for example in a P2P Content Distribution Application, and it is 1180 expected that DECADE-compatible clients take part in application- 1181 specific communication sessions. 1183 The security considerations here focus on threats related to the 1184 DECADE-compatible system and its communication services, i.e., the 1185 DRP/SDT protocols that have been described in an abstract fashion in 1186 this document. 1188 7.1. Threat: System Denial of Service Attacks 1190 A DECADE-compatible network of servers might be used to distribute 1191 data objects from one client to a set of servers using the server-to- 1192 server communication feature that a client can request when uploading 1193 an object. Multiple clients uploading many objects at different 1194 servers at the same time and requesting server-to-server distribution 1195 for them could thus mount massive distributed denial of service 1196 (DDOS) attacks, overloading a network of servers. 1198 This threat is addressed by its access control and resource control 1199 framework. Servers can require Application End-Points to be 1200 authorized to store and to download objects, and Application End- 1201 Points can delegate authorization to other Application End-Points 1202 using the token mechanism. 1204 Of course the effective security of this approach depends on the 1205 strength of the token mechanism. See below for a discussion of this 1206 and related communication security threats. 1208 Denial of Service Attacks against a single server (directing many 1209 requests to that server) might still lead to considerable load for 1210 processing requests and invalidating tokens. A SDT therefore MUST 1211 provide a redirection mechanism as described as a requirement in 1212 [I-D.ietf-decade-reqs]. 1214 7.2. Threat: Protocol Security 1216 7.2.1. Threat: Authorization Mechanisms Compromised 1218 A DECADE-compatible system does not require Application End-Points to 1219 authenticate in order to access a server for downloading objects, 1220 since authorization is not based on End-Point or user identities but 1221 on the delegation-based authorization mechanism. Hence, most 1222 protocol security threats are related to the authorization scheme. 1224 The security of the token mechanism depends on the strength of the 1225 token mechanism and on the secrecy of the tokens. A token can 1226 represent authorization to store a certain amount of data, to 1227 download certain objects, to download a certain amount of data per 1228 time etc. If it is possible for an attacker to guess, construct or 1229 simply obtain tokens, the integrity of the data maintained by the 1230 servers is compromised. 1232 This is a general security threat that applies to authorization 1233 delegation schemes. Specifications of existing delegation schemes 1234 such as OAuth [RFC5849] discuss these general threats in detail. We 1235 can say that the DRP has to specify appropriate algorithms for token 1236 generation. Moreover, authorization tokens should have a limited 1237 validity period that should be specified by the application. Token 1238 confidentiality should be provided by application protocols that 1239 carry tokens, and the SDT and DRP should provide secure 1240 (confidential) communication modes. 1242 7.2.2. Threat: Object Spoofing 1244 In a DECADE-compatible system, an Application End-Point is referring 1245 other Application End-Points to servers to download a specified data 1246 objects. An attacker could "inject" a faked version of the object 1247 into this process, so that the downloading End-Point effectively 1248 receives a different object (compared to what the uploading End-Point 1249 provided). As result, the downloading End-Point believes that is has 1250 received an object that corresponds to the name it was provided 1251 earlier, whereas in fact it is a faked object. Corresponding attacks 1252 could be mounted against the application protocol (that is used for 1253 referring other End-Points to servers), servers themselves (and their 1254 storage sub-systems), and the SDT by which the object is uploaded, 1255 distributed and downloaded. 1257 A DECADE-compatible systems fundamental mechanism against object 1258 spoofing is name-object binding validation, i.e., the ability of a 1259 receiver to check whether the name he was provided and that he used 1260 to request an object, actually corresponds to the bits he received. 1261 As described above, this allows for different forms of name-object 1262 binding, for example using hashes of data objects, with different 1263 hash functions (different algorithms, different digest lengths). For 1264 those application scenarios where hashes of data objects are not 1265 applicable (for example live-streaming) other forms of name-object 1266 binding can be used (see Section 5.3). This flexibility also 1267 addresses cryptographic algorithm evolvability: hash functions might 1268 get deprecated, better alternatives might be invented etc., so that 1269 applications can choose appropriate mechanisms meeting their security 1270 requirements. 1272 DECADE-compatible servers MAY perform name-object binding validation 1273 on stored objects, but Application End-Points MUST NOT rely on that. 1274 In other forms: Application End-Points SHOULD perform name-object 1275 binding validation on received objects. 1277 8. IANA Considerations 1279 This document does not have any IANA considerations. 1281 9. Acknowledgments 1283 We thank the following people for their contributions to this 1284 document: 1286 David Bryan 1288 Hongqiang (Harry) Liu 1290 Yingjie Gu 1292 David McDysan 1294 Borje Ohlman 1296 Haibin Song 1298 Martin Stiemerling 1300 Richard Woundy 1302 Ning Zong 1304 10. References 1305 10.1. Normative References 1307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1308 Requirement Levels", BCP 14, RFC 2119, March 1997. 1310 10.2. Informative References 1312 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1313 Registration Procedures", BCP 13, RFC 4288, December 2005. 1315 [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File 1316 System (NFS) Version 4 Minor Version 1 Protocol", 1317 RFC 5661, January 2010. 1319 [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, 1320 April 2010. 1322 [RFC6392] Alimi, R., Rahman, A., and Y. Yang, "A Survey of In- 1323 Network Storage Systems", RFC 6392, October 2011. 1325 [I-D.ietf-decade-problem-statement] 1326 Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled 1327 Application Data Enroute (DECADE) Problem Statement", 1328 draft-ietf-decade-problem-statement-06 (work in progress), 1329 May 2012. 1331 [I-D.ietf-decade-reqs] 1332 Yingjie, G., Bryan, D., Yang, Y., and R. Alimi, "DECADE 1333 Requirements", draft-ietf-decade-reqs-06 (work in 1334 progress), March 2012. 1336 [OpenFlow] 1337 "OpenFlow Organization", . 1339 [GoogleFileSystem] 1340 Ghemawat, S., Gobioff, H., and S. Leung, "The Google File 1341 System", SOSP 2003, October 2003. 1343 Appendix A. In-Network Storage Components Mapped to DECADE Architecture 1345 In this section we evaluate how the basic components of an in-network 1346 storage system identified in Section 3 of [RFC6392] map into a 1347 DECADE-compatible system. 1349 A.1. Data Access Interface 1351 Clients can read and write objects of arbitrary size through the 1352 client's Data Controller, making use of a SDT. 1354 A.2. Data Management Operations 1356 Clients can move or delete previously stored objects via the client's 1357 Data Controller, making use of a SDT. 1359 A.3. Data Search Capability 1361 Clients can enumerate or search contents of servers to find objects 1362 matching desired criteria through services provided by the Content 1363 Distribution Application (e.g., buffer-map exchanges, a DHT, or peer- 1364 exchange). In doing so, Application End-Points might consult their 1365 local Data Index in the client's Data Controller. 1367 A.4. Access Control Authorization 1369 All methods of access control are supported: public-unrestricted, 1370 public-restricted and private. Access Control Policies are generated 1371 by a Content Distribution Application and provided to the client's 1372 Resource Controller. The server is responsible for implementing the 1373 access control checks. 1375 A.5. Resource Control Interface 1377 Clients can manage the resources (e.g. bandwidth) on the DECADE 1378 server that can be used by other Application End-Points. Resource 1379 Sharing Policies are generated by a Content Distribution Application 1380 and provided to the client's Resource Controller. The server is 1381 responsible for implementing the resource sharing policies. 1383 A.6. Discovery Mechanism 1385 The particular protocol used for discovery is outside the scope of 1386 this document. However, options and considerations have been 1387 discussed in Section 5.5. 1389 A.7. Storage Mode 1391 Servers provide an object-based storage mode. Immutable data objects 1392 might be stored at a server. Applications might consider existing 1393 blocks as data objects, or they might adjust block sizes before 1394 storing in a server. 1396 Authors' Addresses 1398 Richard Alimi 1399 Google 1401 Email: ralimi@google.com 1403 Akbar Rahman 1404 InterDigital Communications, LLC 1406 Email: akbar.rahman@interdigital.com 1408 Dirk Kutscher 1409 NEC 1411 Email: dirk.kutscher@neclab.eu 1413 Y. Richard Yang 1414 Yale University 1416 Email: yry@cs.yale.edu