< draft-ietf-p2psip-share-08.txt   draft-ietf-p2psip-share-09.txt >
P2PSIP Working Group A. Knauf P2PSIP Working Group A. Knauf
Internet-Draft T. Schmidt, Ed. Internet-Draft T. Schmidt, Ed.
Intended status: Standards Track HAW Hamburg Intended status: Standards Track HAW Hamburg
Expires: September 21, 2016 G. Hege Expires: April 13, 2017 G. Hege
daviko GmbH daviko GmbH
M. Waehlisch M. Waehlisch
link-lab & FU Berlin link-lab & FU Berlin
March 20, 2016 October 10, 2016
A Usage for Shared Resources in RELOAD (ShaRe) A Usage for Shared Resources in RELOAD (ShaRe)
draft-ietf-p2psip-share-08 draft-ietf-p2psip-share-09
Abstract Abstract
This document defines a RELOAD Usage for managing shared write access This document defines a RELOAD Usage for managing shared write access
to RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a basic to RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a basic
primitive for enabling various coordination and notification schemes primitive for enabling various coordination and notification schemes
among distributed peers. Access in ShaRe is controlled by a among distributed peers. Access in ShaRe is controlled by a
hierarchical trust delegation scheme maintained within an access hierarchical trust delegation scheme maintained within an access
list. A new USER-CHAIN-ACL access policy allows authorized peers to list. A new USER-CHAIN-ACL access policy allows authorized peers to
write a Shared Resource without owning its corresponding certificate. write a Shared Resource without owning its corresponding certificate.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 21, 2016. This Internet-Draft will expire on April 13, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Shared Resources in RELOAD . . . . . . . . . . . . . . . . . 4 3. Shared Resources in RELOAD . . . . . . . . . . . . . . . . . 4
3.1. Mechanisms for Isolating Stored Data . . . . . . . . . . 5 3.1. Mechanisms for Isolating Stored Data . . . . . . . . . . 5
4. Access Control List Definition . . . . . . . . . . . . . . . 6 4. Access Control List Definition . . . . . . . . . . . . . . . 6
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Data Structure . . . . . . . . . . . . . . . . . . . . . 8 4.2. Data Structure . . . . . . . . . . . . . . . . . . . . . 8
5. Extension for Variable Resource Names . . . . . . . . . . . . 9 5. Extension for Variable Resource Names . . . . . . . . . . . . 9
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Data Structure . . . . . . . . . . . . . . . . . . . . . 10 5.2. Data Structure . . . . . . . . . . . . . . . . . . . . . 10
5.3. Overlay Configuration Document Extension . . . . . . . . 10 5.3. Overlay Configuration Document Extension . . . . . . . . 11
6. Access Control to Shared Resources . . . . . . . . . . . . . 12 6. Access Control to Shared Resources . . . . . . . . . . . . . 12
6.1. Granting Write Access . . . . . . . . . . . . . . . . . . 12 6.1. Granting Write Access . . . . . . . . . . . . . . . . . . 12
6.2. Revoking Write Access . . . . . . . . . . . . . . . . . . 13 6.2. Revoking Write Access . . . . . . . . . . . . . . . . . . 13
6.3. Validating Write Access through an ACL . . . . . . . . . 13 6.3. Validating Write Access through an ACL . . . . . . . . . 13
6.4. Operations of Storing Peers . . . . . . . . . . . . . . . 14 6.4. Operations of Storing Peers . . . . . . . . . . . . . . . 14
6.5. Operations of Accessing Peers . . . . . . . . . . . . . . 14 6.5. Operations of Accessing Peers . . . . . . . . . . . . . . 14
6.6. USER-CHAIN-ACL Access Policy . . . . . . . . . . . . . . 15 6.6. USER-CHAIN-ACL Access Policy . . . . . . . . . . . . . . 15
7. ACCESS-CONTROL-LIST Kind Definition . . . . . . . . . . . . . 15 7. ACCESS-CONTROL-LIST Kind Definition . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8.1. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 16 8.1. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 16
8.2. Malicious or Misbehaving Storing Peer . . . . . . . . . . 16 8.2. Malicious or Misbehaving Storing Peer . . . . . . . . . . 16
8.3. Trust Delegation to a Malicious or Misbehaving Peer . . . 16 8.3. Trust Delegation to a Malicious or Misbehaving Peer . . . 16
8.4. Privacy Issues . . . . . . . . . . . . . . . . . . . . . 17 8.4. Privacy Issues . . . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9.1. Access Control Policy . . . . . . . . . . . . . . . . . . 17 9.1. Access Control Policy . . . . . . . . . . . . . . . . . . 17
9.2. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 17 9.2. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 17
9.3. XML Name Space Registration . . . . . . . . . . . . . . . 17 9.3. XML Name Space Registration . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . 18
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
[RFC6940] defines the base protocol for REsource LOcation And [RFC6940] defines the base protocol for REsource LOcation And
Discovery (RELOAD) that allows for application-specific extensions by Discovery (RELOAD) that allows for application-specific extensions by
skipping to change at page 3, line 39 skipping to change at page 3, line 39
contains the ID of the Kind to be shared and contains trust contains the ID of the Kind to be shared and contains trust
delegations from one authorized to another (previously unauthorized) delegations from one authorized to another (previously unauthorized)
user. user.
Shared write access augments the RELOAD security model, which is Shared write access augments the RELOAD security model, which is
based on the restriction that peers are only allowed to write based on the restriction that peers are only allowed to write
resources at a small set of well defined locations (Resource-IDs) in resources at a small set of well defined locations (Resource-IDs) in
the overlay. Using the standard access control rules in RELOAD, the overlay. Using the standard access control rules in RELOAD,
these locations are bound to the username or Node-ID in the peer's these locations are bound to the username or Node-ID in the peer's
certificate. This document extends the base policies to enable a certificate. This document extends the base policies to enable a
controlled write access for multiple users to a common Resource Id. controlled write access for multiple users to a common Resource-ID.
Additionally, this specification defines an optional mechanism to Additionally, this specification defines an optional mechanism to
store Resources with a variable Resource Name. It enables the store Resources with a variable Resource Name. It enables the
storage of Resources whose name complies to a specific pattern. storage of Resources whose name complies to a specific pattern.
Definition of the pattern is arbitrary, but must contain the user Definition of the pattern is arbitrary, but must contain the user
name of the Resource creator. name of the Resource creator.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document uses the terminology and definitions from the RELOAD This document uses the terminology and definitions from the RELOAD
base [RFC6940] and [I-D.ietf-p2psip-concepts], in particular the base [RFC6940] and [RFC7890], in particular the RELOAD Usage,
RELOAD Usage, Resource and Kind. Additionally, the following terms Resource and Kind. Additionally, the following terms are used:
are used:
Shared Resource: The term Shared Resource in this document defines a Shared Resource: The term Shared Resource in this document defines a
RELOAD Resource with its associated Kinds, that can be written or RELOAD Resource with its associated Kinds, that can be written or
overwritten by multiple RELOAD users following the specifications overwritten by multiple RELOAD users following the specifications
in this document. in this document.
Access Control List: The term Access Control List in this document Access Control List: The term Access Control List in this document
defines a logical list of RELOAD users allowed to write a specific defines a logical list of RELOAD users allowed to write a specific
RELOAD Resource/Kind pair by following the specifications in this RELOAD Resource/Kind pair by following the specifications in this
document. The list items are stored as Access Control List Kinds document. The list items are stored as Access Control List Kinds
skipping to change at page 6, line 16 skipping to change at page 6, line 13
the stored data the stored data
2. Take the least significant 24 bits of that Node-ID to prefix the 2. Take the least significant 24 bits of that Node-ID to prefix the
array index array index
3. Append an 8 bit individual index value to those 24 bit of the 3. Append an 8 bit individual index value to those 24 bit of the
Node-ID Node-ID
The resulting 32 bits long integer MUST be used as the index for The resulting 32 bits long integer MUST be used as the index for
storing an array entry in a Shared Resource. The 24 bits of the storing an array entry in a Shared Resource. The 24 bits of the
Node-ID serve as a pseudo-random identifier. The 8 bit individual Node-ID serve as a collision-resistant identifier. The 8 bit
index remain under the control of a single Peer and can be individual index remain under the control of a single Peer and can be
incremented individually for further array entries. In total, each incremented individually for further array entries. In total, each
Peer can generate 256 distinct entries for application-specific use. Peer can generate 256 distinct entries for application-specific use.
The mechanism to create the array index is related to the pseudo- The mechanism to create the array index inherits collision-resistance
random algorithm to generate an SSRC identifier in RTP, see from the overlay hash function in use (e.g., SHA-1). It is designed
Section 8.1 in [RFC3550] for calculating the probability of a to work reliably for small sizes of groups as applicable to resource
collision (here L=24 is the length of the pseudo-random id). sharing. In the rare event of a collision, the Storing Peer will
refuse to (over-)write the requested array index and protect indexing
integrity as defined in Section 6.1. A Peer could rejoin the overlay
with different Node-ID in such a case.
4. Access Control List Definition 4. Access Control List Definition
4.1. Overview 4.1. Overview
An Access Control List (ACL) is a (self-managed) shared resource that An Access Control List (ACL) is a (self-managed) shared resource that
contains a list of AccessControlListItem structures as defined in contains a list of AccessControlListItem structures as defined in
Section 4.2. Each entry delegates write access for a specific Kind Section 4.2. Each entry delegates write access for a specific Kind
data to a single RELOAD user. An ACL enables the RELOAD user who is data to a single RELOAD user. An ACL enables the RELOAD user who is
authorized to write a specific Resource-ID to delegate his exclusive authorized to write a specific Resource-ID to delegate his exclusive
skipping to change at page 6, line 47 skipping to change at page 6, line 47
the information about who obtains write access, the Kind-ID of the the information about who obtains write access, the Kind-ID of the
Resource to be shared, and whether delegation includes write access Resource to be shared, and whether delegation includes write access
to the ACL itself. The latter condition grants the right to delegate to the ACL itself. The latter condition grants the right to delegate
write access further for the Authorized Peer. Access Control Lists write access further for the Authorized Peer. Access Control Lists
are stored at the same overlay location as the Shared Resource and are stored at the same overlay location as the Shared Resource and
use the RELOAD array data model. They are initially created by the use the RELOAD array data model. They are initially created by the
Resource Owner. Resource Owner.
Figure 1 shows an example of an Access Control List. We omit the Figure 1 shows an example of an Access Control List. We omit the
res_name_ext field to simplify illustration. The array entry at res_name_ext field to simplify illustration. The array entry at
index 0x123abc001 displays the initial creation of an ACL for a index 0x123abc01 displays the initial creation of an ACL for a Shared
Shared Resource of Kind-ID 1234 at the same Resource-ID. It Resource of Kind-ID 1234 at the same Resource-ID. It represents the
represents the root item of the trust delegation tree for this shared root item of the trust delegation tree for this shared RELOAD Kind.
RELOAD Kind. The root entry MUST contain the user name of the The root entry MUST contain the user name of the Resource owner in
Resource owner in the "to_user" field and can only be written by the the "to_user" field and can only be written by the owner of the
owner of the public key certificate associated with this Resource-ID. public key certificate associated with this Resource-ID. The
allow_delegation (ad) flag for a root ACL item is set to 1 by
The allow_delegation (ad) flag for a root ACL item is set to 1 by
default. The array index is generated by using the mechanism for default. The array index is generated by using the mechanism for
isolating stored data as described in Section 3.1. Hence, the most isolating stored data as described in Section 3.1. Hence, the most
significant 24 bits of the array index (0x123abc) are the least significant 24 bits of the array index (0x123abc) are the least
significant 24 bits of the Node-ID of the Resource Owner. significant 24 bits of the Node-ID of the Resource Owner.
The array item at index 0x123abc002 represents the first trust The array item at index 0x123abc02 represents the first trust
delegation to an Authorized Peer that is thus permitted to write to delegation to an Authorized Peer that is thus permitted to write to
the Shared Resource of Kind-ID 1234. Additionally, the Authorized the Shared Resource of Kind-ID 1234. Additionally, the Authorized
peer Alice is also granted write access to the ACL as indicated by peer Alice is also granted write access to the ACL as indicated by
the allow_delegation flag (ad) set to 1. This configuration the allow_delegation flag (ad) set to 1. This configuration
authorizes Alice to store further trust delegations to the Shared authorizes Alice to store further trust delegations to the Shared
Resource, i.e., add items to the ACL. On the contrary, index Resource, i.e., add items to the ACL. On the contrary, index
0x456def001 illustrates trust delegation for Kind-ID 1234, in which 0x456def01 illustrates trust delegation for Kind-ID 1234, in which
the Authorized Peer Bob is not allowed to grant access to further the Authorized Peer Bob is not allowed to grant access to further
peers (ad = 0). Each Authorized Peer signs its ACL items by using peers (ad = 0). Each Authorized Peer signs its ACL items by using
its own signer identity along with its own private key. This allows its own signer identity along with its own private key. This allows
other peers to validate the origin of an ACL item and makes ownership other peers to validate the origin of an ACL item and makes ownership
transparent. transparent.
To manage Shared Resource access of multiple Kinds at a single To manage Shared Resource access of multiple Kinds at a single
location, the Resource Owner can create new ACL entries that refer to location, the Resource Owner can create new ACL entries that refer to
another Kind-ID as shown in array entry index 0x123abc003. Note that another Kind-ID as shown in array entry index 0x123abc03. Note that
overwriting existing items in an Access Control List with a change in overwriting existing items in an Access Control List with a change in
the Kind-ID revokes all trust delegations in the corresponding the Kind-ID revokes all trust delegations in the corresponding
subtree (see Section 6.2). Authorized Peers are only enabled to subtree (see Section 6.2). Authorized Peers are only enabled to
overwrite existing ACL item they own. The Resource Owner is allowed overwrite existing ACL item they own. The Resource Owner is allowed
to overwrite any existing ACL item, but should be aware of its to overwrite any existing ACL item, but should be aware of its
consequences on the trust delegation chain. consequences on the trust delegation chain.
+------------------------------------------------------+ +------------------------------------------------------+
| Access Control List | | Access Control List |
+-----------+------------------------------+-----------+ +-----------+------------------------------+-----------+
| #Index | Array Entries | signed by | | #Index | Array Entries | signed by |
+-----------+------------------------------+-----------+ +-----------+------------------------------+-----------+
| 123abc001 | to_user:Owner Kind:1234 ad:1 | Owner | | 123abc01 | to_user:Owner Kind:1234 ad:1 | Owner |
+-----------+------------------------------+-----------+ +-----------+------------------------------+-----------+
| 123abc002 | to_user:Alice Kind:1234 ad:1 | Owner | | 123abc02 | to_user:Alice Kind:1234 ad:1 | Owner |
+-----------+------------------------------+-----------+ +-----------+------------------------------+-----------+
| 123abc003 | to_user:Owner Kind:4321 ad:1 | Owner | | 123abc03 | to_user:Owner Kind:4321 ad:1 | Owner |
+-----------+------------------------------+-----------+ +-----------+------------------------------+-----------+
| 123abc004 | to_user:Carol Kind:4321 ad:0 | Owner | | 123abc04 | to_user:Carol Kind:4321 ad:0 | Owner |
+-----------+------------------------------+-----------+ +-----------+------------------------------+-----------+
| ... | ... | ... | | ... | ... | ... |
+-----------+------------------------------+-----------+ +-----------+------------------------------+-----------+
| 456def001 | to_user:Bob Kind:1234 ad:0 | Alice | | 456def01 | to_user:Bob Kind:1234 ad:0 | Alice |
+-----------+------------------------------+-----------+ +-----------+------------------------------+-----------+
| ... | ... | ... | | ... | ... | ... |
+-----------+------------------------------+-----------+ +-----------+------------------------------+-----------+
Figure 1: Simplified example of an Access Control List including Figure 1: Simplified example of an Access Control List including
entries for two different Kind-IDs and varying delegation (ad) entries for two different Kind-IDs and varying delegation (ad)
configurations configurations
Implementations of ShaRe should be aware that the trust delegation in Implementations of ShaRe should be aware that the trust delegation in
an Access Control List need not be loop free. Self-contained an Access Control List need not be loop free. Self-contained
skipping to change at page 9, line 26 skipping to change at page 9, line 26
kind: This field contains the Kind-ID of the Shared Resource. kind: This field contains the Kind-ID of the Shared Resource.
allow_delegation: If true, this Boolean flag indicates that the allow_delegation: If true, this Boolean flag indicates that the
Authorized Peer in the 'to_user' field is allowed to add Authorized Peer in the 'to_user' field is allowed to add
additional entries to the ACL for the specified Kind-ID. additional entries to the ACL for the specified Kind-ID.
5. Extension for Variable Resource Names 5. Extension for Variable Resource Names
5.1. Overview 5.1. Overview
In certain use cases such as conferencing it is desirable to increase In certain use cases, such as conferencing, it is desirable to
the flexibility of a peer in using Resource Names beyond those increase the flexibility of a peer in using Resource Names beyond
defined by the user name or Node-ID fields in its certificate. For those defined by the user name or Node-ID fields in its certificate.
this purpose, this document presents the concept for variable For this purpose, this document presents the concept for variable
Resources Names that enables providers of RELOAD instances to define Resources Names that enables providers of RELOAD instances to define
relaxed naming schemes for overlay Resources. relaxed naming schemes for overlay Resources.
Each RELOAD node uses a certificate to identify itself using its user Each RELOAD node uses a certificate to identify itself using its user
name (or Node-ID) while storing data under a specific Resource-ID name (or Node-ID) while storing data under a specific Resource-ID
(see Section 7.3 in [RFC6940]). The specifications in this document (see Section 7.3 in [RFC6940]). The specifications in this document
scheme adhere to this paradigm, but enable a RELOAD peer to store scheme adhere to this paradigm, but enable a RELOAD peer to store
values of Resource Names that are derived from the user name in its values of Resource Names that are derived from the user name in its
certificate. This is done by using a Resource Name with a variable certificate. This is done by using a Resource Name with a variable
substring that still matches the user name in the certificate using a substring that still matches the user name in the certificate using a
skipping to change at page 9, line 51 skipping to change at page 9, line 51
being variable, an allowable Resource Name remains tied to the being variable, an allowable Resource Name remains tied to the
Owner's certificate. A sample pattern might be formed as follows. Owner's certificate. A sample pattern might be formed as follows.
Example Pattern: Example Pattern:
.*-conf-$USER@$DOMAIN .*-conf-$USER@$DOMAIN
When defining the pattern, care must be taken to avoid conflicts When defining the pattern, care must be taken to avoid conflicts
arising from two user names of witch one is a substring of the other. arising from two user names of witch one is a substring of the other.
In such cases, the holder of the shorter name could threaten to block In such cases, the holder of the shorter name could threaten to block
the resources of the longer-named peer by choosing the variable part the resources of the longer-named peer by choosing the variable part
of a Resource Name to contain the entire longer user name. This of a Resource Name to contain the entire longer user name. For
problem can easily be mitigated by delimiting the variable part of example, a "*$USER" pattern would allow user EVE to define a resource
the pattern from the user name part by some fixed string, that by with name "STEVE" and to block the resource name for user STEVE
convention is not part of a user name (e.g., the "-conf-" in the through this. This problem can easily be mitigated by delimiting the
above Example). variable part of the pattern from the user name part by some fixed
string, that by convention is not part of a user name (e.g., the
"-conf-" in the above Example).
5.2. Data Structure 5.2. Data Structure
This section defines the optional ResourceNameExtension structure for This section defines the optional ResourceNameExtension structure for
every Kind that uses the USER-CHAIN-ACL access control policy. every Kind that uses the USER-CHAIN-ACL access control policy.
enum { pattern(1), (255)} ResourceNameType; enum { pattern(1), (255)} ResourceNameType;
struct { struct {
ResourceNameType type; ResourceNameType type;
skipping to change at page 10, line 51 skipping to change at page 11, line 10
for this Kind in the configuration document. for this Kind in the configuration document.
The ResourceNameType enum and the ResourceNameExtension structure can The ResourceNameType enum and the ResourceNameExtension structure can
be extended by further Usages to define other naming schemes. be extended by further Usages to define other naming schemes.
5.3. Overlay Configuration Document Extension 5.3. Overlay Configuration Document Extension
This section extends the overlay configuration document by defining This section extends the overlay configuration document by defining
new elements for patterns relating resource names to user names. It new elements for patterns relating resource names to user names. It
is noteworthy that additional constraints on the syntax and semantic is noteworthy that additional constraints on the syntax and semantic
of names can apply according to specific Usages. For example, AOR of names can apply according to specific Usages. For example,
syntax restrictions apply when using P2PSIP[I-D.ietf-p2psip-sip], Address of Record (AOR) syntax restrictions apply when using
while a more general naming is feasible in plain RELOAD. P2PSIP[I-D.ietf-p2psip-sip], while a more general naming is feasible
in plain RELOAD.
The <variable-resource-names> element serves as a container for one The <variable-resource-names> element serves as a container for one
or multiple <pattern> sub-elements. It is an additional parameter or multiple <pattern> sub-elements. It is an additional parameter
within the kind-block and has a boolean "enable" attribute that within the kind-block and has a boolean "enable" attribute that
indicates, if true, that the overlay provider allows variable indicates, if true, that the overlay provider allows variable
resource names for this Kind. The default value of the "enable" resource names for this Kind. The default value of the "enable"
attribute is "false". In the absence of a <variable-resource-names> attribute is "false". In the absence of a <variable-resource-names>
element for a Kind using the USER-CHAIN-ACL access policy (see element for a Kind using the USER-CHAIN-ACL access policy (see
Section 6.6), implementors MUST assume this default value. Section 6.6), implementors MUST assume this default value.
skipping to change at page 13, line 11 skipping to change at page 13, line 24
probability of a collision of two or more identical array indices probability of a collision of two or more identical array indices
will be negligibly low using the mechanism for isolating stored data will be negligibly low using the mechanism for isolating stored data
(see Section 3.1) (see Section 3.1)
6.2. Revoking Write Access 6.2. Revoking Write Access
Write permissions are revoked by storing a non-existent value Write permissions are revoked by storing a non-existent value
(see[RFC6940] Section 7.2.1) at the corresponding item of the Access (see[RFC6940] Section 7.2.1) at the corresponding item of the Access
Control List. Revoking a permission automatically invalidates all Control List. Revoking a permission automatically invalidates all
delegations performed by that user including all subsequent delegations performed by that user including all subsequent
delegations. This allows to invalidate entire subtrees of the delegations. This allows the invalidation of entire subtrees of the
delegations tree with only a single operation. Overwriting the root delegations tree with only a single operation. Overwriting the root
item with a non-existent value of an Access List invalidates the item with a non-existent value of an Access List invalidates the
entire delegations tree. entire delegations tree.
An existing ACL item MUST only be overwritten by the user who An existing ACL item MUST only be overwritten by the user who
initially stored the corresponding entry, or by the Resource Owner initially stored the corresponding entry, or by the Resource Owner
that is allowed to overwrite all ACL items for revoking write access. that is allowed to overwrite all ACL items for revoking write access.
To protect the privacy of the users, the Resource Owner SHOULD To protect the privacy of the users, the Resource Owner SHOULD
overwrite all subtrees that have been invalidated. overwrite all subtrees that have been invalidated.
skipping to change at page 15, line 40 skipping to change at page 16, line 4
described in Section 6.3 has been successfully applied. described in Section 6.3 has been successfully applied.
Otherwise, the store request MUST be denied. Otherwise, the store request MUST be denied.
7. ACCESS-CONTROL-LIST Kind Definition 7. ACCESS-CONTROL-LIST Kind Definition
This section defines the ACCESS-CONTROL-LIST Kind previously This section defines the ACCESS-CONTROL-LIST Kind previously
described in this document. described in this document.
Name: ACCESS-CONTROL-LIST Name: ACCESS-CONTROL-LIST
Kind IDs: The Resource Name for ACCESS-CONTROL-LIST Kind-ID is the Kind IDs: The Resource Name for ACCESS-CONTROL-LIST Kind-ID is the
Resource Name of the Kind that will be shared by using the ACCESS- Resource Name of the Kind that will be shared by using the ACCESS-
CONTROL-LIST Kind. CONTROL-LIST Kind.
Data Model: The data model for the ACCESS-CONTROL-LIST Kind-ID is Data Model: The data model for the ACCESS-CONTROL-LIST Kind-ID is
array. The array indexes are formed by using the mechanism for array. The array indexes are formed by using the mechanism for
isolated stored data as described in Section 3.1 isolated stored data as described in Section 3.1
Access Control: USER-CHAIN-ACL (see Section 6.6) Access Control: USER-CHAIN-ACL (see Section 6.6)
8. Security Considerations 8. Security Considerations
In this section we discuss security issues that are relevant to the In this section we discuss security issues that are relevant to the
usage of shared resources in RELOAD. usage of shared resources in RELOAD [RFC6940].
8.1. Resource Exhaustion 8.1. Resource Exhaustion
Joining a RELOAD overlay inherently poses a certain resource load on Joining a RELOAD overlay inherently poses a certain resource load on
a peer, because it has to store and forward data for other peers. In a peer, because it has to store and forward data for other peers. In
common RELOAD semantics, each Resource ID and thus position in the common RELOAD semantics, each Resource-ID and thus position in the
overlay may only be written by a limited set of peers - often even overlay may only be written by a limited set of peers - often even
only a single peer, which limits this burden. In the case of Shared only a single peer, which limits this burden. In the case of Shared
Resources, a single resource may be written by multiple peers, who Resources, a single resource may be written by multiple peers, who
may even write an arbitrary number of entries (e.g., delegations in may even write an arbitrary number of entries (e.g., delegations in
the ACL). This leads to an enhanced use of resources at individual the ACL). This leads to an enhanced use of resources at individual
overlay nodes. The problem of resource exhaustion can easily be overlay nodes. The problem of resource exhaustion can easily be
mitigated for Usages based on the ShaRe-Usage by imposing mitigated for Usages based on the ShaRe-Usage by imposing
restrictions on size, i.e., <max-size> element for a certain Kind in restrictions on size, i.e., <max-size> element for a certain Kind in
the configuration document. the configuration document.
skipping to change at page 18, line 32 skipping to change at page 18, line 47
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<http://www.rfc-editor.org/info/rfc3688>. <http://www.rfc-editor.org/info/rfc3688>.
[RFC6940] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S., [RFC6940] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S.,
and H. Schulzrinne, "REsource LOcation And Discovery and H. Schulzrinne, "REsource LOcation And Discovery
(RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940, (RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940,
January 2014, <http://www.rfc-editor.org/info/rfc6940>. January 2014, <http://www.rfc-editor.org/info/rfc6940>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-p2psip-concepts]
Bryan, D., Matthews, P., Shim, E., Willis, D., and S.
Dawkins, "Concepts and Terminology for Peer to Peer SIP",
draft-ietf-p2psip-concepts-08 (work in progress), February
2016.
[I-D.ietf-p2psip-sip] [I-D.ietf-p2psip-sip]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., Jennings, C., Lowekamp, B., Rescorla, E., Baset, S.,
Schulzrinne, H., and T. Schmidt, "A SIP Usage for RELOAD", Schulzrinne, H., and T. Schmidt, "A SIP Usage for RELOAD",
draft-ietf-p2psip-sip-17 (work in progress), March 2016. draft-ietf-p2psip-sip-21 (work in progress), April 2016.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC7890] Bryan, D., Matthews, P., Shim, E., Willis, D., and S.
Jacobson, "RTP: A Transport Protocol for Real-Time Dawkins, "Concepts and Terminology for Peer-to-Peer SIP
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, (P2PSIP)", RFC 7890, DOI 10.17487/RFC7890, June 2016,
July 2003, <http://www.rfc-editor.org/info/rfc3550>. <http://www.rfc-editor.org/info/rfc7890>.
Acknowledgments Acknowledgments
This work was stimulated by fruitful discussions in the P2PSIP This work was stimulated by fruitful discussions in the P2PSIP
working group and SAM research group. We would like to thank all working group and the SAM research group. We would like to thank all
active members for constructive thoughts and feedback. In active members for constructive thoughts and feedback. In
particular, the authors would like to thank (in alphabetical order) particular, the authors would like to thank (in alphabetical order)
Emmanuel Baccelli, Alissa Cooper Lothar Grimm, Cullen Jennings, Peter Emmanuel Baccelli, Alissa Cooper, Lothar Grimm, Russ Housley, Cullen
Musgrave, Joerg Ott, Marc Petit-Huguenin, Peter Pogrzeba, and Jan Jennings, Peter Musgrave, Joerg Ott, Marc Petit-Huguenin, Peter
Seedorf. This work was partly funded by the German Federal Ministry Pogrzeba, and Jan Seedorf. This work was partly funded by the German
of Education and Research, projects HAMcast, Mindstone, and SAFEST. Federal Ministry of Education and Research, projects HAMcast,
Mindstone, and SAFEST.
Authors' Addresses Authors' Addresses
Alexander Knauf Alexander Knauf
HAW Hamburg HAW Hamburg
Berliner Tor 7 Berliner Tor 7
Hamburg D-20099 Hamburg D-20099
Germany Germany
Phone: +4940428758067 Phone: +4940428758067
 End of changes. 31 change blocks. 
64 lines changed or deleted 62 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/