Subject: Re: [tsvwg] SECDIR Early Review of: draft-ietf-tsvwg-rsvp-security-groupkeying

From: "Michael H. Behringer" <[email-masked]>
Date: Sat, 26 Jun 2010 22:10:03 +0200

Gorry, WG, 

We just submitted -06 of the draft, to address the comments received during
the SecDir review. This includes a lot of editorial changes, as well as some
re-organisation of the draft.

The link to the latest version is:
http://www.ietf.org/id/draft-ietf-tsvwg-rsvp-security-groupkeying-06.txt

Please could we also get a slot in Maastricht to go through the changes.

Michael

On 15/01/2010 11:27, "Gorry Fairhurst" <[email-masked]> wrote:

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Sun, 27 Jun 2010 07:51:20 +0100

Good to see this. The chairs will take this forward,

Gorry

On 26/06/2010 21:10, Michael H. Behringer wrote:
> On 15/01/2010 11:27, "Gorry Fairhurst"<[email-masked]>  wrote:
>
>>
>>
>> Gorry&  James
>> From: Stephen Kent<[email-masked]>
>> To: Gorry<[email-masked]>, James M. Polk<[email-masked]>
>> Cc: Samuel Weiler<[email-masked]>, Stephen Kent<[email-masked]>