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

["Michael H. Behringer" <[e-mail]>]

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,
> 
> I've only looked at the diffs from -05, which I already reviewed. So
> this review doesn't imply I've re-checked overall readability.
> 
> S.4.1
> "Static keys are preconfigured, either manually, or through a network
> management system, and not negotiated via a protocol."
> Delete: ", and not negotiated via a protocol" (the NMS uses a
> protocol and implying it somehow does not creates complacency - see
> next point).

Deleted the sub-phrase.
 
> "The provisioning of static keys requires either manual operator
> intervention on each node, or a network management system performing
> the same task."
> 
> Would it be worth pointing out (or is it obvious?) that, if an NMS is
> giving nodes static keys, it needs to regularly change the keys it
> uses to verify that it is talking with the nodes it thinks it is
> talking with? This recursion has to stop somewhere!

I'd argue that would end in a longer discussion on this topic, which is
really not helping the subject of the document significantly. So we made no
change here. 

> S.4.2.1
> It's interesting that the following has been deleted. "However,
> existing key negotiation protocols such as IKEv1 [RFC2409] or IKEv2
> [RFC4306] may not be appropriate in all environments because of the
> relative complexity of the protocols and related operations."
> 
> Operational complexity is why Jonny can't encrypt, but we're not
> allowed to say why Jonny can't encrypt?!
> 
> I would argue that something ought to remain of this sentiment,
> rather than deletion. Perhaps "Although it is recognised that
> existing key neg protocols RFC[...] are operationally complex to
> deploy, the security they provide compared to ad hoc manual
> alternatives is worth the effort invested."

The question that was raised was "what does 'complex' mean?", which would
lead to a significantly longer discussion, which is not really the focus of
the document. So we suggest to not change this section.

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

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