One document matched: draft-rosenberg-dispatch-vipr-reload-usage-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?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-00"
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 />
<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>
<street>MS: SJC-21/2</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>
<date day="9" month="November" year="2009" />
<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="I-D.rosenberg-dispatch-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="I-D.ietf-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="I-D.ietf-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 resourceID 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 +17327662496:</t>
<t>ResourceID= least128(SHA1("+17327662496"))</t>
<t>or</t>
<t>ResourceID = least128(SHA1("COPY1+7327662496"))</t>
<t>or</t>
<t>ResourceID = least128(SHA1("COPY2+7327662496"))</t>
<t>The object stored at this resource ID is a dictionary entry, which
uses data model 0x??. Object = {key,value} Here, the key is formed by
taking the peerID 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 peerID</t>
<t>0x8h60f5gab753037g64ab6c53947fd532</t>
<t>receives a Publish with a Vservice of</t>
<t>0x7ggb6a7036478351</t>
<t>The resulting key is:</t>
<t>8h60f5gab753037g64ab6c53947fd532+7ggb6a7036478351</t>
<t>Both parts of this key are important. Using the peerID of the node
performing the store basically segments the keyspace of the dictionary
so that no two peers every store using the same key. Indeed, the
responsible node will verify the signature over the stored data and
check the peerID 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 Vservice ID) do not clobber
or step on numbers published by another cluster (using a different
Vservice ID). 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 peerID is used. The responsible node must check
that this peerID 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 peerID used for the
signature. If they match, it is good. Otherwise the Store is rejected.
If they did match, next the responsible node checks the value. It must
be a TLV as defined below, and must contain a peerID. The peerID must
match that used for the signature. If they don't match, the Store 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 peerID. For each resourceID, each key constitutes a unique
dictionary entry. So if a peer is storing 5 resource IDs, and at each of
those 5, there are two keys whose first 32 bits correspond to a
particular peerID, it means this node is currently storing 10 unique
dictionary entries for that peerID.</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 peerID 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
peerID associated with this connection. The recipient gets this, and
sends back a similar message, containing its peerID. Both sides will
verify that, the peerID sent by the other side, are amongst the peerIDs
listed in the certificate. The connections are then stored in the
connection tables, indexed by this peerID.</t>
<t>Furthermore, if, after this exchange, a node determines that it
already has a connection in its connection table with that peerID 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
peerID from its peer with the current set of blacklisted peerID from the
ACL that is distributed through the DHT. If the remote peerID 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 peerID 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">
<?rfc include="reference.I-D.ietf-p2psip-base"?>
<reference anchor="I-D.rosenberg-dispatch-vipr-overview">
<front>
<title abbrev="VIPR Overview">Verification Involving PSTN
Reachability: Requirements and Architecture Overview</title>
<author fullname="Jonathan Rosenberg" initials="J.R."
surname="Rosenberg">
<address>
<postal>
<street />
<city>Edison</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>
<street>MS: SJC-21/2</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>
<date day="2" month="November" year="2009" />
<area>RAI</area>
<workgroup>dispatch</workgroup>
</front>
</reference>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-p2psip-sip"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:32:25 |