| TOC |
|
By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
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.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 15, 2008.
This document describes an architecture where peers in an overlay use special IP addresses to identify other peers. Two of the advantages of this approach are that (a) most existing applications can run in an overlay without needing any changes and (b) peer mobility and NAT traversal are handled in a way that is transparent to most applications.
Descriptions of the basic concepts and terminology used in this document can be found in the P2PSIP Concepts and Terminology document [Concepts] (Bryan, D., Matthews, P., Shim, E., and D. Willis, “Concepts and Terminology for Peer to Peer SIP,” March 2007.).
1.
Introduction
2.
Details
2.1.
Identifiers
2.2.
Peer Protocol
2.3.
Shim Layer
3.
Domain Names
4.
Example
5.
Relationship to HIP
6.
Implementing the Shim Layer
7.
IANA Considerations
8.
Security Considerations
9.
Informative References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
This document describes an architecture where nodes use IP addresses drawn from a special range to uniquely identify other peers and clients in the overlay. These IP addresses, called "identifiers" in the rest of this document, are drawn from a special address range and are thus distinct from the actual IP addresses assigned to peers and clients. These identifiers are used by the application and the application’s transport protocol (e.g., TCP or UDP) in place of a peer’s real address. These identifiers are distinguishable from real addresses (because they are drawn from a special range), but most applications do not know or care about the difference.
Using IP addresses as identifiers in this manner brings the following advantages:
To implement this architecture, the identifiers are intercepted (using one of a variety of implementation techniques) just below the transport layer and replaced with a real address before the packet is sent. The mapping of an identifier to the associated real address is handled the Peer Protocol [Concepts] (Bryan, D., Matthews, P., Shim, E., and D. Willis, “Concepts and Terminology for Peer to Peer SIP,” March 2007.). For peers and clients behind NATs, this application uses the ICE protocol [ICE] (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” .) to establish connections through the NATs. This application also handles case where a peer changes its real address for mobility or multi-homing reasons.
Applications learn these identifiers in various ways. Applications that use the distributed database function in the overlay receive identifiers rather than real addresses as responses to queries. Applications that use the gethostbyname() function are returned identifiers rather than real addresses when the destination is known to be in the overlay. And applications may learn identifiers from other applications.
This approach can be compared with the approach taken by most of the other proposals in P2PSIP (e.g., RELOAD, ASP, P2PP, and XPP/PCAN). In these proposals, peers are identified with bitstrings that do not look like addresses, forcing applications that want to run in an overlay to use a new (as yet unspecified) API, rather than the existing Socket API. Furthermore, though these proposals handle NAT traversal for the Peer protocol, they do not handle NAT traversal for applications, forcing each application to invent its own ICE variation. None of these proposals currently consider mobility at all. All of this means that any application that wants to run in an overlay requires significant modification.
The exceptions to the problems described in the previous paragraph are the two P2PSIP proposals based on HIP: HIP-HOP [HIP‑HOP] (Cooper, E., Johnston, A., and P. Matthews, “A Distributed Transport Function in P2PSIP using HIP for Multi-Hop Overlay Routing,” June 2007.) and WITH-HIP [WITH‑HIP] (Hautakorpi, J., Camarillo, G., and J. Koskella, “Utilizing HIP (Host Identity Protocol) for P2PSIP (Peer-to-peer Session Initiation Protocol),” November 2007.). Both of these proposals include the id/location split concept, and thus share the advantages of this concept.
This proposal takes the features of HIP that the authors feel are most beneficial to P2PSIP, while leaving for further investigation the possible adoption of other HIP features (as proposed in HIP-HOP and WITH-HIP). More details on the relationship of this work to HIP is given in Section 5 (Relationship to HIP).
| TOC |
Figure X shows the conceptual relationship between the parts discussed in this section.
_______________ _______________ | | | | Peer Protocol | SIP | Other Apps ... |_______________|_______________|_________________ | | | TCP, UDP, etc | |_________________________________________________| | | | Shim layer | |_________________________________________________| | | | IP (v4 or v6) | |_________________________________________________|
In this architecture, the Peer Protocol is responsible for creating the mapping between identifiers and real addresses, while the Shim layer is responsible for doing the translation on a packet-by-packet basis as well as adding any necessary encapsulation. More details on these roles can be found below.
| TOC |
Identifiers are IPv4 or IPv6 addresses selected from a special range in the IPv4 or IPv6 space respectively. For IPv4, this is the TBD range; for IPv6, this is the TBD range.
These identifiers can be freely intermixed with ordinary (“real”) addresses. Applications are free to use identifiers to talk with application on other nodes in the overlay, and real addresses to talk with applications off the overlay.
OPEN ISSUE: For IPv6, getting a range of addresses should be quite do-able. HIP is currently using the ORCHID space, and this may well be a reasonable choice for this architecture.
But is it realistic to assume that we will be able to get a range of IPv4 addresses to use for this purpose? HIP implementations currently use the 1/8 range (which is marked as "reserved" by IANA) which has 2^24 addresses available in it. If IPv4 identifiers just have local scope, then 2^24 is probably more than required, and a /14 or /16 is probably quite sufficient.
OPEN ISSUE: What is the scope of this identifier (e.g., local node only, overlay-wide, or global)? The IPv4 identifiers probably have to be local, since are not enough to be global and maybe not enough to be overlay-wide. The IPv6 identifiers could be global (and be either identical to, or similar to, HIP’s Host Identity Tags (HITs)) or they could be just overlay-wide, however, either would introduce a difference between the IPv4 and IPv6 identifiers which might be undesirable.
OPEN ISSUE: Is this identifier the same as a peer id [Concepts] (Bryan, D., Matthews, P., Shim, E., and D. Willis, “Concepts and Terminology for Peer to Peer SIP,” March 2007.)? In the case of IPv4 identifiers, it seems pretty clear that the answer is “no”, because the space of IPv4 identifiers simply isn’t large enough. For IPv6, the space is likely large enough, but there are difficulties if the identifier is both globally scoped and is a peer id.
| TOC |
The job of the Peer Protocol in this architecture is (in addition to its other duties of managing the overlay and implementing the Distributed Database [Concepts] (Bryan, D., Matthews, P., Shim, E., and D. Willis, “Concepts and Terminology for Peer to Peer SIP,” March 2007.)) to establish connections between peers and to manage the mappings between identifiers and real addresses. To do this, the Peer Protocol does an ICE exchange with the destination peer to negotiate a set of addresses and ports to use for the data traffic.
The stimulus for doing this ICE exchange is an indication from the Shim layer saying that is has no set of real addresses to use for a given destination identifier (cf. an ARP cache miss). The Peer Protocol then does an ICE exchange with the destination peer, routing the Offer/Answer though other peers in the overlay. Once the exchange has completed, the Peer Protocol installs the appropriate mapping entry into the Shim layer.
| TOC |
The shim layer is a new layer introduced between the IP layer and the transport layer. It has two functions: translating identifiers to/from real addresses, and adding any necessary encapsulation.
There are two forms of encapsulation: null encapsulation and outer-UDP encapsulation.
_____________________________ ___________________________
| | | |
| Application data | | Application data |
|_____________________________| |___________________________|
| | | |
| Transport (TCP or UDP only) | | Transport header |
|_____________________________| |___________________________|
| | | |
| Demux header | | IP header (v4 or v6) |
|_____________________________| |___________________________|
| |
| UDP header | Null Encapsulation
|_____________________________|
| |
| IP header (v4 or v6) |
|_____________________________|
Outer-UDP Encapsulation
The Demux header looks like:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Here the protocol field indicates which transport (or other) protocol follows, and uses the same codepoints as used for the ‘protocol’ field in the IPv4/IPv6 header.
The null encapsulation adds no extra bytes but simply translates identifiers to real addresses and modifies port numbers as necessary to traverse NATs. The null encapsulation is very similar to existing protocol stacks, but requires more work to set up and maintain because each connection requires its own set of ICE connectivity checks.
By contrast, the Outer-UDP encapsulation adds a UDP header plus a 4-byte demux header between the IP header and the transport header. The Outer-UDP encapsulation multiplexes all connections between two given nodes inside a single UDP "pipe". Because intervening NATs see only the outer UDP header, this encapsulation requires only one ICE exchange (to set up the outer pipe), regardless of how many connections there are inside the pipe.
The Outer-UDP encapsulation can be used with all transport protocols, while the null encapsulation can only be used with UDP and TCP.
To explain the mapping and encapsulations in more detail, consider a transport layer PDU is sent from X:x to Y:y, where X is the identifier of the local host, Y is the identifier of the remote host, and x and y are the port numbers allocated off of these identifiers. For both encapsulations, the Peer Protocol will have used ICE to determine a corresponding set of real addresses and ports.
For the null encapsulation, each transport layer 5-tuple (transport protocol,X,x,Y,y) will have a corresponding set of real addresses and ports (X’,x’,Y’,y’). When sending, the port numbers x and y in the transport header are replaced with x’ and y’, and an IP header is added containing addresses X’ and Y’ is added. (TBD: Are the addresses in the transport layer pseudo-header also replaced?). The reverse replacement is done when receiving a PDU.
If either X or Y change their real address, then an ICE exchange is required to determine a new 5-tuple for each connection. For UDP, this new 5-tuple is simply used in place of the old.
OPEN ISSUE: For TCP, this doesn’t work, since generating the new 5-tuple requires a new TCP handshake. This seems to imply that the TCP layer has to be aware of the change in address. So what do we do? Do we just say “don’t use null encapsulation for TCP if you want mobility to work”? Or do we figure out how to make this work?
For the outer-UDP encapsulation, there is a single 5-tuple (UDP,X’,x’,Y’,y’) for each (X,Y) pair. When sending, the transport header is not modified, instead a demux header and a outer UDP header is added. Ports x’ and y’ are inserted in the outer UDP header, and an IP header containing addresses X’ and Y’ is added.
Mobility is simpler with the Outer-UDP encapsulation. In this case, only a single ICE exchange is required, and the new 5-tuple is simply used in place of the old. There are no TCP concerns in this case, since the TCP header is never modified.
See Section 6 (Implementing the Shim Layer) for a discussion of how to implement the mapping layer.
| TOC |
In this section, we briefly describe how the identifier concept might be extended to tie in with domain names in an attractive way. This idea is not core to this draft, but helps simplify the example that follows.
Briefly, the idea is to define a new top-level domain, called “.p2p”. This domain is reserved for use in peer-to-peer overlays. An overlay is then given a name underneath this top-level domain:
<overlay-name>.p2p
and individual peers are allocated names underneath the overlay name:
<peer-name>.<overlay-name>.p2p
For example, a peer named “mars” in an overlay called “solar-system” would have the name:
mars.solar-system.p2p
By storing the mapping between peer names and peer ids in the Distributed Database, this scheme allows users to use human-friendly names for peers in place of peer ids or identifiers.
To make this scheme even more powerful, gethostbyname() is modified to look for domain names ending in “.p2p” and look them up in the Distributed Database rather than in the DNS. When the resource record is returned, an identifier is allocated to the peer and that identifier is returned from gethostbyname(). In that way, the user can type, for example, “http://mars.solar-system.p2p” into her web browser to contact a web server running on “mars”.
More details on how this works can be found in the example of the next section.
| TOC |
In this section, we show a SIP call between two UAs in an overlay.
This example illustrates how this architecture allows applications to work in an overlay without being aware of that fact. The two SIP UAs in this example use standard client-server SIP to communicate, without needing any SIP extensions.
IMPORTANT NOTE: Without extensions to SIP, there is no way to do an AOR to contact URI lookup using the Distributed Database. So in this example, Wilma calls Fred by specifying Fred’s machine name, using the domain name scheme described in the previous section. With this caveat, everything works with SIP as it is today.
Figure X shows the call flow for this example.
Wilma Fred Venus Earth Mars | | | |- DD query for mars.solar-system.p2p ->| | |<--------------- DD response ----------| | | | | |----------- Msg w/ICE Offer ---------->| | | |----- Msg w/ICE Offer ---->| | |<---- Msg w/ICE Ans -------| |<---------- Msg w/ ICE Ans ------------| | | | |<=================== ICE Connectivity Checks =====================>| | | |<-------------------- TCP and TLS handshake ---------------------->| | | |<------------- SIP transaction over TLS connection --------------->| | |
This example shows three machines, named “Venus”, “Earth”, and “Mars” which are part of a larger overlay named “solar-system.p2p”. Wilma is on Venus, and Fred is on Mars.
Wilma initiates the call by typing in sips:fred@mars.solar-system.p2p into her UA. Wilma’s UA does a gethostbyname() call to resolve “mars.solar-system.p2p” and this is resolved by doing a Distributed Database lookup. In this example, it turns out that the corresponding resource record is stored on the machine "Earth". As a result, an identifier for the peer Mars is returned from the gethostbyname() call to Wilma’s UA.
NOTE: If identifiers are the same as peer ids, then the peer id from the resource record is just returned as the identifier. Otherwise, (which is more likely if Wilma's UA is using IPv4 identifiers) the Peer Protocol allocates an identifier and remembers that it maps to the machine named "mars.solar-system.p2p" which has the peer id learned from the response.
Wilma’s UA then issues a connect() to this identifier. This causes TCP to send a SYN to this identifier. Since there is currently no direct connection between Venus and Mars, the Shim layer finds no mapping for this identifier and thus generates an indication to the Peer Protocol.
The Peer Protocol layer on Venus now does an ICE offer/answer exchange with the Peer Protocol layer on Mars. The Offer is sent on the existing connection to Earth, which forwards it to Mars, and the Answer is returned in the same way. ICE connectivity checks are then done, and the result is a tuple of real addresses and ports for the connection.
If null encapsulation is used, then the TCP connection was established as part of the ICE connectivity checks. This new connection is used only for SIP signaling, and subsequent connections require a new offer/answer exchange.
But if Outer-UDP encapsulation is used, then all the ICE connectivity checks do is establish a UDP "pipe" between the two peers, and the TCP and TLS handshakes must still be done inside that pipe (as shown above). However, this UDP pipe can be used for all traffic between Venus and Mars, including subsequent RTP packets) without the need of subsequent offer/answer exchanges.
| TOC |
The fundamental concept in this document, that of an identifier for a node which is distinct from the node’s real addresses, has been adopted from HIP. In HIP, this identifier (known as a HIT [HIP‑Base] (Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, “Host Identity Protocol,” June 2007.))is always an IPv6 identifier, and has global scope and cryptographic properties, making it computationally hard for an second node to steal a node’s identity. (Current HIP implementations also implement an IPv4 identifier as a local identifier, but the properties of this IPv4 identifier are not currently specified anywhere).
HIP also introduces a number of other concepts, whose applicability to p2p overlays is less obvious.
The first is the use of ESP. In HIP, all data packets flowing between two nodes use ESP to encrypt and integrity protect the traffic [HIP‑ESP] (Jokela, P., Moskowitz, R., and P. Nikander, “Using ESP transport format with HIP,” June 2007.). At present, this is done for all traffic, even if the traffic is already protected at a higher layer (e.g., using TLS or application-level encryption). Does we want to encrypt and integrity-protect *all* traffic, or should this decision be made on a per-application basis? Do we want some way to avoid double encryption: if so, how is this done?
The second is the use of computational puzzles to prevent denial of service attacks. Since all traffic is encrypted, when setting up a HIP connection the two endpoints do a Diffie-Hellman exchange to agree on a shared encryption key. Since this is computationally expensive, the node initiating the connection must first solve a computational puzzle generated by the destination, in order to make it more difficult for a hostile initiator to cause the destination to do a lot of work. However, it is not immediately clear how to extend this concept to a peer-to-peer overlay where there are many more connections involved and the different ways of launching denial-of-service attacks seem larger.
Finally, HIP has its own signaling protocol (also called HIP), and the proper relationship of that protocol to the Peer Protocol is not immediately clear. Should the functionality of HIP simply be added to the Peer Protocol? Should HIP signaling be kept as a distinct protocol and carried inside Peer Protocol messages (as proposed in [WITH‑HIP] (Hautakorpi, J., Camarillo, G., and J. Koskella, “Utilizing HIP (Host Identity Protocol) for P2PSIP (Peer-to-peer Session Initiation Protocol),” November 2007.))? Or should HIP signaling be used to create connections in the overlay instead of the Peer Protocol (as proposed in [HIP‑HOP] (Cooper, E., Johnston, A., and P. Matthews, “A Distributed Transport Function in P2PSIP using HIP for Multi-Hop Overlay Routing,” June 2007.))?
| TOC |
A frequent reaction to people hearing about this architecture for the first time is: But how do I implement it? This section provides some guidance, drawing on the experience of the HIP community in implementing HIP.
There are three kinds of implementations: kernel, user-space, and library.
In a kernel implementation, the shim layer is implemented in the kernel.
In a user-space implementation, the packet is intercepted at the link layer and sent up to a user-space process which modifies the packet as required and then the packet is returned to the kernel for further processing.
In a library implementation, the transport and shim layers are implemented in a library (e.g., libc) which is either statically or dynamically linked with the application.
Currently, HIP implementations of the kernel kind exist for Linux and FreeBSD, and of the user-space kind for Linux, OS X, and Windows. Note that the user-space implementations run on operating systems where kernel modifications are not possible. The authors are not currently aware of any libary implementations, but these would be easy to produce.
| TOC |
TBD.
| TOC |
TBD.
| TOC |
| [Concepts] | Bryan, D., Matthews, P., Shim, E., and D. Willis, “Concepts and Terminology for Peer to Peer SIP,” Internet Draft draft-willis-p2psip-concepts-04, March 2007. |
| [HIP-Base] | Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, “Host Identity Protocol,” Internet Draft draft-ietf-hip-base-08, June 2007. |
| [HIP-ESP] | Jokela, P., Moskowitz, R., and P. Nikander, “Using ESP transport format with HIP,” Internet Draft draft-ietf-hip-esp-06, June 2007. |
| [HIP-HOP] | Cooper, E., Johnston, A., and P. Matthews, “A Distributed Transport Function in P2PSIP using HIP for Multi-Hop Overlay Routing,” draft-matthews-p2psip-hip-hop-00 (work in progress), June 2007. |
| [ICE] | Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” Internet Draft draft-ietf-mmusic-ice. |
| [WITH-HIP] | Hautakorpi, J., Camarillo, G., and J. Koskella, “Utilizing HIP (Host Identity Protocol) for P2PSIP (Peer-to-peer Session Initiation Protocol),” draft-hautakorpi-p2psip-with-hip-01 (to appear) (work in progress), November 2007. |
| TOC |
| Eric Cooper | |
| Avaya | |
| 1135 Innovation Drive | |
| Ottawa, Ontario K2K 3G7 | |
| Canada | |
| Phone: | +1 613 592 4343 x228 |
| Email: | ecooper@avaya.com |
| Alan Johnston | |
| Avaya | |
| St. Louis, MO 63124 | |
| USA | |
| Email: | alan@sipstation.com |
| Philip Matthews | |
| Avaya | |
| 100 Innovation Drive | |
| Ottawa, Ontario K2K 3G7 | |
| Canada | |
| Phone: | +1 613 592 4343 x224 |
| Email: | philip_matthews@magma.ca |
| TOC |
Copyright © The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.