One document matched: draft-petithuguenin-p2psip-reload-anonymous-02.xml
<?xml version="1.0" ?>
<?rfc compact="yes" ?>
<?rfc strict="no" ?>
<?rfc symrefs="yes" ?>
<?rfc toc="yes" ?>
<rfc category="std" docName="draft-petithuguenin-p2psip-reload-anonymous-02" ipr="noModificationTrust200902">
<front>
<title abbrev="RELOAD Anonymization">Anonymization for REsource LOcation And Discovery (RELOAD)</title>
<author fullname="Marc Petit-Huguenin" initials="M.P.H" surname="Petit-Huguenin">
<organization>Impedance Mismatch</organization>
<address>
<email>petithug@acm.org</email>
</address>
</author>
<date day="5" month="November" year="2012"/>
<area>RAI</area>
<workgroup>P2PSIP</workgroup>
<abstract>
<t>This document presents a set of techniques that a REsource LOcation And Discovery (RELOAD) node may use to ensure that the use of high level RELOAD operations do not reveal the owner of this node.
These high level features are defined as the set of operations related to data storage, plus the operation that permits to exchange application layer messages.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The goal of
<xref target="RELOAD"/>
is to provide a standardized and NAT friendly access to a peer-to-peer network, with a strong security model.
This security model is designed to provide strong security guarantees even in the face of a large number of malicious nodes, but what it is not designed to do is to provide anonymity for any of the nodes.
</t>
<t>There is a lot of reasons why the owner of a RELOAD node may be reluctant to disclose this ownership, but the main motivation for this document is to alleviate the concerns that commercial entities may have to store data in a RELOAD overlay that is shared with competitors.
Commercial entities that needs to share such data generally provide a way to query their database to their competitors because they can control the access and detect datamining attempts.
A overlay definitively makes datamining more challenging but on the other hand does not let a data owner know the rate of access to its data.
Besides, the problem is more one of perception as even if the properties of the overlay are completely understood nobody can guarantee that someone will not come up with a new way of harvesting data in an overlay, making the act of storing such data a perceptively risky operation.
Adding some guarantee of anonymity to the data stored would dissipate any reluctance because even if the complete set of data stored is somehow captured by an hostile entity, there is no way that this data can be linked to its owner, with the added bonus that the processes to detect and manage datamining are no longer needed, making an overlay a better proposition than a shared database.
In addition to anonymous storage, a node may want to be able to retrieve data or to exchange application messages in an anonymous way too, so this document will also apply to such operations.</t>
<t>
This document focuses only on anonymizing high level operations, excluding all the overlay topology operations (Join, Leave, Update, RouteQuery and Probe) and all the forwarding and link management operations (Attach, AppAttach, Ping, ConfigUpdate and
<xref target="I-D.ietf-p2psip-diagnostics">PathTrack</xref>
), leaving only the data store operations up for anonymization (Store, Fetch, Stat and Find).
AppAttach, although an application level operation, cannot be completely anonymized and so had to be replaced by a new mechanism that can be anonymized.
</t>
<t>A standard RELOAD overlay leaks ownership information in various places for the selected set of anonymizable operations:</t>
<t>
<list style="numbers">
<t>Any request is signed by the originating node and is accompanied with the certificate of the signer.
This certificate may contain information on the owner of the node, particularly in the Subject section.</t>
<t>Even if the certificate accompanying the request does not contain private information, a node can send an Attach or AppAttach to the Node-ID in the certificate to find the IP address of the node and deduce private information.</t>
<t>The data contained in a Store request or a Fetch answer is also signed by the owner of the data, and again accompanied by the certificate of the owner, thus disclosing a second time the same information than in points 1 and 2.</t>
<t>
Some standard RELOAD Usages disclose the owner's Node-ID in the data itself.
This is the case for
<xref target="I-D.ietf-p2psip-sip">P2PSIP</xref>
,
<xref target="REDIR"/>
and probably more existing and future usages.
</t>
</list>
</t>
<t>
Note that RELOAD anonymization, like all security subjects, is not some kind of magic feature that will guarantee anonymization of a specific application - as an example, the techniques described in this document cannot do anything to protect a node that tries to anonymously store data containing the name of its owner.
<vspace blankLines="100"/>
</t>
</section>
<section title="Overview of Operations">
<section title="Anonymous Certificate">
<t>
The first step to achieve anonymity is to separate the certificate used for establishing connectivity from the certificate used for signing message and data.
The certificate used to establish connectivity (i.e. used with the link layer protocols) is the one that is already described by
<xref target="RELOAD"/>
.
The certificate used to sign messages and data must not reveal anything about its owner, so it must contain a different Node-ID than the standard RELOAD certificate, must contain an anonymous rfc822Name (e.g. anonymous@overlay.example.org), must have an empty Subject and must be a
<xref target="RFC5636">Traceable Anonymous Certificate (PAC)</xref>
, created from a different key pair.
</t>
<t>The standard certificate may be used for signing messages and data that does not need to be anonymous, but the PAC must never be used for connectivity, as it would unmask this identity to the neighbors of the node.
For the same reason if the PAC is used for signing a StoreReq message it must also be used used to sign the data inside the message.
Similarly if the PAC is used to sign data in a StoreReq message, then it must also be used to sign the StoreReq message carrying this data.
Not doing this would unmask the identity of the sending node.</t>
</section>
<section title="End to end encryption">
<t>
This document defines a new RELOAD transaction called Tunnel, which carries
<xref target="RFC6347">DTLS</xref>
messages.
A successful handshake will be made of 3 Tunnel transactions, as follow:
</t>
<t>
<list style="numbers">
<t>The tunnel_req message contains a ClientHello DTLS message and the tunnel_ans message contains an HelloVerifyRequest DTLS message.</t>
<t>The tunnel_req message contains a ClientHello DTLS message and the tunnel_ans message contains a ServerHello, ServerKeyExchange and ServerHelloDone DTLS messages.</t>
<t>The tunnel_req message contains a ClientKeyExchange and a Finished DTLS message and the tunnel_ans message contains a Finished DTLS message.</t>
</list>
</t>
<t>
The RELOAD end to end retransmission mechanism replaces the standard DTLS retransmission mechanism.
The client and server sides of the DTLS connection use a key pair different than the key pairs used for the RELOAD certificates.
After the handshake successfully completed, Tunnel transactions can be used to carry ApplicationData DTLS messages in both directions.
Note that tunnelling DTLS over RELOAD imposes to exchange ApplicationData messages in client/server mode, which is different from the way DTLS traditionally operates after the handshake.
<xref target="e2e"/>
shows the messages exchanges.
Intermediate peers are not shown in this diagram.
</t>
<t>
<figure anchor="e2e">
<artwork><![CDATA[Alice Bob
| |
| tunnel_req(ClientHello) |
|-------------------------------------------------------------->|
| tunnel_ans(ServerHello|HelloVerifyRequest) |
|<--------------------------------------------------------------|
| |
| tunnel_req(ClientHello) |
|-------------------------------------------------------------->|
| tunnel_ans(ServerHello|ServerKeyExchange|ServerHelloDone) |
|<--------------------------------------------------------------|
| |
| tunnel_req(ClientKeyExchange|Finished) |
|-------------------------------------------------------------->|
| tunnel_ans(Finished) |
|<--------------------------------------------------------------|
| |
| tunnel_req(ApplicationData) |
|-------------------------------------------------------------->|
| tunnel_ans(ApplicationData) |
|<--------------------------------------------------------------|
| |]]></artwork>
</figure>
</t>
<t>The end to end encryption mechanism described here seems to offering much when compared to running (D)TLS over a connection established by an AppAttach transaction.
The problem with AppAttach is that the IP addresses are exchanged before the establishment of the secure connection, which would indirectly unmask the identity of both sides.
This can be acceptable for some applications, but there are applications that may require an additional step before revealing the identity (e.g. by using a zero-knowledge proof) or may require to never unmask the identity for one or both sides of a communication.
For these cases the mechanism described here will assure that each side will be able to communicate and choose if and when they want to reveal information that can unmask identity.</t>
</section>
<section title="Onion Routing">
<t>To be able to hide the origin of a RELOAD message, some peers in an overlay implement, in addition to the normal message routing described in RELOAD, a new routing algorithm called onion routing.
This routing mode uses a new ID called an Onion-ID and an associated new DestinationType so this ID can be inserted in a Destination.
An Onion-ID contains a session key index and an opaque array containing a list of DestinationS encrypted with the session key indicated by the index.</t>
<t>When a peer implementing onion routing receives a message that have an Onion-ID on the top of the destination_list (after removing its own Node-ID), it uses the index to find the session key and decrypt the opaque array.
The resulting Destination list is then inserted in place of the current list.</t>
<t>If the message received is a request, then the peer takes the current via_list (after inserting the Node-ID of the previous peer), inverts it, then encrypts it with the same session key than previously, and replaces the current via_list with a new list containing the resulting Onion-ID.</t>
<t>If the received message is a Tunnel message and if the signer of the message received is also the node that requested the creation of the session key used to decrypt the Onion-ID, then it is decrypted with the same session key, and send as for a new message, signed by the current node, unless the decrypted message is not a Tunnel message, in which case the decrypted data also contains the transaction_id and SecurityBlock, so the message can be sent signed by the original peer.</t>
<t>If the received message is a Tunnel message but the the signer of the message is not the same than the node that requested the creation of the session key, then the session key is used to encrypt the content of the message which is then inserted in an ApplicationData DTLS message, itself inserted in a Tunnel message. and send as for a new message, signed by the current node.</t>
<t>If the received message is not a Tunnel message then the session key is used to encrypt the content of the message plus the transaction_id and SecurityBlock, which is then inserted in an ApplicationData DTLS message, itself inserted in a Tunnel message, and send as for a new message, signed by the current node.</t>
<t>In all cases the new message is sent without end-to-end retransmission.
That requires the node to keep some state in case the message received is retransmitted.</t>
<t>
This mechanism is inspired by the design of
<xref target="DINGLEDINE 04">TOR</xref>
.
<vspace blankLines="100"/>
</t>
</section>
<section anchor="section_sending" title="Sending anonymous requests">
<t>
A RELOAD overlay providing anonymity must contain a number of peers that also implement both onion routing and the server part of the end-to-end encryption mechanism described in the previous sections.
To permit each node requiring anonymity to find the peers that provide this service, these peers register themselves using
<xref target="REDIR"/>
.
</t>
<t>
A node requiring anonymity shoudl implement the client part of the end-to-end encryption mechanism.
Each of theses nodes will randomly select a number of peers providing anonymous service, and will create a telescoping path, by first establishing a end-to-end encryption path with the first peer, then a second encryption path through the first encryption path, to the second peer, and so on until an end-to-end encryption path is established with the last peer of the list.
<xref target="onion"/>
shows a simplified view of this process, by replacing the 3 DTLS transactions by one named "Keys" and by using "Encrypted(Keys)" as a shortcut for these 3 transactions inside the ApplicationData of the Tunnel message.
</t>
<t>
<figure anchor="onion">
<artwork><![CDATA[Alice Onion 1 Onion 2 Onion 3
| | | |
| Keys | | |
|---------------------------->| | |
| Keys | | |
|<----------------------------| | |
| | | |
| Encrypted(Keys) | | |
|---------------------------->| Keys | |
| |----------------->| |
| | Keys | |
| Encryption(Keys) |<-----------------| |
|<----------------------------| | |
| | | |
| Encrypted(Encrypted(Keys)) | | |
|---------------------------->| Encrypted(Keys) | |
| |----------------->| Keys |
| | |------------>|
| | | Keys |
| | Encrypted(Keys) |<------------|
| Encrypted(Encrypted(Keys)) |<-----------------| |
|<----------------------------| | |
| | | |]]></artwork>
</figure>
</t>
<t>The node stores the session key created by each successive peer in the telescoping path, and will use them to prepare the destination_list for sending an anonymous message.
The destination_list is built by first encrypting the final destination Node-ID with the key of the last peer in the telescopic path, and store it as an Onion-ID, then adding the Node-ID of the final destination on top of the Onion-ID.
The rest of the destination_list is built by encrypting the whole resulting destination_list with the session key of the preceding peer in an Onion-ID, and adding the Node-ID of the peer, and this recursively until all the peers in the list have been added.</t>
<t>
E.g. after the exchange in
<xref target="onion"/>
, the following destination_list can be built to anonymously reach Bob:
</t>
<t>
<figure>
<artwork><![CDATA[[Node-ID(Onion 1), Onion-ID(Onion 1,
Node-ID(Onion 2), Onion-ID(Onion 2,
Node-ID(Onion 3), Onion-ID(Onion 3, Bob)))]]]></artwork>
</figure>
</t>
<t>To send an anonymous message, the node will successsively encrypt it with each session key, in the reserse order of the destination_list, encapsulating each encryption result in an ApplicationData DTLS message and then in a Tunnel message.
When receiving a response to its anonymous request, the node will decrypt the content of each ApplicationData DTLS message inside a Tunnel message by using the session keys in the same order than the destination_list of the request sent.</t>
<t>
By applying the onion routing rules, the data sent by Alice is successively decrypted by each onion peer, and the response back is successively encrypted by each onion peer, as shown in
<xref target="send"/>
(T stands for an ApplicationData DTLS message inside a Tunnel message).
</t>
<t>
<figure anchor="send">
<artwork><![CDATA[Alice Onion 1 Onion 2 Onion 3 Bob
| | | | |
|T(T(T(FetchReq))) | | | |
|----------------->| | | |
| Decrypt | | |
| |T(T(FetchReq)) | | |
| |--------------->| | |
| | Decrypt | |
| | |T(FetchReq) | |
| | |------------->| |
| | | Decrypt |
| | | |FetchReq |
| | | |---------->|
| | | | FetchAns|
| | | |<----------|
| | | Encrypt |
| | | T(FetchAns)| |
| | |<-------------| |
| | Encrypt | |
| | T(T(FetchAns))| | |
| |<---------------| | |
| Encrypt | | |
| T(T(T(FetchAns)))| | | |
|<-----------------| | | |
| | | | |]]></artwork>
</figure>
<vspace blankLines="100"/>
</t>
</section>
<section title="Receiving requests anonymously">
<t>
Some RELOAD usages store a Node-ID in the RELOAD distributed storage so it can be used later by another node to connect to a service.
This is the case for example for
<xref target="I-D.ietf-p2psip-sip">P2PSIP</xref>
and
<xref target="REDIR"/>
.
A node that want to use this technique but do not want to disclose its identity will store, in place of its Node-ID, a Destination list similar to the one it could use to send an anonymous request.
</t>
<t>
E.g. if the destination_list shown in
<xref target="section_sending"/>
was stored by Alice in the overlay, Carol could retrieve it and anonymously reach her by using it in a request, as shown in
<xref target="receive"/>
.
</t>
<t>
<figure anchor="receive">
<artwork><![CDATA[Carol Onion 3 Onion 2 Onion 1 Alice
| | | | |
| Request | | | |
|---------->| | | |
| Encrypt | | |
| | T(Request) | | |
| |------------>| | |
| | Encrypt | |
| | | T(T(Request)) | |
| | |--------------->| |
| | | Encrypt |
| | | | T(T(T(Request))) |
| | | |------------------>|
| | | | T(T(T(Answer))) |
| | | |<------------------|
| | | Decrypt |
| | | T(T(Answer)) | |
| | |<---------------| |
| | Decrypt | |
| | T(Answer) | | |
| |<------------| | |
| Decrypt | | |
| Answer | | | |
|<----------| | | |
| | | | |]]></artwork>
</figure>
<vspace blankLines="100"/>
</t>
</section>
<section title="End to end encryption over onion routing">
<t>
Combining the techniques in the two previous sections guarantees anonymity for both the sender and the receiver.
But the exit onion peer from the point of view of the sender and the admitting onion peer from the point of view of the receiver (and all the intermediate peers between those two) will see the data exchanged, as shown in
<xref target="back-to-back"/>
.
</t>
<t>
<figure anchor="back-to-back">
<artwork><![CDATA[Carol O4 O5 06 03 02 01 Alice
| | | | | | | |
|T(T(T(Req) | | | | | | |
|---------->| | | | | | |
| D | | | | | |
| |T(T(Req)) | | | | | |
| |--------->| | | | | |
| | D | | | | |
| | |T(Req) | | | | |
| | |------>| | | | |
| | | D | | | |
| | | |Req | | | |
| | | |--->| | | |
| | | | E | | |
| | | | |T(Req) | | |
| | | | |------>| | |
| | | | | E | |
| | | | | |T(T(Req)) | |
| | | | | |--------->| |
| | | | | | E |
| | | | | | |T(T(T(Req) |
| | | | | | |---------->|
| | | | | | | |
| | | | | | | T(T(T(Ans)|
| | | | | | |<----------|
| | | | | | D |
| | | | | | T(T(Ans))| |
| | | | | |<---------| |
| | | | | D | |
| | | | | T(Ans)| | |
| | | | |<------| | |
| | | | D | | |
| | | | Ans| | | |
| | | |<---| | | |
| | | E | | | |
| | | T(Ans)| | | | |
| | |<------| | | | |
| | E | | | | |
| | T(T(Ans))| | | | | |
| |<---------| | | | | |
| E | | | | | |
| T(T(T(Ans)| | | | | | |
|<----------| | | | | | |
| | | | | | | |]]></artwork>
</figure>
</t>
<t>
If this is a concern, then the receiving node must also implement the server part of the peer-to-peer encryption so the sender can establish an end-to-end encryption eventually through the telescoping paths on one or both sides.
<vspace blankLines="100"/>
</t>
</section>
</section>
<section title="Terminology">
<t>
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
<xref target="RFC2119"/>
.
</t>
<t>"SHOULD", "SHOULD NOT", "RECOMMENDED", and "NOT RECOMMENDED" are appropriate when valid exceptions to a general requirement are known to exist or appear to exist, and it is infeasible or impractical to enumerate all of them.
However, they must not be interpreted as permitting implementors to fail to implement the general requirement when such failure would result in interoperability failure.</t>
<t>
<list style="hanging">
<t hangText="Onion peer:">An onion peer is a RELOAD peer that has onion routing capabilities.</t>
<t hangText="Anonymous node:">An anonymous node is a RELOAD node that may want to use anonymity for some or all of its application level operations.</t>
</list>
</t>
</section>
<section title="Normative sections">
<t>Coming soon.</t>
</section>
<!--section title="Anonymous Node">
<section title="Anonymous Signatures">
<t>
An anonymous node MUST obtain a <xref target="RFC5636">Traceable Anonymous Certificate</xref> (PAC), in addition to the standard RELOAD certificate.
It MUST use the PAC to sign all Store, Fetch, Stat and Find requests that need to be anonymous.
Requests that do not need to be anonymous MUST use the standard RELOAD certificate.
If a request uses a PAC for its signature, then the data carried MUST be signed with the same certificate.
The node MUST use the standard RELOAD certificate for the link layer protocols and MUST NOT use the PAC for this purpose.
</t>
</section>
<section title="Onion Routing">
<t>
A node that want to send an anonymous request MUST retrieve a list of no less than N onion peers using <xref target="REDIR" /> with a namespace of "onion-router", N being the number of onion peers that need to be used for the level of security selected, multiplied by 100.
The node MAY apply additional measures to ensure non-collusion between onion peers.
This list MUST be destroyed and recreated at least each 24 hours.
The node MUST then randomly select a list of P onion peers in this list, P depending on the security wanted, but which cannot be less than 3.
</t>
<t>
At any time before sending an anonymous request, a node MUST establish a direct connection with each onion peer in the list, using an AppAttach transaction.
</t>
</section>
</section>
<section title="Onion Node">
</section-->
<section anchor="security" title="Security Considerations">
<t>
Coming soon.
<vspace blankLines="100"/>
</t>
</section>
<section title="IANA Considerations"/>
<!--section title="Acknowledgements">
</section-->
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<t>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
RFC 2119.</t>
</list>
</t>
<t>Note that the force of these words is modified by the requirement
level of the document in which they are used.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<format octets="4723" target="ftp://ftp.isi.edu/in-notes/rfc2119.txt" type="TXT"/>
<format octets="17491" target="http://xml.resource.org/public/rfc/html/rfc2119.html" type="HTML"/>
<format octets="5777" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml" type="XML"/>
</reference>
<reference anchor="RFC5636">
<front>
<title>Traceable Anonymous Certificate</title>
<author fullname="S. Park" initials="S." surname="Park">
<organization/>
</author>
<author fullname="H. Park" initials="H." surname="Park">
<organization/>
</author>
<author fullname="Y. Won" initials="Y." surname="Won">
<organization/>
</author>
<author fullname="J. Lee" initials="J." surname="Lee">
<organization/>
</author>
<author fullname="S. Kent" initials="S." surname="Kent">
<organization/>
</author>
<date month="August" year="2009"/>
</front>
<seriesInfo name="RFC" value="5636"/>
<format octets="70316" target="ftp://ftp.isi.edu/in-notes/rfc5636.txt" type="TXT"/>
</reference>
<reference anchor="RFC6347">
<front>
<title>Datagram Transport Layer Security Version 1.2</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla">
<organization/>
</author>
<author fullname="N. Modadugu" initials="N." surname="Modadugu">
<organization/>
</author>
<date month="January" year="2012"/>
</front>
<seriesInfo name="RFC" value="6347"/>
<format octets="73546" target="ftp://ftp.isi.edu/in-notes/rfc6347.txt" type="TXT"/>
</reference>
<reference anchor="RELOAD">
<front>
<title>REsource LOcation And Discovery (RELOAD) Base Protocol</title>
<author fullname="Cullen Jennings" initials="C" surname="Jennings">
<organization/>
</author>
<author fullname="Bruce Lowekamp" initials="B" surname="Lowekamp">
<organization/>
</author>
<author fullname="Eric Rescorla" initials="E" surname="Rescorla">
<organization/>
</author>
<author fullname="Salman Baset" initials="S" surname="Baset">
<organization/>
</author>
<author fullname="Henning Schulzrinne" initials="H" surname="Schulzrinne">
<organization/>
</author>
<date day="16" month="July" year="2012"/>
<abstract>
<t>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.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-p2psip-base-22"/>
<format target="http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-22.txt" type="TXT"/>
</reference>
<reference anchor="REDIR">
<front>
<title>Service Discovery Usage for REsource LOcation And Discovery (RELOAD)</title>
<author fullname="Jouni Maenpaa" initials="J" surname="Maenpaa">
<organization/>
</author>
<author fullname="Gonzalo Camarillo" initials="G" surname="Camarillo">
<organization/>
</author>
<date day="1" month="October" year="2012"/>
<abstract>
<t>REsource LOcation and Discovery (RELOAD) does not define a generic service discovery mechanism as part of the base protocol. This document defines how the Recursive Distributed Rendezvous (ReDiR) service discovery mechanism used in OpenDHT can be applied to RELOAD overlays to provide a generic service discovery mechanism.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-p2psip-service-discovery-06"/>
<format target="http://www.ietf.org/internet-drafts/draft-ietf-p2psip-service-discovery-06.txt" type="TXT"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="I-D.ietf-p2psip-diagnostics">
<front>
<title>P2PSIP Overlay Diagnostics</title>
<author fullname="Haibin Song" initials="H" surname="Song">
<organization/>
</author>
<author fullname="XingFeng Jiang" initials="X" surname="Jiang">
<organization/>
</author>
<author fullname="Roni Even" initials="R" surname="Even">
<organization/>
</author>
<author fullname="David Bryan" initials="D" surname="Bryan">
<organization/>
</author>
<date day="8" month="August" year="2012"/>
<abstract>
<t>This document describes mechanisms for P2PSIP diagnostics. It defines extensions to the RELOAD P2PSIP base protocol RELOAD [I-D.ietf-p2psip-base] to collect diagnostic information, and details the protocol specifications for these extensions. Useful diagnostic information for connection and node status monitoring is also defined. The document also describes the usage scenarios and provides examples of how these methods are used to perform diagnostics in a P2PSIP overlay networks.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-p2psip-diagnostics-09"/>
<format target="http://www.ietf.org/internet-drafts/draft-ietf-p2psip-diagnostics-09.txt" type="TXT"/>
</reference>
<reference anchor="I-D.ietf-p2psip-sip">
<front>
<title>A SIP Usage for RELOAD</title>
<author fullname="Cullen Jennings" initials="C" surname="Jennings">
<organization/>
</author>
<author fullname="Bruce Lowekamp" initials="B" surname="Lowekamp">
<organization/>
</author>
<author fullname="Eric Rescorla" initials="E" surname="Rescorla">
<organization/>
</author>
<author fullname="Salman Baset" initials="S" surname="Baset">
<organization/>
</author>
<author fullname="Henning Schulzrinne" initials="H" surname="Schulzrinne">
<organization/>
</author>
<date day="17" month="January" year="2012"/>
<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-07"/>
<format target="http://www.ietf.org/internet-drafts/draft-ietf-p2psip-sip-07.txt" type="TXT"/>
</reference>
<reference anchor="DINGLEDINE 04">
<front>
<title>Tor: The Second-Generation Onion Router</title>
<author fullname="Roger Dingledine" initials="R" surname="Dingledine">
<organization/>
</author>
<author fullname="Nick Mathewson" initials="N" surname="Mathewson">
<organization/>
</author>
<author fullname="Paul Syverson" initials="P" surname="Syverson">
<organization/>
</author>
<date year="2004"/>
</front>
<seriesInfo name="In Proceedings of" value="the 13th Usenix Security Symposium"/>
<annotation>
<eref target="https://svn.torproject.org/svn/projects/design-paper/tor-design.pdf"/>
</annotation>
</reference>
</references>
<section title="Release notes">
<t>This section must be removed before publication as an RFC.</t>
<!--section title="Design Notes">
<t>
<list style="symbols">
<t>
</t>
</list>
</t>
</section-->
<section title="TODO List">
<t>
<list style="symbols">
<t>Add normative sections.</t>
</list>
</t>
</section>
</section>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 01:53:11 |