Subject: [P2PSIP] Any further HIP discussion in hallways?

From: Spencer Dawkins <[email-masked]>
Date: Thu, 06 Dec 2007 08:55:02 -0800

I agree with Jonathan that further discussion about HIP is really important.

It's OK that this topic wasn't on the agenda this time, but are there any 
hallway discussions planned?

Spencer 

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

---

From: Philip Matthews <[email-masked]>
Date: Thu, 6 Dec 2007 10:36:46 -0800

For anyone who is interested in HIP for P2PSIP, I suggest coming to  
the HIP RG meeting today (Thursday) at 1300.
I will be discussing the current efforts, and there are two other  
discussions on the agenda.

- Philip

On 6-Dec-07, at 08:55 , Spencer Dawkins wrote:

> It's OK that this topic wasn't on the agenda this time, but are  
> there any hallway discussions planned?
>
> Spencer
>
>

---

From: Philip Matthews <[email-masked]>
Date: Thu, 6 Dec 2007 10:39:07 -0800

If there are people who would like to discuss this at this IETF  
meeting, then please send me an e-mail. We might be able to discuss  
this early tomorrow morning.

- Philip

---

From: "Wei Gengyu" <[email-masked]>
Date: Fri, 7 Dec 2007 14:24:01 +0800

Hi, Philip and all,

I do not think it is adequate to use HIP in the P2PSIP overlay. 

From RFC4423 we know that HIP is an enhancement for IP address to be a host identifier.
While HIP was suggested at the place between network layer and the transport layer, 
I still think HIP is also a network stuff because the IP address was originally defined to be the host identifier.

Considering the P2PSIP overlay, each peer should be identified unique.
But it would not be directly tied to the host identifier.
Although each peer is necessary to maitain infomation of mapping Peer Id to Host Id or IP address,  
its Peer Id should be generated in a way indepent to the Host Id. 

Regars, 

Gengyu

---

From: Ali Fessi <[email-masked]>
Date: Fri, 07 Dec 2007 14:29:29 +0100

Hi all,

just some comments

(and maybe also questions to the HIP community who think that using HIP 
for P2PSIP is a good idea)

- apparently, it has been currently understood that using the HIT as a 
peer-id is not a good idea. (due to chosen-location attacks, etc..). so 
what's the advantage for using HIP?

- for NAT traversal: HIP is also doing ICE, which can be used for P2PSIP 
or any P2P application anyway.

- mobility can be achieved by a P2PSIP overlay easily once a P2PSIP 
overlay is running. You can just update you current Contact URI. So here 
again, there is no strong argument for HIP

And the main problem with HIP might be:

- resolving a HIT to an IP address is actually a very similar problem as 
resolving a SIP URI to a Contact URI. And for HIP, this can be done by 
adding some infrastructure, like rendez-points, registrations 
extensions, DNS extensions, etc.. and *this HIP infrastructure is not 
there yet!*

You can try to resolve the HIT to an IP address using a DHT (as 
suggested in draft-ahrenholz-hiprg-dht-01 ). But you will probably turn 
into the same problems as for P2PSIP again. So, you're just moving the 
problems to some layers below.

If some people think that HIP is really a great idea for P2PSIP, then it 
should be also clear to the P2PSIP community what are all the 
consequences of using HIP, which additional infra do they need for using 
HIP, whether they need IPSec ESP support on each node, etc.

Cheers,
  Ali

-- 
Ali Fessi
Computer Networks and Internet
University of Tuebingen, Germany
Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220
EMail: [email-masked]
Web: http://net.informatik.uni-tuebingen.de/~fessi/

---

From: Ingmar Baumgart <[email-masked]>
Date: Fri, 07 Dec 2007 07:46:40 -0800

I agree with most of your issues, but:

By simply updating your Contact URI you won't get seamless voice stream
connectivity. In this case HIP really could help.

And it is true that with P2PSIP and HIP you have the same problem: you
need some kind of distributed name resolution service. But maybe you can
simply use the same name resolution service for both protocols?

Regards,
  Ingmar

-- 
Dipl.-Inform. Ingmar Baumgart
Institut für Telematik, Universität Karlsruhe (TH)
Zirkel 2, 76128 Karlsruhe, Germany
Phone: +49 721 608 8281, Fax: +49 721 608 6789

---

From: Ali Fessi <[email-masked]>
Date: Fri, 07 Dec 2007 17:21:28 +0100

Hi Ingmar,

please see inline

> connectivity. In this case HIP really could help.

if you want to support mobility during a running session, you will 
probably have to send a (re-)INVITE message directly to the peers with 
whoom you're communicating. I'm not saying that you will have then 
seamless voice stream connectivity, but at least i don't see why the HIP 
UPDATE mechanism could perform better.

> simply use the same name resolution service for both protocols?

yes, you could. that would be the case if you're using something like 
P2PNS for the name resolution ;)

but then, both the P2PSIP and the HIP lookup services will be running on 
top of P2PNS, independantly of each other, and it will probably not make 
sense that P2PSIP depends on HIP.

cheers,
  Ali

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 07 Dec 2007 19:07:53 +0100

This is a very good summary, Ali.

I see the usage of HIP for (P2P)SIP more as another end-to-end media 
security solution.

Ciao
Hannes

Ali Fessi wrote:
> Hi all,
>
> just some comments
>
> (and maybe also questions to the HIP community who think that using 
> HIP for P2PSIP is a good idea)
>
> peer-id is not a good idea. (due to chosen-location attacks, etc..). 
> so what's the advantage for using HIP?
>
> - for NAT traversal: HIP is also doing ICE, which can be used for 
> P2PSIP or any P2P application anyway.
>
> overlay is running. You can just update you current Contact URI. So 
> here again, there is no strong argument for HIP
>
> - resolving a HIT to an IP address is actually a very similar problem 
> as resolving a SIP URI to a Contact URI. And for HIP, this can be done 
> by adding some infrastructure, like rendez-points, registrations 
> suggested in draft-ahrenholz-hiprg-dht-01 ). But you will probably 
> turn into the same problems as for P2PSIP again. So, you're just 
> moving the problems to some layers below.
>
> If some people think that HIP is really a great idea for P2PSIP, then 
> it should be also clear to the P2PSIP community what are all the 
> consequences of using HIP, which additional infra do they need for 
> using HIP, whether they need IPSec ESP support on each node, etc.
>
>
> Cheers,
>  Ali
>

---

From: Philip Matthews <[email-masked]>
Date: Fri, 7 Dec 2007 11:46:05 -0800

A brief reply for now. See inline.
- Philip
On 7-Dec-07, at 05:29 , Ali Fessi wrote:

> - apparently, it has been currently understood that using the HIT  
> as a peer-id is not a good idea. (due to chosen-location attacks,  
> etc..). so what's the advantage for using HIP?

The main advantage that I see is that it allows many existing  
applications to run in a P2P overlay without changes, unlike all the  
non-HIP proposals, which require changes to your applications. In  
essence, HIP turns your P2P Overlay into a VPN, and so existing  
applications work in this VPN in much the same way they do in  
existing VPNs. The implementation of HIP uses VPN implementation  
techniques, so if you computer can run VPN software (and many OSes  
can) then it can run HIP.

Like existing VPNs, HIP can also provide encryption between peers in  
the overlay.

> P2PSIP or any P2P application anyway.

Yes, but with the non-HIP-based proposals, you have to modify your  
application.

> here again, there is no strong argument for HIP

Err.. I would not say that mobility is easy.  However, the ID/Locator  
split idea of HIP make mobility easier.

> - resolving a HIT to an IP address is actually a very similar  
> problem as resolving a SIP URI to a Contact URI. And for HIP, this  
> can be done by adding some infrastructure, like rendez-points,  
> registrations extensions, DNS extensions, etc.. and *this HIP  
> infrastructure is not there yet!
>
> If some people think that HIP is really a great idea for P2PSIP,  
> then it should be also clear to the P2PSIP community what are all  
> the consequences of using HIP, which additional infra do they need  
> for using HIP, whether they need IPSec ESP support on each node, etc.

I don't think you understand how the proposals work. None of the  
three current HIP-based proposals require anything extra. They just  
use the DHT.

Try reading draft-matthews-p2psip-id-loc, and look at the example in  
the document. I think this might be easiest way to understand what is  
going on.

- Philip

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Fri, 7 Dec 2007 22:29:24 +0100

Philip,
does HIP have any impact on overlays interconnection (inter-domain routing)?

Thanks,
Victor

-- 
Victor Pascual Ávila

---

From: Philip Matthews <[email-masked]>
Date: Fri, 7 Dec 2007 16:22:13 -0800

> does HIP have any impact on overlays interconnection (inter-domain  

So far, we have not considered connections between two different  
overlays. Right now, everyone seems to be assuming that this  
connection would be made with ordinary client-server SIP.

- Philip

---

From: Spencer Dawkins <[email-masked]>
Date: Sat, 08 Dec 2007 09:20:15 -0600

Recognizing that we are all too stupid from lack of rest to have an 
intelligent conversation this weekend ... but continuing to type anyway ...

:-)

> split idea of HIP make mobility easier.

I agree with Philip's response here, but want to point to a related topic.

A decent number of the application scenarios would benefit from multihoming, 
and another design goal for Bob Moskowitz-era HIP was supporting IPsec VPNs 
that survived path changes because IPsec only saw HITs, so when the 
underlying IP addresses changed, applications survived.

(That's why HITs look like IPv6 addresses, by the way)

This matters more in my own application scenarios of interest, and the 
ID/Loc split in HIP helps with this as well.

Both mobility and multihoming are discussed (in the same section) in 
http://tools.ietf.org/html/rfc4423.

People may be thinking about SIP-level or overlay-level mobility in their 
environments, but neither of these are attributes in the current version of 
the application scenarios draft.

I think some of the "carrier-grade robustness" attributes could be addressed 
by multihoming, but I'm sure this isn't explicit in the current draft, 
either.

I meant to say this during the talk on routing, but we only had 15 minutes 
and I wanted to give the working group as much precious discussion time as 
possible - BUT,

- I'm not thinking that the application scenarios draft would even be 
adopted as a WG draft, and certainly would not be a prerequisite for 
requirements, concepts descriptions, or peer protocol proposals,

BUT

- It would be nice for people to think about the current draft contents, and 
tell us what they are thinking about, that isn't covered (like mobility, 
like support for survivability).

http://tools.ietf.org/wg/p2psip/draft-bryan-p2psip-app-scenarios-00.txt

If you can provide a column (that describes an application scenario), or a 
row (that does the attribute analysis for multiple application scenarios), 
that would be absolutely lovely.

IMO, of course.

Thanks,

Spencer

---

From: "Henry Sinnreich" <[email-masked]>
Date: Sun, 9 Dec 2007 18:28:11 -0800

>whoom you're communicating.

This is a narrow SIP-centric view and probably not optimal either.

See rather http://en.wikipedia.org/wiki/Media_independent_handover how
it can be done at L2 for all IP sessions.

Henry

-----Original Message-----
From: Ali Fessi [mailto:[email-masked]] 
Sent: Friday, December 07, 2007 8:21 AM
To: Ingmar Baumgart
Cc: [email-masked]; Philip Matthews
Subject: Re: [P2PSIP] HIP pros and cons

Hi Ingmar,

please see inline

cheers,
  Ali

>> (and maybe also questions to the HIP community who think that using
HIP
>> peer-id is not a good idea. (due to chosen-location attacks, etc..).
so
>> - for NAT traversal: HIP is also doing ICE, which can be used for
P2PSIP
>> overlay is running. You can just update you current Contact URI. So
here
>> - resolving a HIT to an IP address is actually a very similar problem
as
>> suggested in draft-ahrenholz-hiprg-dht-01 ). But you will probably
turn
>> If some people think that HIP is really a great idea for P2PSIP, then
it
>> consequences of using HIP, which additional infra do they need for
using

---

From: Ali Fessi <[email-masked]>
Date: Mon, 10 Dec 2007 16:02:58 +0100

Dear Henry,

> it can be done at L2 for all IP sessions.

thanks for you hint. Of course there are many possibilities to achieve 
mobility. But it is difficult to say, which one is the best.

The discussion was about the pros and cons of using HIP as underlying 
protocol for P2PSIP. and I was arguing that HIP can be useful for 
mobility, but you can also achieve mobility with different approaches, 
e.g. SIP. and IMHO, it is not obvious to show why HIP mobility is more 
efficient.

Cheers,
  Ali