Re: [Tsvwg] Adopting draft-behringer-tsvwg-rsvp-security-groupkeying as WG item?

Lars Eggert <lars.eggert@nokia.com> Mon, 28 January 2008 10:26 UTC

Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJRC2-00031r-3L; Mon, 28 Jan 2008 05:26:22 -0500
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1JJRC0-0002vP-Am for tsvwg-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 05:26:20 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJRBz-0002vH-W1 for tsvwg@ietf.org; Mon, 28 Jan 2008 05:26:20 -0500
Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJRBy-0007Kl-Ms for tsvwg@ietf.org; Mon, 28 Jan 2008 05:26:19 -0500
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0SAPr4J011418; Mon, 28 Jan 2008 12:26:09 +0200
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jan 2008 12:26:07 +0200
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jan 2008 12:26:03 +0200
Received: from esdhcp0354.research.nokia.com ([172.21.35.4]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jan 2008 12:26:02 +0200
Message-Id: <A268781D-F81A-48B3-8042-1892AC93B749@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
To: ext Francois Le Faucheur IMAP <flefauch@cisco.com>
In-Reply-To: <7A1BB0E8-5EFB-4341-918A-F841DB1B57FF@cisco.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: [Tsvwg] Adopting draft-behringer-tsvwg-rsvp-security-groupkeying as WG item?
Date: Mon, 28 Jan 2008 12:26:02 +0200
References: <47974BDB.70406@ericsson.com> <CD8D57B6-EB94-4DCE-A42A-02BC5F573A13@nokia.com> <7A1BB0E8-5EFB-4341-918A-F841DB1B57FF@cisco.com>
X-Mailer: Apple Mail (2.915)
X-OriginalArrivalTime: 28 Jan 2008 10:26:02.0763 (UTC) FILETIME=[2EC4C5B0:01C86198]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Cc: ext Magnus Westerlund <magnus.westerlund@ericsson.com>, RJ Atkinson <rja@extremenetworks.com>, Brian Weis <bew@cisco.com>, tsvwg list IETF <tsvwg@ietf.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Hi,

On 2008-1-28, at 11:59, ext Francois Le Faucheur IMAP wrote:
> On 24 Jan 2008, at 18:04, Lars Eggert wrote:
>
>> (individual hat on)
>>
>> I'm not convinced that this document needs to be a TSVWG document.  
>> It's an Informational document that surveys group keying options  
>> for RSVP, and as such could be published directly through the RFC  
>> Editor.
>
> I am not aware of any solution currently available from the IETF to  
> actually deploy such distribution of group keys for RSVP.
> This could, for example, be easily achieved with small extensions to  
> GDOI (draft-weis-gdoi-for-rsvp), but a solution will only be defined  
> in IETF (e.g. by MSEC) if the corresponding need is established by  
> the TSVWG.

based on the discussions in Vancouver, I thought the goal of this  
document was to survey the options for group keying for RSVP. I don't  
see how such a survey would motivate the need for any sort of solution  
work. Meaning that even if this survey finds that none of the existing  
options are always satisfactory, that's a finding that to me still  
doesn't immediately motivate the need to develop any new solution. New  
protocol work should be motivated by an application requiring it.

> So, my recommendation is that TSVWG decides whether group keying is  
> useful for RSVP security or not, and if yes documents this decision.  
> Making draft-behringer-tsvwg-.. a WG document seems a natural way to  
> achieve this.
> This is one reason why I feel draft-behringer-tsvwg should be  
> considered for WG document.

For which current work item in TSVWG would group keying be useful, or  
rather, required? A need for a new solution needs to come from an  
application that requires group keying. As far as I know, no such  
application is being worked on in TSVWG.

> (I certainly feel that a group keying solution for RSVP would be  
> very useful. If some people feel that group keying for RSVP is not  
> useful, it would be interesting to know why and how the problems  
> solved by group keying can be addressed differently.)

Lots of things are useful - what application requires group keying for  
RSVP that goes beyond what we currently have? I'd like to understand  
where the motivation comes from.

> Another practical reason is that the issue of group keying methods  
> for RSVP gets raised by Security experts every time there is a new  
> RSVP-related document going to IESG Last Call. See, for example, the  
> thread with Ran Atkinson from Dec 2006 and titled "Re: [Tsvwg] Re:  
> IETF LC comments on draft-ietf-tsvwg-rsvp-ipsec".
> Effectively, on request from Security experts in order to make sure  
> the security aspects are covered appropriately, we end up re- 
> discussing the applicability of existing keying methods +  
> applicability of potential future group keying methods in the  
> "Security Considerations" section of every RSVP-related document  
> (see RFC4860, draft-ietf-tsvwg-emergency-rsvp). It is important that  
> applicability/Pros&cons of various keying methods for RSVP be  
> documented by TSVWG once for all. This discussion should reflect the  
> view of the WG since it affects RSVP security across all RSVP- 
> related documents.

So this argues for extracting the repeated argument into an individual  
draft, so it can be referenced instead of needing to be duplicated.  
But it does not motivate the need for a new solution.

> Also, draft-behringer-tsvwg proposes to document applicability of  
> keying methods to IPsec protection of RSVP (as opposed to just RSVP  
> authentication). We are not aware of an IETF document where this is  
> well addressed and feel this would be useful (and has been requested  
> by a few people e.g. Anshul from LMCO).


Can you point me at Anhul's email, please? I couldn't dig it up locally.

Thanks,
Lars