336 |
SIP: Understanding the Session Initiation Protocol |
overlay due to NAT. This is one reason why often recursive routing is used on overlays instead of iterative routing.
On real overlays, during the bootstrap process (an example of which is described for the RELOAD protocol in the next section), a node learns its successor and predecessor nodes and establishes connections to them using the bootstrap server for rendezvous. The node then requests the finger tables of the neighbor elements and copies information about the node ID that it would use to populate its own finger table. For the nodes that should be in the new node’s finger table, the node uses the other node as a rendezvous server so that it can contact the other nodes, perhaps running ICE for hole punching. Once established, this connection is maintained through keep alives. The node can then request the finger table from this node, and continue in this way until it has a complete finger table and connections established to each of these nodes. As nodes join and leave the overlay, the node will make adjustments to the finger table.
By having nodes in the overlay provide this rendezvous service to other nodes, establishing and maintaining connections, the overlay can work even though nodes are behind NATs.
15.4 RELOAD
The RELOAD (Resource Location and Discovery) Protocol [6] is a P2P protocol being developed in the P2PSIP working group of the IETF. Currently, the protocol is defined in an Internet Draft and still needs significant work before it will be finalized and published as an RFC. Another peer protocol which is not progressing as a standard but is being implemented and deployed is P2PP [7]. Some of the protocol details presented in this section may have changed. Readers interested in peer protocols should check for the latest Internet Drafts and RFCs at the P2PSIP working group charter page [8].
RELOAD attempts to provide a self-organizing overlay network with routing between nodes and service discovery. RELOAD can be used for a number of applications, each of which is defined in separate usage documents. For example, the SIP usage of RELOAD is defined in [9]. In RELOAD, nodes join the overlay by establishing connections to a small number of other nodes in the overlay. Each node in the overlay has a node identifier (Node-ID), which is a 128 bit value used for routing messages across the overlay. Node-IDs are assigned by a centralized enrollment server. The enrollment server also issues credentials (certificates containing the Node-ID) used to authenticate nodes in the overlay. A node joins the overlay using a bootstrap node: a stable node in the overlay with a public IP address that is discoverable based on the name of the overlay. A new node forms new connections to other nodes in the overlay and builds a routing table. The node then actually joins the overlay by inserting itself into the routing
Peer-to-Peer SIP |
337 |
tables of surrounding nodes and storing the data associated with that part of the overlay. Information is stored and retrieved in the overlay distributed database using store and fetch requests. The functions of different types of peers in the overlays are discussed in Table 15.2.
RELOAD uses a combination of binary encoding and TLV (tag length value) encoding; messages are routed over TLS or DTLS. Table 15.3 summarizes some of the diverse function of RELOAD that are grouped together in this protocol.
The SIP usage of RELOAD provides two main functions: registration and rendezvous. The registration function is the ability of a UA to store the mapping between their address of record (AOR) and their Node-ID. This allows another UA in the overlay to do a lookup of their AOR URI to determine their NodeID. The rendezvous function is to use RELOAD to establish a direct connection between two UAs in the overlay so they can exchange SIP messages. Without NAT, this function would not be needed, and instead the registration function could provide a mapping between an AOR and an IP address and port. However, since many peers will be behind NAT, this rendezvous functionality allows them to perform hole punching using ICE in order to establish a direct TLS or DTLS connection between the UAs. At that point, normal SIP messages including INVITE, ACK, and BYE can be exchanged. To complete the NAT traversal, the SIP exchange can provide rendezvous functionality for the media, and hence ICE will be run again. Both the RELOAD ICE and SIP ICE applications need to
|
Table 15.2 |
|
|
Roles in an Overlay |
|
Peer node |
A full member of the overlay that stores information and routes overlay |
|
requests. |
||
|
||
Client node |
Not a full member of the overlay, but it can query the overlay for information. |
|
Joining peer |
A peer attempting to join the overlay. |
|
Bootstrap peer |
A stable peer with a public IP address used to join the overlay. |
|
Admitting peer |
The first peer contacted by joining peer after the bootstrap peer. |
|
Proxy peer |
A SIP proxy server that is also a peer in the overlay. It helps route SIP |
|
|
messages to and from the outside of the overlay. |
|
Enrollment server |
It issues credentials used by peers for authentication in the overlay. |
|
Table 15.3 |
|
RELOAD Protocol Functions |
Usage layer |
An application that uses RELOAD, such as SIP. |
Message transport |
Provides end-to-end reliability of overlay messages. |
Storage |
Provides database functions for overlay users. |
Topology plug-in |
Supports different topologies based on overlay algorithm. |
338 |
SIP: Understanding the Session Initiation Protocol |
have a fallback, and that means TURN transport relay addresses. The method of discovering and using TURN servers is still under development. RELOAD can use different overlay protocols. The current version uses a modified version of Chord.
15.5 Host Identity Protocol
RELOAD as a protocol reimplements many layers of the protocol stack. It provides many transport layer and routing layer services, including reliability and fragmentation. An alternative approach to building an overlay is to reuse the existing parts of the IP stack by inserting shim layers. One example of this is the usage of Host Identity Protocol (HIP) [10] over an overlay. The protocol stack of HIP is shown in Figure 15.3. The HIP architecture separates the identifier and locator roles of an IP address. An HIP host has a constant host identity, while its IP address can change in real-time and over time. The host identity is a public private key pair. HIP uses a Host Identity Tag (HIT) as an identifier. A HIT is a self-certifying identity because it is formed as a prefixed, truncated hash of the public key, ORCHID (Overlay Routable Cryptographic Hash Identifier) [11] as an identifier, which is a 128-bit address that has the same format as an IPv6 address, but is not routable using IPv6. To claim a particular HIT, a host uses the private key associated with the public key of the HIT. The use of an ORCHID means that the IPv6 APIs can be used with HIP without any changes.
HIP may one day be run natively as a transport on top of IP. However, today it is tunneled over UDP so that it can traverse NAT.
HIP exchanges messages between hosts by first establishing connections known as HIP associations. An HIP association is secured using an IPSec tunnel, which is keyed using a DH exchange authenticated by the public keys associated with the host HITs. The HIP base exchange is used to signal the HIP
Figure 15.3 Host Identity Protocol stack.
Peer-to-Peer SIP |
339 |
association, and is currently being extended to support ICE hole punching for NAT traversal.
HIP needs a way to map an HIT to an IP address used to establish HIP connections. This can be done with either DNS, a registration method (a HIP rendezvous server), or an overlay routing protocol. This usage of HIP is described in [12]. Currently, the IETF HIP working group is working on taking parts of the RELOAD protocol and using them for discovery and rendezvous for HIP. Adding HIP to RELOAD would have the following advantages:
•Since HIP uses ICE, all other protocols that run on top of HIP, including RELOAD, SIP, and RTP would all get the benefits of ICE without having to implement it. For example, consider two peers who need to establish a RELOAD connection, exchange SIP messages, and then exchange RTP media. The RELOAD messages would be run over HIP and ICE would be run to establish the secure HIP association between the hosts; then RELOAD messages could be exchanged. Next, SIP could be sent over the same HIP association and finally RTP, all without having to run ICE again.
•Minimal changes to SIP and RTP would be required to use HIP. HITs would be carried as IPv6 addresses in SIP URIs and in SDP offer/answer exchanges for RTP media negotiation. This allows direct HIP usage for SIP and RTP without major changes to the protocols. The only change is the way URIs are resolved. In normal SIP, routing is based on the host part, and the user part is only resolved within the domain. In P2PSIP with HIP, the entire user and host part of the URI would need to be resolved. One solution to this would be to only use the domain part of the URI—the user part would essentially be ignored. While both a RELOAD and an HIP approach require this change to SIP, RELOAD requires even more extensive changes.
The complete set of HIP experimental specifications is listed in Table 15.4. For more details of HIP, see [19].
15.6 Conclusion
P2P SIP is an area with quite a lot of activity, both in industry and in standards. P2P has advantages in some applications and scenarios. Protocols such as RELOAD and HIP will likely be used to implement some of these applications and scenarios.