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

[Gonzalo Camarillo <[e-mail]>]

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
> 
> 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:
> 
>> 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
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/p2psip
> 
> 
> _______________________________________________
> P2PSIP mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/p2psip
> 


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