Subject: [tsvwg] SECDIR Early Review of: draft-ietf-tsvwg-rsvp-security-groupkeying (fwd)

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 15 Jan 2010 10:27:32 +0000

Here is the SECDIR review in its entirety for the WG to review and 
comment upon.  The chairs suggest discussion on this list by any WG 
members that resonate with any point(s) brought up below. Please feel 
free to initiate a discussion about.

Authors - please do address the issues with terminology and any issues 
which you understand how to address, and compile a list of any issues 
that require discussion by the group or security area.

Best wishes,

Gorry & James
(TSVWG Chairs)

---------- Forwarded message ----------
Date: Mon, 30 Nov 2009 22:51:27 -0500
From: Stephen Kent <[email-masked]>
To: Gorry <[email-masked]>, James M. Polk <[email-masked]>
Cc: Samuel Weiler <[email-masked]>, Stephen Kent <[email-masked]>
Subject: draft-ietf-tsvwg-rsvp-security-groupkeying

Folks,

As per your request I reviewed the subject document.

It has a LOT of problems:

- the authors are inconsistent in their use of terms in various places
in the document (e.g., trust zone, trust domain, trust group)

- the authors do not clearly define what they mean by static, manual,
or  dynamic keying. they then make general assertions about the costs of 
various keying methods without providing any analysis to support their 
assertions.

- the authors are clearly big proponents of group keying, and so they
sweep under the rug all the details of what one has to do to 
authenticate group members to a group key server and what the server 
needs to do to distribute keys to the group members. there may be good 
arguments for why group keying is preferable to alternatives, but this 
document does not make that case

- the authors assert that tunnel mode ESP is unsuitable for use with
RSVP due to a MITM vulnerability, but the argument they present is flawed.

- the authors assert that using the group keying mechanisms in RFC 3547
solves the problems of using IPsec with RSVP, which contradicts 
statements elsewhere about problems with IPsec protocols and RSVP.

- the authors argue that Section 3.1 of RFC 5374 describes how to use
tunnel mode in a way that fixes problems otherwise present with AH or 
ESP, but the argument is suspect. The cited section talks about a new 
version of tunnel mode for use by secruity gateways when sending traffic 
on multicast SAs, but there is not reason why routers using RSVP should 
be viewed as secruity gateways with respect to RSVP traffic.

- overall, the document is very poorly organized. it rambles and makes
arguments in one section that appear to contradict analyses in other 
sections.

I have attached an edited version of the document with suggested edits 
and lots of comments.

Steve