Subject: [MSEC] Review of draft-ietf-msec-ipsec-extensions-01

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 15 Jun 2006 03:04:55 -0700

Hi all,

[Disclaimer: Reviewing as an MSEC contributor.  Ran or I will have to 
do a "WG chair" review some time before forwarding this to the IESG.]

I reviewed the first 5 sections.  You have a lot of stuff on NATs and 
NATs are boring to me.  I will review that some other time.

Lakshminath

>MSEC Working Group                                              B. Weis
>Internet-Draft                                            Cisco Systems
>Expires: August, 2006                                          G. Gross
>                                                     IdentAware Security
>                                                             D. Ignjatic
>                                                                 Polycom
>                                                          February, 2006
>
>     Multicast Extensions to the Security Architecture for the Internet
>                                  Protocol
>                   draft-ietf-msec-ipsec-extensions-01.txt

<snip>

>Abstract
>
>    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 IP multicast
>    packets within that Security Architecture.

I think the last sentence needs to be revised.  If 4301 supports 
security services for manually configured IP multicast, perhaps this 
draft specifies dynamically keyed multicast security services using 
IPsec?  What else?

><snip>

>Table of Contents
>
>1.0 Introduction.......................................................2
>   1.1 Scope............................................................3
>   1.2 Terminology......................................................3
>2.0 Overview of IP Multicast Operation.................................5
>3.0 Security Association Modes.........................................5
>   3.1 Tunnel Mode with Address Preservation............................6
>4.0 Security Association...............................................7
>   4.1 Major IPsec Databases............................................7
>     4.1.1 Security Policy Database (SPD)...............................7
>     4.1.2 Security Association Database (SAD)..........................7
>     4.1.3 Peer Authorization Database (PAD)............................8
>     4.1.4 Group Security Association (GSA).............................9

GSA is not a database, is it?  Perhaps this belongs in 4.1.2?

>   4.2 Data Origin Authentication......................................11
>   4.3 Group SA and Key Management.....................................11
>     4.3.1 Co-Existence of Multiple Key Management Protocols...........11
>     4.3.2 New Security Association Attributes.........................12
>5.0 IP Traffic Processing.............................................12
>   5.1 Outbound IP Multicast Traffic Processing........................12
>   5.2 Inbound IP Multicast Traffic Processing.........................12
>6.0 Networking Issues.................................................12
>   6.1 Network Address Translation.....................................13
>     6.1.1 SPD Losses Synchronization with Internet Layer's State......13
>     6.1.2 Secondary Problems Created by NAT Traversal.................14
>     6.1.3 Avoidance of NAT Using an IPv6 Over IPv4 Network............15
>     6.1.4 GKMP/IPsec Multi-Realm IPv4 NAT Architecture................16

Is NAT the only issue?  If so, I suggest moving 6.1 up to 6.0 
level.  I guess more on this in the actual text.

>7.0 Security Considerations...........................................19
>8.0 IANA Considerations...............................................19
>9.0 Acknowledgements..................................................19
>10.0 References.......................................................19
>   10.1 Normative References...........................................19
>   10.2 Informative References.........................................20
>Appendix A - Multicast Application Service Models.....................22

I am not reviewing the Appendix in this round.  (Too tired! :) )

>   A.1 Unidirectional Multicast Applications...........................22

Is this mcast only?

>   A.2 Bi-directional Reliable Multicast Applications..................22

Is this mcast, with a reverse channel?

>   A.3 Any-To-Any Multicast Applications...............................23

Multi-sender mcast?

>Author's Address......................................................24
>Intellectual Property Statement.......................................25
>Copyright Statement...................................................25
>
>1.0 Introduction
>
>    The Security Architecture for the Internet Protocol [RFC4301]
>    provides security services for traffic at the IP layer. It describes
>
>
>Weis, et al.             Expires August, 2006                 [Page 2]
>
>Internet-Draft     Multicast Extensions to RFC 4301         June, 2005

><snip>

>Some support for IP
>    packets with a multicast address in the IP destination field is
>    supported, but only with manual keying, and only between IPsec
>    devices acting as hosts.

Please rewrite that sentence.  The word "support" is repeated.

>    This document describes extensions to RFC 4301 that further define
>    the IPsec security architecture for groups of IPsec devices to share
>    SAs. In particular, it supports SAs with traffic selectors that
>    include a multicast address in the IP destination field, and results
>    in an IPsec packet with an IP multicast address in the IP destination
>    field. It also describes additional semantics for IPsec Group Key
>    Management Protocol (GKMP) Subsystems.

GKMP is RFC 2093.  I'd rather we not reuse that acronym.

Perhaps IPsec with GSAs or something like that is more generic?

>1.1 Scope
>
>    The IPsec extensions described in this document support IPsec
>    Security Associations that result in IPsec packets with IPv4 or IPv6
>    multicast group addresses as the destination address. Both Any-Source
>    Multicast (ASM) and Source-Specific Multicast (SSM) [RFC3569]
>    [RFC3376] group addresses are supported.
>
>    These extensions also support Security Associations with IPv4
>    Broadcast addresses that result in an IPv4 Broadcast packet,

Does this mean link level or subnet level broadcast?  Please clarify.

>  and IPv6
>    Anycast addresses [RFC2526]that result in an IPv6 Anycast packet.

Really?  I am surprised that you are covering anycast.  Will look for 
more details later in the I-D.

>    These destination address types share many of the same
>    characteristics of multicast addresses because there may be multiple
>    receivers of a packet protected by IPsec.
>
>    The IPsec Architecture does not make requirements upon entities not

s/Architecture/architecture

>    participating in IPsec (e.g., network devices between IPsec
>    endpoints). As such, these multicast extensions do not require
>    intermediate systems in a multicast enabled network to participate in
>    IPsec. In particular, no requirements are placed on the use of
>    multicast routing protocols (e.g., PIM-SM [RFC2362]) or multicast
>    admission protocols (e.g., IGMP [RFC3376].
>
>    All implementation models of IPsec (e.g., "bump-in-the-stack", "bump-
>    in-the-wire") are supported.

Nice and limited scope.  I like it.  (Except for the anycast stuff of course).

>1.2 Terminology
>
>
>
>
>Weis, et al.             Expires August, 2006                 [Page 3]
>
>Internet-Draft     Multicast Extensions to RFC 4301         June, 2005
>
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in RFC 2119 [RFC2119].
>
>
>    The following key terms are used throughout this document.
>
>    Any-Source Multicast (ASM)
>       The Internet Protocol (IP) multicast service model as defined in
>       RFC 1112 [RFC1112]. In this model one or more senders source
>       packets to a single IP multicast address. When receivers join the
>       group, they receive all packets sent to that IP multicast address.
>       This is known as a (*,G) group.
>
>    Group Controller Key Server (GCKS)
>       A Group Key Management Protocol (GKMP) server that manages IPsec

Could we not use something like "A group key server that ..."?

I am trying to get you to delete the use of GKMP and the notion of 
GKMP as a keyword in this document.

>       state for a group. A GCKS authenticates and provides the IPsec SA
>       policy and keying material to GKMP group members.
>
>    Group Key Management Protocol (GKMP)
>       A key management protocol used by a GCKS to distribute IPsec
>       Security Association policy and keying material. A GKMP is used
>       when a group of IPsec devices require the same SAs. For example,
>       when an IPsec SA describes an IP multicast destination, the sender
>       and all receivers must have the group SA.

Not sure about the latter part of the above para.  Access controlled 
groups would require that all members (or receivers) to join the 
group via IGMP and request GSA from the GCKS.  So, I don't think it 
really depends on the IP multicast destination (address?) per 
se.  How about something like "members of a secure group?"

>    Group Key Management Protocol Subsystem
>       A subsystem in an IPsec device implementing a Group Key Management
>       Protocol. The GKMP Subsystem provides IPsec SAs to the IPsec
>       subsystem on the IPsec device.

Why not use the notion of GSA with the third SA, the Data security 
SA, being the IPsec SA?  4046 would be a good guide there.

>    Group Member
>       An IPsec device that belongs to a group. A Group Member is
>       authorized to be a Group Speaker and/or a Group Receiver.

I am not too crazy about this definition.  Secure group members don't 
necessarily have to implement IPsec, right?

>    Group Owner
>       An administrative entity that chooses the policy for a group.
>
>    Group Security Association (GSA)
>       A collection of IPsec Security Associations (SAs) and GKMP
>       Subsystem SAs necessary for a Group Member to receive key updates.
>       A GSA describes the working policy for a group.

GSA is defined in 4046, no?

>    Group Receiver
>       A Group Member that is authorized to receive packets sent to a
>       group by a Group Speaker.
>
>    Group Speaker
>       A Group Member that is authorized to send packets to a group.

><snip>

>    Tunnel Mode with Address Preservation
>       A type of IPsec tunnel mode used by security gateway
>       implementations when encapsulating IP multicast packets such that
>       they remain IP multicast packets. This mode is necessary for IP
>       multicast routing to correctly route IP multicast packets
>       protected by IPsec.

This probably deserves more description, perhaps that comes latter?

>2.0 Overview of IP Multicast Operation
>
>    IP multicasting is a means of sending a single packet to a "host
>    group", a set of zero or more hosts identified by a single IP
>    destination address. IP multicast packets are UDP data packets
>    delivered to all members of the group with either "best-effort"
>    [RFC1112], or reliable delivery  (e.g., NORM) [RFC3940].
>
>    A sender to an IP multicast group sets the destination of the packet
>    to an IP address allocated to be used for IP multicast. Allocated IP
>    multicast addresses are defined in RFC 3171 [RFC3171]. Potential
>    receivers of the packet "join" the IP multicast group by registering
>    with a network routing device, signaling its intent to receive
>    packets sent to a particular IP multicast group.

4291 IPv6 addressing architecture and 2375 are additional references 
to include here.

>    Network routing devices configured to pass IP multicast packets
>    participate in multicast routing protocols (e.g., PIM-SM) [RFC2362].
>    Multicast routing protocols maintain state regarding which devices
>    have registered to receive packets for a particular IP multicast
>    group.

Your sentence below is more precise than the one above.  I think 
device level information is not kept, instead the presence of absence 
of receivers (one is as good as a thousand) on an interface basis is 
maintained.

>When a router receives an IP multicast packet, it forwards a
>    copy of the packet out each interface for which there are known
>    receivers.
>
>3.0 Security Association Modes
>
>    IPsec supports two modes of use: transport mode and tunnel mode.  In
>    transport mode, IP Authentication Header (AH) [RFC4302] and IP
>    Encapsulating Security Payload (ESP) [RFC4303] provide protection
>    primarily for next layer protocols; in tunnel mode, AH and ESP are
>    applied to tunneled IP packets.
>
>    A host implementation of IPsec using the multicast extensions MAY use
>    both transport mode and tunnel mode to encapsulate an IP multicast

both or either?

><snip>

>3.1 Tunnel Mode with Address Preservation

I can appreciate the requirement, I think.  If I am not mistaken, 
wouldn't there be three cases here?  There could be a sender which 
cannot IPsec encapsulate and relies on a GW to encrypt and all 
members/receivers can decapsulate IPsec on their own.  In the second 
case, a GW decapsulates for some or all members.  Finally a 
combination of the two.

Would there be implications on the GW to join the multicast in the 
reception case?

It would also be worthwhile to have before and packet headers as in 
4302 and 4303.

Would header compression be possible, given that the inner and outer 
headers might be the same?

>4.0 Security Association
>
>4.1 Major IPsec Databases
>
>    The following sections describe the GKMP Subsystem and IPsec
>    extension interactions with the major IPsec databases. Major IPsec
>    databases need to be expanded in order to fully support multicast.
>
>4.1.1 Security Policy Database (SPD)

><snip>

>    SPD entries created by a GCKS may be assigned identical SPIs to SPD
>    entries created by IKEv2 [RFC4306]. This is not a problem for the
>    inbound traffic as the appropriate SAs can be matched using the
>    algorithm

State the section number to avoid ambiguity.

>described in RFC 4301. In addition, SAs with identical SPI
>    values but not manually keyed can be differentiated because they
>    contain a link to their parent SPD entries. However, the outbound
>    traffic needs to be matched against the SPD selectors so that the
>    appropriate SA can be created on packet arrival. IPsec
>    implementations that support multicast SHOULD use the destination

Why not MUST?  Please state the exceptions to the SHOULD if there are any.

>    address as the additional selector and match it against the SPD
>    entries marked "sender only".
>
>4.1.2 Security Association Database (SAD)
>
>    The Security Association Database (SAD) can support multicast SAs, if
>    manually configured. An outbound multicast SA has the same structure
>
>Weis, et al.             Expires August, 2006                 [Page 7]
>
>Internet-Draft     Multicast Extensions to RFC 4301         June, 2005
>
>
>    as a unicast SA. The source address is that of the sender and the
>    destination address is the multicast group address. An inbound,
>    multicast SA must be configured with the source addresses of each
>    peer authorized to transmit to the multicast SA in question. The SPI
>    value for a multicast SA is provided by a GCKS, not by the receiver,
>    as for a unicast SA. This is similar to the unicast case and does not
>    require changes to SAD.
>    However, the SPD needs a mechanism for automatic multicast SA
>    creation.

The above text seems like the text in 4301.  Is this a placeholder?

>4.1.3 Peer Authorization Database (PAD)

><snip>

>    The PAD MUST provide a management interface capability that allows an
>    administrator to enforce that the scope of a GKMP group's policy
>    specified SPD/SAD modifications are restricted to only those traffic
>    data flows that belong to that group. This authorization MUST be
>    configurable at GKMP group granularity. In the inverse direction, the
>    PAD management interface MUST provide a mechanism(s) to enforce that
>    IKEv2 security associations do not negotiate traffic selectors that
>    conflict or override GKMP group policies. An implementation SHOULD
>    offer PAD configuration capabilities that authorize the GKMP policy
>    configuration mechanism to set security policy for other aspects of
>    an endpoint's SPD/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 am not sure about the normative language above.  I looked at the 
PAD stuff in 4301 and normative language was used quite 
sparingly.  We should probably discuss this more.

>
>
>   - The Group Speaker's "trailing edge" SA is the oldest security
>      association in use by the group for that speaker. All authorized
>      Group Members can receive and decrypt data for this SA, but the
>      Group Speaker does not transmit new data using the "trailing edge"
>      SA after it has transitioned to the "leading edge GSA". The
>      trailing edge SA is deleted by the group's endpoints according to
>      group policy (e.g., after a defined period has elapsed)"

So by this, may I assume that multiple (more than two) IPsec SAs are 
allowed to exist simultaneously?

<snip>

>Implementations MAY offer a Group
>    Owner management interface option to enable/disable re-key rollover
>    continuity for a particular group This specification requires that a

Missing a period above.

>    GKMP/IPsec implementation MUST support at least two concurrent GSA
>    per Group Speaker and this re-key rollover continuity algorithm.

I see that you are mandating the existence of multiple simultaneous 
IPsec SAs.  Please make it a SHOULD.  I know of at least one use case 
where rekeying would involve stopping transmission/reception and 
restarting after a new SA has been established.

>4.2 Data Origin Authentication
>
>    As defined in [RFC3401], data origin authentication is a security
>    service that verifies the identity of the claimed source of data.
>    While HMAC authentication methods are often used to provide data
>    origin authentication, they are not sufficient to provide data origin
>    authentication for groups. With an HMAC, every group member can use
>    the HMAC key to create a valid authentication tag whether or not they
>    are the authentic origin.
>
>    When the property of data origin authentication is required for an
>    IPsec SA distributed from a GKCS, an authentication transform where
>    the originator keeps a secret should be used. Two possible algorithms
>    are TESLA [RFC4082] or RSA [RFC4359].
>
>    In some cases, (e.g., digital signature authentication transforms)
>    the processing cost of the algorithm is significantly greater than an
>    HMAC authentication method. To protect against denial of service
>    attacks from device that is not authorized to join the group, the
>    IPsec SA using this algorithm may be encapsulated with an IPsec SA
>    using an HMAC authentication algorithm. However, doing so requires
>    the packet to be sent across the IPsec boundary for additional
>    inbound processing [RFC4301, Section 5.2].

Not sure I understand the last two sentences.  Please explain.  I can 
appreciate the use of two auth tags, but not the concept of two IPsec 
SAs to do so.

>4.3 Group SA and Key Management
>
>4.3.1 Co-Existence of Multiple Key Management Protocols

><snip>

>4.3.2 New Security Association Attributes
>
>    A number of new security association attributes are defined in this

Two, really!

>    document. Each GKMP supporting this architecture MUST support the
>    following list of attributes described elsewhere in this document.
>
>    - Address Preservation (Section 3.1). This attribute describes
>    whether address preservation is to be applied to the SA on the source
>    address, destination address, or both source and destination
>    addresses.
>
>    - Direction attribute (Section 4.1.1). This attribute describes
>    whether the SPD direction is to be symmetric, receiver only, or
>    sender only.

Why are these listed again?

>5.0 IP Traffic Processing
>
>    Processing of traffic follows [RFC4301, Section 5], with the
>    additions described below when these IP multicast extensions are
>    supported.

All of this probably belongs earlier.  I have asked earlier about hdr 
removal when the inner and outer addresses are the same.  That was 
proposed elsewhere and perhaps should be considered here.
<snip>

>6.0 Networking Issues
>
>
>
>Weis, et al.             Expires August, 2006                [Page 12]
>
>Internet-Draft     Multicast Extensions to RFC 4301         June, 2005
>

I ran out of steam here.  I will do the rest some other time (may be 
tomorrow or something). 

_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec

---

From: George Gross <[email-masked]>
Date: Thu, 15 Jun 2006 05:23:00 -0400 (EDT)

Hi Lakshminath,

thank you for taking the time to review the draft. in the interest of
clarity, I'd like to suggest that we split our responses into separate
threads, each with their own subject line. Brian, Dragan, and I will
confer about our replies, and then post to the list. plz stay tuned...

br
	George

---

From: Brian Weis <[email-masked]>
Date: Thu, 15 Jun 2006 11:15:57 -0700

Hi Lakshminath,

Thanks for the detailed review! I'll do a quick pass over them and we'll 
come up with answers ASAP. Quick comment on the GKMP acronym -- I don't 
think we knew it referred to a particular protocol and can easily change 
it I imagine.

Thanks,
Brian

Lakshminath Dondeti wrote:
 > Hi all,
 >
 > [Disclaimer: Reviewing as an MSEC contributor.  Ran or I will have to do
 > a "WG chair" review some time before forwarding this to the IESG.]
 >

---

From: "Dan Bernardo" <[email-masked]>
Date: Sat, 17 Jun 2006 22:01:04 +1000

Hi,
My company is in the process of implementing mltcast, but am not sure what 
the security issues/limitations around it.
I am following this draft closely, but could not find the org draft.
Can someone point/send me  the org draft, relating to security issues in 
running multicast?

Regards,
Dan
 ----- Original Message ----- 
From: "Lakshminath Dondeti" <[email-masked]>
To: "Brian Weis" <[email-masked]>; "George Gross" <[email-masked]>; 
"Ignjatic, Dragan" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, June 15, 2006 8:04 PM
Subject: [MSEC] Review of draft-ietf-msec-ipsec-extensions-01

> Hi all,
>
> [Disclaimer: Reviewing as an MSEC contributor.  Ran or I will have to do a 
> "WG chair" review some time before forwarding this to the IESG.]
>
> I reviewed the first 5 sections.  You have a lot of stuff on NATs and NATs 
> are boring to me.  I will review that some other time.
>
> Lakshminath
>
> I think the last sentence needs to be revised.  If 4301 supports security 
> services for manually configured IP multicast, perhaps this draft 
> specifies dynamically keyed multicast security services using IPsec?  What 
> else?
>
>><snip>
>
>
>>Table of Contents
>>
> Is NAT the only issue?  If so, I suggest moving 6.1 up to 6.0 level.  I 
> guess more on this in the actual text.
>
> Really?  I am surprised that you are covering anycast.  Will look for more 
> details later in the I-D.
>
> I am trying to get you to delete the use of GKMP and the notion of GKMP as 
> a keyword in this document.
>
> groups would require that all members (or receivers) to join the group via 
> IGMP and request GSA from the GCKS.  So, I don't think it really depends 
> on the IP multicast destination (address?) per se.  How about something 
> like "members of a secure group?"
>
>
> Why not use the notion of GSA with the third SA, the Data security SA, 
> being the IPsec SA?  4046 would be a good guide there.
>
>
>>    Group Member
> 4291 IPv6 addressing architecture and 2375 are additional references to 
> include here.
>
>
> Your sentence below is more precise than the one above.  I think device 
> level information is not kept, instead the presence of absence of 
> receivers (one is as good as a thousand) on an interface basis is 
> maintained.
>
> I can appreciate the requirement, I think.  If I am not mistaken, wouldn't 
> there be three cases here?  There could be a sender which cannot IPsec 
> encapsulate and relies on a GW to encrypt and all members/receivers can 
> decapsulate IPsec on their own.  In the second case, a GW decapsulates for 
> some or all members.  Finally a combination of the two.
>
> It would also be worthwhile to have before and packet headers as in 4302 
> and 4303.
>
> I am not sure about the normative language above.  I looked at the PAD 
> stuff in 4301 and normative language was used quite sparingly.  We should 
> probably discuss this more.
>
>
>>
>>
> I see that you are mandating the existence of multiple simultaneous IPsec 
> SAs.  Please make it a SHOULD.  I know of at least one use case where 
> rekeying would involve stopping transmission/reception and restarting 
> after a new SA has been established.
>
>
>
> appreciate the use of two auth tags, but not the concept of two IPsec SAs 
> to do so.
>
>
> _____________________________________________________
> This mail has been virus scanned by Australia On Line
> see http://www.australiaonline.net.au/mailscanning
>

---

From: George Gross <[email-masked]>
Date: Mon, 19 Jun 2006 08:58:20 -0400 (EDT)

Hi Dan,

inline below...

> I am following this draft closely, but could not find the org draft.

I'm not sure I know what you mean by "org draft" ;o(

> Can someone point/send me  the org draft, relating to security issues in

For an overview of the secure multicast architecture, I'd suggest RFC3740.

To better understand group key management, please take a look at RFC4046.

If you'd like to get background on IP security, then RFC4301 and its
kindred documents.

To rumage through all of the prior IETF MSEC and IRTF GSEC presentations
and to get other links, I'd recommend www.securemulticast.org.

hth,
	George

---

From: George Gross <[email-masked]>
Date: Mon, 19 Jun 2006 11:58:34 -0400 (EDT)

Hi Lakshminath,

this e-mail focuses on your comment regarding the GKMP acronym. future
e-mails will respond wrt/ to other your comments.

inline below....

<snip until first occurance of GKMP acronym>

> Perhaps IPsec with GSAs or something like that is more generic?

To align with RFC4046, we will edit the MSEC IPsec extensions document to
use either the term "GKM protocol" or "GKM subsystem" as appropriate.
Note that RFC4046 defines the acronym "GKM" in its section 1. We will also
add a qualifying sentence to say that "GKM protocol" is a generic term,
not intended to refer to any particular group key management protocol.

br,
	George

---

From: "Dan Bernardo" <[email-masked]>
Date: Tue, 20 Jun 2006 07:52:44 +1000

Thanks George,,,
org draft = original draft ;-)

Will check out the RFC's recommended.

ta
Dan

----- Original Message ----- 
From: "George Gross" <[email-masked]>
To: "Dan Bernardo" <[email-masked]>
Cc: "Brian Weis" <[email-masked]>; "George Gross" <[email-masked]>; 
"Ignjatic, Dragan" <[email-masked]>; "Lakshminath Dondeti" 
<[email-masked]>; <[email-masked]>
Sent: Monday, June 19, 2006 10:58 PM
Subject: Re: [MSEC] Review of draft-ietf-msec-ipsec-extensions-01

>> > do a
>> > NATs
>> >>                                                     IdentAware 
>> >> Security
>> >>                                                             D. 
>> >> Ignjatic
>> >>                                                          February, 
>> >> 2006
>> > security
>> >>1.0 
>> >>Introduction.......................................................2
>> >>   1.1 
>> >> Scope............................................................3
>> >>   1.2 
>> >> Terminology......................................................3
>> >>2.0 Overview of IP Multicast 
>> >>Operation.................................5
>> >>3.0 Security Association 
>> >>Modes.........................................5
>> >>   3.1 Tunnel Mode with Address 
>> >> Preservation............................6
>> >>4.0 Security 
>> >>Association...............................................7
>> >>   4.1 Major IPsec 
>> >> Databases............................................7
>> >>   4.2 Data Origin 
>> >> Authentication......................................11
>> >>   4.3 Group SA and Key 
>> >> Management.....................................11
>> >>5.0 IP Traffic 
>> >>Processing.............................................12
>> >>6.0 Networking 
>> >>Issues.................................................12
>> >>   6.1 Network Address 
>> >> Translation.....................................13
>> >>7.0 Security 
>> >>Considerations...........................................19
>> >>8.0 IANA 
>> >>Considerations...............................................19
>> >>9.0 
>> >>Acknowledgements..................................................19
>> >>10.0 
>> >>References.......................................................19
>> >>   10.1 Normative 
>> >> References...........................................19
>> >>   10.2 Informative 
>> >> References.........................................20
>> >>   A.1 Unidirectional Multicast 
>> >> Applications...........................22
>> >
>> > Is this mcast only?
>> >
>> >>   A.3 Any-To-Any Multicast 
>> >> Applications...............................23
>> >
>> > Multi-sender mcast?
>> >
>> >>Author's 
>> >>Address......................................................24
>> >>Intellectual Property 
>> >>Statement.......................................25
>> >>Copyright 
>> >>Statement...................................................25
>> >>
>> >>1.0 Introduction
>> >>
>> > wouldn't
>> > 4302
>> > IPsec
>> > SAs

---

From: George Gross <[email-masked]>
Date: Mon, 26 Jun 2006 07:11:07 -0400 (EDT)

Hi Laksminath,

Brian, Dragan, and I have worked off-list the last week to accomodate many
of your comments and also some issues that we detected as co-authors. we
have issued a v02 of the ID that will publish shortly. although we felt we
could revise the text to reflect your feedback in most cases, there were
some instances where we need to follow up with discussion or clarifying
questions. for these, we could introduce any additional revisions in v03
after the Montreal IETF.

I will spin off a few e-mails shortly for those of your comments that we
have a need to discuss/clarify....

br,
    George

---

From: George Gross <[email-masked]>
Date: Mon, 26 Jun 2006 07:41:08 -0400 (EDT)

Hi Lakshminath,

as promised, the first of several topic specific e-mails...

<snip for brevity>

> case, a GW decapsulates for some or all members.  Finally a

We could easily get tangled up in explaining the many use cases. This
section really should only define the semantics, not the use cases. If you
think the use cases need to be identified, I would suggest that you
prepare some text that we can put into an appendix.

> Would there be implications on the GW to join the multicast in the

Clearly, the decapsulating security gateway has to be either a multicast
router or IGMP proxy or multicast leaf node for the multicast group in
order to receive the data stream. are you saying we should explicitly say
that?

> It would also be worthwhile to have before and packet headers as in

maybe we can add this into v03.

> headers might be the same?

Compression was identified as an SA attribute in RFC2407, but RFC4301 only
briefly mentions compression in section 3.1. Does the compression that you
are talking about resemble Nikander's proposed BEET mode?

In any case, there is nothing in RFC4301 that would stop a GKM protocol
from negotiating tunnel mode header compression, but that would be a
separate and future specification from this one.

br,
	George

---

From: George Gross <[email-masked]>
Date: Mon, 26 Jun 2006 08:14:51 -0400 (EDT)

Hi Lakshminath,

<snip>
> allowed to exist simultaneously?

Yes.

> >    continuity for a particular group This specification requires that a

ok.

> restarting after a new SA has been established.

The rekey rollover algorithm is a fairly fundemental MSEC inter-op
requirement.  Unlike a pair-wise unicast SA that negotiate policies, we
are constrained to support only homogeneous groups (unless you consider
moving composite groups back into the MSEC IPsec draft).

If even one endpoint does not implement the rekey rollover algorithm, then
the performance of the whole group is degraded because we are forced to
either saddle the group with the handicap of the least common denominator
or else exclude those candidate members who don't implement the SHOULD.

The use case you cite is at odds with the major motivation for MSEC IPsec
service, continous reliable real-time delivery of secured content.
Interrupting that delivery by dropping packets or stopping packet
transmission for the duration of a rekey operation would preclude
multi-vendor support of the reliable real-time service objective.

br,
	George