Subject: [P2PSIP] New draft: draft-matthews-p2psip-hip-hop-00

From: Philip Matthews <[email-masked]>
Date: Sun, 17 Jun 2007 09:15:25 -0400

Folks:

Eric Cooper, Alan Johnston, and I have just written a draft that  
suggests what we think
is an interesting direction for the P2PSIP working group.

We argue that a P2PSIP overlay should use HIP (the Host Identity  
Protocol)
to provide a number of the basic features in an overlay, namely:
	o  Peer IDs;
	o  Transporting messages around the overlay;
	o  Signaling new overlay connections;
	o  Supporting mobility and multi-homing of peers;
	o  Providing message security.

One of the reasons we really like this idea is because, using the  
approach
described in the draft, many existing applications don't require any  
modifications
and "just work" in an overlay.

We describe this idea in a draft that has just been submitted.
Until the draft appears in the archives, you can get a copy at
	http://www.magma.ca/~philip_matthews/draft-willis-p2psip- 
concepts-04.txt
or for the html version
	http://www.magma.ca/~philip_matthews/draft-willis-p2psip- 
concepts-04.htm

Here is the abstract from the draft:
    This document examines a P2PSIP architecture where the peer-to-peer
    (P2P) layer is separate from and lies below the SIP layer.  We
    discuss the functions of the P2P layer in such an architecture, and
    focus in on the Distributed Transport function - the function that
    allows a peer to exchange messages with any other peer in the
    overlay, even in the presence of NATs.  We list the features that  
the
    Distributed Transport function needs to provide, and observe that  
the
    Host Identity Protocol (HIP) already provides a number of these
    features.  We then propose extensions to HIP that allow it to  
provide
    the missing features.  We discuss how a complete P2PSIP architecture
    can be built around HIP, and contrast this approach with other
    approaches for implementing a P2P layer.  Two of the advantages of
    HIP 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.

- Philip

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 17 Jun 2007 21:07:47 +0200

Hi Phillip,

you might also find these two documents of interest for you:

Interaction between SIP and HIP
http://www.tschofenig.com/svn/draft-tschofenig-hiprg-host-identities/draft-tschofenig-hiprg-host-identities-05.txt

Using SRTP transport format with HIP
http://www.tschofenig.com/svn/draft-tschofenig-hiprg-hip-srtp/draft-tschofenig-hiprg-hip-srtp-02.txt

Ciao
Hannes

Philip Matthews wrote:
>     http://www.magma.ca/~philip_matthews/draft-willis-p2psip-concepts-04.txt 
>
> or for the html version
>     http://www.magma.ca/~philip_matthews/draft-willis-p2psip-concepts-04.htm 
>
>
>    overlay, even in the presence of NATs.  We list the features that the
>    Distributed Transport function needs to provide, and observe that the
>    features.  We then propose extensions to HIP that allow it to provide

---

From: Philip Matthews <[email-masked]>
Date: Sun, 17 Jun 2007 19:58:08 -0400

Whoops!
It was just pointed out to me that I gave the wrong links in the e- 
mail below.

The correct links are:
Text version:
     http://www.magma.ca/~philip_matthews/draft-matthews-p2psip-hip- 
hop-00.txt
HTML version:
     http://www.magma.ca/~philip_matthews/draft-matthews-p2psip-hip- 
hop-00.htm

Sorry about that.

- Philip

PS. The links quoted in the original message were to the Concepts draft.
I recommend reading that one too!  :-)

On 17-Jun-07, at 09:15 , Philip Matthews wrote:

> described in the draft, many existing applications don't require  
> any modifications

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 18 Jun 2007 14:05:20 +0300

Hi,

some comments on this draft (disclaimer: I read an earlier version of 
this document; some of my initial comments may have already been 
addressed in this version).

In short, I like the concept of having a generic overlay; there has been 
work in the past to build HIP-based generic overlays (e.g., Hi3).

Many readers will not be familiar with HIP. Thus, we would need to 
clarify a few fundamental concepts. The paper says that hosts can create 
HIs without accessing a central server. It would be good to clarify that 
this can be done when the hosts use opportunistic security (i.e., leap 
of faith). SIP people are familiar with that because of S/MIME; so, they 
will be able to draw a connection between SIP and HIP security.

The draft claims that since HITs are "large enough", there are no 
collisions. I guess we should clarify that large HITs alone do not 
ensure that. That property also come from the fact that HITs are derived 
from HIs using a hash algorithm with low-collision properties.

When talking about integrating HIP with existing applications and the 
fact that HITs look and feel like IPv6 addresses, it would be good to 
mention that there HIP WG is working on an API for HIP-aware 
applications and on how legacy applications (i.e., HIP-unaware 
applications) can use HIP. There are two drafts that we could reference 
in that context. We also need to talk about LSIs in the context of 
non-IPv6 applications.

The paper is not clear on how a typical HIP connection looks like. We 
need to be clear that, after the initial four-way exchange, hosts 
exchange regular ESP-protected IP traffic. That is, the ESP-based 
security association between two hosts is a regular security association 
that even though was established by HIP, does not carry any HIP 
information. We should also say that, given that some applications do 
not want their traffic to be protected by ESP (e.g., applications using 
SRTP), there is work to support alternative protections.

The draft talks about piggybacking regular traffic on HIP packets. 
Existing implementations do not support that. We should be aware that we 
would need to work on that a little more.

The draft also talks about hop-by-hop routing. We have dome some work on 
HIP delegation in the past that could be used in such a context. In any 
case, we will need to work on it a little more as well, especially on 
the security implications.

Cheers,

Gonzalo

Philip Matthews wrote:
> Whoops!
> It was just pointed out to me that I gave the wrong links in the e-mail 
> below.
> 
> The correct links are:
> Text version:
>     
> http://www.magma.ca/~philip_matthews/draft-matthews-p2psip-hip-hop-00.txt
> HTML version:
>     
> http://www.magma.ca/~philip_matthews/draft-matthews-p2psip-hip-hop-00.htm
> 
> Sorry about that.
> 
> - Philip
>

---

From: Philip Matthews <[email-masked]>
Date: Mon, 18 Jun 2007 12:23:13 -0400

Hannes:

Thanks for the references.

 From a quick read of your documents, it seems like they might form  
the basis
of some extensions to our proposal.

However, your document is talking about Client-Server SIP, while ours  
is talking about P2PSIP,
and this seems to  allow us to  do things that you cannot do.

For example, one of the things we like about our approach is
that we can mostly hide the application the face that it is running  
in an overlay.
In other words, we want to take existing applications that work in
a non-overlay environment and make them work in a P2PSIP overlay  
without  change.
We are trying to do this by doing the HIP stuff behind existing APIs  
to the extent possible.
We don't succeed in every case, but the degree to which we do succeed  
is interesting.

- Philip

On 17-Jun-07, at 15:07 , Hannes Tschofenig wrote:

> http://www.tschofenig.com/svn/draft-tschofenig-hiprg-host- 
> identities/draft-tschofenig-hiprg-host-identities-05.txt
>

---

From: Philip Matthews <[email-masked]>
Date: Mon, 18 Jun 2007 14:05:32 -0400

Gonzalo:

May thanks for your comments. Replies inline.

- Philip

PS to others: The authors had asked Gonzalo, who is both a SIP expert  
as well as a HIP WG chair, to read and comment on an earlier version  
of the document. Unfortunately, he got locked away in a room in  
Brussels without Internet access for a while (is this inhuman  
torture, or what? :-) , and was unable to comment before we  
published. Thus some of his comments refer to things that got changed/ 
fixed in the published -00 version.

On 18-Jun-07, at 07:05 , Gonzalo Camarillo wrote:

> Hi,
>
> some comments on this draft (disclaimer: I read an earlier version  
> of this document; some of my initial comments may have already been  
> In short, I like the concept of having a generic overlay; there has  
> been work in the past to build HIP-based generic overlays (e.g., Hi3).

We are glad you like it. For the reasons we state in the draft, we  
now think a more generic approach is better as well.  Others have  
been making  similar comments on the P2PSIP list in the past few days.

> clarify a few fundamental concepts. The paper says that hosts can  
> create HIs without accessing a central server. It would be good to  
> clarify that this can be done when the hosts use opportunistic  
> security (i.e., leap of faith). SIP people are familiar with that  
> because of S/MIME; so, they will be able to draw a connection  
> between SIP and HIP security.

The published -00 version says that Host Identities and HITs (= Peer  
IDs) might be allocated either (a) by a peer generating one on its  
own, or (b) by being allocated one from some external entity. The  
pros and cons of the two approaches need more investigation.

> ensure that. That property also come from the fact that HITs are  
> derived from HIs using a hash algorithm with low-collision properties.

Yes, HITs (= Peer IDs) are generated from a SHA-1 hash of a Host  
Identity. This is similar to the way Chord generates peer IDs, and  
was one of the first things that got us thinking "Hmm ...  HIP seems  
similar to P2PSIP".

I think this is clearer now in the published -00 version, but will  
take a second look.

>
> When talking about integrating HIP with existing applications and  
> the fact that HITs look and feel like IPv6 addresses, it would be  
> good to mention that there HIP WG is working on an API for HIP- 
> aware applications and on how legacy applications (i.e., HIP- 
> unaware applications) can use HIP. There are two drafts that we  
> could reference in that context. We also need to talk about LSIs in  
> the context of non-IPv6 applications.

Yes. we should add these in the next revision.

To my mind, one of the exciting things about the proposal is that  
many existing applications don't need any changes to operate in an  
overlay.  Thus the document on how legacy applications can use HIP is  
especially interesting.

>
> The paper is not clear on how a typical HIP connection looks like.  
> We need to be clear that, after the initial four-way exchange,  
> hosts exchange regular ESP-protected IP traffic. That is, the ESP- 
> based security association between two hosts is a regular security  
> association that even though was established by HIP, does not carry  
> any HIP information. We should also say that, given that some  
> applications do not want their traffic to be protected by ESP  
> (e.g., applications using SRTP), there is work to support  
> alternative protections.

This is now discussed in much more detail. There is a section (5.4.2)  
that discusses both ESP transport and a proposal for an alternative  
transport for SRTP.

> Existing implementations do not support that. We should be aware  
> that we would need to work on that a little more.

We see this happening only inside an overlay. Since the P2PSIP group  
controls these protocols, backwards compatibility is not a problem.

>
> The draft also talks about hop-by-hop routing. We have dome some  
> work on HIP delegation in the past that could be used in such a  
> context. In any case, we will need to work on it a little more as  
> well, especially on the security implications.

There are two security issues here.
One is the security of the HIP signaling messages when they go hop-by- 
hop. Here we think that the existing HIP mechanisms can be easily  
extended.
The other is the security of data piggybacked on these packets. Here  
we think that TLS might be the appropriate approach.
All this is discussed in section 5.5, which is new since the version  
you read.

---

From: JiangXingFeng <[email-masked]>
Date: Wed, 27 Jun 2007 10:02:56 +0800

HI, Philip:

In all, using HIP to deliver peer protocol message is an interesting topic.
I give some comments below.
Regards!

1. section 1.1 Note that SIP and other applications an access the
Distributed Transport function directly without going through the other two
functions.

[JiangXingFeng]Do you want to make the distributed transported function so
general that all application messages could be forwarded in the overlay? 

Let me show an example: 
Alice wants to call Bob? How does Alice send the Invite message? Send to Bob
through the overlay or get the Bob's contact address first, later send to
Bob directly? If Alice sends the invite message through the overlay, what
does the admitting peer of Bob's key do? Forward the message to Bob's
contact address? If it forwards the message, how does the admitting peer
know the characteristic of the value under this key?

2.   o  Network layer: The ability to deliver a message to an arbitrary peer
in the overlay.  In our view, this involves adding a header to the message
that specifies the destination peer ID and then routing that message along
existing connections in the overlay to the destination peer.

[JiangXingFeng] What does the network layer refer to? IP layer or overlay
network layer? 
In my opinion, it refers to overlay network layer here.

3. Figure 2:Each peer in the network is behind its own NAT. 
What does this statement mean? 

4.   There are two ways to send a packet to another peer in the overlay:
   send it on a direct connection to the remote peer, or send it hop-by-
   hop through the overlay.  A peer typically uses hop-by-hop routing
   when it has only a small amount of data to transfer to the remote
   peer (for example, a Distributed Database update or a SIP INVITE
   transaction), and sets up a direct connection when it has a larger
   amount of data to transfer (for example, an RTP session).

In my opinion, only the peer protocol message should be routed hop-by-hop
through the overlay? Like the comments in 1, how does the admitting peer
process the application message? Maybe the peer does not recognize the
specific application message? 

That Sending packets directly to destination peer, i think, is a problem
arising from the usage of HIP, not in the scope of P2P, because in P2PSIP
case, not all communications should be protected by IPSEC ESP.

--
Jiang XingFeng

> -----Original Message-----
> From: Philip Matthews [mailto:[email-masked]]
> Sent: Sunday, June 17, 2007 9:15 PM
> To: P2PSIP Mailing List
> Subject: [P2PSIP] New draft: draft-matthews-p2psip-hip-hop-00
> 
> Folks:
>

---

From: Philip Matthews <[email-masked]>
Date: Thu, 28 Jun 2007 05:19:05 -0400

Jiang XingFeng:

Thanks very much for your questions and comments.
We are pleased that you are interested in the general idea of using  
HIP for P2PSIP.

I have responded in-line.

On 26-Jun-07, at 22:02 , JiangXingFeng wrote:sh tunnels with each other (and maybe  
> negotiate dht to use etc), the p2p layer can provide the SIP UA  
> with a non-NATed network. All signaling is secured and relaying can  
> easily be offered as a service to the SIP layer.
>
> The benefit of layering is that you can reuse existing software  
> implementations directly, you leverage years of NAT traversal  
> experience, and you avoid that p2psip enabling of existing UAs  
> turns into a large software implementation project with lots of  
> uncertain characteristics.
>
> This is NOT intended as an argument in favor of hip-hop vs. dSIP,  
> rather an example to show why I don't like the NAT discussion to be  
> preempted as "ice will be the choice anyway." I'm afraid it will  
> prevent us from looking at other approaches (or reducing ice to the  
> subset we really need).

I agree with much of what you said above.
However, I would like to make a comment.

Even if we push NAT traversal down to a lower layer (as you mention,  
and as draft-matthews-p2psip-hip-hop proposes), there is still the  
question of how the connections at that layer are established.
I think they will use something very ICE-like. It may not be exactly  
ICE, because ICE is officially an extension of SDP, but if we extract  
out the basic concepts, they are independent of SDP or SIP.
There ARE totally different approaches: MIDCOM or Microsoft's  
Universal Plug-n-Play (UPnP), for example (and there are others). But  
right now, none of these different approaches look very compelling to  
me.

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Thu, 28 Jun 2007 05:19:05 -0400

Jiang XingFeng:

> general that all application messages could be forwarded in the  

Yes.
In our proposal, the distributed transport function can transport
many different application protocols, and is not limited to just SIP.
We feel that, if P2PSIP is successful, then people will want to use it
for other protocols. Take a look, for example, at the various IM  
services
one has today (Skype, GoogleTalk, MSN Messenger, ...). In these  
services,
not only can exchange voice and video, but one can also use it to push
a file from one client to another.
We feel that, if we limit ourselves to just SIP, then people will just
use SIP to carry other protocols, something that we think is a bad idea
(and the SIP group agrees with us).

> In my opinion, it refers to overlay network layer here.

Yes. We used the term "network layer' because HIP plays a role in an  
overlay
that is very similar to the role IP plays in IP routing.

> specific application message?

The question is: What do we do if peer X want to send an application  
message to peer Y,
and there is no direct connection between peer X and peer Y.
Does peer X first set up a direct connection, and then send the message,
or does the application message get sent hop-by-hop through the overlay?
In our proposal, both are possible, and we have not yet specified the  
details
of how the choice would be made.
For some protocols, sending hop-by-hop makes more sense, while for other
protocols, first establishing a direct connection makes more sense.

- Philip

> general that all application messages could be forwarded in the  

Yes.
In our proposal, the distributed transport function can transport
many different application protocols, and is not limited to just SIP.
We feel that, if P2PSIP is successful, then people will want to use it
for other protocols. Take a look, for example, at the various IM  
services
one has today (Skype, GoogleTalk, MSN Messenger, ...). In these  
services,
not only can exchange voice and video, but one can also use it to push
a file from one client to another.
We feel that, if we limit ourselves to just SIP, then people will just
use SIP to carry other protocols, something that we think is a bad idea
(and the SIP group agrees with us).

> In my opinion, it refers to overlay network layer here.

Yes. We used the term "network layer' because HIP plays a role in an  
overlay
that is very similar to the role IP plays in IP routing.

> specific application message?

The question is: What do we do if peer X want to send an application  
message to peer Y,
and there is no direct connection between peer X and peer Y.
Does peer X first set up a direct connection, and then send the message,
or does the application message get sent hop-by-hop through the overlay?
In our proposal, both are possible, and we have not yet specified the  
details
of how the choice would be made.
For some protocols, sending hop-by-hop makes more sense, while for other
protocols, first establishing a direct connection makes more sense.

- Philip