idnits 2.17.1 draft-dannewitz-ppsp-secure-naming-02.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 : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 14, 2011) is 4791 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission C. Dannewitz 3 Internet-Draft University of Paderborn 4 Intended status: Informational T. Rautio 5 Expires: September 15, 2011 VTT Technical Research Centre of 6 Finland 7 O. Strandberg 8 Nokia Siemens Networks 9 B. Ohlman 10 Ericsson 11 March 14, 2011 13 Secure naming structure and p2p application interaction 14 draft-dannewitz-ppsp-secure-naming-02 16 Abstract 18 Today, each application typically uses its own way to identify data. 19 The lack of a common naming scheme prevents applications from 20 benefiting from available copies of the same data distributed via 21 different P2P and CDN systems. The main proposal presented in this 22 draft is idea that there should be a secure and application 23 independent way of naming information objects that are transported 24 over the Internet. The draft defines a set of requirements for such 25 a naming structure. It also presents a proposal for such a naming 26 structure that could relevant for a number of work groups (existing 27 and potential), e.g. PPSP, DECADE and CDNI. In addition, today's 28 P2P naming schemes lack important security aspects that would allow 29 the user to check the data integrity and build trust in data and data 30 publishers. This is especially important in P2P applications as data 31 is received from untrusted peers. Providing a generic naming scheme 32 for P2P systems so that multiple P2P systems can use the same data 33 regardless of data location and P2P system increases the efficiency 34 and data availability of the overall data dissemination process. The 35 secure naming scheme is providing self-certification such that the 36 receiver can verify the data integrity, i.e., that the correct data 37 has been received, without requiring a trusted third party. It also 38 enables owner authentication to build up trust in (potentially 39 anonymous) data publishers. The secure naming structure should be 40 beneficial as potential design principle in defining the two 41 protocols identified as objectives in the PPSP charter. This 42 document enumerates a number of design considerations to impact the 43 design and implementation of the tracker-peer signaling and peer-peer 44 streaming signaling protocols. 46 Requirements Language 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in [RFC2119]. 52 Status of this Memo 54 This Internet-Draft is submitted in full conformance with the 55 provisions of BCP 78 and BCP 79. 57 Internet-Drafts are working documents of the Internet Engineering 58 Task Force (IETF). Note that other groups may also distribute 59 working documents as Internet-Drafts. The list of current Internet- 60 Drafts is at http://datatracker.ietf.org/drafts/current/. 62 Internet-Drafts are draft documents valid for a maximum of six months 63 and may be updated, replaced, or obsoleted by other documents at any 64 time. It is inappropriate to use Internet-Drafts as reference 65 material or to cite them other than as "work in progress." 67 This Internet-Draft will expire on September 15, 2011. 69 Copyright Notice 71 Copyright (c) 2011 IETF Trust and the persons identified as the 72 document authors. All rights reserved. 74 This document is subject to BCP 78 and the IETF Trust's Legal 75 Provisions Relating to IETF Documents 76 (http://trustee.ietf.org/license-info) in effect on the date of 77 publication of this document. Please review these documents 78 carefully, as they describe your rights and restrictions with respect 79 to this document. Code Components extracted from this document must 80 include Simplified BSD License text as described in Section 4.e of 81 the Trust Legal Provisions and are provided without warranty as 82 described in the Simplified BSD License. 84 This document may contain material from IETF Documents or IETF 85 Contributions published or made publicly available before November 86 10, 2008. The person(s) controlling the copyright in some of this 87 material may not have granted the IETF Trust the right to allow 88 modifications of such material outside the IETF Standards Process. 89 Without obtaining an adequate license from the person(s) controlling 90 the copyright in such materials, this document may not be modified 91 outside the IETF Standards Process, and derivative works of it may 92 not be created outside the IETF Standards Process, except to format 93 it for publication as an RFC or to translate it into languages other 94 than English. 96 Table of Contents 98 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 99 2. Naming requirements . . . . . . . . . . . . . . . . . . . . . 5 100 3. Basic Concepts for an Application-independent Naming Scheme . 6 101 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 102 3.2. ID Structure . . . . . . . . . . . . . . . . . . . . . . . 8 103 3.3. Security Metadata Structure . . . . . . . . . . . . . . . 8 104 4. Examples of application use of secure naming structure . . . . 9 105 4.1. Secure naming for P2P applications . . . . . . . . . . . . 9 106 4.2. Secure naming use in DECADE . . . . . . . . . . . . . . . 12 107 4.3. Secure naming for CDNs . . . . . . . . . . . . . . . . . . 13 108 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 13 109 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 110 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 111 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 112 9. Informative References . . . . . . . . . . . . . . . . . . . . 14 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 115 1. Introduction 117 Today's dominating naming schemes in the Internet, i.e., IP addresses 118 and URLs, are rather host-centric with respect to the fact that they 119 are bound to a location. This kind of naming scheme is not optimal 120 for many of the predominant users of todays Internet like P2P and CDN 121 systems as they are based on an information-centric thinking, i.e., 122 putting the information itself in focus. In these system the source 123 of the information is secondary and can constantly change, e.g. new 124 caches or P2P peers becomes available. It also common to retrieve 125 information from more than one source at once. 127 For any type of caching solution (network based or P2P) and network 128 based storage, e.g. DECADE, a common application independent naming 129 scheme is essential to be able to identify cached copies of 130 information/data objects. 132 Many applications, in particular P2P applications, use their own data 133 model and protocol for keeping track of data and locations. This 134 poses a challenge for use of the same information for several 135 applications. A common naming scheme for information objects is 136 important to enable interconnectivity between different application 137 systems, such as P2P and CDN. To be able to build a common P2P 138 infrastructure that can serve a multitude of applications there is a 139 need for a common application independent naming scheme. With such a 140 naming scheme different applications can use and refer to the same 141 information/data objects. 143 It is possible to introduce false data into P2P systems, only 144 detectable when the content is played out in the user application. 145 The false data copies can be identified and sorted out if the P2P 146 system can verify the reference used in the tracker protocol towards 147 data received at the peer. One option to address this can be to 148 secure the naming structure i.e. make the data reference be dependent 149 on the data and related metadata. 151 An additional reason to introduce a common naming scheme for 152 information objects is caching. When data are named in a host- 153 centric way, as is done today, it is not always identify that copies 154 of the same information object are available in multiple hosts. With 155 location independent identifiers for information objects this becomes 156 much easier. 158 This document enumerates and explains the rationale for why a common 159 naming structure for information/data objects should be defined and 160 used by a wide range of applications and network protocols. Examples 161 of WGs (and potential WGs) where we think a new standard for naming 162 of information/data objects should be valuable includes PPS, DECADE 163 and CDNI. For P2P systems the main advantage is probably in the 164 definition of a protocol for signaling and control between trackers 165 and peers (the PPSP "tracker protocol") but also a signaling and 166 control protocol for communication among the peers (the PPSP "peer 167 protocol") might have benefits from a common and secure naming 168 scheme. In DECADE one key feature would be that different 169 applications can easily share the same cache entries. It should also 170 be valuable for cooperative caching, e.g. CDNI. 172 2. Naming requirements 174 In the following, we discuss the requirements that a common naming 175 scheme has to fulfill. 177 To enable efficient, large scale data dissemination that can make use 178 of any available data copy, identifiers (IDs) have to be location- 179 independent. Thereby, identical data can be identified by the same 180 ID independently of its storage location and improved data 181 dissemination can then benefit from all available copies. This 182 should be possible without compromising trust in data regardless of 183 its network source. 185 Security in an information-centric network (including P2P, caching, 186 and network-based solutions) needs to be implemented differently than 187 in host-centric networks. In the latter, most security mechanisms 188 are based on host authentication and then trusting the data that the 189 host delivers. In e.g. a P2P system, host authentication cannot be 190 relied upon, or one of the main advantages of a P2P system, i.e., 191 benefiting from any available copy, is defeated. Host authentication 192 of a random, untrusted host that happens to have a copy does not 193 establish the needed trust. Instead, the security has to be directly 194 attached to the data which can be done via the scheme used to name 195 the data. 197 Therefore, self-certification is a main requirement for the naming 198 scheme. Self-certification ensures the integrity of data and 199 securely binds this data to its ID. More precisely, this property 200 means that any unauthorized change of data with a given ID is 201 detectable without requiring a third party for verification. 202 Beforehand, secure retrieval of IDs (e.g., via search, embedded in a 203 Web page as link, etc.) is required to ensure that the user has the 204 right ID in the first place. Secure ID retrieval can be achieved by 205 using recommendations, past experience, and specialized ID 206 authentication services and mechanisms that are out of the scope of 207 this discussion. 209 Another important requirement is name persistence, not only with 210 respect to storage location changes as discussed above, but also with 211 respect to changes of owner and/or owner's organizational structure, 212 and content changes producing a new version of the information. 213 Information should always be identifiable with the same ID as long as 214 it remains essentially equivalent. Spreading of persistent naming 215 schemes like the Digital Object Identifier (DOI) [Paskin2010] also 216 emphasizes the need for a persistent naming scheme. However, name 217 persistence and self-certification are partly contradictory and 218 achieving both simultaneously for dynamic content is not trivial. 220 From a user's perspective, persistent IDs ensure that links and 221 bookmarks remain valid as long as the respective information exists 222 somewhere in the network, reducing today's problem of "404 - file not 223 found" errors triggered by renamed or moved content. From a content 224 provider's perspective, name persistence simplifies data management 225 as content can, e.g., be moved between folders and different servers 226 as desired. Name persistence with respect to content changes makes 227 it possible to identify different versions of the same information by 228 the same consistent ID. If it is important to differentiate between 229 multiple versions, a dedicated versioning mechanism is required, and 230 version numbers may be included as a special part of the ID. 232 The requirement of building trust in an information-centric system 233 combined with the desire for anonymous publication as well as 234 accountability (at least for some content) can be translated into two 235 related naming requirements. The first is owner authentication, 236 where the owner is recognized as the same entity, which repeatedly 237 acts as the object owner, but may remain anonymous. The second is 238 owner identification, where the owner is also identified by a 239 physically verifiable identifier, such as a personal name. This 240 separation is important to allow for anonymous publication of 241 content, e.g., to support free speech, while at the same time 242 building up trust in a (potentially anonymous) owner. 244 In general, the naming scheme should be able to adapt to future 245 needs. Therefore, the naming scheme should be extensible, i.e., it 246 should be able to add new information (e.g., a chunk number for 247 BitTorrent-like protocols) to the naming scheme. The need for such 248 extensions is stressed by today's variety of naming schemes (e.g., 249 DOI or PermaLink) added on top of the original Internet architecture 250 that fulfill specialized needs which cannot be met by the common 251 Internet naming schemes, i.e., IP addresses and URLs. 253 3. Basic Concepts for an Application-independent Naming Scheme 255 In this section, we introduce an exemplary naming scheme that 256 illustrates a possible way to fulfill the requirements posed upon an 257 application-independent naming scheme for information-centric 258 networks. The naming scheme integrates security deeply into the 259 system architecture. Trust is based on the data's ID in combination 260 with additional security metadata. Section 3.1 gives an overview of 261 the naming scheme in general with details about the ID structure, and 262 Section 3.2 describes the security metadata in more detail. 264 3.1. Overview 266 Building on an identifier/locator split, each data element, e.g., 267 file, is given a unique ID with cryptographic properties. Together 268 with the additional security metadata, the ID can be used to verify 269 data integrity, owner authentication, and owner identification. The 270 security metadata contains information needed for the security 271 functions of the naming scheme, e.g., public keys, content hashes, 272 certificates, and a data signature authenticating the content. In 273 comparison with the security model in today's host-centric networks, 274 this approach minimizes the need for trust in the infrastructure, 275 especially in the host(s) providing the data. 277 In an information-centric network, multiple copies of the same data 278 element typically exist at different locations. Thanks to the ID/ 279 locator split and the application-independent naming scheme, those 280 identical copies have the same ID and, hence, each application can 281 benefit from all available copies. 283 Data elements are manipulated (e.g., generated, modified, registered, 284 and retrieved) by physical entities such as nodes (clients or hosts), 285 persons, and companies. Physical entities able of generating, i.e., 286 creating or modifying data elements are called owners here. Several 287 security properties of this naming scheme are based on the fact that 288 each ID contains the hash of a public key that is part of a public/ 289 secret key pair PK/SK. This PK/SK pair is conceptually bound to the 290 data element itself and not directly to the owner as in other systems 291 like DONA [Koponen]. If desired, the PK/SK pair can be bound to the 292 owner only indirectly, via a certificate chain. This is important to 293 note because it enables owner change while keeping persistent IDs. 294 The key pair bound to the data is thus denoted as PK_D/SK_D. 296 Making the (hash of the) public key part of ID enables self- 297 certification of dynamic content while keeping persistent IDs. Self- 298 certification of static content can be achieved by simply including 299 the hash of content in the ID, but this would obviously result in 300 non-persistent IDs for dynamic content. For dynamic content, the 301 public key in the ID can be used to securely bind the hash of content 302 to the ID, by signing it with the corresponding secret key, while not 303 making it part of ID. 305 The owner's PK as part of the ID inherently provides owner 306 authentication. If the public key is bound to the owner's identity 307 (i.e., to its real-world name) via a trusted third party certificate, 308 this also allows owner identification. Without this additional 309 certificate, the owner can remain anonymous. 311 To support the potentially diverse requirements of certain groups of 312 applications and adapt to future changes, the naming scheme can 313 enable flexibility and extensibility by supporting different name 314 structures, differentiated via a Type field in the ID. 316 3.2. ID Structure 318 The naming scheme uses flat IDs to support self-certification and 319 name persistence. In addition, flat IDs are advantageous when it 320 comes to mobility and they can be allocated without an administrative 321 authority by relying on statistical uniqueness in a large namespace, 322 with the rare case of ID collisions being handled by the 323 applications. Although IDs are not hierarchical, they have a 324 specified basic ID structure. The ID structure given as ID = (Type 325 field | A = hash(PK) | L) is described subsequently. 327 The Authenticator field A=Hash(PK_D) binds the ID to a public key 328 PK_D. The hash function Hash is a cryptographic hash function, which 329 is required to be one-way and collision-resistant. The hash function 330 serves only to reduce the bit length of PK_D. PK_D is generated in 331 accordance with a chosen public-key cryptosystem. The corresponding 332 secret key SK_D should only be known to a legitimate owner. In 333 consequence, an owner of the data is defined as any entity who 334 (legitimately) knows SK_D. 336 The pair (A, L) has to be globally unique. Hence, the Label field L 337 provides global uniqueness if PK_D is repeatedly used for different 338 data. 340 To build a flexible and extensible naming scheme, e.g., to adapt the 341 naming scheme to future changes, different types of IDs are supported 342 by the naming scheme and differentiated via a mandatory and globally 343 standardized Type field in each ID. For example, the Type field 344 specifies the hash functions used to generate the ID. If a used hash 345 function becomes insecure, the Type field can be exploited by the P2P 346 system in order to automatically mark the IDs using this hash 347 function as invalid. 349 3.3. Security Metadata Structure 351 The security metadata is extensible and contains all information 352 required to perform the security functions embedded in the naming 353 scheme. The metadata (or selected parts of it) will be signed by 354 SK_D corresponding to PK_D. This securely binds the metadata to the 355 ID, i.e., to the Hash(PK_D) which is part of the ID. For example, 356 the security metadata may include: 358 o specification of the hash function h and the algorithm DSAlg used 359 for the digital signature 361 o complete PK_D (not only Hash(PK_D)) 363 o specification of the parts of data that are self-certified, i.e., 364 authenticated via the signature 366 o hash of the self-certified data 368 o signature of the self-certified data signed by SK_D 370 o all data required for owner authentication and identification 372 A detailed description and security analysis of this naming scheme 373 and its security properties, especially self-certification, name 374 persistence, owner authentication, and owner identification can be 375 found in the GIS paper Secure Naming for a Network of Information 376 [Dannewitz_10]. 378 4. Examples of application use of secure naming structure 380 This section contains a number of examples how a secure naming 381 system, as outlined in this draft, could be used by different types 382 of applications. 384 4.1. Secure naming for P2P applications 386 From an P2P application perspective the main advantage of a secure 387 naming structure for a P2P infrastructure is that multiple P2P 388 applications can have common access to the same data elements. 389 Another benefit of application-independent naming is that locally 390 available and cached copies can easily be located. The secure naming 391 also enables that data can be verified even if it is received from an 392 untrusted host. 394 For example, when an application like BitTorrent [WWWbittorrent] uses 395 self-certifying names, the user is guaranteed that the data received 396 is actually the data that has been requested, without having to trust 397 any servers in the network (e.g., the tracker) or the peers that 398 provide the data. 400 This means that BitTorrent's validation of the data integrity can be 401 improved significantly using the presented secure naming structure. 402 Currently, a standard BitTorrent system has no means to verify the 403 integrity of the torrent file and consequently of the data. The 404 torrent file (see Figure 1) contains the SHA1 hashes of the content 405 pieces (pieces in Figure 2). However, anyone can modify a torrent 406 file to bind different content to this file. If the torrent file 407 gets modified, the user has no means any more to verify the integrity 408 of the data. Modification of the torrent affects only to info_hash 409 value, which is SHA1 hash calculated from the torrent's info field 410 (see figure). The info_hash is respectively used for torrent session 411 identification in different software entities (e.g. in trackers). 412 After changes in the torrent's info field, the torrent is referring 413 to different torrent session that is carrying a forged content. 414 Additionally if, the tracker allows insertion of several torrents 415 with the same name - delivers forged data (consistent with the forged 416 torrent file), a user could effectively be tricked into downloading 417 forged content which would falsely be identified as being correct by 418 the BitTorrent client. On the other hand, the torrent referring to a 419 forged content can be also modified to point to, another, 420 "convenient" tracker by modifying the announce field in the torrent, 421 and the outcome would be the same from user perspective. I.e., in 422 the current BitTorrent system, a user has no guarantee that the 423 downloaded content actually matches the expected/correct content. 425 +---------------------------------+---------------------------------+ 426 | announce | info | 427 +---------------------------------+---------------------------------+ 429 Figure 1: Basic structure of the BitTorrent torrent file 431 +-----------+--------------+-------------+------------+-------------+ 432 | name | piece length | pieces | length | path (opt) | 433 +-----------+--------------+-------------+------------+-------------+ 435 Figure 2: Structure of info field in torrent file 437 +-----------+--------------+-------------+------------+-------------+ 438 | name | piece length | pieces | length | path (opt) | 439 +-----------+--------------+-------------+------------+-------------+ 440 +----------------------+----------------------+---------------------+ 441 | h | DSAlg | PK_D | 442 +----------------------+----------------------+---------------------+ 443 +----------------------+----------------------+---------------------+ 444 | certified pieces | ID | signature | 445 +----------------------+----------------------+---------------------+ 447 Figure 3: Structure of Secure naming enabled info field in torrent 449 The secure naming structure presented in this draft can provide a 450 simple solution for this problem by securely binding the content of 451 the torrent file to the name/ID of the torrent file. This can be 452 done by extending the torrent file to include the above described 453 security metadata information, as it is seen in Figure 3. In 454 practice, during the torrent file creation, an object owner would 455 store information about utilized algorithms (h - hash function and 456 DSAlg - digital signature algorithm), the public key (PK_D), 457 specification of signed data and ID into the torrent's info field, 458 and will sign the combination of the secure metadata and the piece 459 hash values (pieces in the torrent's info field) with the private key 460 (SK_D). The generated signature will also be included in the 461 extension part of the info field (signature). 463 After the content of the extended torrent is created, the respective 464 torrent file ID would be generated according to the rules described 465 in Section 3. As defined in that section, ID contains three 466 different fields, namely Type, A and L. In the case of BitTorrent, 467 Type field would carry on information about used hash function to 468 generate field A from PK_D, and also structure of the field L. If, 469 for example, L has name and version of the distributed file, Type 470 field should tell that by including strings "Name" and "Version" in 471 it. The next one, field A, includes hash values of the used PK_D 472 (method defined in Type). And finally the proposed BitTorrents ID 473 field L, can take in name and version of the distributed file. 474 According to the description and by using separators - (within one 475 field) and _ (between fields) the torrent file name could look, for 476 example, like: HashMethod-Name-Version_HashofPK_Filename- 477 Fileversion.torrent. 479 Consequently, whenever a user knows the ID of the content/torrent 480 file and retrieves the torrent file, she/he can now open the torrent 481 with the secure naming supported BitTorrent client. The client 482 verifies the integrity of the torrent file by comparing PK_D in 483 secure metadata and field A in the ID, in addition, conformance of ID 484 in the torrent name and ID in the metadata is verified. With respect 485 to the secure metadata the signature and actual data is compared 486 also. Once these three are verified, the client can download the 487 data pieces, and can use the BitTorrent's included (and now secured) 488 hash(es) to verify the integrity of the received data. As a result, 489 the user can be sure that the correct content was retrieved. 491 4.2. Secure naming use in DECADE 493 DECADE WG is specifying requirements for a protocol concerning 494 accessing data in a network storage and resource control of said 495 data. A key aspect in accessing data in a network storage is the way 496 the data is referenced. This naming draft has outlined a naming 497 structure that can be utilized to enhance the reference to include 498 additional features. The secure naming structure tries to fulfill 499 several design targets and requirements, however not all are 500 necessarily the priority requirements for the DECADE scope. 502 The DECADE storage is used by individual and uncoordinated entities, 503 thus the naming of the data must be collision free. Also when a user 504 accesses data the name should point to the correct data. With no 505 entity to keep track of used names for data, one potential approach 506 is to use large enough identifier designed with statistically 507 collision free random properties. One obvious identifier alternative 508 is to base it on the hash of the content. 510 The basic requirement for naming in DECADE is that the data 511 identifier is tied to the hash of the content and that it is taken 512 from a large enough flat namespace. In this way, wherever the same 513 data is stored, the same name identifier can be used. Someone 514 accessing the data can verify that the content is correct based on 515 relationship between data and identifier. Other requirements can be 516 included to further enhance the meaning and capability of the data 517 reference identifier. Additional naming requirements could be: 519 o self-certified name for verifying content owner (owner of Pk/Sk 520 keys), the self-certification can be used for building trust about 521 data publisher 523 o solution for persistent identifier names for dynamic (changing) 524 data 526 o potentially way to identify content owner, this typically requires 527 trusted third party certifier. 529 This draft specifies several requirements that would be useful for 530 the DECADE protocol, the main requirement is hashing of data into the 531 identifier name. Depending of data use (like enhanced security 532 properties) other secondary requirements will be beneficial for 533 additional functionality. 535 4.3. Secure naming for CDNs 537 The use of common naming within a CDN is not the challenge, it is the 538 common naming between end users and the CDN or between CDNs that can 539 be feasible. A common naming enables use of numerous caching points 540 and CDNs as the same data can be referenced in the same way. The 541 same data can depending of popularity be available in multiple 542 location like caches and CDNs. The population of the resources 543 (caches and CDNs) can be efficient if a common naming of data is 544 used. The interaction between CDNs to 'negotiate' data population of 545 caching resources would benefit from a common data reference model. 546 The security features of the naming scheme also helps the CDN 547 provider trust the data it is accessing and providing. The CDN 548 interaction is potentially in the scope of the CDNI WG BOF. 550 5. Conclusion 552 The main proposal presented in this draft is idea that there should 553 be a secure and application independent way of naming information 554 objects that are transported over the Internet. The draft defines a 555 set of requirements for such a naming structure. It also presents a 556 proposal for such a naming structure that could relevant for a number 557 of work groups (existing and potential), e.g. PPSP, DECADE and CDNI. 559 Specifically for the PPSP WG the secure naming structure is proposed 560 for consideration as common reference ID structure. For any P2P 561 streaming application to have fair and multitude of data access, it 562 is essential to have a common naming structure that is suitable for 563 many different needs. The common naming is probably best displayed 564 in the tracker protocol case but potential benefit in the actual 565 streaming protocol case has to still be identified. The secure 566 binding of reference ID to the actual content is manifested in the 567 end user peer possibility to check correct data reception in regard 568 to the used ID. 570 The naming structure has been implemented in the 4WARD project 571 prototypes and has been released as open source (www.netinf.org). 572 The naming structure is also available through a public NetInf 573 registration service at www.netinf.org. Three NetInf-enabled 574 applications have also been published, the InFox (Firefox plugin), 575 InBird (Thunderbird plugin), and a NetInf Information Object 576 Management Tool, all available at the www.netinf.org site. 578 Continued work on defining a common naming structure for information 579 objects is carried out in the SAIL project. More information is 580 available at the www.sail-project.eu site. 582 6. IANA Considerations 584 This document has no requests to IANA. 586 7. Security Considerations 588 There are considerations about what private/public key and hash 589 algorithms to utilize when designing the naming structure in a secure 590 way. 592 8. Acknowledgements 594 We would like to thank all the persons participating in the Network 595 of Information work packages in the EU FP7 projects 4WARD and SAIL 596 and the Finnish ICT SHOK Future Internet 2 project for contributions 597 and feedback to this document. 599 9. Informative References 601 [Dannewitz_10] 602 Dannewitz, C., Golic, J., Ohlman, B., and B. Ahlgren, 603 "Secure Naming for a Network of Information", 13th IEEE 604 Global Internet Symposium , 2010. 606 [Koponen] Koponen, T., Chawla, M., Chun, B., Ermolinskiy, A., Kim, 607 K., Shenker, S., and I. Stoica, "A Data-Oriented (and 608 beyond) Network Architecture", Proc. ACM SIGCOMM , 2007. 610 [Paskin2010] 611 Paskin, N., "Digital Object Identifier ({DOI}?) System", 612 Encyclopedia of Library and Information Sciences , 2010. 614 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 615 Requirement Levels", BCP 14, RFC 2119, March 1997. 617 [WWWbittorrent] 618 Cohen, B., "The BitTorrent Protocol Specification", 619 http://www.bittorrent.org/beps/bep_0003.html , 2008. 621 Authors' Addresses 623 Christian Dannewitz 624 University of Paderborn 625 Paderborn 626 Germany 628 Email: cdannewitz@upb.de 630 Teemu Rautio 631 VTT Technical Research Centre of Finland 632 Oulu 633 Finland 635 Email: teemu.rautio@vtt.fi 637 Ove Strandberg 638 Nokia Siemens Networks 639 Espoo 640 Finland 642 Email: ove.strandberg@nsn.com 644 Borje Ohlman 645 Ericsson 646 Stockholm 647 Sweden 649 Email: Borje.Ohlman@ericsson.com