draft-ietf-p2psip-service-discovery-14.txt   draft-ietf-p2psip-service-discovery-15.txt 
P2PSIP Working Group J. Maenpaa P2PSIP Working Group J. Maenpaa
Internet-Draft G. Camarillo Internet-Draft G. Camarillo
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: January 30, 2015 July 29, 2014 Expires: February 14, 2015 August 13, 2014
Service Discovery Usage for REsource LOcation And Discovery (RELOAD) Service Discovery Usage for REsource LOcation And Discovery (RELOAD)
draft-ietf-p2psip-service-discovery-14.txt draft-ietf-p2psip-service-discovery-15.txt
Abstract Abstract
REsource LOcation and Discovery (RELOAD) does not define a generic REsource LOcation and Discovery (RELOAD) does not define a generic
service discovery mechanism as a part of the base protocol. This service discovery mechanism as a part of the base protocol. This
document defines how the Recursive Distributed Rendezvous (ReDiR) document defines how the Recursive Distributed Rendezvous (ReDiR)
service discovery mechanism used in OpenDHT can be applied to RELOAD service discovery mechanism used in OpenDHT can be applied to RELOAD
overlays to provide a generic service discovery mechanism. overlays to provide a generic service discovery mechanism.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 January 30, 2015. This Internet-Draft will expire on February 14, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 12 skipping to change at page 2, line 12
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Introduction to ReDiR . . . . . . . . . . . . . . . . . . . . 5 3. Introduction to ReDiR . . . . . . . . . . . . . . . . . . . . 5
4. Using ReDiR in a RELOAD Overlay Instance . . . . . . . . . . 8 4. Using ReDiR in a RELOAD Overlay Instance . . . . . . . . . . 8
4.1. Data Structure . . . . . . . . . . . . . . . . . . . . . 8 4.1. Data Structure . . . . . . . . . . . . . . . . . . . . . 8
4.2. Selecting the Starting Level . . . . . . . . . . . . . . 9 4.2. Selecting the Starting Level . . . . . . . . . . . . . . 10
4.3. Service Provider Registration . . . . . . . . . . . . . . 10 4.3. Service Provider Registration . . . . . . . . . . . . . . 10
4.4. Refreshing Registrations . . . . . . . . . . . . . . . . 11 4.4. Refreshing Registrations . . . . . . . . . . . . . . . . 11
4.5. Service Lookups . . . . . . . . . . . . . . . . . . . . . 11 4.5. Service Lookups . . . . . . . . . . . . . . . . . . . . . 11
4.6. Removing Registrations . . . . . . . . . . . . . . . . . 13 4.6. Removing Registrations . . . . . . . . . . . . . . . . . 13
5. Access Control Rules . . . . . . . . . . . . . . . . . . . . 13 5. Access Control Rules . . . . . . . . . . . . . . . . . . . . 14
6. REDIR Kind Definition . . . . . . . . . . . . . . . . . . . . 13 6. REDIR Kind Definition . . . . . . . . . . . . . . . . . . . . 14
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Service Registration . . . . . . . . . . . . . . . . . . 14 7.1. Service Registration . . . . . . . . . . . . . . . . . . 15
7.2. Service Lookup . . . . . . . . . . . . . . . . . . . . . 16 7.2. Service Lookup . . . . . . . . . . . . . . . . . . . . . 17
8. Overlay Configuration Document Extension . . . . . . . . . . 17 8. Overlay Configuration Document Extension . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10.1. Access Control Policies . . . . . . . . . . . . . . . . 17 10.1. Access Control Policies . . . . . . . . . . . . . . . . 18
10.2. A New IETF XML Registry . . . . . . . . . . . . . . . . 18 10.2. A New IETF XML Registry . . . . . . . . . . . . . . . . 18
10.3. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 18 10.3. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 19
10.4. RELOAD Services Registry . . . . . . . . . . . . . . . . 18 10.4. RELOAD Services Registry . . . . . . . . . . . . . . . . 19
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . 19 12.1. Normative References . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . 19 12.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
REsource LOcation And Discovery (RELOAD) [RFC6940] is a peer-to-peer REsource LOcation And Discovery (RELOAD) [RFC6940] is a peer-to-peer
signaling protocol that can be used to maintain an overlay network, signaling protocol that can be used to maintain an overlay network,
and to store data in and retrieve data from the overlay. Although and to store data in and retrieve data from the overlay. Although
RELOAD defines a Traversal Using Relays around Network Address RELOAD defines a Traversal Using Relays around Network Address
Translation (TURN) specific service discovery mechanism, it does not Translation (TURN) specific service discovery mechanism, it does not
define a generic service discovery mechanism as a part of the base define a generic service discovery mechanism as a part of the base
skipping to change at page 3, line 24 skipping to change at page 3, line 24
number of nodes that provide the service. The problem is two-fold: number of nodes that provide the service. The problem is two-fold:
the node n that is responsible for service s identified by key k may the node n that is responsible for service s identified by key k may
end up storing a large number of Node-IDs and most importantly, may end up storing a large number of Node-IDs and most importantly, may
also become overloaded since all service lookup requests for service also become overloaded since all service lookup requests for service
s will need to be answered by node n. An efficient service discovery s will need to be answered by node n. An efficient service discovery
mechanism does not overload the nodes storing pointers to service mechanism does not overload the nodes storing pointers to service
providers. In addition, the mechanism must ensure that the load of providers. In addition, the mechanism must ensure that the load of
providing a given service is distributed evenly among the nodes providing a given service is distributed evenly among the nodes
providing the service. providing the service.
It should be noted that a simple service discovery mechanism such as
the one mentioned in the previous paragraph might be an appropriate
solution in a very small overlay network consisting of perhaps tens
of nodes. The ReDiR-based service discovery mechanism described in
this document is suitable for use even in overlay networks where the
number of end-users that may make service discovery requests can be
very high (e.g., tens of thousands of nodes or even higher), and
where a large fraction of the peers (e.g., on the order of one out of
ten or more) can offer the service.
ReDiR implements service discovery by building a tree structure of ReDiR implements service discovery by building a tree structure of
the service providers that provide a particular service. The tree the service providers that provide a particular service. The tree
structure is stored into the RELOAD Overlay Instance using RELOAD structure is stored into the RELOAD Overlay Instance using RELOAD
Store and Fetch requests. Each service provided in the Overlay Store and Fetch requests. Each service provided in the Overlay
Instance has its own tree. The nodes in a ReDiR tree contain Instance has its own tree. The nodes in a ReDiR tree contain
pointers to service providers. During service discovery, a peer pointers to service providers. During service discovery, a peer
wishing to use a given service fetches ReDiR tree nodes one-by-one wishing to use a given service fetches ReDiR tree nodes one-by-one
from the RELOAD Overlay Instance until it finds a service provider from the RELOAD Overlay Instance until it finds a service provider
responsible for its Node-ID. It has been proved that ReDiR can find responsible for its Node-ID. It has been proved that ReDiR can find
a service provider using only a constant number of Fetch operations a service provider using only a constant number of Fetch operations
[Redir]. [Redir].
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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
This document uses the terminology and definitions from the Concepts
and Terminology for Peer to Peer SIP [I-D.ietf-p2psip-concepts]
draft.
DHT: Distributed Hash Tables (DHTs) are a class of decentralized DHT: Distributed Hash Tables (DHTs) are a class of decentralized
distributed systems that provide a lookup service similar to a distributed systems that provide a lookup service similar to a
regular hash table. Given a key, any peer participating in the regular hash table. Given a key, any peer participating in the
system can retrieve the value associated with that key. The system can retrieve the value associated with that key. The
responsibility for maintaining the mapping from keys to values is responsibility for maintaining the mapping from keys to values is
distributed among the peers. distributed among the peers.
H(x): Refers to a hash function (e.g., SHA-1) calculated over the H(x): Refers to a hash function (e.g., SHA-1 [RFC3174]) calculated
value x. over the value x.
H(x,y,z): Refers to a hash function calculated over a concatenated
string consisting of x, y, and z, where x, y, and z can be both
strings and integers. The network byte order is used.
I(lvl,k): An interval at level lvl in the ReDiR tree that encloses I(lvl,k): An interval at level lvl in the ReDiR tree that encloses
key k. As an example, I(5,10) refers to an interval at level 5 in key k. As an example, I(5,10) refers to an interval at level 5 in
the ReDiR tree within whose range key 10 falls. the ReDiR tree within whose range key 10 falls.
n.id: Refers to the RELOAD Node-ID of node n. n.id: Refers to the RELOAD Node-ID of node n.
Namespace: An arbitrary identifier that identifies a service Namespace: An arbitrary identifier that identifies a service
provided in the RELOAD Overlay Instance. Examples of potential provided in the RELOAD Overlay Instance. Examples of potential
namespaces include "voice-mail" and "turn-server". The namespace namespaces include "voice-mail" and "turn-server". The namespace
is an UTF-8 text string. is an UTF-8 [RFC3629] text string.
numBitsInNodeId: Refers to the number of bits in a RELOAD Node-ID. numBitsInNodeId: Refers to the number of bits in a RELOAD Node-ID.
This value is used in the equations for calculating the ranges of This value is used in the equations for calculating the ranges of
intervals that ReDiR tree nodes are responsible for. intervals that ReDiR tree nodes are responsible for.
ReDiR tree: A tree structure of the nodes that provide a particular ReDiR tree: A tree structure of the nodes that provide a particular
service. The nodes embed the ReDiR tree into the RELOAD Overlay service. The nodes embed the ReDiR tree into the RELOAD Overlay
Instance using RELOAD Store and Fetch requests. Each tree node in Instance using RELOAD Store and Fetch requests. Each tree node in
the ReDiR tree belongs to some level in the tree. The root node the ReDiR tree belongs to some level in the tree. The root node
of the ReDiR tree is located at level 0 of the ReDiR tree. The of the ReDiR tree is located at level 0 of the ReDiR tree. The
skipping to change at page 6, line 19 skipping to change at page 6, line 27
by tree node, by storing the values of tree node (level,j) under a by tree node, by storing the values of tree node (level,j) under a
key created by taking a hash over the concatenation of the namespace, key created by taking a hash over the concatenation of the namespace,
level, and j, that is, as H(namespace,level,j). As an example, the level, and j, that is, as H(namespace,level,j). As an example, the
root of the tree for a voice mail service is stored at H("voice- root of the tree for a voice mail service is stored at H("voice-
mail",0,0). Each node (level,j) in the ReDiR tree contains b mail",0,0). Each node (level,j) in the ReDiR tree contains b
intervals of the DHT's identifier space as follows: intervals of the DHT's identifier space as follows:
[2^numBitsInNodeID*b^(-level)*(j+(b'/b)), [2^numBitsInNodeID*b^(-level)*(j+(b'/b)),
2^numBitsInNodeID*b^(-level)*(j+((b'+1)/b))), for 0<=b'<b, 2^numBitsInNodeID*b^(-level)*(j+((b'+1)/b))), for 0<=b'<b,
where b is the branching-factor. where b is the branching-factor and b' refers to the number of an
interval within the ReDiR tree node j.
Figure 1 shows an example of a ReDiR tree whose branching factor is Figure 1 shows an example of a ReDiR tree whose branching factor is
2. In the figure, the size of the identifier space of the overlay is 2. In the figure, the size of the identifier space of the overlay is
16. Each tree node in the ReDiR tree is shown as two horizontal 16. Each tree node in the ReDiR tree is shown as two horizontal
lines separated by a vertical bar ('|') in the middle. The lines separated by a vertical bar ('|') in the middle. The
horizontal lines represent the two intervals each node is responsible horizontal lines represent the two intervals each node is responsible
for. At level 0, there is only one node, (0,0) responsible for two for. At level 0, there is only one node, (0,0) responsible for two
intervals that together cover the entire identifier space of the intervals that together cover the entire identifier space of the
RELOAD Overlay Instance. At level 1, there are two nodes, (1,0) and RELOAD Overlay Instance. At level 1, there are two nodes, (1,0) and
(1,1), each of which is responsible for half of the identifier space (1,1), each of which is responsible for half of the identifier space
skipping to change at page 9, line 38 skipping to change at page 10, line 21
lookup, a peer needs to determine the starting level Lstart for the lookup, a peer needs to determine the starting level Lstart for the
registration or lookup operation in the ReDiR tree. It is registration or lookup operation in the ReDiR tree. It is
RECOMMENDED that Lstart is set to 2. This recommendation is based on RECOMMENDED that Lstart is set to 2. This recommendation is based on
the findings in [Redir], which indicate that this starting level the findings in [Redir], which indicate that this starting level
results in good performance. In subsequent registrations, Lstart results in good performance. In subsequent registrations, Lstart
MAY, as an optimization, be set to the lowest level at which a MAY, as an optimization, be set to the lowest level at which a
registration operation has last completed. registration operation has last completed.
In the case of subsequent service lookups, nodes MAY, as an In the case of subsequent service lookups, nodes MAY, as an
optimization, record the levels at which the last 16 service lookups optimization, record the levels at which the last 16 service lookups
completed and take Lstart to be the mode of those depths. completed and take Lstart to be the mode of those depths (mode, in
statistics, is the value that appears most often in a set of data).
4.3. Service Provider Registration 4.3. Service Provider Registration
A node MUST use the following procedure to register as a service A node MUST use the following procedure to register as a service
provider in the RELOAD Overlay Instance: provider in the RELOAD Overlay Instance:
1. A node n with Node-ID n.id wishing to register as a service 1. A node n with Node-ID n.id wishing to register as a service
provider starts from a starting level Lstart (see Section 4.2 for provider starts from a starting level Lstart (see Section 4.2 for
the details on selecting the starting level). Therefore, node n the details on selecting the starting level). Therefore, node n
sets the current level to level=Lstart. sets the current level to level=Lstart.
skipping to change at page 11, line 12 skipping to change at page 11, line 29
within the tree node) responsible for interval I(l,k). In contrast, within the tree node) responsible for interval I(l,k). In contrast,
I(l,k) refers to a specific interval within a tree node. I(l,k) refers to a specific interval within a tree node.
4.4. Refreshing Registrations 4.4. Refreshing Registrations
All state in the ReDiR tree is soft. Therefore, a service provider All state in the ReDiR tree is soft. Therefore, a service provider
needs to periodically repeat the registration process to refresh its needs to periodically repeat the registration process to refresh its
RedirServiceProvider Resource Record. If a record expires, it MUST RedirServiceProvider Resource Record. If a record expires, it MUST
be dropped from the dictionary by the peer storing the tree node. be dropped from the dictionary by the peer storing the tree node.
Deciding an appropriate lifetime for the RedirServiceProvider Deciding an appropriate lifetime for the RedirServiceProvider
Resource Records is up to each service provider. Every service Resource Records is up to each service provider. However, a default
provider MUST repeat the entire registration process periodically value of 10 minutes is RECOMMENDED as this is a good tradeoff between
until it leaves the RELOAD Overlay Instance. keeping the amount of ReDiR traffic in the overlay at a reasonable
level and ensuring that stale information is removed quickly enough.
Every service provider MUST repeat the entire registration process
periodically until it leaves the RELOAD Overlay Instance. The
service provider SHOULD initiate each refresh process slightly
earlier (e.g., when 90% of the refresh interval has passed) than the
expiry time of the Resource Record.
Note that no new mechanisms are needed to keep track of the remaining Note that no new mechanisms are needed to keep track of the remaining
lifetime of RedirServiceProvider records. The 'storage_time' and lifetime of RedirServiceProvider records. The 'storage_time' and
'lifetime' fields of RELOAD's StoredData structure can be used for 'lifetime' fields of RELOAD's StoredData structure can be used for
this purpose in the usual way. this purpose in the usual way.
4.5. Service Lookups 4.5. Service Lookups
The purpose of a service lookup for identifier k in namespace ns is The purpose of a service lookup for identifier k in namespace ns is
to find the node that is a part of ns and whose identifier most to find the node that is a part of ns and whose identifier most
skipping to change at page 11, line 38 skipping to change at page 12, line 15
A service lookup operation resembles the service registration A service lookup operation resembles the service registration
operation described in Section 4.3. Service lookups start from a operation described in Section 4.3. Service lookups start from a
given starting level level=Lstart in the ReDiR tree (see Section 4.2 given starting level level=Lstart in the ReDiR tree (see Section 4.2
for the details on selecting the starting level). At each step, a for the details on selecting the starting level). At each step, a
node n wishing to discover a service provider MUST fetch the tree node n wishing to discover a service provider MUST fetch the tree
node responsible for the interval I(level,n.id) that encloses the node responsible for the interval I(level,n.id) that encloses the
search key n.id at the current level using a RELOAD Fetch request. search key n.id at the current level using a RELOAD Fetch request.
Having fetched the tree node, node n MUST determine the next action Having fetched the tree node, node n MUST determine the next action
to carry out as follows: to carry out as follows:
1. If there is no successor of node n present in the just fetched Condition 1
ReDiR tree node (note: within the entire tree node and not only
within the current interval) responsible for I(level,n.id), then
the successor of node n must be present in a larger segment of
the identifier space (i.e., further up in the ReDiR tree where
each interval and tree node covers a larger range of the
identifier space). Therefore, node n MUST reduce the current
level by one to level=level-1 and carry out a new Fetch operation
for the tree node responsible for n.id at that level. The
fetched tree node is then analyzed and the next action determined
by checking conditions 1-3.
2. If n.id is neither the lowest nor the highest Node-ID within the If there is no successor of node n present in the just fetched
interval (note: within the interval, not within the entire tree ReDiR tree node (note: within the entire tree node and not only
node) I(level,n.id), n MUST next check the tree node responsible within the current interval) responsible for I(level,n.id), then
for n.id at the next level down the tree. Thus, node n MUST the successor of node n must be present in a larger segment of the
increase the level by one to level=level+1 and carry out a new identifier space (i.e., further up in the ReDiR tree where each
Fetch operation at that level. The fetched tree node is then interval and tree node covers a larger range of the identifier
analyzed and the next action determined by checking conditions space). Therefore, node n MUST reduce the current level by one to
1-3. level=level-1 and carry out a new Fetch operation for the tree
node responsible for n.id at that level. The fetched tree node is
then analyzed and the next action determined by checking
Conditions 1-3.
3. If neither of the conditions above holds, meaning that there is a Condition 2
successor s of n.id present in the just fetched ReDiR tree node
and n.id is the highest or lowest Node-ID in its interval, the If n.id is neither the lowest nor the highest Node-ID within the
service lookup has finished successfully and s must be the interval (note: within the interval, not within the entire tree
closest successor of n.id in the ReDiR tree. node) I(level,n.id), n MUST next check the tree node responsible
for n.id at the next level down the tree. Thus, node n MUST
increase the level by one to level=level+1 and carry out a new
Fetch operation at that level. The fetched tree node is then
analyzed and the next action determined by checking the conditions
listed here starting at Condition 1.
Condition 3
If neither of the conditions above holds, meaning that there is a
successor s of n.id present in the just fetched ReDiR tree node
and n.id is the highest or lowest Node-ID in its interval, the
service lookup has finished successfully and s must be the closest
successor of n.id in the ReDiR tree.
Note that above, when we refer to 'the tree node responsible for Note that above, when we refer to 'the tree node responsible for
interval I(l,k)', we mean the entire tree node (that is, all the interval I(l,k)', we mean the entire tree node (that is, all the
intervals within the tree node) responsible for interval I(l,k). In intervals within the tree node) responsible for interval I(l,k). In
contrast, I(l,k) refers to a specific interval within a tree node. contrast, I(l,k) refers to a specific interval within a tree node.
Note also that there may be some cases in which no successor can be Note also that there may be some cases in which no successor can be
found from the ReDiR tree. An example is a situation in which all of found from the ReDiR tree. An example is a situation in which all of
the service providers stored in the ReDiR tree have a Node-ID smaller the service providers stored in the ReDiR tree have a Node-ID smaller
than identifier k. In this case, the upward walk of the service than identifier k. In this case, the upward walk of the service
skipping to change at page 13, line 9 skipping to change at page 13, line 46
RedirServiceProvider entries that have been fetched during the upward RedirServiceProvider entries that have been fetched during the upward
and downward walks of a service lookup operation. Should it happen and downward walks of a service lookup operation. Should it happen
that a service lookup operation fails due to the downward walk that a service lookup operation fails due to the downward walk
reaching a level that does not contain a successor, the cache is reaching a level that does not contain a successor, the cache is
searched for successors of the search key. If there are successors searched for successors of the search key. If there are successors
present in the cache, the closest one of them is selected as the present in the cache, the closest one of them is selected as the
service provider. service provider.
4.6. Removing Registrations 4.6. Removing Registrations
Before leaving the RELOAD Overlay Instance, a service provider MUST Before leaving the RELOAD Overlay Instance, a service provider SHOULD
remove the RedirServiceProvider records it has stored by storing remove the RedirServiceProvider records it has stored by storing
exists=False values in their place, as described in [RFC6940]. exists=False values in their place, as described in [RFC6940].
5. Access Control Rules 5. Access Control Rules
As specified in RELOAD base [RFC6940], every Kind which is storable As specified in RELOAD base [RFC6940], every Kind which is storable
in an overlay must be associated with an access control policy. This in an overlay must be associated with an access control policy. This
policy defines whether a request from a given node to operate on a policy defines whether a request from a given node to operate on a
given value should succeed or fail. Usages can define any access given value should succeed or fail. Usages can define any access
control rules they choose, including publicly writable values. control rules they choose, including publicly writable values.
skipping to change at page 17, line 17 skipping to change at page 18, line 4
This document extends the RELOAD overlay configuration document by This document extends the RELOAD overlay configuration document by
adding a new element "branching-factor" inside the new "REDIR" kind adding a new element "branching-factor" inside the new "REDIR" kind
element: element:
redir:branching-factor: The branching factor of the ReDir tree. The redir:branching-factor: The branching factor of the ReDir tree. The
default value is 10. default value is 10.
The Relax NG Grammar for this element is: The Relax NG Grammar for this element is:
namespace redir = "urn:ietf:params:xml:ns:p2p:redir" namespace redir = "urn:ietf:params:xml:ns:p2p:redir"
parameter &= element redir:branching-factor { xsd:unsignedInt }? parameter &= element redir:branching-factor { xsd:unsignedInt }?
The 'redir' namespace is added into the <mandatory-extension> element The 'redir' namespace is added into the <mandatory-extension> element
in the overlay configuration file. in the overlay configuration file.
9. Security Considerations 9. Security Considerations
There are no new security considerations introduced in this document. This document defines a new access control policy called NODE-ID-
The security considerations of RELOAD [RFC6940] apply. MATCH (see Section 5) whose purpose is to control which nodes in the
overlay are allowed read and write access to the ReDiR tree nodes.
The NODE-ID-MATCH access control policy ensures that the only node in
the overlay that can store a pointer to a specific service provider
in the ReDiR tree is the service provider itself. This prevents
attacks where a malicious node is inserting pointers to other nodes
in the ReDiR tree. Further, the NODE-ID-MATCH access control policy
ensures that a node can only store in locations in the ReDiR tree
where it is entitled to store information. In other words, a node
can only store one RedirServiceProvider record at any given level in
the ReDiR tree. This prevents an attack where a malicious node is
trying to insert a high number of pointers to the ReDiR tree.
It should be noted that this document defines a new access control When it comes to attacks such as a malicious node refusing to store a
policy called NODE-ID-MATCH (see Section 5) whose purpose is to value or denying knowledge of value it has previously accepted, such
control which nodes in the overlay are allowed read and write access security concerns are already discussed in the RELOAD base
to the ReDiR tree nodes. specification [RFC6940].
10. IANA Considerations 10. IANA Considerations
10.1. Access Control Policies 10.1. Access Control Policies
This document introduces one additional access control policy to the This document introduces one additional access control policy to the
"RELOAD Access Control Policy" Registry: "RELOAD Access Control Policy" Registry:
NODE-ID-MATCH NODE-ID-MATCH
skipping to change at page 19, line 29 skipping to change at page 20, line 15
mechanism specified in the RELOAD base specification [RFC6940]. The mechanism specified in the RELOAD base specification [RFC6940]. The
namespace 'voice-mail' is intended for a voice mail service namespace 'voice-mail' is intended for a voice mail service
implemented on top of a RELOAD overlay. implemented on top of a RELOAD overlay.
Note to RFC Editor: please replace AAAA with the RFC number for this Note to RFC Editor: please replace AAAA with the RFC number for this
specification. specification.
11. Acknowledgments 11. Acknowledgments
The authors would like to thank Marc Petit-Huguenin, Joscha The authors would like to thank Marc Petit-Huguenin, Joscha
Schneider, and Carlos Bernardos for their comments on the document. Schneider, Carlos Bernardos, Spencer Dawkins, Barry Leiba, Adrian
Farrel, Alexey Melnikov, Ted Lemon, and Stephen Farrell for their
comments on the document.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, September 2001.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[RFC6940] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and [RFC6940] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", RFC 6940, January 2014. Base Protocol", RFC 6940, January 2014.
12.2. Informative References 12.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-06 (work in progress), June
2014.
[Redir] Rhea, S., Godfrey, P., Karp, B., Kubiatowicz, J., [Redir] Rhea, S., Godfrey, P., Karp, B., Kubiatowicz, J.,
Ratnasamy, S., Shenker, S., Stoica, I., and H. Yu, "Open Ratnasamy, S., Shenker, S., Stoica, I., and H. Yu, "Open
DHT: A Public DHT Service and Its Uses", October 2005. DHT: A Public DHT Service and Its Uses", October 2005.
Authors' Addresses Authors' Addresses
Jouni Maenpaa Jouni Maenpaa
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Jouni.Maenpaa@ericsson.com Email: Jouni.Maenpaa@ericsson.com
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
 End of changes. 25 change blocks. 
70 lines changed or deleted 105 lines changed or added

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