One document matched: draft-rosenberg-dispatch-vipr-reload-usage-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="yes" ?>
<?rfc strict="no" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<?rfc colonspace="yes" ?>
<?rfc rfcedstyle="no" ?>
<?rfc tocdepth="4"?>
<rfc category="std" docName="draft-rosenberg-dispatch-vipr-reload-usage-03"
ipr="trust200902">
<front>
<title abbrev="ViPR Reload Usage">A Usage of Resource Location and
Discovery (RELOAD) for Public Switched Telephone Network (PSTN)
Verification</title>
<author fullname="Jonathan Rosenberg" initials="J.R." surname="Rosenberg">
<organization>jdrosen.net</organization>
<address>
<postal>
<street></street>
<city>Monmouth</city>
<region>NJ</region>
<country>US</country>
</postal>
<email>jdrosen@jdrosen.net</email>
<uri>http://www.jdrosen.net</uri>
</address>
</author>
<author fullname="Cullen Jennings" initials="C." surname="Jennings">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone>+1 408 421-9990</phone>
<email>fluffy@cisco.com</email>
</address>
</author>
<author fullname="Marc Petit-Huguenin" initials="M."
surname="Petit-Huguenin">
<organization>Stonyfish</organization>
<address>
<email>marc@stonyfish.com</email>
</address>
</author>
<date day="25" month="October" year="2010" />
<area>RAI</area>
<workgroup>dispatch</workgroup>
<abstract>
<t>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.</t>
</abstract>
<note title="Legal">
<t>This documents and the information contained therein 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 THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>This document relies heavily on the concepts and terminology defined
in <xref target="VIPR-OVERVIEW"></xref> and will not make sense if you
have not read that document first. As it defines a usage for RELOAD
<xref target="P2PSIP-BASE"></xref>, it assumes the reader is also
familiar with that specification. The same DHT can also be used for a
RELOAD SIP usage <xref target="P2PSIP-SIP"></xref>.</t>
</section>
<section title="ViPR Usage ">
<t>The ViPR usage defines details for how the DHT is used for ViPR
operations.</t>
<t>The ViPR usage defines Kind-ID 0x00000001. This Kind-ID is a
dictionary entry. Its Resource-ID is defined through a transformation
which takes an E.164 based number, and computes a Resource-ID as the
least significant 128 bits of the SHA1 hash of the following string:
Cat(CHOICE(null, "COPY", "COPY2"), number) That is, the Resource-ID is
the hash of a string which is the concatenation of the number, prefixed
with nothing, or the words "COPY1" or "COPY2".</t>
<t>For example, for number +14085555432:</t>
<t>Resource-ID = least128(SHA1("+14085555432"))</t>
<t>or</t>
<t>Resource-ID = least128(SHA1("COPY1+14085555432"))</t>
<t>or</t>
<t>Resource-ID = least128(SHA1("COPY2+14085555432"))</t>
<t>The object stored at this resource ID is a dictionary entry, which
has a key and a value:</t>
<t>Object = {key,value}</t>
<t>Here, the key is formed by taking the Node-ID of the storing node in
hex format, without the "0x", appending a "+", followed by the
VServiceID in hex format, without the "0x". For example, if a peer with
Node-ID</t>
<t>0x8f60f5eab753037e64ab6c53947fd532</t>
<t>receives a Publish with a VServiceID of</t>
<t>0x7eeb6a7036478351</t>
<t>The resulting key is:</t>
<t>8f60f5eab753037e64ab6c53947fd532+7eeb6a7036478351</t>
<t>Both parts of this key are important. Using the Node-ID of the node
performing the store basically segments the keyspace of the dictionary
so that no two peers ever store using the same key. Indeed, the
responsible node will verify the signature over the stored data and
check the Node-ID against the value of the key, to make sure that a
conflict does not take place. The usage of 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 responsible node does not verify or check the
VServiceID.</t>
<t>When a node receives a Store operation for this usage, the data
itself has a signature. The node responsible for storing the data must
verify this signature; the certificate will always be included in the
data and indicate which Node-ID is used. The responsible node must check
that this Node-ID is included in the cert. If the signature verifies,
the responsible node checks that the data model is a dictionary entry.
The key must meet the format above. The responsible node must check that
it is a 32 character sequence of numbers and letters a-f, followed by a
+, followed by a 16 character sequence of numbers and letters a-f. If
this checks, the key is split in half along the plus. The first 32
characters are considered a hex value and compared with the Node-ID used
for the signature. If they match, it is good. Otherwise the Store
operation is rejected. If they did match, next the responsible node
checks the value. It must be a TLV, with the same format used by VAP,
and it must contain a single Node-ID attribute. The Node-ID must match
that used for the signature. If they don't match, the Store operation is
rejected. If they do match, the next step is a quota check.</t>
<t>For each peer that the responsible node is storing data for, it must
maintain a count of the number of unique dictionary entries being stored
for that Node-ID. For each resourceID, each key constitutes a unique
dictionary entry. So if a peer is storing 5 resourceIDs, and at each of
those 5, there are two keys whose first 32 bits correspond to a
particular Node-ID, it means this node is currently storing 10 unique
dictionary entries for that Node-ID.</t>
<t>It takes the StorageQuota configuration parameter for this DHT, which
measures the amount of numbers a particular node can store. That value
is multiplied by nine (a 3x factor to account for the application-layer
copies (COPY1 and COPY2), and another 3x factor for replicas). Then, an
addition 3x factor is added for rounding to make sure that the
probability is low that a rejection occurs due to imperfect distribution
of resourceIDs across the ring. (Open Issue: need to adjust this
multiplier - basically birthday problem!) and then divided by the
fraction of the hashspace owned by this ViPR server. If the result is
less than one, it is rounded up to two. This is the max number of unique
entries that can be stored for this storing peer ID. If the ViPR server
is not yet storing this many entries for that peer ID, the store is
allowed.</t>
<t>The method for merging data after a partition follows the normal
RELOAD rules around temporal ordering.</t>
</section>
<section title="PeerID Shim">
<t>Because the ViPR implementation of RELOAD protocol makes use of the
concept of multiple Node-ID on the same physical box, utilizing a single
cert, the TLS handshakes alone are not sufficient to determine the
entity on both sides of the TLS connection. As such, we will have a
small "shim" type of protocol, which runs after TLS, but is not formally
part of RELOAD.</t>
<t>When a node initiates a TLS connection towards another node, after
the TLS completes, it sends this message. The message contains the
Node-ID associated with this connection. The recipient gets this, and
sends back a similar message, containing its Node-ID. Both sides will
verify that, the Node-ID sent by the other side, are amongst the
Node-IDs listed in the certificate. The connections are then stored in
the connection tables, indexed by this Node-ID.</t>
<t>Furthermore, if, after this exchange, a node determines that it
already has a connection in its connection table with that Node-ID on
the far side, the older connection is closed. This is actually a
critical security function! Without this, a user could clone ViPR
servers utilizing the same certs, and each one can join the network.</t>
<t>Finally, once the exchange has taken place, the node compares the
Node-ID from its peer with the current set of blacklisted Node-ID from
the ACL that is distributed through the DHT. If the remote Node-ID
appears on the list, the node closes the TCP/TLS connection
immediately.</t>
<t>The reason we are using a non-reload message for this, is that we
need to be 100% sure that this never propagates. It is strictly over a
single connection and should never be routed. Indeed, had we not had
this idea of multiple Node-ID in a single cert, this would have
effectively been accomplished through TLS. Alternatively, there is a TLS
command for telling the other side who I expect them to be; however this
is not implemented in older versions of OpenSSL, and so our shim forms
an alternative to that which can be run on top of OpenSSL.</t>
</section>
<section title="Security Considerations">
<t>TBD</t>
</section>
<section title="IANA Considerations">
<t>TBD. Need to register items in IANA registries created by RELOAD.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="P2PSIP-BASE">
<front>
<title>REsource LOcation And Discovery (RELOAD) Base
Protocol</title>
<author fullname="Cullen Jennings" initials="C" surname="Jennings">
<organization></organization>
</author>
<author fullname="Bruce Lowekamp" initials="B" surname="Lowekamp">
<organization></organization>
</author>
<author fullname="Eric Rescorla" initials="E" surname="Rescorla">
<organization></organization>
</author>
<author fullname="Salman Baset" initials="S" surname="Baset">
<organization></organization>
</author>
<author fullname="Henning Schulzrinne" initials="H"
surname="Schulzrinne">
<organization></organization>
</author>
<date day="12" month="October" year="2010" />
<abstract>
<t>In this document the term BCP 78 and BCP 79 refer to RFC 3978
and RFC 3979 respectively. They refer only to those RFCs and not
to any documents that update or supersede them. This specification
defines REsource LOcation And Discovery (RELOAD), a peer-to-peer
(P2P) signaling protocol for use on the Internet. A P2P signaling
protocol provides its clients with an abstract storage and
messaging service between a set of cooperating peers that form the
overlay network. RELOAD is designed to support a P2P Session
Initiation Protocol (P2PSIP) network, but can be utilized by other
applications with similar requirements by defining new usages that
specify the kinds of data that must be stored for a particular
application. RELOAD defines a security model based on a
certificate enrollment service that provides unique identities.
NAT traversal is a fundamental service of the protocol. RELOAD
also allows access from "client" nodes that do not need to route
traffic or store data for others. Legal This documents and the
information contained therein 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 THEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-p2psip-base-11" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-11.txt"
type="TXT" />
</reference>
<reference anchor="VIPR-OVERVIEW">
<front>
<title>Verification Involving PSTN Reachability: Requirements and
Architecture Overview</title>
<author fullname="Jonathan Rosenberg" initials="J.R."
surname="Rosenberg">
<organization></organization>
</author>
<author fullname="Cullen Jennings" initials="C." surname="Jennings">
<organization></organization>
</author>
<author fullname="Marc Petit-Huguenin" initials="M."
surname="Petit-Huguenin">
<organization></organization>
</author>
<date day="17" month="October" year="2010" />
<area>RAI</area>
<workgroup>dispatch</workgroup>
<abstract>
<t>The Session Initiation Protocol (SIP) has seen widespread
deployment within individual domains, typically supporting voice
and video communications. Though it was designed from the outset
to support inter-domain federation over the public Internet, such
federation has not materialized. The primary reasons for this are
the complexities of inter-domain phone number routing and concerns
over security. This document reviews this problem space, outlines
requirements, and then describes a new model and technique for
inter-domain federation with SIP, called Verification Involving
PSTN Reachability (ViPR). ViPR addresses the problems that have
prevented inter-domain federation over the Internet. It provides
fully distributed inter-domain routing for phone numbers,
authorized mappings from phone numbers to domains, a new technique
for automated VoIP anti-spam, and privacy of number ownership, all
while preserving the trapezoidal model of SIP.</t>
</abstract>
<note title="Legal">
<t>This documents and the information contained therein 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 THEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.</t>
</note>
</front>
<seriesInfo name="Internet-Draft"
value="draft-rosenberg-dispatch-vipr-overview-04" />
<format target="http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-overview-04.txt"
type="TXT" />
</reference>
</references>
<references title="Informative References">
<reference anchor="P2PSIP-SIP">
<front>
<title>A SIP Usage for RELOAD</title>
<author fullname="Cullen Jennings" initials="C" surname="Jennings">
<organization></organization>
</author>
<author fullname="Bruce Lowekamp" initials="B" surname="Lowekamp">
<organization></organization>
</author>
<author fullname="Eric Rescorla" initials="E" surname="Rescorla">
<organization></organization>
</author>
<author fullname="Salman Baset" initials="S" surname="Baset">
<organization></organization>
</author>
<author fullname="Henning Schulzrinne" initials="H"
surname="Schulzrinne">
<organization></organization>
</author>
<date day="12" month="July" year="2010" />
<abstract>
<t>This document defines a SIP Usage for REsource LOcation And
Discovery (RELOAD), The SIP Usage provides the functionality of a
SIP proxy or registrar in a fully-distributed system. The SIP
Usage provides lookup service for AoRs stored in the overlay. The
SIP Usage also defines GRUUs that allow the registrations to map
an AoR to a specific node reachable through the overlay. The
AppAttach method is used to establish a direct connection between
nodes through which SIP messages are exchanged.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-p2psip-sip-05" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-p2psip-sip-05.txt"
type="TXT" />
</reference>
</references>
<section title="Release notes">
<t>This section must be removed before publication as an RFC.</t>
<section title="Modifications between rosenberg-03 and rosenberg-02">
<t><list style="symbols">
<t>Nits.</t>
<t>Shorter I-Ds references.</t>
<t>Fixed the peerID and VServiceID to be hexadecimal.</t>
<t>Fixed the description of the dictionary entry</t>
<t>Fixed the description of the TLV.</t>
<t>Used +1 408 555 prefix for phone numbers in examples.</t>
<t>Replaced peerId by Node-ID</t>
<t>Replaced resourceID by Resource-ID</t>
</list></t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 09:18:59 |