Source-Specific Multicast for IP
draft-ietf-ssm-arch-07

IANA follow-up comments:
Upon approval, we understand this document to update the references for SSM block at the following:
http://www.iana.org/assignments/multicast-addresses
IANA will also add an entry in the following registry to document the IPv6 SSM range:
http://www.iana.org/assignments/ipv6-multicast-addresses

[Ballot comment]
Overall, I am happy with the update.  There is a cut-and-paste problem at
the end of the first paragraph in section 7.2.  The meaning is unclear.

[Ballot discuss]
Picking up Harald's DISCUSS asking for an important clarification:

4.1, top of page 7 - This section makes me think ASM listeners won't
  be able to listen to SSM traffic, but the document doesn't
  explicitly say so, one way or the other. It's a little less vague on
  SSM listeners and ASM traffic, but could be clearer here, too.

[Ballot comment]
From Pekka Savola, OPS directorate:

From 'high view', I think this is OK.  The comments in the tracker
need to be taken into account.  SSM is already out there, and many
other related specs already specify a lot of the same things that this
spec does, but from a different perspective.

As a bigger comment:

As a matter of fact, IMHO a lot clarity problems that seem to have
come up from those who first read the spec stem from the fact that the
specification has been distributed in a large number of documents, and
there is substantial overlap.  At least these deal with SSM:

- 'ssm overview', RFC 3569
- 'ssm architecture', this document
- draft-ietf-mboned-ssm232-08.txt [rfc ed queue]
- draft-holbrook-idmr-igmpv3-ssm-08.txt [rfc ed queue]
- [ draft-ietf-pim-sm-v2-new ]

For example, draft-ietf-mboned-ssm232-08.txt specifies much better how
the hosts and routers should treat with ASM inside the SSM prefix.
I think the reasoning has been that the architecture describes the
generic architecture, and protocols or address ranges are described in
other documents as they might change a bit more, but I don't think
this has entirely successful, because the architecture has ended up
also discussing the protocols and numbers a lot, which was not the
original intent AFAICS.

I'm not sure how to fix this properly, and whether it's even worth
fixing up properly, but one option (if it's deemed useful, personally
this might be beyond the point of diminishing returns already) might
be using more normative references to the abovementioned specs, and
making this spec as barebones as reasonable.

...

It has been at least a year since I last looked at this, and only
skimming now, two comments:

4.3.  Allocation of Source-Specific Multicast Addresses

The SSM destination address 232.0.0.0 is reserved, and a system MUST
NOT send a datagram with a destination address of 232.0.0.0.

==> this seems bogus and should probably be removed.  We don't
restrict hosts from sending packets to address 0.0.0.0, 224.0.0.0 or a
number of other clearly invalid addresses either, but this seems to be
wrong place to specify that such transmissions must be prevented.
And how would that even be implemented -- should the hosts be able to
send packets to 232.0.0.0 using raw sockets?

As a suggestion, just say:

The SSM destination address 232.0.0.0 is reserved, and it must not be
used as a destination address.

...

A host operating system SHOULD provide an interface to allow an
application to request a unique allocation of a channel destination
address in advance of a session's commencement, and this allocation
database SHOULD persist across host reboots.

==> a worthy goal, but I don't know any implementation which is
providing such an interface.. well, this stuff can probably be removed
if this spec is ever pushed forward to draft standard..

nits:

- there are a large number of improperly used uppercase keywords
- s/RFC2373/RFC3513/
- s/FF3x:3FFF:FFFF/FF3x::3FFF:FFFF/

[Ballot comment]
Thoughout the document: s/IPSec/IPsec/

  In the Abstract and in the Introduction:
    s/IP addresses in the 232/IP version 4 (IPv4) addresses in the 232/

[Ballot discuss]
Section 7.1 does not reflect the compromise worked out between the
  MSEC WG and the IPsec WG.  Please review draft-ietf-ipsec-rfc2401bis-03,
  especially sections 4.1, 4.4.1.1, 4.4.2, and 4.6.  Explicit provisions
  for multicast SA lookup added a long time ago (at least a year ago).
  Steve Kent has provided this extract from the most recent versions of
  AHbis, ESPbis, and 21401bis, with protocol-specific references removed:

    In many secure multicast architectures, e.g., [RFC3740], a central
    Group Controller/Key Server unilaterally assigns the group security
    association's SPI. This SPI assignment is not negotiated or
    coordinated with the key management (e.g., IKE) subsystems that
    reside in the individual end systems that comprise the group.
    Consequently, it is possible that a group security association and a
    unicast security association can simultaneously use the same SPI. A
    multicast-capable IPsec implementation MUST correctly de-multiplex
    inbound traffic even in the context of SPI collisions.

    Each entry in the Security Association Database (SAD) [Ken-Arch] must
    indicate whether the SA lookup makes use of the destination, or
    destination and source, IP addresses, in addition to the SPI. For
    multicast SAs, the protocol field is not employed for SA lookups. For
    each inbound, IPsec-protected packet, an implementation must conduct
    its search of the SAD such that it finds the entry that matches the
    "longest" SA identifier. In this context, if two or more SAD entries
    match based on the SPI value, then the entry that also matches based
    on destination, or destination and source, address comparison(as
    indicated in the SAD entry) is the "longest" match. This implies a
    logical ordering of the SAD search as follows:

          1. Search the SAD for a match on {SPI, destination
              address, source address}. If a SAD entry
              matches then process the inbound packet with that
              matching SAD entry. Otherwise, proceed to step 2.

          2. Search the SAD for a match on {SPI, destination
              address}. If the SAD entry matches then
              process the inbound packet with that matching SAD
              entry. Otherwise, proceed to step 3.

          3. Search the SAD for a match on only {SPI} if the receiver
              has chosen to maintain a single SPI space for AH and ESP,
              or on {SPI, protocol} otherwise. If an SAD
              entry matches then process the inbound packet with
              that matching SAD entry. Otherwise, discard the packet
              and log an auditable event.

    The indication of whether source and destination address matching is
    required to map inbound IPsec traffic to SAs MUST be set either as a
    side effect of manual SA configuration or via negotiation using an SA
    management protocol, e.g., IKE or GDOI [RFC3547]. Typically, Source-
    Specific Multicast (SSM) [HC03] groups use a 3-tuple SA identifier
    composed of an SPI, a destination multicast address, and source
    address. An Any-Source Multicast group SA requires only an SPI and a
    destination multicast address as an identifier.

[Ballot discuss]
Section 7.1 does not reflect the compromise worked out between the
  MSEC WG and the IPsec WG.  Please review draft-ietf-ipsec-rfc2401bis-03,
  especially sections 4.1, 4.4.1.1, 4.4.2, and 4.6.  Explicit provisions
  for multicast SA lookup added a long time ago (at least a year ago).
  Steve Kent has provided this extract from the most recent versions of
  AHbis, ESPbis, and 21401bis, with protocol-specific references removed:

  In many secure multicast architectures, e.g., [RFC3740], a central
  Group Controller/Key Server unilaterally assigns the group security
  association's SPI. This SPI assignment is not negotiated or
  coordinated with the key management (e.g., IKE) subsystems that
  reside in the individual end systems that comprise the group.
  Consequently, it is possible that a group security association and a
  unicast security association can simultaneously use the same SPI. A
  multicast-capable IPsec implementation MUST correctly de-multiplex
  inbound traffic even in the context of SPI collisions.

  Each entry in the Security Association Database (SAD) [Ken-Arch] must
  indicate whether the SA lookup makes use of the destination, or
  destination and source, IP addresses, in addition to the SPI. For
  multicast SAs, the protocol field is not employed for SA lookups. For
  each inbound, IPsec-protected packet, an implementation must conduct
  its search of the SAD such that it finds the entry that matches the
  "longest" SA identifier. In this context, if two or more SAD entries
  match based on the SPI value, then the entry that also matches based
  on destination, or destination and source, address comparison(as
  indicated in the SAD entry) is the "longest" match. This implies a
  logical ordering of the SAD search as follows:

          1. Search the SAD for a match on {SPI, destination
              address, source address}. If a SAD entry
              matches then process the inbound packet with that
              matching SAD entry. Otherwise, proceed to step 2.

          2. Search the SAD for a match on {SPI, destination
              address}. If the SAD entry matches then
              process the inbound packet with that matching SAD
              entry. Otherwise, proceed to step 3.

          3. Search the SAD for a match on only {SPI} if the receiver
              has chosen to maintain a single SPI space for AH and ESP,
              or on {SPI, protocol} otherwise. If an SAD
              entry matches then process the inbound packet with
              that matching SAD entry. Otherwise, discard the packet
              and log an auditable event.

  The indication of whether source and destination address matching is
  required to map inbound IPsec traffic to SAs MUST be set either as a
  side effect of manual SA configuration or via negotiation using an SA
  management protocol, e.g., IKE or GDOI [RFC3547]. Typically, Source-
  Specific Multicast (SSM) [HC03] groups use a 3-tuple SA identifier
  composed of an SPI, a destination multicast address, and source
  address. An Any-Source Multicast group SA requires only an SPI and a
  destination multicast address as an identifier.

[Ballot discuss]
Section 7.1 does not reflect the compromise worked out between the
  MSEC WG and the IPsec WG.  Please review draft-ietf-ipsec-rfc2401bis-03,
  especially sections 4.1, 4.4.1.1, 4.4.2, and 4.6.

[Ballot comment]
Some other groups (RMT is one) have been eagerly awaiting this.  It's clear and well-written.
I hope that the IESG discussion will resolve with clarity.  If it would be helpful to have some RMT
developers who depend on this technology, and intend to use it security features, participate
in any discussions, let me know.

[Ballot comment]
Reviewed by Spencer Dawkins, Gen-ART

His review:

This document is on the right track, but is still a couple of stops
from the end of the line :-)

Introduction - The first four paragraphs aren't appropriate for an
Introduction - they are fine, but they should be in a following
section, by themselves. The fifth paragraph begins a high-level
description and justification of SSM - THAT'S what an Introduction
should look like.

4.1, top of page 7 - This section makes me think ASM listeners won't
  be able to listen to SSM traffic, but the document doesn't
  explicitly say so, one way or the other. It's a little less vague on
  SSM listeners and ASM traffic, but could be clearer here, too.

4.3 - No justification of the MUST NOT for 232.0.0.0. In general, the
      justifications in this section are weak, missing, or separated
      from specific requirements. I'm sure the authors understand all
      this stuff; the goal is that people who DIDN'T write the
      document will know how to extend it in the future.

7.1 - points out that SSM can break in the presence of SPI collisions
      by two senders, but doesn't say whether either senders or
      receivers can detect this condition automatically - they promise
      a solution, but don't describe the ability of participants to
      identify the problem in the meanwhile.

7.1 and 7.3 call out AH - my impression is that the use of AH in
    standards-track protocols is almost non-existent, and Steve
    Bellovin keeps telling me that there's no reason for AH. Probably
    good if these sections aren't too dependent on AH.

7.2 Not sure where "A router MAY have a configuration option to allow
    source routing" came from - I think this is actually an
    unintentional use of capitals; surely router requirements for
    source routing support aren't being specified in the security
    considerations section of SSM :-)

8 is called "Transition Considerations". What's the vision here -
coexistence or transition from ASM to SSM? Is it the same vision in
IPv4 and IPv6?

[Ballot discuss]
I believe the lack of clarity Spencer noted about ASM/SSM deserves to be addressed. Either it should be known to work or it should be known to not work.

Spencer said:

4.1, top of page 7 - This section makes me think ASM listeners won't
  be able to listen to SSM traffic, but the document doesn't
  explicitly say so, one way or the other. It's a little less vague on
  SSM listeners and ASM traffic, but could be clearer here, too.

His other comments are worth thinking about, but I don't think they should be blocking.

[Ballot discuss]
The discussion of IPsec in Section 7.1 appears to be incorrect.  Senders do not chose or allocate SPIs; rather, SPIs are chosen by the "owner" of the destination address; the owner then informs the sender.  In the unicast world, that's easy;  In the multicast world, the owner would be whoever allocated the multicast group address.  The real question here is how the multicast SA is set up.

AD-review comments posted on Apr-13-2004:

Generally the document is in a great shape. Very good job. I have one meta
issue and one editorial nit.

Meta:

The document does not spell out what protocols hosts and routers MUST
implement. I.e., this kind of document is expected to specify the
mandatory-to-implement mechanisms that will ensure that hosts and routers can
interoperate. However, there is no place in the document where it says
something like "hosts supporting the SSM network service MUST implement IGMPv3
for IPv4 and MLDv2 for IPv6", or "routers supporting the SSM network service
MUST implement PIM-SSM..."

Editorial

The following part:

> 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 [RFC 2119].

should be moved inside the body of the document (preferably not in Abstract)

Abstract:

> IP addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are
> designated as source-specific multicast (SSM) destination addresses and
> are reserved for use by source-specific applications and protocols.  For
> IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for
> source-specific multicast use.  It defines an extension to the Internet
                                  ^^
                                needs to be expanded. "This document" ?


Section "Intellectual Property Rights Notice". To reflect the situation
with Apple, this section also needs to include the following paragraph
from RFC 2026.

        "The IETF has been notified of intellectual property rights
        claimed in regard to some or all of the specification contained
        in this document.  For more information consult the online list
        of claimed rights."