Multicast Extensions to the Security Architecture for the Internet Protocol
draft-ietf-msec-ipsec-extensions-09

[Ballot comment]
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
carefully.

[Ballot discuss]
Steve Kent has expressed concerns in several areas.  Brian Weis and
  Steve have been discussing them, but they have not reached closure
  yet.  Steve's concerns include:
 
  - The need to support a potentially unbounded set of source addresses
    in an multicast SAD entries.

  - Whether IGMP/MLD messages that might trigger creation of a multicast
    SA are themselves authenticated.

  - Normative statements regarding directionality and GSDP-I/O.

[Ballot comment]
3. Section 6.3.3.6:

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

[Ballot discuss]
1. Section 2.

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

To my knowledge the basic definition of multicast packets would imply only that they are IP packets. When it comes to general IETF defined transport protocols the only one that really work is UDP. But there are no limiation to only use UDP. In addition NORM is not providing datagram level reliable delivery, it is providing bulk data or stream level reliability.

2. It is also evident that this document will update RFC 4301 as it breaks normative language in RFC 4301. For example in Section 4.1 of RFC 4301:
  "If an IPsec implementation supports
  multicast, then it MUST support multicast SAs using the algorithm
  below for mapping inbound IPsec datagrams to SAs."

I think this is clearly related to Russ discuss and also Sam's abstain. There need to be clear what changes it does to the IPsec model and already existing procedures.

[Ballot discuss]
1. Section 2.

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

To my knowledge the basic definition of multicast packets would imply only that they are IP packets. When it comes to general IETF defined transport protocols the only one that really work is UDP. But there are no limiation to only use UDP. In addition NORM is not providing datagram level reliable delivery, it is providing bulk data or stream level reliability.

2. It is also evident that this document will update RFC 4301 as it breaks normative language in RFC 4301. For example in Section 4.1 of RFC 4301:
  "If an IPsec implementation supports
  multicast, then it MUST support multicast SAs using the algorithm
  below for mapping inbound IPsec datagrams to SAs."

I think this is clearly related to Russ discuss and also Sam's abstain. There need to be clear what changes it does to the IPsec model and already existing procedures.

[Ballot discuss]
This document is well written, but it has two types of problems.
  First, there are places where it is not well aligned with RFC 4301.
  Second, the extensions to RFC 4301 are not specified in sufficient
  detail to ensure interoperability.

  Section 3.1: the discussion of the PFP (populate from packet) flag is
  not aligned with the description in RFC 4301.  Also, it is unclear
  whether the described mechanism is applied for all multicast protocols
  or just some of them.  If it is not all of them, the architecture
  must tell how to figure out which ones.

  Section 4.1.1: the description of how the SPD is extended to become
  the GSPD is unclear.  Also, the description of how to distinguish
  inbound multicast and unicast traffic is not consistent with use of
  the decorrelated SPD model defined in RFC 4301, even though it
  appears to rely on that model everywhere.

  Section 4.1.1: is the intent that receipt of an inbound, multicast
  IPsec packet will trigger creation of an SA.  This is not the case
  for unicast packets to avoid possible DoS attacks.

  Section 4.1.3.1: the description of the PAD does not match my
  understanding of RFC 4301.

  Section 4.1.3.1: the extensions to the PAD need further specification.
  The PAD needs to be the linkage between the SPD and the key management
  protocol.  Since this document does not specify a particular key
  management protocol, the linkage is insufficient.  It may be the case
  that a key management protocol (like GSAKMP) must be selected to
  resolve this concern.  Also, creating a PAD entry for a group owner
  seems to create a need for a more extensive set of controls in the PAD.
  For example, what keeps one group owner from interfering with the
  authorized actions of other group owners?

  Section 4.2.1: the discussion explains why an implementation needs to
  to support multiple SAs for the same traffic during a re-key to allow
  clean migration, but not a specification for an implementer.  Also,
  alludes to critical timers without telling the origin of the timer
  values.

  Section 4.2.2: it is unclear whether the new entry attributes for SAs
  are for both SPD and SAD entries, only SPD entries, or only SAD
  entries.

  Sections 5: this section needs to describe precise changes to the
  algorithms from RFC 4301, perhaps by replicating that text and
  highlighting the differences.

[Ballot comment]
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.

[Ballot comment]
> 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.

[Ballot comment]
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.