Subject: [Ipsec] Please review draft-ietf-msec-ipsec-extensions-03.txt

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 17 Oct 2006 07:38:26 -0700

Folks,

We need a review of the following MSEC WG document describing 
multicast extensions to 4301.

thanks,
Lakshminath

>         Title           : Multicast Extensions to the Security 
> Architecture for the Internet Protocol
>         Author(s)       : B. Weis, et al.
>         Filename        : draft-ietf-msec-ipsec-extensions-03.txt
>         Pages           : 26
>         Date            : 2006-10-16
>
>The Security Architecture for the Internet Protocol [RFC4301]
>    describes security services for traffic at the IP layer. That
>    architecture primarily defines services for Internet Protocol (IP)
>    unicast packets, as well as manually configured IP multicast packets.
>    This document further defines the security services for manually and
>    dynamically keyed IP multicast packets within that Security
>    Architecture.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-extensions-03.txt

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 17 Oct 2006 17:07:00 -0700

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-extensions-04.txt

Lakshminath

---

From: <[email-masked]>
Date: Wed, 25 Oct 2006 13:16:11 +0300

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

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

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.

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

5) References not cited anywhere in the text: RFC3552

Best regards,
Pasi 

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