Subject: Re: [Tsvwg] Review of draft-ietf-tsvwg-rsvp-security-groupkeying-04

From: "Carlberg, Kenneth G." <[email-masked]>
Date: Tue, 2 Jun 2009 10:15:24 -0400

Francois & Michael,

Here is another review of the draft.  Its mostly comprised of nits and
requests for additional clarification.

-ken

1) page 4,  "Implicitly each node trusts each other node with which
   it has a trust relationship established via the mechanisms here to
   adhere to the protocol specifications laid out by the various
   standards."

The sentence is a bit long and confusing.  You need to break up the
sentence and clarify the content of the word "here".  Also,
s/other/other's

2) page 5, 3'rd para.  s/R2 and will ignore/R2 will ignore

3) page 5, 5'th para.  
   "With neighbor based keys, an RSVP key is bound to an interface plus
a
   neighbor on that interface.  It allows the distinction of different
   trust groups on a single subnet.  (Assuming that layer-2 security is
   correctly implemented to prevent layer-2 attacks.)"

Does the above text concerning neighbor based keys allow for different
trust groups per interface?  If so, this should be stated to the reader.

4) Page 6, 5'th para.  s/domains however/domains. However

5) page 14, 2'nd para.
   "In
   particular, such keying can be used for RSVP authentication (e.g.,
   using RSVP authentication or IPsec AH) and/ or for RSVP encryption
   (e.g., using IPsec ESP in tunnel mode)."

The sentence is a bit unclear with respect to using the term RSVP
authentication as an example of keying "used for RSVP authentication".
You'll either need to clarify the text, or just rely on IPsec AH as a
single example.

6) Page 15, late sentence of 4'th para.  
   "Therefore the impact of subverted nodes on the path is comparable,
   independently whether per-interface, per-neighbor or group keys are
   used."

The reader would probably ask, comparable to what?  It would be helpful
if you could complete the object of the sentence.

---

From: "Sheela Rowles (sheela)" <[email-masked]>
Date: Tue, 2 Jun 2009 21:54:53 -0700

Francois & Michael,

I'm also planning to review the draft.  I hope to complete the review
within a week or two.  

Sheela 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Carlberg, Kenneth G.
Sent: Tuesday, June 02, 2009 7:15 AM
To: Francois Le Faucheur (flefauch); Michael Behringer (mbehring)
Cc: tsvwg IETF list
Subject: Re: [Tsvwg] Review of
draft-ietf-tsvwg-rsvp-security-groupkeying-04

Francois & Michael,

-ken

3) page 5, 5'th para.  

5) page 14, 2'nd para.
   "In

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Wed, 3 Jun 2009 10:33:33 +0200

Hi James, Gorry, Lars,

At last IETF, Lars conditioned Last Calling of rsvp-security- 
groupkeying on getting explicit commitments from subject experts that  
they will indeed review the doc.
Considering that, since then, Brian Weis, Bob Briscoe and Ken Carlberg  
have posted their full review comments and Sheela just committed to  
also do a review, would it be appropriate to move to Last Call now?

Thanks

Francois

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 3 Jun 2009 11:58:06 +0200

Hi Brian, 

Thanks for your review - this is very useful. 

Regarding your comment, I agree that the statement is confusing. And to
be honest, the point wasn't so much about distinguishing between
explicit or implicit, the point was that in a group keying scenario you
trust all members of the group. We'll simplify the sentence to "Note
that in any group keying scheme like GDOI a node trusts all the other
members of the group."

I thought about adding more on implicit vs explicit, but came to the
conclusion that this makes this section a lot more confusing, while not
really adding much value over the beginning of that paragraph. 

Does this address your concern? Is this appropriate? 

Michael

> From: Brian Weis (bew)
> Sent: 06 May 2009 1:50
> Subject: Review of draft-ietf-tsvwg-rsvp-security-groupkeying-04
> 
> Hi Francois & Michael,
> 
> I have reviewed this document and have only one comment. Section 2
> discussed "implicit" and "explicit" trust. Generally, I agree with it
> except for the following sentence:
> 
> "Note that in any group keying scheme like GDOI a node trusts
> explicitly as well as implicitly all the other members of the group."
> 
> I don't see where the fact that multiple parties hold the same key to
> make the trust explicit. For example, when manual keying is used the
> node doesn't really have any idea how many other nodes share that key
> (i.e., whether it is a pairwise or group key). It simply sends and
> receives RSVP messages and explicitly trusts the next RSVP node to
> handle the message to do the right thing, regardless of whether its
> identity is known or unknown. Non-neighbors are always trusted
> implicitly whether or not they happen to share a key.
> 
> Were you thinking of some other attribute of group keying that makes
> the trust explicit?
> 
> Thanks,
> Brian
> 
> --
> Brian Weis
> Router/Switch Security Group, ARTG, Cisco Systems
> Telephone: +1 408 526 4796
> Email: [email-masked]
> 
>

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 3 Jun 2009 16:01:45 +0200

Ken, 

Thanks for the feedback, this is very helpful! Inline...

> From: Carlberg, Kenneth G. [mailto:[email-masked]]
> Sent: 02 June 2009 16:15
> Subject: RE: [Tsvwg] Review of draft-ietf-tsvwg-rsvp-security-
> groupkeying-04
> 
> Francois & Michael,
> 

Agreed. We simplified that sentence to: 

Implicitly each node trusts each other node in the RSVP domain to adhere
to the protocol specifications laid out by the various standards. 

> 2) page 5, 3'rd para.  s/R2 and will ignore/R2 will ignore

Done. Good catch!

> trust groups per interface?  If so, this should be stated to the

Ken - I don't understand this one. Isn't the sentence "It allows the
distinction of different trust groups on a single subnet." addressing
exactly your point? 

> 4) Page 6, 5'th para.  s/domains however/domains. However

Reworded. 
 
> You'll either need to clarify the text, or just rely on IPsec AH as a

Re-worded: "such keying can be used for RSVP authentication (e.g., using
the RSVP INTEGRITY object or IPsec AH) and/ or for RSVP encryption
(e.g., using IPsec ESP in tunnel mode)." 
 
> if you could complete the object of the sentence.

Re-worded: "Therefore the impact of subverted nodes on the path is
comparable for all keying schemes discussed here (per-interface,
per-neighbor, group keys)."

Thanks again for your thorough review, and all your comments. Please let
us know if our corrections are still not clear or have introduced new
questions. 

Michael

---

From: "Carlberg, Kenneth G." <[email-masked]>
Date: Wed, 3 Jun 2009 10:21:59 -0400

Michael, 

>  >    trust groups on a single subnet.  (Assuming that 
>  layer-2 security
>  is
>  Ken - I don't understand this one. Isn't the sentence "It 
>  allows the distinction of different trust groups on a single 
>  subnet." addressing exactly your point? 

I may be too picky, but in only saying "a single subnet", the reader
could have the impression that in (for example) a broadcast subnet, the
text may be refering to a ships-in-the-night scenario where I have some
nodes operating in one trust group and other nodes in another trust
group.  By extending your text to explicitly say that neighbor based
keys allows for different trust groups per interface in a subnet, there
is no ambiguity.

Its not a major issue so feel free to disregard the suggestion.

-ken

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 3 Jun 2009 18:51:52 +0200

> Sent: 03 June 2009 16:22
> To: Michael Behringer (mbehring); Francois Le Faucheur (flefauch)
> Cc: tsvwg IETF list
> >  >    "With neighbor based keys, an RSVP key is bound to an
interface
> >  plus

Got it! Will incorporate this point as well, thanks!

Michael

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 4 Jun 2009 12:34:45 +0200

We have just uploaded version -05, incorporating the latest comments
received:

   o  Clarified in section 6.3 that IPsec AH also secures the immutable
      fields of the outer header (comment from Bob Briscoe)
   o  Simplified in section 2 the comment that trust in group keying
      extends to all members of the group (deleted the words on
      "explicit and implicit"). (comment from Brian Weis)
   o  A number of corrections, re-wordings and clarifications in
      response to Kenneth Carlberg's email from 2 June 2009

This would be the right version of the document for LC now, if
applicable. 
http://tools.ietf.org/html/draft-ietf-tsvwg-rsvp-security-groupkeying

Thanks, 
Michael

> From: Francois Le Faucheur (flefauch)
> Sent: 03 June 2009 10:34
> To: James Polk (jmpolk); Gorry Fairhurst; Lars Eggert
> Cc: Francois Le Faucheur (flefauch); Michael Behringer (mbehring);
> tsvwg IETF list
> Subject: Re: [Tsvwg] Review of draft-ietf-tsvwg-rsvp-security-
> groupkeying-04
> 
> Hi James, Gorry, Lars,
>

---

From: Brian Weis <[email-masked]>
Date: Thu, 4 Jun 2009 23:09:25 -0700

Hi Michael,

> Does this address your concern? Is this appropriate?

Thanks for the clarification. The proposed change works for me, and I  
see you've already included it in -05.

Thanks,
Brian