Re: [Speermint] AD review: draft-ietf-speermint-voipthreats-05

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Thu, 03 February 2011 08:57 UTC

Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: speermint@core3.amsl.com
Delivered-To: speermint@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADE393A689B for <speermint@core3.amsl.com>; Thu, 3 Feb 2011 00:57:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.622
X-Spam-Level:
X-Spam-Status: No, score=-106.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2wvMCQZDh8g for <speermint@core3.amsl.com>; Thu, 3 Feb 2011 00:57:46 -0800 (PST)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 35D0D3A68A4 for <speermint@ietf.org>; Thu, 3 Feb 2011 00:57:45 -0800 (PST)
X-AuditID: c1b4fb39-b7cfbae000005c8e-9f-4d4a6ed35400
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id EF.0D.23694.3DE6A4D4; Thu, 3 Feb 2011 10:01:07 +0100 (CET)
Received: from [131.160.126.175] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.2.234.1; Thu, 3 Feb 2011 10:01:05 +0100
Message-ID: <4D4A6ED1.5060008@ericsson.com>
Date: Thu, 03 Feb 2011 11:01:05 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: Jan Seedorf <Jan.Seedorf@neclab.eu>
References: <4CA35805.80606@ericsson.com> <4CE26FC7.10605@ericsson.com> <2779C9F0771F974CAD742BAE6D9904FE7EC444@PALLENE.office.hd>
In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE7EC444@PALLENE.office.hd>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Cc: "speermint@ietf.org" <speermint@ietf.org>, Saverio Niccolini <Saverio.Niccolini@neclab.eu>, Eric Chen <eric.chen@lab.ntt.co.jp>, "hendrik.scholz@voipfuture.com" <hendrik.scholz@voipfuture.com>
Subject: Re: [Speermint] AD review: draft-ietf-speermint-voipthreats-05
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Feb 2011 08:57:47 -0000

Hi Jan,

thanks for addressing the comments. I have just requested an IETF LC for
this draft.

Cheers,

Gonzalo


On 25/01/2011 3:14 PM, Jan Seedorf wrote:
> Dear Gonzalo,
> 
> Thanks for your - indeed valid - comments on our -06 version of draft-ietf-speermint-voipthreats. Sorry for taking a while, your comments resulted in quite some changes in the draft. I just posted a new -07 version, let me explain below how we think we addressed your comments in this version:
> 
>>> While message modification and eavesdropping is included in the
>>> threats against SF and MF, they do not seem to appear in the threats
>>> against LRF and LUF. Why?
> Indeed message modification and eavesdropping are threats also for the LUF and LRF. We assumed those addressed with "confidentiality" and "integrity". We added some more text now, e.g. specifically mentioning "eavesdropping" and "message modification" under "confidentiality" and "integrity", respectively, for the LUF and LRF. For us, it was implicit that when one talks about confidentiality he/she indirectly talks about "eavesdropping", and when one talks about integrity he/she indirectly talks about "message modification". Anyway, we hope the text now explicitly makes this clear.
> 
>> Also, the reasons why Section 4.5 recommends TCP over UDP are still not
>> clear. UDP over DTLS would meet the requirements in both Sections 3.2
>> and 4.5.
> This is a very good point, which caused changes in section 4.5, 3.2, and in some other parts. At the time we started writing this draft back in 2007, RFC4347 on DTLS was less than a year old and there was no mature implementation of DTLS at the time.  Companies designing NGN at the time did not consider DTLS for the same reason. Since it has been more than three years, nowadays there seem to be quite a few DTLS implementations (at the IETF privacy workshop in Dec., I talked with Eric Rescorla about this and he confirmed that some stable implementations exist by now). We now updated the sections, saying that transport layer security can be either DTLS or TLS, depending on the use of the underlying transport protocol (UDP or TCP). Thus, we also do not recommend TCP over UDP anymore, and the section was renamed to "4.5 Secure Exchange of SIP messages". Accordingly, the former section "4.13.  Encryption and Integrity Protection of Signaling Messages" is now obsolete and we had
 to update also section 3.2., mentioning DTLS as an alternative to TLS.
> 
> We hope the draft is in better shape now and that all your comments have been addressed.
> 
> Sorry again for taking so long,
> 
>  - Jan
> 
> 
>> -----Original Message-----
>> From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On Behalf
>> Of Gonzalo Camarillo
>> Sent: Dienstag, 16. November 2010 12:49
>> To: speermint@ietf.org
>> Subject: Re: [Speermint] AD review: draft-ietf-speermint-voipthreats-05
>>
>> Hi,
>>
>> thanks for having submitted a new revision of this draft:
>>
>> http://tools.ietf.org/html/draft-ietf-speermint-voipthreats-06
>>
>> This revision addresses most of my comments below. However, I do not
>> think I got an answer to the following question:
>>
>>> While message modification and eavesdropping is included in the
>>> threats against SF and MF, they do not seem to appear in the threats
>>> against LRF and LUF. Why?
>>
>> Also, the reasons why Section 4.5 recommends TCP over UDP are still not
>> clear. UDP over DTLS would meet the requirements in both Sections 3.2
>> and 4.5.
>>
>> Thanks,
>>
>> Gonzalo
>>
>>
>> On 29/09/2010 5:15 PM, Gonzalo Camarillo wrote:
>>> Hi,
>>>
>>> a couple of days ago I received a publication request for the following
>>> draft:
>>>
>>> https://datatracker.ietf.org/doc/draft-ietf-speermint-voipthreats/
>>>
>>> Here you have my AD review of the draft (see below). The authors should
>>> be able to address all my comments fairly quickly. As soon as they
>>> revise the draft I will initiate its IETF LC.
>>>
>>> Thanks,
>>>
>>> Gonzalo
>>>
>>>
>>> draft-ietf-speermint-voipthreats-05
>>>
>>> Expand acronyms on their first use (e.g., SPEERMINT in the title and
>>> VoIP in the Introduction).
>>>
>>> The Abstract and the Introduction attempt to explain the relationship
>>> between this draft and draft-ietf-speermint-requirements. However,
>>> Section 3.1 does a better job at that. Could you please clarify in the
>>> Introduction that the requirements in draft-ietf-speermint-requirements
>>> were derived from the threats documented in this draft? Also, please
>>> clarify that in addition to be the base for those requirements, this
>>> draft provides countermeasures to meet those requirements. Any SPEERMINT
>>> expert will probably understand that by reading the Abstract and the
>>> Introduction but clarifying those points will help readers who have not
>>> been that involved in the process.
>>>
>>> While message modification and eavesdropping is included in the
>>> threats against SF and MF, they do not seem to appear in the threats
>>> against LRF and LUF. Why?
>>>
>>> Section 4.5 recommends to use TCP instead of UDP. That advice is great,
>>> but the reasons Section 4.5 discusses are not that strong. The fact that
>>> the linux kernel has improved is irrelevant if an operator uses
>>> non-linux boxes. Also, an operator using UDP over IPsec, for instance,
>>> will not face the problems described there. The main recommendation in
>>> Section 4.5 seems to actually be to use an integrity protection
>>> mechanism. Clarifying that section would be useful.
>>>
>>> [refs.sbcfuncs] has been published as RFC 5853
>>>
>>> A few references only include the title and the author fields. Adding
>>> the venue where they were published would be useful.
>>>
>>
>> _______________________________________________
>> Speermint mailing list
>> Speermint@ietf.org
>> https://www.ietf.org/mailman/listinfo/speermint
>