Skip to main content

Anonymization for REsource LOcation And Discovery (RELOAD)
draft-petithuguenin-p2psip-reload-anonymous-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Marc Petit-Huguenin
Last updated 2012-10-15
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-petithuguenin-p2psip-reload-anonymous-00
P2PSIP                                                 M. Petit-Huguenin
Internet-Draft                                        Impedance Mismatch
Intended status: Standards Track                        October 15, 2012
Expires: April 18, 2013

       Anonymization for REsource LOcation And Discovery (RELOAD)
             draft-petithuguenin-p2psip-reload-anonymous-00

Abstract

   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.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may not be modified,
   and derivative works of it may not be created, except to format it
   for publication as an RFC or to translate it into languages other
   than English.

   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 April 18, 2013.

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           Expires April 18, 2013                 [Page 1]
Internet-Draft            RELOAD Anonymization              October 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.  Overview of Operations . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Anonymous Certificate  . . . . . . . . . . . . . . . . . .  5
     2.2.  End to end encryption  . . . . . . . . . . . . . . . . . .  5
     2.3.  Onion Routing  . . . . . . . . . . . . . . . . . . . . . .  6
     2.4.  Sending anonymous requests . . . . . . . . . . . . . . . .  8
     2.5.  Receiving requests anonymously . . . . . . . . . . . . . . 11
     2.6.  End to end encryption over onion routing . . . . . . . . . 12
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . . 15
   4.  Normative sections . . . . . . . . . . . . . . . . . . . . . . 15
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 16
   Appendix A.  Release notes . . . . . . . . . . . . . . . . . . . . 17
     A.1.  TODO List  . . . . . . . . . . . . . . . . . . . . . . . . 17
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17

Petit-Huguenin           Expires April 18, 2013                 [Page 2]
Internet-Draft            RELOAD Anonymization              October 2012

1.  Introduction

   The goal of [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.

   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.

   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 PathTrack
   [I-D.ietf-p2psip-diagnostics] ), 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.

   A standard RELOAD overlay leaks ownership information in various
   places for the selected set of anonymizable operations:

   1.  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

Petit-Huguenin           Expires April 18, 2013                 [Page 3]
Internet-Draft            RELOAD Anonymization              October 2012

       section.
   2.  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.
   3.  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.
   4.  Some standard RELOAD Usages disclose the owner's Node-ID in the
       data itself.  This is the case for P2PSIP [I-D.ietf-p2psip-sip] ,
       [REDIR] and probably more existing and future usages.

   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.

Petit-Huguenin           Expires April 18, 2013                 [Page 4]
Internet-Draft            RELOAD Anonymization              October 2012

2.  Overview of Operations

2.1.  Anonymous Certificate

   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 [RELOAD] .  The certificate used to sign
   messages and data should not reveal anything about its owner, so it
   should contain a different Node-ID than the standard RELOAD
   certificate, may contain an anonymous rfc822Name (e.g.
   anonymous@overlay.example.org), should have an empty Subject and
   should be a Traceable Anonymous Certificate (PAC) [RFC5636] , created
   from a different key pair.

   The standard certificate may be used for signing messages and data
   that does not need to be anonymous, but the PAC should 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 should 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 should also be used to sign the StoreReq message
   carrying this data.  Not doing this would unmask the identity of the
   sending node.

2.2.  End to end encryption

   This document defines a new RELOAD transaction called Tunnel, which
   carries DTLS [RFC6347] messages.  A successful handshake will be made
   of 3 Tunnel transactions, as follow:

   1.  The tunnel_req message contains a ClientHello DTLS message and
       the tunnel_ans message contains an HelloVerifyRequest DTLS
       message.
   2.  The tunnel_req message contains a ClientHello DTLS message and
       the tunnel_ans message contains a ServerHello, ServerKeyExchange
       and ServerHelloDone DTLS messages.
   3.  The tunnel_req message contains a ClientKeyExchange and a
       Finished DTLS message and the tunnel_ans message contains a
       Finished DTLS message.

   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

Petit-Huguenin           Expires April 18, 2013                 [Page 5]
Internet-Draft            RELOAD Anonymization              October 2012

   imposes to exchange ApplicationData messages in client/server mode,
   which is different from the way DTLS traditionally operates after the
   handshake.  Figure 1 shows the messages exchanges.  Intermediate
   peers are not shown in this diagram.

   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) |
     |<--------------------------------------------------------------|
     |                                                               |

                                 Figure 1

   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.

2.3.  Onion Routing

   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.

Petit-Huguenin           Expires April 18, 2013                 [Page 6]
Internet-Draft            RELOAD Anonymization              October 2012

   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.

   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 list of DestinationS s then inserted
   in place of the current destination.  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, and if the message is of type
   Tunnel and is carrying a ApplicationData DTLS message, then the same
   key is used to decrypt the content of the Tunnel message and the
   resulting RELOAD message is used as content for the new message.  If
   not, but the top Node-ID in the decrypted destination_list and the
   next Onion-ID matches a 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.
   If the message received is a request, then the peer takes the current
   via_list (after inserting the Node-ID of the previous peer), encrypts
   it with the same session key used to encrypt or decrypt, and replaces
   the current via_list with a new list containing the resulting
   Onion-ID.  The new resulting message is then signed by the peer and
   send as for a new message, but without end-to-end retransmission.

   There is a exception to the rule above in case the RELOAD message
   onion routed is StoreReq.  Because the signer of a StoreReq is the
   same than the signer of the data inside it, the StoreReq message sent
   at the end of the decryption process is signed by the original signer
   using its PAC, meaning that the SecurityBlock is also sent inside the
   ApplicationData.  This means that the receiver of a StoreReq can
   never be anonymous, but that should not be a concern as it is a
   random peer that does not implement end-to-end encryption anyway.

   This mechanism is inspired by the design of TOR [DINGLEDINE 04] .

Petit-Huguenin           Expires April 18, 2013                 [Page 7]
Internet-Draft            RELOAD Anonymization              October 2012

2.4.  Sending anonymous requests

   A RELOAD overlay providing anonymity may 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 [REDIR] .

   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.
   Figure 2 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.

   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)) |<-----------------|             |
     |<----------------------------|                  |             |
     |                             |                  |             |

                                 Figure 2

   The node stores the session key created by each successive peer in
   the telescoping path, and will use them to prepare the

Petit-Huguenin           Expires April 18, 2013                 [Page 8]
Internet-Draft            RELOAD Anonymization              October 2012

   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.

   E.g. after the exchange in Figure 2 , the following destination_list
   can be built to anonymously reach Bob:

   [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)))]

   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.

   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 Figure 3 (T
   stands for an ApplicationData DTLS message inside a Tunnel message).

Petit-Huguenin           Expires April 18, 2013                 [Page 9]
Internet-Draft            RELOAD Anonymization              October 2012

   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)))|                |              |           |
     |<-----------------|                |              |           |
     |                  |                |              |           |

                                 Figure 3

Petit-Huguenin           Expires April 18, 2013                [Page 10]
Internet-Draft            RELOAD Anonymization              October 2012

2.5.  Receiving requests anonymously

   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 P2PSIP [I-D.ietf-p2psip-sip] and
   [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.

   E.g. if the destination_list shown in Section 2.4 was stored by Alice
   in the overlay, Carol could retrieve it and anonymously reach her by
   using it in a request, as shown in Figure 4 .

   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 |             |                |                   |
     |<----------|             |                |                   |
     |           |             |                |                   |

                                 Figure 4

Petit-Huguenin           Expires April 18, 2013                [Page 11]
Internet-Draft            RELOAD Anonymization              October 2012

2.6.  End to end encryption over onion routing

   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
   Figure 5 .

Petit-Huguenin           Expires April 18, 2013                [Page 12]
Internet-Draft            RELOAD Anonymization              October 2012

   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)|          |       |    |       |          |           |
    |<----------|          |       |    |       |          |           |
    |           |          |       |    |       |          |           |

                                 Figure 5

   If this is a concern, then the receiving node should also implement

Petit-Huguenin           Expires April 18, 2013                [Page 13]
Internet-Draft            RELOAD Anonymization              October 2012

   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.

Petit-Huguenin           Expires April 18, 2013                [Page 14]
Internet-Draft            RELOAD Anonymization              October 2012

3.  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] .

   "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 should not be interpreted as
   permitting implementors to fail to implement the general requirement
   when such failure would result in interoperability failure.

   Onion peer:  An onion peer is a RELOAD peer that has onion routing
      capabilities.
   Anonymous node:  An anonymous node is a RELOAD node that may want to
      use anonymity for some or all of its application level operations.

4.  Normative sections

   Coming soon.

5.  Security Considerations

   Coming soon.

Petit-Huguenin           Expires April 18, 2013                [Page 15]
Internet-Draft            RELOAD Anonymization              October 2012

6.  IANA Considerations

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5636]  Park, S., Park, H., Won, Y., Lee, J., and S. Kent,
              "Traceable Anonymous Certificate", RFC 5636, August 2009.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, January 2012.

   [RELOAD]   Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
              H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
              Base Protocol", draft-ietf-p2psip-base-22 (work in
              progress), July 2012.

   [REDIR]    Maenpaa, J. and G. Camarillo, "Service Discovery Usage for
              REsource LOcation And Discovery (RELOAD)",
              draft-ietf-p2psip-service-discovery-06 (work in progress),
              October 2012.

7.2.  Informative References

   [I-D.ietf-p2psip-diagnostics]
              Song, H., Jiang, X., Even, R., and D. Bryan, "P2PSIP
              Overlay Diagnostics", draft-ietf-p2psip-diagnostics-09
              (work in progress), August 2012.

   [I-D.ietf-p2psip-sip]
              Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
              H. Schulzrinne, "A SIP Usage for RELOAD",
              draft-ietf-p2psip-sip-07 (work in progress), January 2012.

   [DINGLEDINE 04]
              Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The
              Second-Generation Onion Router", In Proceedings of the
              13th Usenix Security Symposium, 2004.

              <https://svn.torproject.org/svn/projects/design-paper/
              tor-design.pdf>

Petit-Huguenin           Expires April 18, 2013                [Page 16]
Internet-Draft            RELOAD Anonymization              October 2012

Appendix A.  Release notes

   This section must be removed before publication as an RFC.

A.1.  TODO List

   o  Add normative sections.

Author's Address

   Marc Petit-Huguenin
   Impedance Mismatch

   Email: petithug@acm.org

Petit-Huguenin           Expires April 18, 2013                [Page 17]