Multicast Extensions to the Security Architecture for the Internet Protocol
RFC 5374

Note: This ballot was opened for revision 09 and is now closed.

(Tim Polk) Yes

(Jari Arkko) No Objection

Comment (2007-12-19 for -)
No email
send info
> A security gateway implementation of IPsec using the multicast
> extensions MUST use a tunnel mode SA, for the reasons described in
> Section 4.1 of [RFC4301]. In particular, the security gateway
> needs to use tunnel mode to encapsulate incoming fragments, since
> IPsec cannot directly operate on fragments.

Is there something specific to multicast about this requirement? RFC 4301 already requires the use of tunnel mode except in two special circumstances.

(Ross Callon) No Objection

(Lisa Dusseault) (was No Record, No Objection) No Objection

(Lars Eggert) (was No Record, No Objection) No Objection

Comment (2007-12-18 for -)
No email
send info
Section 1., paragraph 2:
>    This document describes extensions to RFC 4301 that further define
>    the IPsec security architecture for groups of IPsec devices to
>    share SAs.

  Seems like it should update 4301.

(Russ Housley) (was Discuss) No Objection

(Chris Newman) (was Abstain) No Objection

(Jon Peterson) No Objection

(Mark Townsley) No Objection

Magnus Westerlund (was Discuss) No Objection

Comment (2008-01-10)
No email
send info
3. Section

  "In a transport mode multicast application GSA, the UDP checksum 
   operation requires the origin endpoint's IP address to complete 
   successfully. In IKEv2, this information is obtained from the 
   Traffic Selectors associated with the exchange [RFC4306, Section 
   2.23]. See also reference [RFC3947]. A facility that obtains the 
   same result needs to exist in a GKM protocol payload that defines 
   the multicast application GSA attributes for each Group Sender. "

It is good that this issue is brought up. In fact the NAT discussion section is really good. However, I think it might be beneficial to be even more blunt and say something like: "Unless the GKM has the facility the usage of transport mode is impossible across any NAT." But that may in any fact be a mote point in regards to (un)likely it is to get ESP in transport mode to traverse a NAT anyway. 

I am supportive of Sam's abstain and unless things are improved I will go to abstain when my Discuss has been resolved.

(Sam Hartman) Abstain

Comment (2008-01-07 for -)
No email
send info
This is a strong abstain; I am asking other IESG members to consider
my comments and enter abstain or discuss positions if they agree.  I'm
also asking Tim to review whether he believes a yes vote is
appropriate.  The main reason I'm not entering a discuss is that I don't think I'll be on the IESG long enough to resolve it and I'm not sure there is a lot of energy left in msec.  My opinion is that having no document in this space would be better than publishing this spec.

My main problem is that RFc 4301 has a fairly detailed conceptual
model.  This document updates that model without sufficient clarity to
preserve the properties of the model.  I think having formal models
that are ignored in future specs  is one of the worst things we can do.  If we really believe that the level of detail in this document is what we want to see from future IPsec documents then we should deprecate the model in RFC 4301 and accept that implementations will provide rather different services using the IPsec wire protocols many of which do not meet the security requirements we hoped for out of the IPsec suite.  That path is not my preference, although it is far preferable in my mind to approving this document without making it clear that we have abandoned the RFC 4301 model.

My specific concern is that RFC 4301 specifies several data structures
including the SPD, PAD and specifies processing rules that use these
data structures.  With some carefully explained exceptions, the data
structures in RFC 4301 provide the necessary inputs and describe the
state needed for the algorithms in RFC 4301.  That is not true of the
changes proposed in this document.  For example one of the attributes
of a SA (and presumably security policy that triggers creation of an
SA) is whether the tunnel preserves addresses.  However neither the
sections describing the changes to the SAD or SPD actually note this new  information.  Other parts of the document do note that it needs to be kept track of.  Text in the document suggests that this is actually only a property of the GKM state and does not affect the IPsec machineary.  That seems incorrect to me: the SPD drives the GKM  and the SAD needs to give the IPsec implementation the necessary data to actually send ESP packets.

The description of PAD changes is even more confused.  In RFC 4301 the PAD is a ordered list  of authorized  peers.  It's not clear to me that  is true here.  It seems that this text envisions a PAD  that describes multicast groups more than specific authorized peers or groups of peers.  It's not clear to me that's even the same database  as contemplated by RFC 4301.  

How do address preserving tunnels interact with  SA selection when SAs are indexed by destination or source address?

Appendix A seems problematic.  It has a lot of normative statements
for an appendix.

(Cullen Jennings) Abstain

Comment (2008-03-05 for -)
No email
send info
I find Sam's arguments here pretty convincing. The RFC 4301
architecture was pretty carefully crafted, and trying to 
rebuild it in flight seems like it needs to be done very

(Dan Romascanu) Abstain

(David Ward) Abstain