One document matched: draft-matthews-p2psip-id-loc-00.txt
P2PSIP Working Group E. Cooper
Internet-Draft A. Johnston
Intended status: Standards Track P. Matthews
Expires: May 14, 2008 Avaya
November 11, 2007
An ID/Locator Architecture for P2PSIP
draft-matthews-p2psip-id-loc-00
Status of this Memo
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 14, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
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.
Cooper, et al. Expires May 14, 2008 [Page 1]
Internet-Draft ID/Loc November 2007
Terminology
Descriptions of the basic concepts and terminology used in this
document can be found in the P2PSIP Concepts and Terminology document
[Concepts].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Details . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Peer Protocol . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Shim Layer . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Domain Names . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Relationship to HIP . . . . . . . . . . . . . . . . . . . . . 10
6. Implementing the Shim Layer . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Informative References . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Cooper, et al. Expires May 14, 2008 [Page 2]
Internet-Draft ID/Loc November 2007
1. Introduction
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:
o The identifiers are stable and unique.
o The identifiers can be used in the Socket API without changes.
o Applications do not need to worry about NAT traversal, mobility,
or multi-homing.
o Most applications do not need to be aware that they are running in
an overlay. Only applications that want to take advantage of the
special properties that the overlay provides need to be aware.
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]. For peers and clients behind
NATs, this application uses the ICE protocol [ICE] 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
Cooper, et al. Expires May 14, 2008 [Page 3]
Internet-Draft ID/Loc November 2007
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] and
WITH-HIP [WITH-HIP]. 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.
2. Details
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.
Cooper, et al. Expires May 14, 2008 [Page 4]
Internet-Draft ID/Loc November 2007
2.1. Identifiers
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]?
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.
2.2. Peer Protocol
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]) 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.
Cooper, et al. Expires May 14, 2008 [Page 5]
Internet-Draft ID/Loc November 2007
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.
2.3. Shim Layer
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
Cooper, et al. Expires May 14, 2008 [Page 6]
Internet-Draft ID/Loc November 2007
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.
Cooper, et al. Expires May 14, 2008 [Page 7]
Internet-Draft ID/Loc November 2007
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 for a discussion of how to implement the mapping layer.
3. Domain Names
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.
Cooper, et al. Expires May 14, 2008 [Page 8]
Internet-Draft ID/Loc November 2007
4. Example
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.
Cooper, et al. Expires May 14, 2008 [Page 9]
Internet-Draft ID/Loc November 2007
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.
5. Relationship to HIP
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])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.
Cooper, et al. Expires May 14, 2008 [Page 10]
Internet-Draft ID/Loc November 2007
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]. 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])? Or should HIP signaling be used to create connections
in the overlay instead of the Peer Protocol (as proposed in
[HIP-HOP])?
6. Implementing the Shim Layer
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.
Cooper, et al. Expires May 14, 2008 [Page 11]
Internet-Draft ID/Loc November 2007
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.
7. IANA Considerations
TBD.
8. Security Considerations
TBD.
9. Informative References
[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.
Cooper, et al. Expires May 14, 2008 [Page 12]
Internet-Draft ID/Loc November 2007
[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.
Authors' Addresses
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
Cooper, et al. Expires May 14, 2008 [Page 13]
Internet-Draft ID/Loc November 2007
Full Copyright Statement
Copyright (C) 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Cooper, et al. Expires May 14, 2008 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-24 04:48:38 |