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

Miika Komu <miika@iki.fi> Fri, 21 December 2007 09:38 UTC

Return-path: <p2psip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5eKO-00071Y-1r; Fri, 21 Dec 2007 04:38:00 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5eKL-0006zv-UQ for p2psip@ietf.org; Fri, 21 Dec 2007 04:37:57 -0500
Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5eKL-0003vg-Eq for p2psip@ietf.org; Fri, 21 Dec 2007 04:37:57 -0500
Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 8ED382EE8; Fri, 21 Dec 2007 11:37:56 +0200 (EET)
X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi
X-Spam-Level:
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810
X-Spam-Niksula: No
Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 52B012EBD; Fri, 21 Dec 2007 11:37:49 +0200 (EET)
Date: Fri, 21 Dec 2007 11:37:49 +0200
From: Miika Komu <miika@iki.fi>
X-X-Sender: mkomu@kekkonen.cs.hut.fi
To: Ali Fessi <ali.fessi@uni-tuebingen.de>
Subject: Re: [P2PSIP] HIP vs. TLS/DTLS/SRTP (was HIP pros and cons)
In-Reply-To: <476697F2.4080903@uni-tuebingen.de>
Message-ID: <Pine.SOL.4.64.0712211102180.12362@kekkonen.cs.hut.fi>
References: <E1J0dHW-0005ik-OT@megatron.ietf.org> <Pine.SOL.4.64.0712080222070.16938@kekkonen.cs.hut.fi> <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <Pine.SOL.4.64.0712121240120.24969@kekkonen.cs.hut.fi><20d2bdfb0712121521x14e831cal2473fdf5045f4e37@mail.gmail.com> <Pine.SOL.4.64.0712130913000.6449@kekkonen.cs.hut.fi> <24CCCC428EFEA2469BF046DB3C7A8D223AE40E@namail5.corp.adobe.com> <E5562AA1-2E70-4E4B-B774-FEE9E4D8A9E1@magma.ca> <4765A9FF.7000903@uni-tuebingen.de> <24CCCC428EFEA2469BF046DB3C7A8D223AE414@namail5.corp.adobe.com> <476697F2.4080903@uni-tuebingen.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: Henry Sinnreich <hsinnrei@adobe.com>, Philip Matthews <philip_matthews@magma.ca>, p2psip@ietf.org
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
Errors-To: p2psip-bounces@ietf.org

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.

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

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?

> BTW, the 3GPP IMS, for example, uses its own authentication and 
> 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.

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

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip