Subject: [Ipsec] re: Please review draft-ietf-msec-ipsec-extensions-04 (fwd)

From: [email-masked]
Date: Thu, 26 Oct 2006 17:48:17 -0400

Hi Pasi, 

thank you for taking the time to review and comment on the draft. responses 
inline below... 

 ----------Forwarded message ----------
> Date: Wed, 25 Oct 2006 13:16:11 +0300
> From: [email-masked]
> To: [email-masked], [email-masked]
> Cc: [email-masked]
> Subject: RE: [Ipsec] Please review draft-ietf-msec-ipsec-extensions-04 
>
> A couple of comments: 
>
> 1) Sections 4.1.2 and 4.4.2 are not quite clear whether IPsec SAs for
> multicast are unidirectional (separate SAs for sending and receiving)
> or possibly bidirectional (a bigger change to RFC4301).

Section 4.1.2 last sentence specifically says that the SAD behaves the same 
as RFC4301. 

Section 4.4.2 does mention that the GKM must provide a "direction 
attribute". As you know, IKE-v2 alway negotiates unicast bi-directional 
traffic flows, i.e. an IPsec SA in each direction. However, an IPsec 
subsystem should not assume IKE-v2 behavior. What section 4.4.2 is advising 
the implementor is that the GKM system can create an IPsec SA that has no 
peer IPsec SA for a traffic flow in the opposite direction. 

For example, in a typical SSM configuration, a Group Speaker can have an 
IPsec SA to encrypt and transmit to the group. The Group Receivers each have 
an IPsec SA that decrypts the Speaker's transmission. There is no IPsec SA 
for protecting an inverse traffic flow from the Group Receivers to the Group 
Speaker. 

> 2) Section 4.1.3.1: "An implementation SHOULD offer PAD configuration
> capabilities that authorize the GKM policy configuration mechanism to
> set security policy for other aspects of an endpoint's GSPD/SAD
> configuration, not confined to its group security associations. This
> capability allows the group's policy to inhibit the creation of back
> channels that might otherwise leak confidential group application
> data." 
>
> I didn't quite understand this; a more detailed description might
> be helpful...

What this was intended to enable are security policies that would use the 
SPD-O DISCARD processing option to prevent an insider Adversary from 
re-broadcasting (either multicast or unicast) the group's data (e.g. a 
pay-per-view content). I don't know if explaining that helps answer your 
question though... 

> 3) Appendix A.2 seems to suggest that GKM can also set up unicast
> IPsec SAs? ("However, the unicast inverse flows can use the group's
> IPsec group authentication mechanism.") This text needs clarification.

One of the use cases is NORM, which does multicast from the Group Speaker to 
the Group Receivers, and unicast from Group Receiver(s) to the Group 
Speaker. The unicast messages include NACK repair requests, congestion 
control metering, and other session control messages. Would it help if we 
explicitly mentioned that NORM would fit into this use case? 

> 4) Section 4.1.1, "identical SPIs to SPD entries created by IKEv2",
> "SPD entries" -> "SAD entries"

ok, we'll fix. 

> 5) References not cited anywhere in the text: RFC3552

ok, will delete it. 

br,
   George 

 -----Original Message-----
> From: ext Lakshminath Dondeti [mailto:[email-masked]]
> Sent: 18 October, 2006 03:07
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Ipsec] Please review draft-ietf-msec-ipsec-extensions-04 
>
> Folks, 
>
> There was a small problem with -03- apparently and the authors have
> posted -04-.  Please review this version.  Thanks. 
>
> http://ietf.org/internet-drafts/draft-ietf-msec-ipsec-extensio
ns-04.txt
>
> Lakshminath 
>
>
> _______________________________________________
> Ipsec mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipsec 
>

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec 

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec