Skip to main content

Early Review of draft-ietf-tsvwg-rsvp-security-groupkeying-
review-ietf-tsvwg-rsvp-security-groupkeying-secdir-early-kent-2009-12-18-00

Request Review of draft-ietf-tsvwg-rsvp-security-groupkeying
Requested revision No specific revision (document currently at 11)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2011-08-09
Requested 2009-11-20
Authors Michael H. Behringer , Brian Weis , François Le Faucheur
I-D last updated 2009-12-18
Completed reviews Secdir Early review of -?? by Stephen Kent
Secdir Telechat review of -?? by Stephen Kent
Assignment Reviewer Stephen Kent
State Completed
Request Early review on draft-ietf-tsvwg-rsvp-security-groupkeying by Security Area Directorate Assigned
Completed 2009-12-18
review-ietf-tsvwg-rsvp-security-groupkeying-secdir-early-kent-2009-12-18-00
This is the message I sent to the WG chairs  o 11/30, in response to 


this special request.




Steve
------

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

Attachment:


draft-ietf-tsvwg-rsvp-security-groupkeying-05.pdf




Description:

 Adobe PDF document