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

Lars Eggert <lars.eggert@nokia.com> Tue, 29 January 2008 10:05 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 1JJnLO-0003ts-Mf; Tue, 29 Jan 2008 05:05:30 -0500
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1JJnLM-0003tm-GQ for tsvwg-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 05:05:28 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJnLM-0003te-47 for tsvwg@ietf.org; Tue, 29 Jan 2008 05:05:28 -0500
Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJnLJ-0007EA-P4 for tsvwg@ietf.org; Tue, 29 Jan 2008 05:05:28 -0500
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0TA4xFQ030495; Tue, 29 Jan 2008 12:05:12 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jan 2008 12:05:11 +0200
Received: from esdhcp034122.research.nokia.com ([172.21.34.122]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jan 2008 12:05:10 +0200
Message-Id: <E119D886-0838-4323-ABD7-0C8CCAE5C7A3@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
To: ext Brian Weis <bew@cisco.com>
In-Reply-To: <E603EB77-B600-4A73-9217-EB797A5D7AAB@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: Tue, 29 Jan 2008 12:05:08 +0200
References: <47974BDB.70406@ericsson.com> <CD8D57B6-EB94-4DCE-A42A-02BC5F573A13@nokia.com> <7A1BB0E8-5EFB-4341-918A-F841DB1B57FF@cisco.com> <A268781D-F81A-48B3-8042-1892AC93B749@nokia.com> <E603EB77-B600-4A73-9217-EB797A5D7AAB@cisco.com>
X-Mailer: Apple Mail (2.915)
X-OriginalArrivalTime: 29 Jan 2008 10:05:10.0547 (UTC) FILETIME=[6ECD8630:01C8625E]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: ext Magnus Westerlund <magnus.westerlund@ericsson.com>, RJ Atkinson <rja@extremenetworks.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, Brian,

On 2008-1-28, at 19:58, ext Brian Weis wrote:
> Calling draft-behringer-tsvwg a "survey" of "group keying for RSVP"  
> isn't an entirely accurate statement. It's a much more fundamental  
> description of RSVP security: it documents the RSVP trust model  
> (perhaps for the first time), and from there it describes the  
> appropriate uses for RSVP keys that should be used within different  
> network topologies, as well as provisioning methods for those keys.  
> Although these topics don't motivate new TSVWG protocol development,  
> taking ownership of these RSVP security fundamentals is important  
> for TSVWG. I believe that is a good rationale for accepting draft- 
> behringer-tsvwg as a WG item.

I agree with you, and I said during the Vancouver meeting that I'd see  
such an Informational document in scope for TSVWG.

However, I'm now hesitating, because I've heard the argument being  
made (both in Vancouver during SAAG and in the recent email by  
Francois) that the acceptance of draft-behringer-tsvwg-rsvp-security- 
groupkeying as a TSVWG work item would establish a need to work on a  
solution in MSEC (based on draft-weis-gdoi-for-rsvp). I don't agree  
with this argument. At best, the document would identify a hole in the  
solution space, and if MSEC wants to fill that, I'd need to find its  
own motivation for doing so.

Lars