Internet DRAFT - draft-petithuguenin-vipr-reload-usage
draft-petithuguenin-vipr-reload-usage
VIPR M. Petit-Huguenin
Internet-Draft Unaffiliated
Intended status: Standards Track J. Rosenberg
Expires: September 13, 2012 jdrosen.net
C. Jennings
Cisco
March 12, 2012
A Usage of Resource Location and Discovery (RELOAD) for Public Switched
Telephone Network (PSTN) Verification
draft-petithuguenin-vipr-reload-usage-04
Abstract
Verification Involving PSTN Reachability (VIPR) is a technique for
inter-domain SIP federation. VIPR makes use of the RELOAD protocol
to store unverified mappings from phone numbers to RELOAD nodes, with
whom a validation process can be run. This document defines the
usage of RELOAD for this purpose.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 13, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Petit-Huguenin, et al. Expires September 13, 2012 [Page 1]
Internet-Draft VIPR Reload Usage March 2012
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Registering an E.164 number . . . . . . . . . . . . . . . . . 3
4. Fetching a registration . . . . . . . . . . . . . . . . . . . 4
5. VIPR-REGISTRATION Kind Definition . . . . . . . . . . . . . . 5
6. Overlay Configuration Document Extension . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8.1. Access Control Policies . . . . . . . . . . . . . . . . . 6
8.2. Application-ID . . . . . . . . . . . . . . . . . . . . . . 6
8.3. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . . 7
8.4. IETF XML Namespaces Registry . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . . 8
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 8
Appendix B. Release notes . . . . . . . . . . . . . . . . . . . . 9
B.1. Modifications between vipr-04 and vipr-03 . . . . . . . . 9
B.2. Modifications between vipr-03 and vipr-02 . . . . . . . . 9
B.3. Modifications between vipr-02 and vipr-01 . . . . . . . . 9
B.4. Modifications between vipr-01 and vipr-00 . . . . . . . . 10
B.5. Modifications between vipr-00 and dispatch-03 . . . . . . 10
B.6. Modifications between dispatch-03 and dispatch-02 . . . . 10
B.7. Running Code Considerations . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Petit-Huguenin, et al. Expires September 13, 2012 [Page 2]
Internet-Draft VIPR Reload Usage March 2012
1. Introduction
This document relies heavily on the concepts and terminology defined
in [VIPR-OVERVIEW] and will not make sense if you have not read that
document first. As it defines a usage for RELOAD [P2PSIP-BASE], it
assumes the reader is also familiar with that specification.
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 [RFC2119].
3. Registering an E.164 number
To register an E.164 number a VIPR server stores a ViprRegistration
structure using the fully qualified E.164 based number without any
non-digit characters but the '+' character as Resource Name.
The contents of the ViprRegistration structure are as follow:
enum { reserved(0), node_id(8200), (65535) } ViprRegistrationType;
struct {
opaque name<0..2^8-1>;
} Method;
struct {
select (ViprRegistrationType) {
case node_id:
Destination pvp_provider<0..2^16-1>;
Method methods<0..2^16-1>;
/* This type can be extended */
} ViprRegistrationData;
struct {
ViprRegistrationType type;
uint16 length;
ViprRegistrationData data;
} ViprRegistration;
The ViprRegistration structure contains the following values:
Petit-Huguenin, et al. Expires September 13, 2012 [Page 3]
Internet-Draft VIPR Reload Usage March 2012
type
The type of the registration
length
The length of the data structure, i.e. not counting the type and
length fields
pvp_provider
A sequence of destinations to which an AppAttach request should be
sent to initiate the PVP protocol
methods
The set of methods that the PVP client can try to validate a PSTN
call to the E.164 number used as Resource Name. The format of the
method name is defined in [VIPR-PVP].
The Node-ID used in the key MUST be ready to process AppAttach
requests for Application-ID 8470 at the time the registration is
done.
VIPR supports multiple registrations for a single E.164 number by
using a Dictionary Data Model. The dictionary key is the
concatenation of the Node-ID and the VServiceId, resulting in a 24
bytes long value. Using the Node-ID of the node performing the store
segments the keyspace of the dictionary so that no two peers ever
store using the same key. Using the VService allows for a single
VIPR server to service multiple clusters, and to ensure that numbers
published by one cluster (using one VServiceID) do not clobber or
step on numbers published by another cluster (using a different
VServiceID).
The Store operations are paced into the overlay at a fixed rate. The
VIPR server maintains a queue that is filled with store requests.
The VIPR server services that queue at a fixed, provisioned rate,
which is stored in a kind configuration variable named <store-rate-
limit>.
4. Fetching a registration
A VIPR server wishing to validate a E.164 number will start a Fetch
transaction using the fully qualified E.164 based number without any
non-digit characters but the '+' character as Resource Name. The
VIPR server will also retrieves the two replicas of the resource
record just retrieved.
The VIPR server will then inspects the elements in the 3 resource
Petit-Huguenin, et al. Expires September 13, 2012 [Page 4]
Internet-Draft VIPR Reload Usage March 2012
record returned and will keep only the registrations that have the
same key in at least 2 of the 3 resource records returned. For each
registration kept, the VIPR server will fetch the certificates
associated with the Node-ID in the key using the CERTIFICATE_BY_NODE
usage and will verify that the signature of the registration is
valid.
The VIPR server can then send an AppAttach to the Node-ID found in
the key and registration, using the Application-ID 8470. After the
connection is established, the VIPR server can start PVP as specified
in [VIPR-PVP].
5. VIPR-REGISTRATION Kind Definition
Name VIPR-REGISTRATION
Kind Ids The Resource Name for the VIPR-REGISTRATION Kind-ID is a
fully qualified E.164 based number without any non-digit
characters but the '+' character. The data stored is a
ViprRegistration, which contains the Node-ID of the peer to which
an AppAttach request should be sent to initiate the PVP protocol.
Data Model The data model for the VIPR Kind-ID is dictionary. The
dictionary key is the concatenation of the Node-ID and the
VServiceId, resulting in a 24 bytes long value. Using the Node-ID
of the node performing the store segments the keyspace of the
dictionary so that no two peers ever store using the same key and
using the VService allows for a single VIPR server to service
multiple clusters, and to ensure that numbers published by one
cluster (using one VServiceID) do not clobber or step on numbers
published by another cluster (using a different VServiceID).
Access Control The VIPR-MATCH policy can only be used with a VIPR-
REGISTRATION Kind-ID. In this policy, a given value MUST be
written (or overwritten) if and only if the first 16 bytes of the
dictionary key is equal to the Node-ID is indicated in the
SignerIdentity of the value. Note that VIPR always let the values
stored expire, so the exists field is always equal to TRUE.
Quota This kind MUST use the proportional quota algorithm described
in [RELOAD-QUOTA] by adding the <max-count-per> element with a
value of "SIGNER" to the configuration file. A VIPR server MUST
provide enough Node-IDs to store all the E.164 numbers it is
responsible for by dividing this count by the <max-count> value,
itself adjusted by an additional 3x factor to make sure that the
probability is low that a rejection occurs due to imperfect
distribution of Resource-IDs across the ring.
Petit-Huguenin, et al. Expires September 13, 2012 [Page 5]
Internet-Draft VIPR Reload Usage March 2012
[[Open Issue: need to adjust the multiplier - basically birthday
problem!]]
The method for merging data after a partition follows the normal
RELOAD rules around temporal ordering.
6. Overlay Configuration Document Extension
This document extends the overlay configuration document by defining
a new element in the "urn:ietf:params:xml:ns:p2p:vipr" namespace.
The <store-rate-limit> defines the maximum rate in seconds that a
VIPR server must use to execute Store requests.
The Compact Relax NG Grammar for this element is:
namespace vipr = "urn:ietf:params:xml:ns:p2p:vipr"
parameter &= element vipr:store-rate-limit { xsd:unsignedInt }
7. Security Considerations
TBD
8. IANA Considerations
8.1. Access Control Policies
This document adds a new access control policy to the "RELOAD Access
Control Policy" Registry:
+---------------+---------------+
| Access-Policy | RFC |
+---------------+---------------+
| VIPR-MATCH | This document |
+---------------+---------------+
This access control policy was described in Section 5.
8.2. Application-ID
This document adds a new application ID to the "RELOAD
Application-ID" Registry:
Petit-Huguenin, et al. Expires September 13, 2012 [Page 6]
Internet-Draft VIPR Reload Usage March 2012
+-------------+----------------+---------------+
| Application | Application-ID | Specification |
+-------------+----------------+---------------+
| PVP | 8470 | This document |
+-------------+----------------+---------------+
This access control policy was described in Section 5.
8.3. Data Kind-ID
This document adds a new Data Kind-ID to the "RELOAD Data Kind-ID
Registry":
+-------------------+---------+---------------+
| KIND | Kind-ID | RFC |
+-------------------+---------+---------------+
| VIPR-REGISTRATION | 17 | This document |
+-------------------+---------+---------------+
This Kind-ID was defined in Section 5.
8.4. IETF XML Namespaces Registry
This document adds the following URN to the "XML Namespaces" class of
the "IETF XML Registry":
urn:ietf:params:xml:ns:p2p:vipr
9. Acknowledgements
This document was improved by the input from the VIPR Design Team:
Mary Barnes
Daryl Malas
Hakim Mehmood
Muthu Arul Mozhi Perumal
Jon Peterson
Marc Petit-Huguenin
Michael Procter
John Ward
Dean Willis
This document was written with the xml2rfc tool described in
[RFC2629].
10. References
Petit-Huguenin, et al. Expires September 13, 2012 [Page 7]
Internet-Draft VIPR Reload Usage March 2012
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[P2PSIP-BASE]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", draft-ietf-p2psip-base-20 (work in
progress), January 2012.
[VIPR-OVERVIEW]
Barnes, M., Jennings, C., Rosenberg, J., and M. Petit-
Huguenin, "Verification Involving PSTN Reachability:
Requirements and Architecture Overview",
draft-jennings-vipr-overview-02 (work in progress),
September 2011.
[VIPR-PVP]
Petit-Huguenin, M., Rosenberg, J., and C. Jennings, "The
Public Switched Telephone Network (PSTN) Validation
Protocol (PVP)", draft-petithuguenin-vipr-pvp-04 (work in
progress), March 2012.
[RELOAD-QUOTA]
Petit-Huguenin, M., Rosenberg, J., and C. Jennings,
"Proportional Quota in REsource LOcation And Discovery
(RELOAD)", draft-petithuguenin-vipr-proportional-quota-00
(work in progress), October 2011.
10.2. Informative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[ACCESS-CONTROL]
Petit-Huguenin, M., "Configuration of Access Control
Policy in REsource LOcation And Discovery (RELOAD) Base
Protocol", draft-petithuguenin-p2psip-access-control-04
(work in progress), October 2011.
Appendix A. Examples
The Resource Name and Resource-ID for the E.164 number +1 408 555
5432 are:
Petit-Huguenin, et al. Expires September 13, 2012 [Page 8]
Internet-Draft VIPR Reload Usage March 2012
+---------------+---------------------------------+
| Resource Name | Resource-ID |
+---------------+---------------------------------+
| +14085555432 | 6abaec4308294521e2f600ab5fd01e5 |
+---------------+---------------------------------+
The VIPR-MATCH access control can be implemented with the following
code (Using the notation in [ACCESS-CONTROL]):
var equals = function(a, b) {
if (a.length !== b.length) return false;
for (var i = 0; i < a.length; i++) {
if (a[i] !== b[i]) return false;
}
return true;
};
var length = configuration.node_id_length;
return equals(entry.key.slice(0, length), signature.node_id);
Appendix B. Release notes
This section must be removed before publication as an RFC.
B.1. Modifications between vipr-04 and vipr-03
o The ViprRegistration record now contains a destination list
instead of a Node-ID.
B.2. Modifications between vipr-03 and vipr-02
o The E.164 number is no longer stored 3 times.
o Moved the <store-rate-limit> parameter under the <configuration>
element.
o The VIPR registration now also contains the list of supported PVP
methods.
B.3. Modifications between vipr-02 and vipr-01
o Made clear in the access control policy that exists is always
equal to TRUE.
o Updated with new version of proportional-quota.
o The access control code now uses the configuration parameter.
o Assigned values to Application-ID and Kind-ID.
o Added running code section.
Petit-Huguenin, et al. Expires September 13, 2012 [Page 9]
Internet-Draft VIPR Reload Usage March 2012
o Nits
B.4. Modifications between vipr-01 and vipr-00
o Moved most of the quota algorithm to a separate I-D named
draft-petithuguenin-p2psip-proportional-quota.
o Removed the text saying that the same DHT can also be used for a
RELOAD SIP usage, as it contradicts text in overview. Also the
quota algorithm does not work with clients, but SIP registration
uses clients.
o Added Terminology section
o Converted the TLV value stored to a structure using the syntax
described in p2psip-base to not be dependent on VAP. The new
structure is bit compatible with the old definition.
o Changed the dictionary key to be binary based instead of text
based.
o Copied text from VAP explaining that the Store operations are
queued and that the rate is limited.
o Added voting algorithm when fetch returns different results for
the 3 copies.
o Added explanation on how to verify the signatures.
o Added text on how to form the PVP connection
o Rewrote some of the text so it looks more like a regular RELOAD
usage.
o Removed section 3 "PeerID Shim" now that support for multiple
Node-ID in certificates in fully integrated in RELOAD base.
o Filled IANA section
o Added examples of conversion from E.164 number to Resource-ID
o Added example code for the VIPR access control
B.5. Modifications between vipr-00 and dispatch-03
o Moved to new Working Group.
B.6. Modifications between dispatch-03 and dispatch-02
o Nits.
o Shorter I-Ds references.
o Fixed the peerID and VServiceID to be hexadecimal.
o Fixed the description of the dictionary entry
o Fixed the description of the TLV.
o Used +1 408 555 prefix for phone numbers in examples.
o Replaced peerId by Node-ID
o Replaced resourceID by Resource-ID
Petit-Huguenin, et al. Expires September 13, 2012 [Page 10]
Internet-Draft VIPR Reload Usage March 2012
B.7. Running Code Considerations
o Reference Implementation for the kind and access control policy
(<http://debian.implementers.org/testing/source/reload.tar.gz>).
Marc Petit-Huguenin. Implements version -02.
Authors' Addresses
Marc Petit-Huguenin
Unaffiliated
Email: petithug@acm.org
Jonathan Rosenberg
jdrosen.net
Monmouth, NJ
US
Email: jdrosen@jdrosen.net
URI: http://www.jdrosen.net
Cullen Jennings
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Phone: +1 408 421-9990
Email: fluffy@cisco.com
Petit-Huguenin, et al. Expires September 13, 2012 [Page 11]
