Network Working Group V. Narayanan Internet-Draft Qualcomm, Inc. Intended status: Standards Track November 21, 2008 Expires: May 25, 2009 Usage Agnostic Overlay Operation in RELOAD draft-vidya-p2psip-usage-agnostic-reload-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 25, 2009. Abstract RELOAD [1] defines an overlay framework for providing peer-to-peer connectivity and storage/retreival primitives for applications. Applications or usages are expected to reside on top of such an overlay. In general, this is a good design that allows multiple applications to use the same overlay framework. In such a design, however, there are some decisions to be made in terms of what is an overlay function and what must be defined by a usage. These decisions should generally be based on whether the particular function is expecting an operation or guarantee from the overlay nodes in general or from a particular usage only. This type of separation is especially crucial to avoid needing flag days for upgrading nodes in order to accommodate a newer usage version for Narayanan Expires May 25, 2009 [Page 1] Internet-Draft Usage Agnostic Overlay Operation November 2008 performing the overlay operation. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation for Usage Agnostic Overlay Behavior . . . . . . . . 3 4. Data Authorization . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Data Authorization Properties and Requirements . . . . . . 4 4.2. Data Authorization in RELOAD and Proposed Changes . . . . . 6 5. Storage Semantics in RELOAD and Proposed Changes . . . . . . . 7 5.1. Store and Remove Request Processing . . . . . . . . . . . . 7 5.2. Storing and Retrieval of Related Data . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Narayanan Expires May 25, 2009 [Page 2] Internet-Draft Usage Agnostic Overlay Operation November 2008 1. Introduction RELOAD allows usages to be defined on top of an overlay instantiation. Usages may define various kinds of data, with a corresponding data model for each kind. In order to store data on a particular node in the overlay, RELOAD requires that it recognizes the kind id of the data being stored and that the data model used is the correct one for that kind id. Further, for data authorization, RELOAD requires that the resource name be computed using a certified user name or node id, where the certificate of interest and resource name calculation mechanism may be defined by a usage. For these reasons, it will be necessary that all nodes in an overlay support all usages that may be offered on that overlay. Further, when usages evolve to newer versions, it will be essential that all nodes support the same versions of all usages. In a distributed system, this requires a flag day for all devices, which is usually unrealistic. The goal of this draft is to bring out the need for keeping storage and overlay-level data authorization usage agnostic. By doing so, RELOAD compatible overlays will yield more easily to supporting heterogeneous usages as well as allow upgrades to evolve over time. For properties and primitives provided at the overlay level, it is crucial that we maintain such usage independence. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. This document uses the terminology used in RELOAD. In addition, the following terms are used: o "Overlay level" - The term "overlay level" is used to refer to operations at the layers below the usage layer and above the transport layer in the RELOAD architecture. o "Application/Usage level" - The terms "application level" or "usage level" are used to refer to operations at the usage layer in the RELOAD architecture. 3. Motivation for Usage Agnostic Overlay Behavior At a very fundamental level, DHTs provide key-based routing, on top of which several applications may exist. Overlay protocols, such as the one defined in RELOAD, provide storage and retrieval semantics and allow peer-to-peer connectivity for nodes. These are very basic Narayanan Expires May 25, 2009 [Page 3] Internet-Draft Usage Agnostic Overlay Operation November 2008 primitives that can be used by a wide range of applications. Even for the SIP-based class of applications within the scope of the P2PSIP WG, there are several applications that may exist on various nodes in an overlay. It is not necessary that all nodes in an overlay support the same applications. Further, a given application may evolve over time, with newer versions potentially defining new kinds of data to be stored and retrieved on an overlay. Overlay primitives such as storage functioning independent of the usage has a huge advantage in that it does not require all nodes in the overlay to support a given usage in order to store data corresponding to that usage. Usages may, of course, provide additional mechanisms at the usage level that may be interpreted by nodes that do support those usages - but, this itself is independent of the overlay primitives. Given the heterogeneous usages and potential evolution of even the same usage, an overlay will need a flag day for upgrading all devices, if the operations on the overlay primitives are allowed to be defined by the usages. The overlay will then be rendered unusable or will result in unpredictable behavior when incompatible usages are present on various nodes. Hence, while usages should be allowed to interface with the overlay layer to provide certain inputs, the operations on overlay primitives such as storage should be defined and contained within the overlay layers. 4. Data Authorization 4.1. Data Authorization Properties and Requirements Before discussing the specific data authorization model employed in RELOAD, let us briefly discuss the requirements for data authorization and what properties are expected of it. Data authorization provides the following properties: o Data authorization allows the storing node to verify that the data owner is in fact authorized to store at that particular resource id. This allows the overlay to restrict the number of locations at which data can be stored by a given node and hence limits the impact of a single node to the distributed quota available in the overlay. However, the ability to spread a given node's data around the overlay is also an equally important feature - hence, restricting the location of storage corresponding to a node to exactly one is also a problem. Without this, a given node may be burdened by all the data from a heavy user. This also provides an attacker incentives to target a particular resource id for a chosen location attack. Narayanan Expires May 25, 2009 [Page 4] Internet-Draft Usage Agnostic Overlay Operation November 2008 o Data authorization allows the data owner to control which nodes/ users are allowed to write to that particular resource id. Without this, any node may potentially overwrite the contents of a given resource id. Both properties described above are usage independent and should be realized as such. The following are the requirements to consider in designing a data authorization solution: o Data authorization for overlay storage MUST be provided in a usage agnostic fashion. Hence, a node in the overlay should be able to verify authorization of a storage request from another node, without having to support the usage to which the data to be stored belongs. o Data authorization MUST allow the data owner to ensure that unauthorized nodes cannot write to or modify the contents of the particular items in the resource id that it stored. It should be noted that the assurance of the data authorization model is dependent on the storing node enforcing the model. o An authorized store MUST be independently verifiable by any node in the overlay. In other words, a node retrieving the contents of a resource id must be able to verify that the data owner corresponding to it was authorized to store at that resource id. It should be noted that it is not readily possible to verify that the storing node was responsible for a given resource id. o A given node SHOULD be able to store at multiple locations in the overlay. This allows a node to spread its data across an overlay and not rely on a single node. In general, replication and caching strategies may address the single point of storage limitations. However, the overlay storage primitives natively offering the spread is inherently useful in handling queries and the storage itself. o Data authorization at the overlay level MUST be based on overlay credentials (e.g., the certificate provided by an enrollment server or a self-signed certificate, whichever is honored by the overlay). Usage specific certificates cannot be honored by nodes that do not support those usages and hence, are not a viable candidate for overlay level data authorization. o The overlay MUST provide the ability for a querier to look up a service without having prior knowledge of the user name or node id of the entity offering the service. For e.g., a node looking for TURN services cannot be realistically expected to know the corresponding user names or node ids. Narayanan Expires May 25, 2009 [Page 5] Internet-Draft Usage Agnostic Overlay Operation November 2008 o Resource id computation MUST be performed in a usage agnostic fashion. Usages may be allowed to provide usage-specific inputs into the resource id computation. 4.2. Data Authorization in RELOAD and Proposed Changes Data authorization in RELOAD is based on the use of a certified user name or node id being used to compute the resource name. Essentially, the use of such a mechanism for resource id calculation allows a storing node to verify that the data owner is authorized to store at that location. RELOAD allows the resource name that is used as input to resource id computation to be defined by specific usages. Further, each usage is also allowed to define its own rules for data authorization. This makes the data authorization model usage dependent, lending itself to the need for homogeneous usage support and usage upgrade flag days for overlays. This section suggests a slight deviation in the authorization model for RELOAD to allow independent operation of storage authorization at the overlay level. Resource ID is computed as a hash of a Resource Name, as specified in RELOAD. However, the Resource Name comprises two parts - a usage specific string and an AuthName, separated by the delimiter ":". The usage specific string may be provided by a given usage or defaulted to the usage id. The AuthName is the certified user name or node id. Hence, ResourceID = h(UsageString:AuthName). As an example, it amounts to something like h(sip:alice@example.dht.org). Note that there is some ambiguity in the text around resource id generation in the current RELOAD draft and it may potentially be leading to this same point. When a usage is interested in allowing queries without prior knowledge of the user name or node id, authorized resource ids cannot be used to store the data. Hence, such storage can only be accomplished in an unauthorized fashion and the node MUST NOT include the AuthName as part of the Resource Name. However, in an unauthorized store scenario, it is possible for other nodes to modify the data. In such cases, the data may be protected by applying the same authorization rules at the value level. For instance, ":AuthName" may be appended to the value for this purpose. Note that this is more straightforward in the Single Value and Dictionary data models and more challenging in the array case. Usages must evaluate the need for authorization and corresponding data models. Without the possibility for the value-level data authorization, however, querying without user name or node id knowledge will take more complicated overlay crawling and service publication for discovery purposes. In order to support this dual level authorization, the protocol must allow the ability to signal the appropriate authorization type in use. Further, authorization MUST NOT be Narayanan Expires May 25, 2009 [Page 6] Internet-Draft Usage Agnostic Overlay Operation November 2008 applied at the resource id and value levels at any time. 5. Storage Semantics in RELOAD and Proposed Changes 5.1. Store and Remove Request Processing RELOAD requires a node receiving a store/remove request to verify that the kind id is known to it and the corresponding data model is correct. This assumes that the storing node supports the exact same usage, which may not necessarily be true. Hence, it is recommended that these checks not be required to store the data. A node may, based on local policies, provide preference to data corresponding to usages it supports - but, such local decisions should be outside the scope of the overlay protocol itself. 5.2. Storing and Retrieval of Related Data Going by the resource id computation described in Section 4.2, data corresponding to a given usage and a given user/node may be stored at a particular resource id. Usages may actually even spread the data corresponding to it around further by providing different semantics to the usage specific data in the resource name. For instance, instead of "sip:alice@example.dht.org" being the resource name, one may envision "sipaor:alice@example.dht.org", etc. RELOAD allows storing the certificate corresponding to a user name or node id at the resource ids corresponding to the hash of the user name and/or node id. That by itself is useful; however, it is also useful if the certificate can be stored at the same place as the SIP AOR. There are two ways in which this can be accomplished. The SIP usage may specify a certificate kind that also may be stored at the resource id. Alternately, it can be modeled as a targeted storage of a resource id and corresponding value at a node that may not own that resource id. This would allow a node that is storing data corresponding to multiple usages at the same resource id (either because it chose to not have authorization or because it computed its resource id as simply a hash of its AuthName) to just store one instance of a certificate even if multiple usages make use of it. However, at this time, it seems reasonable to expect each usage to define all required related data kinds such that those objects can be stored at the same resource id with relative ease. 6. Security Considerations This draft relates to usage independent overlay semantics in peer-to- peer networks. The related security aspects for data authorization have been described in the body of the draft. There are no Narayanan Expires May 25, 2009 [Page 7] Internet-Draft Usage Agnostic Overlay Operation November 2008 additional security considerations to document at this time. 7. IANA Considerations None 8. Acknowledgments This draft came about as a result of several discussions with Lakshminath Dondeti, Ranjith Jayaram, Radha Padmanabhan, and Saumitra Das. 9. Normative References [1] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", draft-ietf-p2psip-base-00 (work in progress), October 2008. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Author's Address Vidya Narayanan Qualcomm, Inc. 5775 Morehouse Dr San Diego, CA USA Phone: +1 858-845-2483 Email: vidyan@qualcomm.com Narayanan Expires May 25, 2009 [Page 8] Internet-Draft Usage Agnostic Overlay Operation November 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Narayanan Expires May 25, 2009 [Page 9]