Re: (another) WGLC started for "RSVP Security Groupkeying" ID

[Bob Briscoe <[e-mail]>]

Michael,

Looked at diffs, and I'm happy with the new text that reinstates the 
route diversion attack and points to RFC5374 address preservation as 
a protection against it.

Nits are all cleared too.

Cheers


Bob

At 20:43 24/09/2010, Bob Briscoe wrote:
>To: "Michael H. Behringer" <[e-mail]>
>From: Bob Briscoe <[e-mail]>
>Subject: Re: (another) WGLC started for "RSVP Security Groupkeying" ID
>Cc: "James Polk (jmpolk)" <[e-mail]>, Francois Le Faucheur 
><[e-mail]>, tsvwg IETF list <[e-mail]>, <[e-mail]>
>In-Reply-To: <[e-mail]>
>References: <[e-mail]> 
><[e-mail]>
>
>Michael,
>
>
>At 10:08 23/09/2010, Michael H. Behringer wrote:
>>WGs,
>>
>>Thanks to the reviewers for their feedback on this draft.
>>
>>The only suggestions we got from the WGLC came from Bob, and below you can
>>see how we addressed them in the just submitted version 7.
>>
>>We believe to have now addressed all comments following the WGLC, and would
>>like the chairs to move this document forward.
>>
>>Thanks,
>>Michael, Francois, Brian
>>
>>
>>On 27/07/2010 18:42, "Bob Briscoe" <[e-mail]> wrote:
>>
>> > James, Michael, Francois,
>> >
>> > Here's my review,
>> >

[snip]

>> > S.6.1
>> > "A router implementing GDOI and the AH and/or ESP protocols is
>> > therefore able to implement this policy."
>> >
>> > The 'and/or' implies the ESP protocol alone could be enough. This
>> > needs to refer forward to the limitations of ESP discussed in
>> > Security Considerations. (except they aren't there any more - 
>> see next point)
>> >
>> > S.6.3.
>> > "In the case of ESP the new, outer IP header however is not
>> > cryptographically secured in this process.  This has consequences
>> > when group keying is used; see the Security Considerations section
>> > for details."
>> >
>> > There is nothing about ESP in the Security Considerations section.
>> > And the re-routing attack previously described in Section "6.2. Using
>> > IPsec ESP" that I think this refers to has been deleted. Has this
>> > attack been proven to not exist, or was losing this text a mistake?
>>
>>We provided new text to clarify this.
>
>I'll look at the diffs shortly, but must dash now.
>
>Cheers
>
>
>
>Bob
>
>
>> > S.6.5.
>> > "  Tunnel mode with address preservation, in conjunction with group
>> >     keying, allows the use of AH or ESP for protection of RSVP even in
>> >     cases where non-RSVP nodes have to be traversed.  This is because it
>> >     allows routing of the IPsec protected packet through the non-RSVP
>> >     nodes in the same way as if it was not IPsec protected.
>> > "
>> > If we still intend to talk about the reservation re-routing attack
>> > (see previous point), we also need to refer to it here (once we have
>> > reinstated the text that talks about it). Because a reservation can
>> > be redirected by a non-RSVP hop in the address-preserving case as in
>> > other cases using ESP.
>>
>>We provided new text to clarify this.
>>
>> > S.10.1
>> > Another "Subverted Nodes" attack occurs to me that uses the weakness
>> > of ESP vs AH. Using a group key, a subverted node could turn round a
>> > PATH message back to the previous node that the subverted node
>> > received it from, thus pretending the PATH had traversed the rest of
>> > the path when in fact the subverted node has just been holding on to
>> > it for a while. Thus the sending half of the nodes think the
>> > reservation has been set-up, while the receiving half never saw it.
>> >
>> >
>> > The point of mentioning these attacks is that, with group keying, a
>> > subverted node can change which direction it sends messages
>> > (sideways, backwards), not just subvert the messages it forwards.
>>
>>Also addressed in the new text.
>>
>> > Nits
>> > ====
>> > S.2
>> > "If a group key is used, the authentication granularity becomes group
>> > membership, not (individual) peer authentication."
>> > You might want to make it clear that you are talking about a group of
>> > nodes not humans ('group membership' is ambiguous). But I'm not
>> > insisting - it's unlikely to be misunderstood.
>>
>>Changed the sentence to "... the authentication granularity becomes group
>>membership of devices, not (individual) peer authentication between
>>devices."
>>
>> > s/...whether authentication or encryption (or both) are used.
>> >   /...whether authentication or encryption (or both) is used./
>> > Change it back to the correct English: the verb shouldn't match the
>> > phrase in the parenthesis.
>>
>>Changed.
>>
>> > S.2. Penultimate para:
>> > s/We note that if this handshake is taking place,
>> >   /We note that if this handshake has taken place,/
>>
>>Not changed. (I believe the present tense is more readable here)
>>
>> > S.3.1
>> > s/INTEGITY
>> >   /INTEGRITY/
>>
>>Changed.
>>
>> > S.6.3.
>> > "This has consequences when group keying is used; see the Security
>> > Considerations section for details."
>> >
>> > s/consequences/negative consequences/
>>
>>Changed.
>>
>> > S.6.5.
>> > "it is not possible to use tunnel-endpoint destination address"
>> > s/tunnel-endpoint
>> >   /a tunnel-endpoint/
>>
>>Changed.
>>
>> > Bob
>> >
>> >
>> > At 10:27 25/07/2010, Bob Briscoe wrote:
>> >> James,
>> >>
>> >> I can try to have a look by the deadline.
>> >>
>> >>
>> >> Bob
>> >>
>> >> At 17:48 14/07/2010, James M. Polk wrote:
>> >>> TSVWG
>> >>>
>> >>> This is to let everyone know we've initiated a new WGLC for the
>> >>> "RSVP Security Groupkeying" ID here.
>> >>>
>> >>> 
>> http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-rsvp-security-groupkeying/
>> >>>
>> >>> This ID has had some significant modifications based on the SecDir
>> >>> review by Stephen Kent.  Please reread this ID to verify these
>> >>> changes are appropriate, and do not introduce new issues or concerns.
>> >>>
>> >>> Once you have reviewed this version, please send a note to the list
>> >>> with an indication whether or not this doc should proceed to the
>> >>> IESG for RFC consideration. We chairs need to gauge WG interest
>> >>> before this (or any) document progresses towards publication.
>> >>>
>> >>> Because of the IETF meeting so close, this is an extended WGLC,
>> >>> lasting 4 weeks - ending August 11th, 2010.
>> >>>
>> >>> Please do review this document and let us/the list know what you think.
>> >>>
>> >>> James & Gorry
>> >>> TSVWG chairs
>> >>
>> >> ________________________________________________________________
>> >> Bob Briscoe,                                BT Innovate & Design
>> >
>> > ________________________________________________________________
>> > Bob Briscoe,                                BT Innovate & Design
>> >
>
>________________________________________________________________
>Bob Briscoe,                                BT Innovate & Design

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design