Subject: [P2PSIP] Re: HIP pros and cons

From: Miika Komu <[email-masked]>
Date: Sat, 8 Dec 2007 02:43:49 +0200 (EET)

Ali Fessi <[email-masked]> 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)
>
> - 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?

I am not sure about the issue here but does the chosen-location attack 
have do anything with HIP? I think it is not really a HIP specific attack, 
just something related to DHTs.

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

I'd disagree here. It is possible to use ICE in P2P-SIP because it is 
completely new application and not a legacy application. However, if you 
think about it architecturally, why makes P2P-SIP so special that it must 
burden itself with NAT traversal? Why cannot just use a NAT traversal 
service transparently from the lower layers?

I think the designers and implementors of P2P-SIP can concentrate better 
to some P2P-SIP issues if NAT traversal is handled by someone else.

> - 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

Disagree again here. Doesn't it still disconnect active phone calls?

If you want to support mobility during phone calls in P2P-SIP, I'd ask the 
same question as before: what makes SIP such an special application that 
it needs its own host mobility mechanism?

> 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!*

Agree partially, but I think this would make new business cases for 
corporations from deploying infrastructure for customers.

The DNS extensions are not mandatory. You can use opportunistic mode which 
works in the similar leap-of-fait manner as ssh.

> 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.

Well, isn't it the right layer for solving those problems?

> 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.

Minimal requirements are that you need some HIP relays to transport the 
HIP "offer/answer". Implementing NULL-ESP is trivial and supported by the 
HIP specs. DNS extensions are not mandatory.

-- 
Miika Komu                                       http://www.iki.fi/miika/

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

---

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

> If you want to support mobility during phone calls in P2P-SIP

See
http://en.wikipedia.org/wiki/Media_independent_handover

>I think the designers and implementors of P2P-SIP can concentrate
better to >some P2P-SIP issues if NAT traversal is handled by someone
else. Why cannot >just use a NAT traversal service transparently from
the lower layers?

I fully agree. See the link above.

The P2P SIP WG is now closer IMHO to examine carefully the various
proposals and meld the best features as much as possible. This will
require a lot of work, both analytical comparisons and measurements.

See also:

http://tools.ietf.org/id/draft-ahrenholz-hiprg-dht-01.txt

As for ICE/STUN/TURN vs. HIP I would not exclude a synergy between the
two that can be devised, since the HIP security, mobility, multiplex,
etc. and applicability for any other application protocol are hard to
beat and IP also uses an ICE-like approach.

http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-02.txt 

Henry  

-----Original Message-----
From: Miika Komu [mailto:[email-masked]] 
Sent: Friday, December 07, 2007 4:44 PM
To: [email-masked]
Subject: [P2PSIP] Re: HIP pros and cons

I am not sure about the issue here but does the chosen-location attack 
have do anything with HIP? I think it is not really a HIP specific
attack, 
just something related to DHTs.

think about it architecturally, why makes P2P-SIP so special that it
must 
burden itself with NAT traversal? Why cannot just use a NAT traversal 
service transparently from the lower layers?

If you want to support mobility during phone calls in P2P-SIP, I'd ask
the 
same question as before: what makes SIP such an special application that

The DNS extensions are not mandatory. You can use opportunistic mode
which 
works in the similar leap-of-fait manner as ssh.

Minimal requirements are that you need some HIP relays to transport the 
HIP "offer/answer". Implementing NULL-ESP is trivial and supported by
the 
HIP specs. DNS extensions are not mandatory.

-- 
Miika Komu
http://www.iki.fi/miika/

---

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

Miika,

thanks for the clarification.

one question: what happens if the HIP identifier colludes with an IPv6 
address that is reserved for multicast, anycast, or e.g. local IPv6 
addresses?

or does HIP generate several public/private pairs until it finds a good one?

Cheers,
  Ali

Miika Komu wrote:
> attack, just something related to DHTs.
> 
> must burden itself with NAT traversal? Why cannot just use a NAT 
> traversal service transparently from the lower layers?
> 
> the same question as before: what makes SIP such an special application 
> that it needs its own host mobility mechanism?
> 
> which works in the similar leap-of-fait manner as ssh.
> 
> the HIP specs. DNS extensions are not mandatory.
> 

-- 
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: "Bruce Lowekamp" <[email-masked]>
Date: Mon, 10 Dec 2007 11:56:36 -0500

> just something related to DHTs.

The chosen location attack is related to the method of generating a
HIT from a node-generated key.  As long as the HIT can be allocated by
an enrollment server (or otherwise secured so that a single node
cannot generate multiple or arbitrary HITs), there isn't a security
problem here.  If a node must be able to generate its own HIT, then
the HIT cannot be used as a replacement for the peer-id in a DHT.

> works in the similar leap-of-fait manner as ssh.

Surely there's an option in between "use dns" and "use leap-of-faith"
of using certificate chains?

> HIP specs. DNS extensions are not mandatory.

(I rearranged this a little bit to bring these two issues together.)

One of the confusing things about applying HIP to p2psip is the
layering issues required to address the deployment scenarios for
p2psip.  We need it to work in an environment without provisioned DNS
support for the overlay and where we cannot assume an infrastructure
provider providing HIP relays.  We need to be able to obtain those
services from peers in the overlay.  So, minimally, this means the
ability to support the HIP relay functionality at the overlay layer.
This is where the proposal becomes confusing, because while HIP
provides a very nice abstraction on top of which to build a p2p
application, it also requires that p2p application for its
connectivity.

I've spent some time working with Philip on how to provide support for
HIP inside of a p2psip peer protocol, and I think it's entirely
doable, but I think we need to be clear on how the layering works and
what support is needed in both directions before deciding how to
accomplish it.

Bruce

---

From: Spencer Dawkins <[email-masked]>
Date: Mon, 10 Dec 2007 12:15:16 -0600

> what support is needed in both directions before deciding how to

I agree completely (on both "doable" and "need to be clear on how the 
layering works").

At a minumum, we could figure out whether we're running SIP over HIP or HIP 
over SIP...

:-)

Spencer

---

From: "Roy, Radhika R Dr CTR USA USAMC" <[email-masked]>
Date: Mon, 10 Dec 2007 13:33:06 -0500

Inline [RRR]

----- Original Message -----
From: Spencer Dawkins 
Date: Monday, December 10, 2007 13:16
Subject: Re: [P2PSIP] Re: HIP pros and cons
To: [email-masked]

> At a minumum, we could figure out whether we're running SIP over 

[RRR] Please help us to understand: What does it mean with respect to the P2PSIP protocol when do the following: SIP over HIP or HIP-over-SIP?

[RRR] Are you suggesting that the P2PSIP protocol will include the above features as well as others defined in the requirement document, and the combined protocol will still be called P2PSIP?

---

From: "Wei Gengyu" <[email-masked]>
Date: Tue, 11 Dec 2007 20:34:44 +0800

Hi Bruce, 

I think there are some problems to be clarified after reading your email. 

When you suppose that P2PSIP overlay works in an environment without provisioned DNS support for the overlay, 
you also suppose there are not other facilities, such as P2PNS, to support for mapping host id to IP address.
So you conclude that you need to do mapping at the P2PSIP overlay.  In this situation HIP is required.
Do I understand it right?

I also admit that HIP is good in terms of supporting mobility, multihome, unique host id etc.
But, I think we realy need to make the working environment of  P2PSIP overlay clear.

For conventional Internet with DNS, P2PSIP overlay could get the IP address by mapping DNS to IP address.
For the Internet with HIP at between network layer and transport layer and DNS also works,
      P2PSIP overlay could  get the IP address by mapping DNS-HIT-IP address.
For the working environment without DNS, probably another mapping mechanism, such as P2PNS, would work.

So what you supposed seems to be the working environment without DNS, without HIP at network layer.
Is it in this situation that HIP would work at the P2PSIP overlay? 

I agree what you said "we need to be clear on how the layering works and
what support is needed in both directions before deciding how to accomplish it."

Regards,

Gengyu

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 11 Dec 2007 06:57:25 -0800

Gengyu, Bruce,

Diagrams with step by step resolution would be here of help for us.

Henry

-----Original Message-----
From: Wei Gengyu [mailto:[email-masked]] 
Sent: Tuesday, December 11, 2007 4:35 AM
To: Bruce Lowekamp
Cc: [email-masked]
Subject: Re: [P2PSIP] Re: HIP pros and cons

Hi Bruce, 

I think there are some problems to be clarified after reading your
email. 

When you suppose that P2PSIP overlay works in an environment without
provisioned DNS support for the overlay, 
you also suppose there are not other facilities, such as P2PNS, to
support for mapping host id to IP address.
So you conclude that you need to do mapping at the P2PSIP overlay.  In
this situation HIP is required.
Do I understand it right?

I also admit that HIP is good in terms of supporting mobility,
multihome, unique host id etc.
But, I think we realy need to make the working environment of  P2PSIP
overlay clear.

For conventional Internet with DNS, P2PSIP overlay could get the IP
address by mapping DNS to IP address.
For the Internet with HIP at between network layer and transport layer
and DNS also works,
      P2PSIP overlay could  get the IP address by mapping DNS-HIT-IP
address.
For the working environment without DNS, probably another mapping
mechanism, such as P2PNS, would work.

So what you supposed seems to be the working environment without DNS,
without HIP at network layer.
Is it in this situation that HIP would work at the P2PSIP overlay? 

accomplish it."

Regards,

Gengyu

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 11 Dec 2007 16:48:10 -0800

Bruce,

>We need it to work in an environment without provisioned DNS support
for 
>the overlay and where we cannot assume an infrastructure provider
providing >HIP relays.  We need to be able to obtain those services from
peers in the >overlay.  So, minimally, this means the ability to support
the HIP relay >functionality at the overlay layer.

You are right.

It appears this problem has been addressed in the I-D: 
draft-ahrenholz-hiprg-dht-01 By J. Ahrenholz (2/12/2007)

Jeff: Is this I-D still available online and do you intend to resubmit
an update?

Henry

-----Original Message-----
From: Bruce Lowekamp [mailto:[email-masked]] 
Sent: Monday, December 10, 2007 10:57 AM
To: Miika Komu
Cc: [email-masked]
Subject: Re: [P2PSIP] Re: HIP pros and cons

attack,

which

must
> I think the designers and implementors of P2P-SIP can concentrate
better
the

Bruce

---

From: Miika Komu <[email-masked]>
Date: Wed, 12 Dec 2007 13:11:32 +0200 (EET)

On Mon, 10 Dec 2007, Ali Fessi wrote:

Hi,

it cannot because IANA has allocated a special prefix for HIP:

ftp://ftp.rfc-editor.org/in-notes/rfc4843.txt

>> I am not sure about the issue here but does the chosen-location attack have 
>> do anything with HIP? I think it is not really a HIP specific attack, just 
>> something related to DHTs.
>> 
>> I think the designers and implementors of P2P-SIP can concentrate better to 
>> some P2P-SIP issues if NAT traversal is handled by someone else.
>> 
>> same question as before: what makes SIP such an special application that it 
>> needs its own host mobility mechanism?
>> 
>> Minimal requirements are that you need some HIP relays to transport the HIP 
>> "offer/answer". Implementing NULL-ESP is trivial and supported by the HIP 
>> specs. DNS extensions are not mandatory.
>> 
>
>
> -- 
> Ali Fessi

---

From: Miika Komu <[email-masked]>
Date: Wed, 12 Dec 2007 13:11:22 +0200 (EET)

On Sun, 9 Dec 2007, Henry Sinnreich wrote:

Hi,

(sorry for the long delay in comments)

> I fully agree. See the link above.

Having MIH (micromobility) would be great, but it seems to me that it 
requires support both from the infrastructure (access points, core) and 
end-user equipment. I have no idea how widely deployed that stuff is. 
Minimally, HIP (macromobility) requires support only from the end-user 
equipment. Having both of them would be great.

(There is also a paper called Micromobility support in HIP: survey and 
extension of host identity protocol by Novaczki et al)

> http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-02.txt

FYI, the HIP-NAT design team is going to use ICE (almost) as it is for NAT 
traversal at the lower layers to reuse ICE implementations.

---

From: Miika Komu <[email-masked]>
Date: Wed, 12 Dec 2007 13:11:45 +0200 (EET)

> the HIT cannot be used as a replacement for the peer-id in a DHT.

What prevents a node from allocating keys from the enrollment server until 
it gets what it wants?

Besides, there is an additional cost in using the HIT as the key. The HIT 
is generated from a public key and creation of public keys costs more than 
just generating a random key.

> of using certificate chains?

Surely, if you have PKI :) This has similar, or even worse, infrastructure 
requirements as DNS.

> application, it also requires that p2p application for its

By p2p application you mean the overlay? HIP provides security and NAT 
traversal for the overlay and the overlay does what it does. Not a bad 
casting of roles?

Assuming still that you mean the overlay, it would be possible to 
implement the overlay based on HIP, i.e. embed one or multiple DHT 
algorithms to HIP rendezvous forwarding architecture. I am sure that this 
alternative has been discussed earlier here.

> what support is needed in both directions before deciding how to

This sounds like hi3 as long as we are talking about the overlay 
functionality:

http://www.tml.tkk.fi/~pnr/publications/sncnw2004.pdf
http://www.tools.ietf.org/html/draft-nikander-hiprg-hi3-00

Certainly doable. At least OpenHIP and HIPL projects have implemented 
this.

---

From: Miika Komu <[email-masked]>
Date: Wed, 12 Dec 2007 13:12:07 +0200 (EET)

On Mon, 10 Dec 2007, Roy, Radhika R Dr CTR USA USAMC wrote:

> [RRR] Please help us to understand: What does it mean with respect to 
> the P2PSIP protocol when do the following: SIP over HIP or HIP-over-SIP?
>
> [RRR] Are you suggesting that the P2PSIP protocol will include the above 
> features as well as others defined in the requirement document, and the 
> combined protocol will still be called P2PSIP?

I guess it means that HIP could be placed on three places in the stack:

 	application
 	   |
 	transport
 	   |      <----- (1) Overlay routes HIP packets (like Hi3)
 	overlay   <----- (2) HIP-based overlay
 	   |      <----- (3) HIP secures point-to-point connections
           ip                 for overlay nodes

Does this clarify the situation?

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 12 Dec 2007 08:08:12 -0800

At Wed, 12 Dec 2007 13:11:45 +0200 (EET),
> What prevents a node from allocating keys from the enrollment server until 

Yes, you need to throttle queries somewhat at the enrollment server.
But this is a much easier problem than throttling key generations
which don't require a server query.

> just generating a random key.

Not enough more to make a practical difference. Please see my talk
in YVR for the relevant analysis.

-Ekr

---

From: "Ahrenholz, Jeffrey M" <[email-masked]>
Date: Wed, 12 Dec 2007 08:32:30 -0800

Henry,

> Jeff: Is this I-D still available online and do you intend to resubmit

Although this -01 draft has expired, yes I plan to submit a -02 update
based on comments (see hipsec-rg mailing list from August 2007). Here is
the expired draft:
http://www.watersprings.org/pub/id/draft-ahrenholz-hiprg-dht-01.txt

Also, we have deployed a DHT server on our HIP test server at
hipserver.mct.phantomworks.org. When testing HIP you can use that server
or the OpenDHT ring available on PlanetLab. The idea with having our own
server is that in the future we may modify the Bamboo DHT code slightly
to perform increased security checks (see the "hip-secure-addr"
application from the draft.)

-Jeff

---

From: Philip Matthews <[email-masked]>
Date: Tue, 11 Dec 2007 16:32:47 -0800

On 10-Dec-07, at 07:15 , Ali Fessi wrote:

> one question: what happens if the HIP identifier colludes with an  
> IPv6 address that is reserved for multicast, anycast, or e.g. local  
> IPv6 addresses?
>

IANA has allocated a range of IPv6 addresses to use for HITs. Thus  
there no possibility of collision.

- Philip

---

From: Ali Fessi <[email-masked]>
Date: Wed, 12 Dec 2007 17:45:13 +0100

Hi all,

draft draft-ahrenholz-hiprg-dht is currenty an IRTF draft.

Would it make sense to encourage the IETF HIP WG to work on this draft, 
since it could be useful for the P2PSIP WG?

Cheers,
  Ali

---

From: Philip Matthews <[email-masked]>
Date: Wed, 12 Dec 2007 15:15:45 -0500

Henry:

Though the below mentioned work on DHTs is similar to what P2PSIP is  
looking at, none of the three proposals for using HIP for P2PSIP  
published so far make use of it.

- Philip

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 12 Dec 2007 14:09:37 -0800

Phil,

>none of the three proposals for using HIP for P2PSIP  

Shouldn't we look at synergies between the _four_ efforts?
Maybe some separate session would be worth while.

Henry

-----Original Message-----
From: Philip Matthews [mailto:[email-masked]] 
Sent: Wednesday, December 12, 2007 2:16 PM
To: Henry Sinnreich
Cc: Bruce Lowekamp; Miika Komu; [email-masked];
[email-masked]
Subject: Re: [P2PSIP] HIP DHT interface (was HIP pros and cons)

Henry:

- Philip

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Wed, 12 Dec 2007 18:00:37 -0500

Gengyu,

> Do I understand it right?

I'm not sure what you mean by P2PNS there.  I think all of the peer
protocol proposals have ways of searching in the overlay and
establishing a connection with a specific peer.  Certainly reload
does.  HIP isn't needed to solve that problem.

Bruce

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Wed, 12 Dec 2007 18:00:37 -0500

Gengyu,

Bruce

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Wed, 12 Dec 2007 18:21:27 -0500

> Surely, if you have PKI :) This has similar, or even worse, infrastructure

Sorry, but I completely disagree here.  An enrollment server
generating certificates requires one-time communication.  The
enrollment server itself is trivial to write (ignoring how you
authenticate requesters, which will vary by the security model of the
overlay).  It's a trivial addition that could even be provided with
every UA if desired for ad hoc environments.

> traversal for the overlay and the overlay does what it does. Not a bad

Except that the overlay is still needed for rendezvous.  Once you have
that, the nat traversal really isn't hard.

> Certainly doable. At least OpenHIP and HIPL projects have implemented

I'd be interested in how that's implemented.  From what I can see, the
original papers simply assume the existence of Secure-i3 for
rendezvous, and I don't see detailed enough docs from OpenHIP or HIPL
for me to tell how they've implemented it.

Bruce

---

From: Miika Komu <[email-masked]>
Date: Thu, 13 Dec 2007 09:29:37 +0200 (EET)

On Wed, 12 Dec 2007, Eric Rescorla wrote:

Hi Eric,

> which don't require a server query.

I have two questions regarding to this:
* Is it possible to have a distributed enrollment server (i.e. the DHT) or
   is this an open research problem?
* Why can't we just use a centralized enrollment server to distribute
   mandatory certificates for Host Identities? The enrollment server could
   still throttle based on the IP address of the client, which I assume you
   we suggesting?

I find it a little bit controversial that the P2P-SIP is supposed to 
distributed (DHT) and non-distributed (enrollment servers) at the same 
time. Who owns the centralized enrollment server and how do you prevent 
it to become a single point of failure for P2P-SIP?

---

From: Miika Komu <[email-masked]>
Date: Thu, 13 Dec 2007 09:30:20 +0200 (EET)

On Wed, 12 Dec 2007, Bruce Lowekamp wrote:

Hi,

> every UA if desired for ad hoc environments.

Agree if we are talking about a centralized enrollment server (which is 
not really PKI).

> that, the nat traversal really isn't hard.

What layer would you choose to implement the overlay and how would you 
deploy it?

> for me to tell how they've implemented it.

At least HIPL implements it by using the deployed i3 network in planetlab. 
If I recall correctly, HIP packets are transported over i3 headers 
through the overlay and ESP packets are sent directly between the peers. 
We are currently integrating STUN/ICE with "normal-mode" HIP and later 
with Hi3. The implementations are available at:

http://infrahip.hiit.fi/
http://www.openhip.org/
http://www.hip4inter.net/

---

From: Joakim Koskela <[email-masked]>
Date: Thu, 13 Dec 2007 11:56:18 +0200

Hi,

I don't think there's anything in the with-hip that would prevent us from 
using opendht or any of the other proposed hip lookup infrastructures. My 
personal view on this thing is that when establishing p2p connections we 
should use all available methods/channels. 

One of the benefits of using hip is that we aren't bound to only using an 
ICE-like procedure through the overlay (which I think many of the proposals 
are restricted to), but we can also use whatever other methods that hip might 
provide - existing (dns, rvs, opendht ..), planned or something that hasn't 
even been thought of yet.

Although will need the overlay for the initial aor lookup and it's usually a 
safe bet for getting initial packets through, I think it's also a good idea 
if we have some way of establishing connections in case the overlay gets 
partially congested or suitably populated with malicious / malfunctioning 
peers (which I guess can be a problem even if we have good access control and 
network diagnostics). That's why I'm voting for this sort of hybrid approach 
where we use hip for connections (thus benefit from existing non p2psip 
infrastructure), but where the bex can go through the overlay as well. The 
only thing that might be confusing is the layering issues. 

..and to pour some fuel on that fire - is it really that bad sending the bex 
over the peer protocol? Doesn't actually most protocols relay their 
corresponding connection establishment info (ICE candidates) on top of the 
peer protocol? Would it help if we called it something like 'connectivity 
parameter packets' (instead of hip packets) which would just happen to have 
basically the same information as the I1/R1/I2/R2 packets (ICE candidates and 
keying material, signed) and be fed into the hip daemon on the receiver side? 
Is this just horribly wrong? Subsequent mobility / multihoming updates would 
of course be handled at the hip-layer only without any involvement of the 
p2psip application.

br, j

On Wednesday 12 December 2007 22:15:45 Philip Matthews 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
> >
> >>> - 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
> >
> >>> extensions, DNS extensions, etc.. and *this HIP infrastructure is
> >
> > not
> >
> >>> there yet!*
> >>
> >>> - for NAT traversal: HIP is also doing ICE, which can be used for
> >
> > P2PSIP
> >
> >> completely new application and not a legacy application. However, if
> >
> > you
> >
> >>> 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
> >
> >> Minimal requirements are that you need some HIP relays to transport
> >
> > the
> >

-- 
Joakim Koskela
Helsinki Institute for Information Technology (HIIT)
email: [email-masked]
mobile: +358 50 5459786

---

From: Miika Komu <[email-masked]>
Date: Thu, 13 Dec 2007 12:27:24 +0200 (EET)

On Wed, 12 Dec 2007, Ali Fessi wrote:

Hi Ali,

the WG is currently chartered for NAT traversal.

> Would it make sense to encourage the IETF HIP WG to work on this draft, since 
> it could be useful for the P2PSIP WG?
>
>
> Cheers,
> Ali
>

---

From: Philip Matthews <[email-masked]>
Date: Thu, 13 Dec 2007 08:28:19 -0500

I think it would be great to find synergies between all the efforts.
This effort is starting now on the HIP RG mailing list.

- Philip

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 13 Dec 2007 07:18:58 -0800

Phil,

> This effort is starting now on the HIP RG mailing list.

This is good news and I hope it will be pursued by all parties!

What we need now is an _ANALYTICAL STUDY_ inside an I-D (instead of
endless mail) showing what HIP is adding (or not) to P2PSIP and I hope
the folks knowing HIP can collaborate for such a paper on a private
list.

For HIP supported NAT traversal, what are all the options to succeed in
multi-NAT-ed networks, especially for hairpinning?

Peers inside various  NAT levels can use STUN techniques to determine
their NAT scenario and communicate it to other peers, but such a
protocol has net yet been proposed and ICE is really dealing best only
with the NAT level closest to the STUN/TURN server. What could HIP do
here better and if yes, then how? 

Such 5%-10% corner cases where ICE may fail (are there other numbers?)
but HIP may be more successful would indeed make all the difference.

Or should we all admit that using port 80 (perish the thought) is the
last resort for NAT traversal? If so, how does HIP matter? Again, a
formal paper would really help.

Henry

-----Original Message-----
From: Philip Matthews [mailto:[email-masked]] 
Sent: Thursday, December 13, 2007 7:28 AM
To: Henry Sinnreich
Cc: Bruce Lowekamp; Miika Komu; [email-masked];
[email-masked]

- Philip

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Thu, 13 Dec 2007 11:14:43 -0500

>    is this an open research problem?

For the purposes of the p2psip wg, it was ruled out of scope as an
open research problem.

>    still throttle based on the IP address of the client, which I assume you

As long as the enrollment server is able to restrict someone from
picking arbitrary IDs and either throttles requests or restricts
requests in some other way, that probably meets the security
requirement.  Not very secure if it's just based on the IP address of
the client, though, as it's easy to get a lot of those.

> it to become a single point of failure for P2P-SIP?

Depends on the deployment scenario.  For a partial list, take a look
at http://tools.ietf.org/wg/p2psip/draft-bryan-p2psip-app-scenarios-00.txt

Bruce

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 13 Dec 2007 08:30:32 -0800

At Thu, 13 Dec 2007 09:29:37 +0200 (EET),
>    is this an open research problem?

It's an open research problem. Moreover it's explicitly a non-charter
item.

>    still throttle based on the IP address of the client, which I assume you

I don't know what this means. The entire point of the HIP public-key->HIT
relationship was to make HITs self-authenticating. Once you're using
certificates, you've dramatically changed the situation.

> time.

Well, again, it's a charter item, moreover, there was consensus
*again* in YVR.

-Ekr

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Thu, 13 Dec 2007 12:00:19 -0500

> Agree if we are talking about a centralized enrollment server (which is

True.  I think some of the application scenarios call for true PKI,
but I don't think anyone has proposed solving that problem as part of
a standards draft at this point (the assumption being that if someone
wants to use this for a large-scale type deployment, they can figure
out how to do it).

> What layer would you choose to implement the overlay and how would you

There are so many different proposals for architecture that I think
it's hard to answer that question.  Thinking of reload only
(architecture at
http://www.p2psip.org/drafts/draft-bryan-p2psip-reload-02.html#anchor2)
anything from a "pure HIP" replacing both the Transport Layer and
STUN/ICE at the forwarding layer, if it's in a deployment where the
necessary infrastructure is there for HIP to function; to just as a
transport layer with the overlay routing the setup messages (acting as
a rendezvous server); to something where the p2psip functions without
hip and essentially provides the id/locator abstraction to the
application layer have been proposed in various p2psip drafts.

I suspect that ultimately, we will not and should not settle on a
single solution, but there will be a couple different options for
transports that are viable and make sense in different deployment
scenarios.  If HIP proves itself useful, it will naturally be adopted.

Bruce

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Thu, 13 Dec 2007 12:03:04 -0500

> but HIP may be more successful would indeed make all the difference.

HIP is using ICE for establishing connectivity.  It has a couple
different interesting methods for locating a rendezvous server, but
ICE is still the basic proposal for seeing if you can get a direct
connection (or fallback to a relay) between nodes, AFAIK.

Bruce

---

From: Miika Komu <[email-masked]>
Date: Thu, 13 Dec 2007 22:51:41 +0200 (EET)

On Thu, 13 Dec 2007, Eric Rescorla wrote:

Hi Eric,

> certificates, you've dramatically changed the situation.

It means that the centralized enrollment server has to sign your public 
key, possibly along with some other data such as URI. When too many 
enrollments are coming from a single IP, the enrollment server just drops 
the enrollments. Without successful enrollment, you cannot be part of the 
overlay.

The enrollment procedure could be folded nicely to a HIP base exchange 
with some registration parameters:

http://www.ietf.org/internet-drafts/draft-ietf-hip-registration-02.txt

It is possible to do this, of course, at the upper layers.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 13 Dec 2007 12:52:50 -0800

At Thu, 13 Dec 2007 22:51:41 +0200 (EET),
> It is possible to do this, of course, at the upper layers.

Yes, but I don't see how HIP is offering any advantage here.

-Ekr

---

From: "Palanisamy, Kandasamy (Kandasamy)" <[email-masked]>
Date: Thu, 13 Dec 2007 16:01:33 -0700

How will centralized enrollment dropping too many enrollments from a
single IP restrict
  enrollments from a botnet? Won't each entity in the botnet be
considered a separate
  peer?

  How does any of the protocols - HIP-based or reload - handle botnets?
  Does that threat need to be addressed? Is that not applicable for the
P2P scenario?

Kand

-----Original Message-----
From: Miika Komu [mailto:[email-masked]] 
Sent: Thursday, December 13, 2007 12:52 PM
To: Eric Rescorla
Cc: [email-masked]
Subject: Re: [P2PSIP] Re: HIP pros and cons

Hi Eric,

> I don't know what this means. The entire point of the HIP 
> public-key->HIT relationship was to make HITs self-authenticating. 
> Once you're using certificates, you've dramatically changed the
situation.

It means that the centralized enrollment server has to sign your public
key, possibly along with some other data such as URI. When too many
enrollments are coming from a single IP, the enrollment server just
drops the enrollments. Without successful enrollment, you cannot be part
of the overlay.

-- 
Miika Komu
http://www.iki.fi/miika/

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 13 Dec 2007 15:46:02 -0800

>Well, again, it's a charter item, moreover, there was consensus

The charter says 
"The initial work will assume the existence of some enrollment
process..."
"Developing a non-centralized enrollment process is not in scope."

Research type p2p topics are also excluded. 

http://ietf.org/html.charters/p2psip-charter.html 

Please help me understand.

Henry

-----Original Message-----
From: Eric Rescorla [mailto:[email-masked]] 
Sent: Thursday, December 13, 2007 10:31 AM
To: Miika Komu
Cc: [email-masked]
Subject: Re: [P2PSIP] Re: HIP pros and cons

public-key->HIT

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 13 Dec 2007 15:44:01 -0800

At Thu, 13 Dec 2007 15:46:02 -0800,
> Please help me understand.

Well, what I was trying to say was that centralized enrollment was
a charter item and distributed was not.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 13 Dec 2007 15:46:11 -0800

At Thu, 13 Dec 2007 16:01:33 -0700,
>   enrollments from a botnet? Won't each entity in the botnet be

Yes, it's clear that if you use IP then botnets are a problem.
That's why I didn't make IP a concrete proposal for enrollment
limitation. Clearly, there are techniques which are not
botnet susceptible (e.g., credit card #). In any case, this
question is out of scope for the WG. We are simply to assume
that some mechanism exists for the central enrollment server
to use to throttle mass enrollment by attackers.

-Ekr

---

From: Miika Komu <[email-masked]>
Date: Fri, 14 Dec 2007 08:40:40 +0200 (EET)

On Thu, 13 Dec 2007, Henry Sinnreich wrote:

Hi Henry,

> the folks knowing HIP can collaborate for such a paper on a private

Sure, just let us know when the list exists.

> multi-NAT-ed networks, especially for hairpinning?

HIP use ICE as its NAT traversal mechanism and hence has the same 
properties as ICE. Also, it has few extra advantage over plain ICE. First, 
there is no need to burden the application with the details (=API) of ICE. 
Second, the application can address other peers globally using the HITs.

Hairpinning means that a host talks to another host behind the same NAT. 
As I mentioned, HIP uses ICE and ICE supports hairpinning. However, when 
ICE tries connectivity tests between all candidate pairs, it tries also 
connectivity tests between HITs. As far as I have understoon, this should 
mean effectively that the HIP software should try to send HIP directly 
over IP. Legacy NATs will certainly drop these packets and we can 
determine that there is definitely not any NAT between.

> here better and if yes, then how?

I think ICE does not care about NAT scenarios. It just gets a bunch of 
addresses associated with the local host and then it tries to connect them 
peer addresses. Trying to determine a NAT scenario is prone to error and 
has been excluded from ICE design because it is too flaky.

> but HIP may be more successful would indeed make all the difference.

I am curious to get a reference for these numbers?

I mentioned on benefit of HIP above regarding to hairpinning. We have also 
been discussing if we can reuse HIP D-H keymaterial to provide some extra 
protection for the STUN/ICE messages.

> formal paper would really help.

The ESP packets are supposed to be run over UDP unless the hosts are 
behind the same NAT, in which case we can exclude the UDP encapsulation. 
Also DNS requests use UDP, so I think they should traverse firewalls 
relative well. Unfortunately, I don't have any statistics to reference.

---

From: Miika Komu <[email-masked]>
Date: Fri, 14 Dec 2007 09:08:30 +0200 (EET)

> Yes, but I don't see how HIP is offering any advantage here.

Ok, let's forget about the certificates with HIP then. If the clients 
create their own public keys and the centralized enrollment server 
requires the client to provide a credit card number or captcha, I don't 
see what is the problem then? I don't really see why the enrollment server 
needs to create the identifiers in such a case. The cost of an attack is 
just too expensive.

---

From: "Wei Gengyu" <[email-masked]>
Date: Fri, 14 Dec 2007 16:41:37 +0800

Bruce, 

What I understood to use HIP in some proposals is for generation and/or resolution of Peer ID.
Before establishing a connetion beween Peers, the intiative peer should resolve the IP address of the destination peer by Peer ID.
With or without HIP in conventional Internet, we do it by DNS services.

The working environment that you supposed is without DNS, so HIP will be a doable facility of resolution for P2PSIP overlay.

My basic idea is that each Peer should do resolution relying on some common facilities/services in the Internet, not do it by itself. 
As P2PSIP is just a facility to support SIP,  the Peer ID resolution mechanism is not sole funtion of P2PSIP 
among applications based on P2P technology in Internet. 
Prabably there is another resolution mechanism in the Internet, such as P2PNS when DNS is not there. 

So, I think Peer ID resolution function is an external facility adhered to P2PSIP,
just as DNS service is an external faciltiy of SIP. 

I think this should be noticed when defining peer protocol.

Gengyu

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 14 Dec 2007 03:24:52 -0800

Bruce,

>HIP is using ICE for establishing connectivity.

How do you see the handling of multi-NAT-ed scenarios and hairpinning? 

How can we detect multi-homing, before one of the links has failed?

Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bruce
Lowekamp
Sent: Thursday, December 13, 2007 11:03 AM
To: Henry Sinnreich
Cc: Philip Matthews; Miika Komu; [email-masked];
[email-masked]
Subject: Re: [P2PSIP] HIP DHT interface (was HIP pros and cons)

Bruce

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Fri, 14 Dec 2007 09:28:13 -0500

> The working environment that you supposed is without DNS, so HIP will be a doable facility of resolution for P2PSIP overlay.

I think HIP is an option for a transport, but I'm still unclear on how
it will be accomplished.  My impression is still that HIP is not
designed to work standalone, i.e. in an ad hoc network without access
to external services.  It will have to rely on the P2P overlay for the
rendezvous functionality it gets from other external services.  I am
also concerned that it appears to be addressing a different set of
security concerns than a P2P overlay has, and it is not immediately
clear to me how those will be resolved.

Some of the advantages of HIP can be achieved with other techniques,
such as Philip's ID/Loc draft.

> I think this should be noticed when defining peer protocol.

I think all of the p2psip peer protocol proposals at this point
separate a basic P2P overlay routing and resource storage abstraction
from the P2PSIP application layer.

Bruce

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 14 Dec 2007 06:25:07 -0800

>Peer ID resolution function is an external facility adhered to 
>P2PSIP, just as DNS service is an external faciltiy of SIP. 

>I think this should be noticed when defining peer protocol.

I agree. Could something like this also be included in the Concepts I-D?

As for the HIP pros and cons, such a resolution at the HIP RSV level
would work for any other application level protocols as well. 
Do you see any problems?

Henry

-----Original Message-----
From: Wei Gengyu [mailto:[email-masked]] 
Sent: Friday, December 14, 2007 2:42 AM
To: Bruce Lowekamp
Cc: [email-masked]
Subject: Re: [P2PSIP] Re: HIP pros and cons

Bruce, 

What I understood to use HIP in some proposals is for generation and/or
resolution of Peer ID.
Before establishing a connetion beween Peers, the intiative peer should
resolve the IP address of the destination peer by Peer ID.
With or without HIP in conventional Internet, we do it by DNS services.

The working environment that you supposed is without DNS, so HIP will be
a doable facility of resolution for P2PSIP overlay.

My basic idea is that each Peer should do resolution relying on some
common facilities/services in the Internet, not do it by itself. 
As P2PSIP is just a facility to support SIP,  the Peer ID resolution
mechanism is not sole funtion of P2PSIP 
among applications based on P2P technology in Internet. 
Prabably there is another resolution mechanism in the Internet, such as
P2PNS when DNS is not there. 

So, I think Peer ID resolution function is an external facility adhered
to P2PSIP,
just as DNS service is an external faciltiy of SIP. 

Gengyu

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 14 Dec 2007 06:25:07 -0800

Henry

-----Original Message-----
From: Wei Gengyu [mailto:[email-masked]] 
Sent: Friday, December 14, 2007 2:42 AM
To: Bruce Lowekamp
Cc: [email-masked]
Subject: Re: [P2PSIP] Re: HIP pros and cons

Bruce, 

Gengyu

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 14 Dec 2007 06:38:57 -0800

Miika,

>I am curious to get a reference for these numbers?

http://www.bford.info/pub/net/p2pnat/

The numbers are actually far worse. Look at Table 1.
I must confess this paper has made me more than cautious until we see
similar tools and deployment measurements for ICE and ICE-based HIP NAT
traversal. Not to mention delay measurements.

Henry 

-----Original Message-----
From: Miika Komu [mailto:[email-masked]] 
Sent: Friday, December 14, 2007 12:41 AM
To: Henry Sinnreich
Cc: Philip Matthews; Bruce Lowekamp; [email-masked];
[email-masked]
Subject: RE: [P2PSIP] HIP DHT interface (was HIP pros and cons)

Hi Henry,

HIP use ICE as its NAT traversal mechanism and hence has the same 
properties as ICE. Also, it has few extra advantage over plain ICE.
First, 
there is no need to burden the application with the details (=API) of
ICE. 
Second, the application can address other peers globally using the HITs.

connectivity tests between HITs. As far as I have understoon, this
should 

I think ICE does not care about NAT scenarios. It just gets a bunch of 
addresses associated with the local host and then it tries to connect
them 
peer addresses. Trying to determine a NAT scenario is prone to error and

I mentioned on benefit of HIP above regarding to hairpinning. We have
also 
been discussing if we can reuse HIP D-H keymaterial to provide some
extra 
protection for the STUN/ICE messages.

-- 
Miika Komu
http://www.iki.fi/miika/

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 14 Dec 2007 06:57:48 -0800

At Fri, 14 Dec 2007 09:08:30 +0200 (EET),
Miika Komu wrote:
> see what is the problem then?

Then how does a relying party verify that the client actually enrolled
rather than just generated their own key and didn't enroll?

> I don't really see why the enrollment server 

Huh? Attacking a single point on the overlay is the cost of doing
a single captcha (about $.01).

I'm sorry if this seems overly direct, but (1) this is a significant
open research problem (2) I've gone over these issues a number of 
times on the list and in person and (3) this is out of our charter
scope. If you think you've solved the distributed DHT enrollment
problem, and you have a complete description of your proposed
solution complete with security analysis, I'll be happy to read
it, but I don't see a lot of point on going over the same ground
repeatedly on the list.

-Ekr

---

From: "Wei Gengyu" <[email-masked]>
Date: Sat, 15 Dec 2007 01:21:19 +0800

There is one possible problem.

HIP has already been standardized for Hosd indentification in rfc4423. 
Each host would have only one HIT according to RFC4423.
Peer ID is an identifier of Peer entity in P2PSIP overlay (at application layer of Internet).
There is a proposal of using HIT as Peer ID, so a host could only have one Peer entity.

But, if there are two or more Peer entities located at one host, how could you manage them?
In general, I think, it is possible that  more than one Peer entity located at one host.  

How do you think of this?

Gengyu

----- Original Message ----- 
From: "Henry Sinnreich" <[email-masked]>
To: "Wei Gengyu" <[email-masked]>; "Bruce Lowekamp" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, December 14, 2007 10:25 PM
Subject: RE: [P2PSIP] Re: HIP pros and cons

Henry

-----Original Message-----
From: Wei Gengyu [mailto:[email-masked]] 
Sent: Friday, December 14, 2007 2:42 AM
To: Bruce Lowekamp
Cc: [email-masked]
Subject: Re: [P2PSIP] Re: HIP pros and cons

Bruce, 

Gengyu

---

From: "Ahrenholz, Jeffrey M" <[email-masked]>
Date: Fri, 14 Dec 2007 09:28:28 -0800

Gengyu,
I think you may have misread RFC4423, in the introduction it states:

   "Each host will have at least one Host Identity, but it will 
    typically have more than one."

The implementations also support multiple Host Identities and HITs per
host.

-Jeff

> Sent: Friday, December 14, 2007 9:21 AM
> To: Henry Sinnreich; Bruce Lowekamp
> Cc: [email-masked]

---

From: Philip Matthews <[email-masked]>
Date: Fri, 14 Dec 2007 12:56:32 -0500

Henry:

HIP is using ICE, so you won't see higher success ratios with HIP.

What you WILL see is a better interface to the application.
With all three HIP-based proposals that I know about, the details
of the NAT traversal are hidden from the application. So there is
no need to invent ICE-for-XXX, where XXX is {SIP, MSRP, Jabber,
HTTP, SSH, etc. etc. etc.}.

- Philip

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 14 Dec 2007 14:45:37 -0600

It's also worth pointing out a couple of other things. From Section 1 
("Disclaimer"):

1.  Disclaimer

   The purpose of this memo is to provide a stable reference point in
   the development of the Host Identity Protocol architecture.  This
   memo describes the thinking of the authors as of Fall 2003; their
   thinking may have evolved since then.  Occasionally, this memo may be
   confusing or self-contradicting.  That is (partially) intentional,
   and it reflects the snapshot nature of this memo.

Pekka graciously took over the editor pen on Bob's draft so we'd have an 
architecture document as a starting point, but since HIP was chartered as a 
working group, it wasn't appropriate for him to write lots of text updating 
the draft as an individual. He didn't update the draft based on his own 
opinions.

RFC4423 is a snapshot, not a final specification, and

   This RFC is not a candidate for any level of Internet Standard.  The
   IETF disclaims any knowledge of the fitness of this RFC for any
   purpose and notes that the decision to publish is not based on IETF
   review.  However, the ideas put forth in this RFC have generated
   significant interest, including the formation of the IETF HIP Working
   Group and the IRTF HIP Research Group.  These groups are expected to
   generate further documents, sharing their findings with the whole
   Internet community.

RFC4423 didn't standardize HIP, not even the HIP architecture.

Not surprising that people miss this because

(1) the "not a candidate for a standard" is usually provided as an "IESG 
Note" in more recent RFCs (sse 
http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg04080.html 
for an example), and

(2) many people assume that RFCs are standards, although there are many RFCs 
that aren't standards (see http://www.ietf.org/rfc/rfc1796.txt).

Thanks,

Spencer

(who helped with the final editing, among others)

----- Original Message ----- 
From: "Ahrenholz, Jeffrey M" <[email-masked]>
To: "Wei Gengyu" <[email-masked]>; "Henry Sinnreich" 
<[email-masked]>; "Bruce Lowekamp" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, December 14, 2007 11:28 AM
Subject: RE: [P2PSIP] Re: HIP pros and cons

Gengyu,

-Jeff

---

From: Philip Matthews <[email-masked]>
Date: Fri, 14 Dec 2007 15:51:37 -0500

1) HIP explicitly allows a node to have multiple Host Identities (or  
HITs).
2) The HIP-HOP proposal was to allow a node to use its HIT as a peer  
ID in multiple overlays.

However, EKR has pointed out a problem with this approach.
To avoid long debate on this subject, I suggest we all just
assume that a peer ID is NOT the same thing as the HIT.

So a node might have just one HIT, but multiple peer IDs
(one for each overlay in which it is a member).

- Philip

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 14 Dec 2007 13:38:19 -0800

Phil, 

>(one for each overlay in which it is a member).

This is correct, although there is more to it.
One node may carry several applications (SIP, Games, etc.) and they
don't have each and all to worry about NAT traversal and ICE API's,
since it is done only once at the HIP level.

It was mentioned in an earlier message. Is this correct?

Henry

-----Original Message-----
From: Philip Matthews [mailto:[email-masked]] 
Sent: Friday, December 14, 2007 2:52 PM
To: Wei Gengyu
Cc: Henry Sinnreich; Bruce Lowekamp; [email-masked]
Subject: Re: [P2PSIP] Re: HIP pros and cons

- Philip

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 14 Dec 2007 14:46:30 -0800

Phil,

>HTTP, SSH, etc. etc. etc.}.

Exactly! That's it.

Henry

-----Original Message-----
From: Philip Matthews [mailto:[email-masked]] 
Sent: Friday, December 14, 2007 11:57 AM
To: Henry Sinnreich
Cc: Miika Komu; Bruce Lowekamp; [email-masked];
[email-masked]

Henry:

- Philip

---

From: "Henry Sinnreich" <[email-masked]>
Date: Sat, 15 Dec 2007 09:53:35 -0800

Naïve question:

Since HIP ESP data traffic is protected like in a VPN, are TLS, DTLS SRTP still required? I would just like to be sure on this topic.

Thanks, Henry

---

From: Philip Matthews <[email-masked]>
Date: Sat, 15 Dec 2007 16:40:00 -0500

> It was mentioned in an earlier message. Is this correct?

Absolutely correct. This is one of the big advantages that I see of  
the HIP approach.
All three of the existing HIP-based proposals have this property.

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Sun, 16 Dec 2007 16:07:40 -0500

Good question!

The most straight-forward way to use HIP for P2PSIP is to protect ALL  
traffic with ESP, thus making TLS, DTLS, and SRTP unnecessary. This  
doesn't mean they cannot be used -- it just means that they are not  
needed.

- Philip

On 15-Dec-07, at 12:53 , Henry Sinnreich wrote:

> Naïve question:
>
> Since HIP ESP data traffic is protected like in a VPN, are TLS,  
> DTLS SRTP still required? I would just like to be sure on this topic.
>
> Thanks, Henry
>

---

From: Ali Fessi <[email-masked]>
Date: Sun, 16 Dec 2007 23:43:11 +0100

Philip,

I wouldn't bet on that. ESP can use also null encryption and null data 
integrity. (although the combination of both nulls is not allowed)

In general, security mechanisms on the application layer shoudn't depend 
on security mechanisms in underlaying layers, in this case the HIP 
overlay layer.

Cheers,
  Ali

Philip Matthews wrote:
> doesn't mean they cannot be used -- it just means that they are not needed.
> 
> - Philip
> 
>> Since HIP ESP data traffic is protected like in a VPN, are TLS, DTLS 
>> SRTP still required? I would just like to be sure on this topic.
>>
>> Thanks, Henry
>>

---

From: "Henry Sinnreich" <[email-masked]>
Date: Sun, 16 Dec 2007 15:28:17 -0800

Ali,

> on security mechanisms in underlaying layers,

We have no disagreement on the need for strong p2p authentication provided by the enrollment service or server.

However, do you have any specific reasons to duplicate the VPN-like transmission security of HIP (that would be duplicated in TLS, DTL and SRTP)? What would they be?

Henry

-----Original Message-----
From: Ali Fessi [mailto:[email-masked]] 
Sent: Sunday, December 16, 2007 4:43 PM
To: Philip Matthews
Cc: Henry Sinnreich; [email-masked]
Subject: Re: [P2PSIP] Re: HIP pros and cons

Philip,

Cheers,
  Ali

---

From: Ingmar Baumgart <[email-masked]>
Date: Mon, 17 Dec 2007 14:24:47 +0100

Miika Komu wrote:
> At least HIPL implements it by using the deployed i3 network in
> planetlab. If I recall correctly, HIP packets are transported over i3
> headers through the overlay and ESP packets are sent directly between
> the peers. We are currently integrating STUN/ICE with "normal-mode" HIP
> and later with Hi3. The implementations are available at:
> 
> http://infrahip.hiit.fi/
> http://www.openhip.org/

Which ICE library (PJNATH, Nice,...) do you use in your HIP implementation?

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: Mon, 17 Dec 2007 16:38:26 +0100

Henry,

some of the reasons why applications should not rely on security 
mechanisms provided by the network/HIP layer, is that there are often a 
discrepancy between what you want to protect at the application and the 
protection provided at the network layer, e.g. VPN.

For example, if you want to use a HIP overlay for P2PSIP lookup service, 
and as soon as you find the Callee, you want to perform the subsequent 
SIP signaling in a B2BUA mode and send your media streams directly using 
IP routing. (although i know some people will say here you can use HIP. 
but i think you don't want to use the HIP overlay for routing the media 
data)

In this case, you would use the HIP overlay for the lookup and will need 
to use SRTP for protecting the media streams. and probably also TLS/DTLS 
for protecting the B2B SIP signaling.

I hope this was clear?

Another reason, is that there might a misunderstanding of the security 
services provided by the HIP layer. e.g. some environments could use HIP 
for the overlay and think they are safe, while HIP is configured to use 
null encryption. So, this could lead to security holes quickly in practice.

In general, i think it is a good practice if the security of the 
application does not depend on the security provided by the lower layers 
(under layer 4).

BTW, the 3GPP IMS, for example, uses its own authentication and 
confidentiality mechanisms independantly of the access network, which 
is, i think, wise.

Also, if you look at things how they work today, you don't want to 
establish a VPN tunnel to a web server if you want to protect your HTTP 
traffic. You would rather use TLS.

Cheers,
  Ali

---

From: Miika Komu <[email-masked]>
Date: Mon, 17 Dec 2007 18:04:42 +0200 (EET)

> rather than just generated their own key and didn't enroll?

The same way as without public keys. I fail to see the problem here.

> a single captcha (about $.01).

Let's then rely on the credit card payment as you suggested.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 17 Dec 2007 08:44:36 -0800

At Mon, 17 Dec 2007 18:04:42 +0200 (EET),
> The same way as without public keys. I fail to see the problem here.

I don't even understand what you're proposing any more.

If you want to describe a specific proposal, I'll be happy to address
its merits.

-Ekr

---

From: "David Barrett" <[email-masked]>
Date: Mon, 17 Dec 2007 11:31:40 -0800

> Subject: [P2PSIP] HIP vs. TLS/DTLS/SRTP (was HIP pros and cons)
> 

I think the point is if you already have a VPN connection established with
the webserver, then you don't need to *also* use TLS.  Similarly, if you
already had NAT-traversal built in, then you wouldn't *also* use ICE.

If I understand correctly (Philip -- Please correct me if I'm wrong), HIP
effectively gives us a NAT-traversing VPN connection "out of the box" for
every TCP connection established, rendering much of TLS redundant.  (Clearly
there are still the authentication and authorization benefits, but those
could be layered atop HIP for those streams that need it.)

Personally, I think the idea of a P2P layer that provides standard
NAT-traversal and encryption is fantastic.  Ideally it'd be implemented with
an open-source library having an interface almost exactly like the Berkeley
Socket API, and then we can re-establish the end-to-end principle of the net
-- with "free" encryption out of the box.  (Free in terms of coding time,
not CPU.)

If such a thing existed, it seems a no-brainer to use it for P2P-SIP, and
pretty much everything else online.

-david

PS: Philip -- Does HIP only provide a TCP-like reliable peer connection, or
would it also provide a UDP-like lossy peer connection?

---

From: Philip Matthews <[email-masked]>
Date: Mon, 17 Dec 2007 17:30:24 -0500

Let me try to answer both Ali and David's e-mails by giving a brief  
description of what happens. I will give a generic description that  
works for all three HIP-based proposals.

Applications running in the overlay uses special IP addresses to  
identify other peers in the overlay. These addresses are drawn from a  
special range of addresses so they can be distinguished from regular  
addresses. So say an application running on peer X issues a TCP  
connect() to a port on peer Y, using the special IP address for peer  
Y. This connect() call causes the TCP stack on X to send a SYN packet.

In the Windows implementation, this SYN packet in intercepted at the  
link layer by a TAP device driver and diverted to a user-space  
process. At this point, the user-space process checks if there is an  
existing direct connection to peer Y. Assuming one is, and assuming  
that ESP is used (*), the IP header is removed, and three new headers  
(ESP over UDP over IP) are added to the packet. The addresses and  
ports in the new UDP and IP packets are "real" addresses and ports  
determined using ICE, not the virtual addresses used in the removed  
IP header.

Thus the packet looks like:
    IP  |   UDP  |  ESP  |  TCP (SYN)
I like to think of it as a ESP over UDP "pipe" between X and Y, over  
which all application packets are multiplexed.

If no existing direct connection exists between X and Y, then one is  
established using signaling (**) that goes hop-by-hop around the  
overlay, or via a signaling relay.

(*) The WITH-HIP proposal always uses ESP; the HIP-HOP proposal uses  
ESP by default, but provides a way to not use it; and the ID-LOC  
proposal currently does not use it, though that may change in the  
next revision.

(**) The details on how signaling is done depends on the proposal.

Ali wrote:
> For example, if you want to use a HIP overlay for P2PSIP lookup  
> service, and as soon as you find the Callee, you want to perform  
> the subsequent SIP signaling in a B2BUA mode and send your media  
> streams directly using IP routing. (although i know some people  
> will say here you can use HIP. but i think you don't want to use  
> the HIP overlay for routing the media data)
>
> In this case, you would use the HIP overlay for the lookup and will  
> need to use SRTP for protecting the media streams. and probably  
> also TLS/DTLS for protecting the B2B SIP signaling.

In all three proposals, media packets would flow directly between the  
X and Y, and not hop-by-hop around the overlay. So when ESP was used,  
there would be no need to use STRP for media, or TLS or DTLS for  
signaling.

> Another reason, is that there might a misunderstanding of the  
> security services provided by the HIP layer. e.g. some environments  
> could use HIP for the overlay and think they are safe, while HIP is  
> configured to use null encryption. So, this could lead to security  
> holes quickly in practice.

I think the risk of this happening depends on how we write the  
standard. I don't think the risk here is any greater than never using  
ESP and applications not using (D)TLS when they should.

> could be layered atop HIP for those streams that need it.)

Let me just note that the current HIP specification is not defined to  
work in an overlay. The various proposals (HIP-HOP, WITH-HIP, ID-LOC)  
describe how to extend it to work in an overlay.

But briefly, yes.

> -- with "free" encryption out of the box.  (Free in terms of coding  

Though library implementations are possible, my preference is for a  
VPN-like implementation where applications continue to use the  
kernel's Berkeley Socket API, and packets are intercepted at the link  
layer. This is the way VPNs are implemented today (at least on  
Windows -- other implementation techniques are available on Unix  
platforms).

> pretty much everything else online.

There are three open-source HIP implementations available today,  
which between them support virtually all major platforms. However,  
NAT traversal support is still work-in-progress, and the details of  
working in an overlay is the part that we discussing.

> would it also provide a UDP-like lossy peer connection?

The short answer is: Yes.

The longer answer is that all three proposals support, at a minimum,  
a "UDP pipe" between peer X and peer Y over which TCP connection and  
UDP packets can be multiplexed. This can be shown in a drawing as  
follows

     -----------Outer UDP Pipe ----------------
      <===== TCP Connection #1 =============>
X    <===== TCP Connection #2 =============>    Y
      <===== UDP packet stream #1 ==========>
      <===== UDP packet stream #2 ==========>
     ------------------------------------------

In WITH-HIP and in HIP-HOP, this UDP pipe always uses ESP.
In ID-LOC, this pipe does not currently use ESP (due to concerns  
about double encryption) but probably will in the next version.

HIP-HOP and ID-LOC currently support other encapsulations as well.  
See the ID-LOC draft for a description.

- Philip

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 18 Dec 2007 00:48:06 -0800

At Mon, 17 Dec 2007 17:30:24 -0500,
> there would be no need to use STRP for media, or TLS or DTLS for  

This is arguably a bug, not a feature.

SRTP was explicitly designed to have very low overhead: just the
bits of the authentication tag itself, with no header, etc. The
rationale for this design was that RTP packets tend to be very
small and so the overhead for the header, IV, etc. was significant.
In cases where that type of constraint applies, then wrapping the
RTP in ESP would be bad.

-Ekr

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 18 Dec 2007 10:46:29 +0100

This was one of the concern raised when we looked in using HIP together 
with SIP a few years ago.
As a consequence we wrote a separate document to allow HIP to create 
SRTP security associations.
A student also implemented it. The interaction between the different 
layers wasn't easy.

Ciao
Hannes

---

From: Philip Matthews <[email-masked]>
Date: Tue, 18 Dec 2007 10:19:50 -0500

> In cases where that type of constraint applies, then wrapping the

Glad you brought that up. I have been debating that point for some  
months now.

Both HIP-HOP and ID-LOC provide for an alternative encapsulation (the  
"null-encapsulation" as it is called in ID-LOC). This encapsulation  
does not add any additional headers, but just modified the addresses  
and ports in the existing IP and transport headers. Cullen has  
described this as making the node act like a NAT.

The two encapsulations are:
    IP | UDP | ESP | transport | app       (called the "Outer-DUP"  
encapsulation in ID-LOC (*) )
and
    IP | transport | app                   (null-encapsulation)

The benefits of the null-encapsulation are:
* It does not add any additional overhead

The benefits of the "Outer-UDP" encapsulation are:
* It is easy to encrypt all packets
* Transport protocols such as SCTP, DCCP, and UDP-lite can be easily  
transported through NATs
* There is just one "UDP pipe" between the source and destination  
over which all flows are multiplexed, and thus you need just one ICE  
exchange (rather than one per flow as with the null-encapsulation).

I have been debating the pros and cons of the two encapsulations.  
Should P2PSIP support both encapsulations? Or should we just pick  
one? VPNs seem to do fine with the "Outer-UDP" encapsulation, so  
perhaps we should just stick with it. The only real argument against  
it is the overhead argument you mention, and some people argue that  
various tunneling techniques used in the Internet today already add  
lots of overhead. Plus one could use Robust Header Compression if  
this is really a problem.

(*) The ID-LOC draft does not currently use ESP, but instead uses a  
"demux" header which specifies the protocol number of the following  
transport protocol.

- Philip

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 18 Dec 2007 08:52:51 -0800

> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Tuesday, December 18, 2007 1:46 AM
> To: Eric Rescorla
> Cc: Henry Sinnreich; Philip Matthews; P2PSIP Mailing List
> Subject: Re: [P2PSIP] HIP vs. TLS/DTLS/SRTP (was HIP pros and cons)
> 

For reference:
http://tools.ietf.org/html/draft-tschofenig-hiprg-hip-srtp-02

---

From: Miika Komu <[email-masked]>
Date: Tue, 18 Dec 2007 19:28:59 +0200 (EET)

On Mon, 17 Dec 2007, Eric Rescorla wrote:

Hi Eric,

> If you want to describe a specific proposal, I'll be happy to address

This is one example how it could work:

You connect with your web browser to the enrollment server. The DNS
contains the HIT of the enrollment server, which triggers a base
exchange with the enrollment server and makes the HTTP(S) connection to
use HIP. You fill in a web form and give your bank card number for the
enrollment server. The web server software stores the HIT and the bank
card number for enrollment purposes. From this on, we could have two 
alternative design solutions:

a) When the new peer joins the network, DHT nodes that have been already
    accepted in the network will ask the enrollment server if the new peer
    has enrolled successfully.
b) The enrollment server could give the new peer a certificate which the
    peer could be using directly when actually joining the DHT.

I believe approach (a) proves my original point that you can use 
host-generated DHT identifiers without certificates.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 18 Dec 2007 09:35:59 -0800

At Tue, 18 Dec 2007 19:28:59 +0200 (EET),
> host-generated DHT identifiers without certificates.

Uh, sure, if you're willing to have the enrollment server online
24-7 acting as a real-time CA. It's hard to see how that's 
practical operationally.

-Ekr

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 18 Dec 2007 12:36:34 -0500

<as individual>
While a) proves your point, I think we're not really interested in a
solution that requires the enrollment server to be reachable by any peer to
determine admittance to the overlay.  It's one thing to need to be able to
reach the enrollment service once to enroll; it's quite another to require
it to be available to join the overlay.

Brian

> Sent: Tuesday, December 18, 2007 12:29 PM
> To: Eric Rescorla
> Cc: [email-masked]

---

From: Miika Komu <[email-masked]>
Date: Tue, 18 Dec 2007 19:45:49 +0200 (EET)

On Tue, 18 Dec 2007, Brian Rosen wrote:

Hi Brian,

thanks for the feedback. It seems like the alternative b is mandatory for 
p2p-sip. Otherwise, then I don't see how you are going to avoid the use of 
cryptographic certificates without compromising dht identifier security 
and revocation.

In alternative b, it is still possible to use host generated dht key 
identifiers.

---

From: Miika Komu <[email-masked]>
Date: Tue, 18 Dec 2007 19:53:56 +0200 (EET)

> Which ICE library (PJNATH, Nice,...) do you use in your HIP implementation?

Hi Ingmar,

currently PJNATH.

---

From: "Dan York" <[email-masked]>
Date: Tue, 18 Dec 2007 18:08:56 +0000

Two words: "Skype outage". As best we can understand, (a) is similar to the architecture used by Skype. A Skype client must be able to communicate with the authorization/enrollment servers to be able to access the Skype P2P cloud. When those servers then became inaccessible, the scenario unfolded that led to the 2-day outage.

I don't want to debate Skype's outage, but my point is that I would think we want to avoid anything that introduces a "single point-of-failure" which (a) seems to me to do. It seems to me to be the opposite of what we are trying to do with P2P SIP.  

(So I agree with the comments from Brian and EKR that (a) is not advisable.)

My 2 cents,
Dan
-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Bring your web applications to the phone.
Find out how at http://evolution.voxeo.com

-----Original Message-----
From: "Brian Rosen" <[email-masked]>

Date: Tue, 18 Dec 2007 12:36:34 
To:"'Miika Komu'" <[email-masked]>, "'Eric Rescorla'" <[email-masked]>
Cc:[email-masked]
Subject: RE: [P2PSIP] Re: HIP pros and cons

<as individual>

Brian

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 18 Dec 2007 10:18:32 -0800

At Tue, 18 Dec 2007 19:45:49 +0200 (EET),
> In alternative b, it is still possible to use host generated dht key 

Again, not if you want to use them as the locations in the DHT,
because then you get chosen location attacks.

-Ekr

---

From: "David Barrett" <[email-masked]>
Date: Tue, 18 Dec 2007 12:38:26 -0800

Just curious, if my laptop gets stolen, will P2PSIP provide any facility for
me to prevent the thief from making and receiving calls in my name?

If so, how will that be done without a 24/7 realtime check to either a
centralized or federated server?

If we assume there's some kind of password, then that means there's some
sort of password check.  If we assume we can ban clients, then we need to
somehow record which clients are banned and check that.  If we can revoke
certificates, then there's a certificate revocation list.

Is there any way to support this seemingly obvious requirement -- the
requirement that I can prevent a thief from forever, undetectably
impersonating me -- without some sort of central, realtime, 24/7 lookup?

Or is the answer "to be determined" or "not our problem; we punt this to
another layer"?

-david

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Tuesday, December 18, 2007 9:37 AM
> To: 'Miika Komu'; 'Eric Rescorla'
> Cc: [email-masked]

---

From: "David Barrett" <[email-masked]>
Date: Tue, 18 Dec 2007 12:51:39 -0800

The Skype outage demonstrates precisely the opposite of what you're
claiming.  Rather, it shows that inappropriate use of decentralization turns
minor spikes into fatal calamities due to congestion-collapse scenarios.

Had they simply authenticated everything globally, then a spike in login
requests would result in a slowdown of logins for an hour or so, and that's
it.

But because they built a totally unnecessary p2p solution, the spike caused
*days* of instability.

Skype is the very example of why we should build central authentication.

-david

> From: Dan York [mailto:[email-masked]]
> Sent: Tuesday, December 18, 2007 10:09 AM
> To: Brian Rosen; 'Miika Komu'; 'Eric Rescorla'
> Cc: [email-masked]
> Two words: "Skype outage". As best we can understand, (a) is similar to
> the architecture used by Skype. A Skype client must be able to communicate
> with the authorization/enrollment servers to be able to access the Skype
> P2P cloud. When those servers then became inaccessible, the scenario
> unfolded that led to the 2-day outage.
> 
> I don't want to debate Skype's outage, but my point is that I would think
> we want to avoid anything that introduces a "single point-of-failure"
> which (a) seems to me to do. It seems to me to be the opposite of what we
> are trying to do with P2P SIP.
>

---

From: Miika Komu <[email-masked]>
Date: Fri, 21 Dec 2007 11:37:49 +0200 (EET)

On Mon, 17 Dec 2007, Ali Fessi wrote:

Hi Ali,

(I think there were already response to your message from Philip also)

> For example, if you want to use a HIP overlay for P2PSIP lookup service, and 
> as soon as you find the Callee, you want to perform the subsequent SIP 
> signaling in a B2BUA mode and send your media streams directly using IP 
> routing. (although i know some people will say here you can use HIP. but i 
> think you don't want to use the HIP overlay for routing the media data)

You can use HIP :)

> In this case, you would use the HIP overlay for the lookup and will need to 
> use SRTP for protecting the media streams. and probably also TLS/DTLS for 
> protecting the B2B SIP signaling.
>
> I hope this was clear?

Not exactly.

> services provided by the HIP layer. e.g. some environments could use HIP for 
> the overlay and think they are safe, while HIP is configured to use null 
> encryption. So, this could lead to security holes quickly in practice.

If the application needs to know this, it can query this using a 
getsockopt or similar call:

http://www.ietf.org/internet-drafts/draft-ietf-btns-c-api-01.txt

> In general, i think it is a good practice if the security of the application 
> does not depend on the security provided by the lower layers (under layer 4).

Why?

> confidentiality mechanisms independantly of the access network, which is, i 
> think, wise.

What prevents the application from requesting a specific security service 
from the lower layers?

> Also, if you look at things how they work today, you don't want to establish 
> a VPN tunnel to a web server if you want to protect your HTTP traffic. You 
> would rather use TLS.

You are using VPN as a synonym for IPsec which is not entirely correct. 
VPN usually means that usually you have a gateway. In HIP there is usually 
no gateway (end-to-middle), but instead the traffic is end-to-end.

---

From: Miika Komu <[email-masked]>
Date: Fri, 21 Dec 2007 11:51:02 +0200 (EET)

On Tue, 18 Dec 2007, Eric Rescorla wrote:

Eric,

> because then you get chosen location attacks.

Yes but it costs. I don't see the difference here with host vs. enrollment 
server generated keys because the end-host can enroll several times until 
it is satisfied with the id. What makes the difference is the cost.

Since I took the time to describe a detailed, step-by-step approach with 
host generated identifiers, could you do the same with enrollment 
server generated keys? Thanks.

P.S. If you want to reference some work, please give the authors and 
titles to the publication or URL instead of some acronyms. Thanks.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 21 Dec 2007 09:06:40 -0800

At Fri, 21 Dec 2007 11:51:02 +0200 (EET),
> it is satisfied with the id. What makes the difference is the cost.

For the nth time, yes, but it requires a separate query to the 
enrollment server, which the enrollment server can throttle.
This doesn't work if the enrollment server lets the peer
propose the peer-id, since the peer can mount an offline 
attack on the location. Again, this is all in my slides from
YVR.

> server generated keys? Thanks.

I don't propose using enrollment server generated keys. I propose
separating cryptographic keys from peer-ids and using certificates
to bind them together. This is described in fairly complete detail
draft-bryan-p2psip-reload-02.

> titles to the publication or URL instead of some acronyms. Thanks.

I generally try to. If there's a particular one that wasn't clear
lemme know and I'll send you a full reference.

-Ekr

---

From: Miika Komu <[email-masked]>
Date: Sun, 23 Dec 2007 23:00:52 +0200 (EET)

> In cases where that type of constraint applies, then wrapping the

I think the difference is around 18 bytes:

http://dasan.sejong.ac.kr/~wisa04/ppt/1A1.ppt

In practice, the difference is insignificant according to these results:

Bilien et at: Secure VoIP: call establishment and media protection:
http://www.minisip.org/publications/secvoip-minisip-camera.pdf

Currently, all three (public) HIP implementations support BEET-mode-ESP by 
default. It has exactly the same byte overhead as transport mode.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 23 Dec 2007 13:33:31 -0800

> http://www.minisip.org/publications/secvoip-minisip-camera.pdf

I don't see that this paper is at all relevant to the question of whether 18
bytes of per-packet overhead is significant. In any case, if you want
to argue this point, I would advise you to take it up in AVT, since
low overhead was one of the principal design considerations for
SRTP.

-Ekr

---

From: Miika Komu <[email-masked]>
Date: Mon, 24 Dec 2007 00:02:22 +0200 (EET)

> low overhead was one of the principal design considerations for

I find this answer unsatisfying for three reasons. First, I don't think 
that the SRTP has been fixed for this working group unless I have 
mistaken. Secondly, I find the paper highly relevant to the original 
discussion. Thirdly, SRTP RFC does not discuss the differences between 
IPsec and SRTP, but merely mentions it in one sentence. Looking forward 
for more accurate references to SRTP, preferably with some performance 
results.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 23 Dec 2007 14:18:06 -0800

At Mon, 24 Dec 2007 00:02:22 +0200 (EET),
Miika Komu wrote:
> I find this answer unsatisfying for three reasons.

I wasn't aware it was my job to satisfy you.

> First, I don't think 
> mistaken. 

Sure. Go ahead and explain to the RAI, SEC, and TSV ADs and
the AVT chairs that you propose that RTP security for P2PSIP
will be using a different set of security mechanisms from
those used for ordinary SIP-based VoIP. Let me know what
they say.

> Secondly, I find the paper highly relevant to the original 

As I recall, this was extensively discussed on the AVT mailing list
during the period when RTP was being designed. As I said in my
previous message, this is primarily a topic for the AVT WG.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 23 Dec 2007 14:18:47 -0800

At Sun, 23 Dec 2007 14:18:06 -0800,
> during the period when RTP was being designed. As I said in my
s/RTP/SRTP/

-Ekr