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

Francois Le Faucheur IMAP <flefauch@cisco.com> Mon, 28 January 2008 09:59 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 1JJQmF-0002zc-RY; Mon, 28 Jan 2008 04:59:43 -0500
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1JJQmD-0002zV-QG for tsvwg-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 04:59:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJQmD-0002zN-Al for tsvwg@ietf.org; Mon, 28 Jan 2008 04:59:41 -0500
Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJQmC-0003L1-QE for tsvwg@ietf.org; Mon, 28 Jan 2008 04:59:41 -0500
X-IronPort-AV: E=Sophos;i="4.25,258,1199660400"; d="scan'208";a="4125535"
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 28 Jan 2008 10:59:40 +0100
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0S9xelp017208; Mon, 28 Jan 2008 10:59:40 +0100
Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0S9x7ll011083; Mon, 28 Jan 2008 09:59:35 GMT
Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jan 2008 10:59:35 +0100
Received: from [10.0.0.58] ([10.61.81.166]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jan 2008 10:59:34 +0100
In-Reply-To: <CD8D57B6-EB94-4DCE-A42A-02BC5F573A13@nokia.com>
References: <47974BDB.70406@ericsson.com> <CD8D57B6-EB94-4DCE-A42A-02BC5F573A13@nokia.com>
Mime-Version: 1.0 (Apple Message framework v753)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <7A1BB0E8-5EFB-4341-918A-F841DB1B57FF@cisco.com>
Content-Transfer-Encoding: 7bit
From: Francois Le Faucheur IMAP <flefauch@cisco.com>
Subject: Re: [Tsvwg] Adopting draft-behringer-tsvwg-rsvp-security-groupkeying as WG item?
Date: Mon, 28 Jan 2008 10:59:31 +0100
To: Lars Eggert <lars.eggert@nokia.com>
X-Mailer: Apple Mail (2.753)
X-OriginalArrivalTime: 28 Jan 2008 09:59:34.0950 (UTC) FILETIME=[7C5BBC60:01C86194]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2582; t=1201514380; x=1202378380; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20<flefauch@cisco. com> |Subject:=20Re=3A=20[Tsvwg]=20Adopting=20draft-behringer-ts vwg-rsvp-security-groupkeying=20as=20WG=20item? |Sender:=20; bh=XP/oBXgI+TUFUkcwyDe+2TSISUeqyDwQGbW6UvNwpGM=; b=VgO53cExV1ha92KHFIoD9YWFxQWADiH+CHPAbcSpnOvjfdI2rd6okNyXMS xX7n2qZUw5j/YGzds8HiBmxHmtnl8O18DuzrZYG/GmdVLUFXmZQBc3k0HVgI IFKbAXlqeX;
Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; );
X-Spam-Score: -4.0 (----)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Cc: RJ Atkinson <rja@extremenetworks.com>, ext Magnus Westerlund <magnus.westerlund@ericsson.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 Lars and all,

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

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

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.

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

Cheers

Francois

>
> Lars