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

Miika Komu <miika@iki.fi> Sun, 23 December 2007 22:02 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 1J6Yu3-0001B2-TU; Sun, 23 Dec 2007 17:02:35 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6Yu2-00016w-Bp for p2psip@ietf.org; Sun, 23 Dec 2007 17:02:34 -0500
Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J6Yu1-0005Xj-T6 for p2psip@ietf.org; Sun, 23 Dec 2007 17:02:34 -0500
Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 2CEDB2EC6; Mon, 24 Dec 2007 00:02:28 +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 52E6E2C1B; Mon, 24 Dec 2007 00:02:22 +0200 (EET)
Date: Mon, 24 Dec 2007 00:02:22 +0200
From: Miika Komu <miika@iki.fi>
X-X-Sender: mkomu@kekkonen.cs.hut.fi
To: Eric Rescorla <ekr@networkresonance.com>
Subject: Re: [P2PSIP] HIP vs. TLS/DTLS/SRTP (was HIP pros and cons)
In-Reply-To: <20071223213331.979885081A@romeo.rtfm.com>
Message-ID: <Pine.SOL.4.64.0712232352470.25393@kekkonen.cs.hut.fi>
References: <476697F2.4080903@uni-tuebingen.de> <0F3808C7-7BFA-4874-8105-A7AE3F4606A5@magma.ca> <20071218084807.4047C33C69@delta.rtfm.com> <Pine.SOL.4.64.0712232239250.25393@kekkonen.cs.hut.fi> <20071223213331.979885081A@romeo.rtfm.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: Henry Sinnreich <hsinnrei@adobe.com>, Philip Matthews <philip_matthews@magma.ca>, P2PSIP Mailing List <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 Sun, 23 Dec 2007, Eric Rescorla wrote:

>> On Tue, 18 Dec 2007, Eric Rescorla wrote:
>>
>>> At Mon, 17 Dec 2007 17:30:24 -0500,
>>> Philip Matthews wrote:
>>>> 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.
>>>
>>> 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.
>>
>> 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
>
> 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.

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.

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

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