Subject: [ssm] short last call (again) for draft-ietf-ssm-arch-03.txt

From: Hugh Holbrook <[email-masked]>
Date: Thu, 8 May 2003 13:32:37 -0700 (PDT)

A new version of the SSM architecture document is now available in the
ID archives at:

           http://www.ietf.org/internet-drafts/draft-ietf-ssm-arch-03.txt

This is a working group last call for changs.  Since the changes have
been pretty small since the last revision, I am making this a short
last call, ending on May 15.

I believe this draft addresses all of the issues raised during the
previous last call.  All document changes are summarized below, and
I've included the diffs of the nroff source relative to the -02
version, for people who don't want to re-read the whole document.

Please send any comments if you have them.

Thanks!
-Hugh
----------------------------------------------------------------

Changes since the -02 revision and the wg last call.

Section 1: Explained why FF3x::0000:0001 to FF3x::3FFF:FFFF are
invalid addresses.

Section 4.3: Corrections: randomization applies to the lowest 31 bits of the
IPv6 address.  Previously we said the "lower 32" which was imprecise
and wrong (only 31 bits are randomly selected).

Section 4.3: Added a note that v6 scoping may have to be applied to both S and
G..

Section 7.0: Added a two-sentence intro to Security Considerations.

Section 7.4: Add an entirely new section discussing Admin Scoping to Security
Considerations.

Section 9.0: IANA Considerations.  Added a note about the fact that
FF3x::4000:0000 to FF3x::7FFF:FFFF are IANA allocated and the
allocation policy.

Everywhere: A few minor editorial changes, mostly from Pekka, and a
few that I found along the way.

----------------------------------------------------------------

===================================================================
RCS file: RCS/draft-ietf-ssm-arch.nroff,v
retrieving revision 1.3
diff -uw -r1.3 draft-ietf-ssm-arch.nroff
--- draft-ietf-ssm-arch.nroff	2003/03/02 09:43:56	1.3
+++ draft-ietf-ssm-arch.nroff	2003/05/08 06:29:55
@@ -9,22 +9,22 @@
 .ds RF PUTFFHERE[Page %]
 .ds CF
 .ds LH INTERNET-DRAFT
-.ds RH 2 Mar 2003
+.ds RH 7 May 2003
 .ds CH Source-Specific Multicast
 .ad l
 .in 0
 .na
 INTERNET-DRAFT          Source-Specific Multicast            H. Holbrook
-Expires Sep 2, 2003                                        Cisco Systems
+Expires Nov 7, 2003                                        Cisco Systems
                                                                  B. Cain 
                                                         Storigen Systems
-                                                              2 Mar 2003
+                                                              7 May 2003
 .sp 2
 .nr PI 0n
 .ce
 Source-Specific Multicast for IP
 .ce
-<draft-ietf-ssm-arch-02.txt>
+<draft-ietf-ssm-arch-03.txt>
 .sp
 .in 0
 .ne 4
@@ -63,8 +63,8 @@
 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.
+the address prefix FF3x::/32 is reserved for source-specific
+multicast use.
 It defines an extension to the Internet 
 network service that applies to datagrams sent to SSM addresses
 and defines the host and router requirements to support this extension.
@@ -82,7 +82,7 @@
 This model supports both one-to-many and many-to-many group
 communication.
 This document uses the term "Any-Source
-Multicast" (ASM) to refer to the RFC 1112 model of multicast.
+Multicast" (ASM) to refer to model of multicast defined in RFC 1112.
 RFC 2373 [RFC2373] specifies the form of IPv6 multicast 
 addresses with ASM semantics.
 .PP
@@ -94,24 +94,28 @@
 .PP
 For IPv6, the address prefix FF3x::/32 is reserved for source-specific
 multicast use, where 'x' is any valid scope identifier, by [IPV6-UBM].
-Using the terminology of [IPv6-UBM], this means that P=1, T=1, and 
-plen=0 for any SSM address.
+Using the terminology of [IPv6-UBM], all SSM addresses must have P=1, T=1, and 
+plen=0.
 [IPv6-MALLOC] mandates that the network prefix field
 of an SSM address also be set to zero, hence all SSM
 addresses fall in the FF3x::/96 range.
 Future documents may allow a non-zero network prefix field if, for
 instance, a new IP address to MAC address mapping is defined.
 Thus, address allocation should occur within the FF3x::/96 range, but
-a system should treat all of FF3x::/32 as an SSM address, to allow
+a system should treat all of FF3x::/32 as SSM addresses, to allow
 for compatibility with possible future uses of the network prefix field.
 .PP
 Addresses in the range FF3x::4000:0000 through FF3x::7FFF:FFFF are
-reserved for allocation by IANA, and
-addresses in the range FF3x::8000:0000 through FF3x::FFFF:FFFF are
+reserved in [IPv6-MALLOC] for allocation by IANA.
+Addresses in the range FF3x::8000:0000 through FF3x::FFFF:FFFF are
 allowed for dynamic allocation by a host, as described in [IPV6-MALLOC].
 Addresses in the range
 FF3x::0000:0000 through FF3x::3FFF:FFFF are invalid IPv6 SSM
-addresses, per [IPV6-UBM].  The treatment of a packet sent to
+addresses.  ([IPV6-MALLOC] indicates
+that FF3x::0000:0001 to FF3x:3FFF:FFFF must set P=0 and T=0, but
+for SSM, [IPV6-UBM] mandates that  P=1 and T=1, hence their designation 
+as invalid).
+The treatment of a packet sent to
 such an invalid address is undefined -- a router or host
 MAY choose to drop such a packet.
 .PP
@@ -216,7 +220,7 @@
 The extended interface is defined in section 4.1.
 It is meaningless for an application or host to request reception
 of datagrams sent to an SSM destination address G,
-as is supported in the Any-Source Multicast model,
+as is supported in the any-source multicast model,
 without also specifying a corresponding source address, and
 routers MUST ignore any such request.
 .\" pursuant to [GMPSSM].
@@ -257,8 +261,8 @@
 .NH 1
 Terminology
 .PP
-To reduce confusion when talking about the Any-Source
-and Source-Specific Multicast models,
+To reduce confusion when talking about the any-source
+and source-specific multicast models,
 we use different terminology when discussing them.
 
 We use the term "channel" to refer to the 
@@ -284,13 +288,13 @@
 
 The following table summarizes the terminology:
 .IP "" 2
-Service Model:        Any-Source          Source-Specific
+Service Model:        any-source          source-specific
 .br
 Network Abstraction:  group               channel
 .br
 Identifier:           G                   S,G
 .br
-Receiver Operations:  join, leave         subscribe, unsubscribe
+Receiver Operations:  Join, Leave         Subscribe, Unsubscribe
 .br
 .PP
 We note that, although this document specifies a new
@@ -301,7 +305,7 @@
 Host Requirements
 .PP
 This section describes requirements on hosts that
-support Source-Specific Multicast, including:
+support source-specific multicast, including:
 .IP "" 2
 - Extensions to the IP Module Interface
 
@@ -376,10 +380,10 @@
 request on interface I to indicate to 
 neighboring routers 
 that the host wishes to receive traffic sent by source S 
-to source-specific destination G.
+to source-specific multicast destination G.
 Similarly, when the last socket on a host unsubscribes from
 a channel on interface I, the host IP module
-sends an unsubscription request for that channel out interface I.
+sends an unsubscription request for that channel to interface I.
 .PP
 These requests will typically be Internet Group Management Protocol
 version 3 messages for IPv4, or Multicast Listener Discovery
@@ -390,11 +394,14 @@
 Allocation of Source-Specific Multicast Addresses
 .PP
 The SSM destination address 232.0.0.0 is reserved, 
-and systems MUST NOT send datagrams
-with destination address of 232.0.0.0.
+and a system MUST NOT send a datagram
+with a destination address of 232.0.0.0.
 The address range
 232.0.0.1-232.0.0.255 is currently reserved for allocation by IANA.
-The IPv6 SSM address range FF3x::/32 is reserved for IANA allocation.
+SSM
+destination addresses in the range FF3x::4000:0000 through
+FF3x::7FFF:FFFF are similarly reserved for IANA allocation
+[IPv6-MALLOC].
 .PP
 The policy for allocating the rest of the SSM addresses to 
 sending applications is strictly locally determined by the sending host.
@@ -405,8 +412,8 @@
 It is RECOMMENDED to allocate SSM addresses to applications 
 randomly, while ensuring that allocated addresses are not given
 simultaneously to multiple applications 
-(and avoiding the reserved address range for IPv4).
-For IPv6, the randomization should apply to the lower 32 bits of the
+(and avoiding the reserved addresses).
+For IPv6, the randomization should apply to the lowest 31 bits of the
 address.
 .PP
 As described in Section 6, the mapping of
@@ -422,7 +429,7 @@
 As a result,
 traffic destined for one channel subscriber 
 would be delivered to another's IP module, which would then 
-have to reject the datagram.
+have to discard the datagram.
 .PP
 A host operating system SHOULD provide an interface to
 allow an application to
@@ -445,10 +452,11 @@
 If this interface is used, the starting address of the 
 range SHOULD be selected at random by the application.
 .PP
-For IPv6, administratively scoped SSM addresses are created by
-choosing an appropriate scope identifier for the SSM destination
-address.  Normal IPv6 multicast scope boundaries are applied to
-traffic sent to an SSM destination address.
+For IPv6, administratively scoped SSM channel addresses are created
+by choosing an appropriate scope identifier for the SSM destination
+address.  Normal IPv6 multicast scope boundaries [SCOPINGV6] are applied to
+traffic sent to an SSM destination address, including any relevant
+boundaries applied to both the source and destination address.
 .PP  
 No globally agreed-upon administratively-scoped address range
 [ADMIN-SCOPE] is currently defined for IPv4 source-specific multicast.
@@ -477,7 +485,7 @@
 to support SSM.
 .PP
 A network can concurrently support SSM in the SSM address range and 
-Any-Source Multicast
+any-source multicast
 in the rest of the multicast address space, 
 and it is expected that this will be commonplace.
 In such a network, a
@@ -518,6 +526,11 @@
 them to the socket layer.
 .NH 1
 Security Considerations
+.PP
+This section outlines security issues pertaining to SSM.  The
+following topics are addressed: limitations of IPSec,
+denial of service attacks, source spoofing, and security
+issues related to administrative scoping.
 .NH 2
 IPSec and SSM
 .PP
@@ -588,13 +601,13 @@
 source-specific state, using router CPU and network bandwidth
 .PP
 To reduce the damage from such an attack, a router MAY have
-configuration options to limit the following items:
+configuration options to limit, for example, the following items:
 .IP "" 4
 - The total rate at which all hosts on any one interface are
 allowed to initiate subscriptions (to limit the damage caused by
 forged source-address attacks)
 
-- The total number of subscriptions that can be initated from any
+- The total number of subscriptions that can be initiated from any
 single interface or host.
 .PP
 Any decision by an implementor to artificially limit the rate or
@@ -609,7 +622,7 @@
 Failure to do so would exacerbate a spoofed-source address attack.
 .PP
 We note that these attacks are not unique to SSM -- they are also present
-for Any-Source Multicast.
+for any-source multicast.
 .NH 2
 Spoofed Source Addresses
 .PP
@@ -641,6 +654,23 @@
 routing.
 Anti-source spoofing mechanisms such as source address filtering at
 the edges of the network are also strongly encouraged.
+.NH 2
+Administrative Scoping
+.PP
+Administrative scoping should not relied upon as a security measure
+[ADMIN-SCOPE]; however, in some cases it is part of a security
+solution.  It should be noted that no administrative scoping exists for
+IPv4 source-specific multicast.  An alternative approach is to manually
+configure traffic filters on routers to create such scoping if necessary.
+.PP
+Furthermore, for IPv6, neither source nor destination address scoping
+should be used as a security measure.  In some currently-deployed IPv6
+routers (those that do not conform to [SCOPED-ARCH]), scope boundaries
+are not always applied to all source address (for instance, an
+implentation may filter link-local addresses but nothing else).  Such
+a router may incorrectly forward an SSM channel (S,G) through a scope
+boundary for S.
+.PP
 .NH 1
 Transition Considerations
 .PP
@@ -650,7 +680,7 @@
 As stated above, 
 a router that receives a non-source-specific (e.g., IGMPv1
 or IGMPv2 or MLDv1) host report for a 
-source-specific destination addresses
+source-specific multicast destination address
 MUST ignore these reports.
 Failure to do so would violate the SSM service model promised to the
 sender: that a packet sent to (S,G) would only be delivered to hosts
@@ -661,7 +691,7 @@
 by simply forwarding any packet destined to G to all hosts that have requested
 subscription of (S,G) for any S.
 However, this implementation risks unduly
-burdening the network infrastructure by deliver (S,G) datagrams to hosts 
+burdening the network infrastructure by delivering (S,G) datagrams to hosts 
 that did not request them.
 Such an implementation for addresses in the SSM range is
 specifically not compliant with Section 5.2 of this document.
@@ -669,7 +699,7 @@
 IANA Considerations
 .PP
 Addresses in the range 232.0.0.1 through 232.0.0.255 and IPv6
-addresses with prefix FF3x::
+addresses in the range FF3x:4000:0000 to FF3x::7FFF:FFFF
 are reserved for
 services with wide applicability that either require
 or would strongly benefit if all hosts used a well-known SSM
@@ -692,19 +722,21 @@
 SSM destination address to a particular entity or application.  
 To do so would compromise one of the important benefits of the
 source-specific model: the ability for a host to simply and
-autonomously allocate a source-specific address from a large flat address
+autonomously allocate a source-specific multicast
+address from a large flat address
 space.
 .NH 1
 Acknowledgments
 .PP
 The SSM service model draws on a variety of prior work on alternative
-aproaches to IP multicast, including the EXPRESS multicast model of
+approaches to IP multicast, including the EXPRESS multicast model of
 Holbrook and Cheriton [EXPRESS], Green's [SMRP] and the Simple
 Multicast proposal of Perlman et. al. [SIMPLE]. 
 We would also like to
 thank Jon Postel and David Cheriton for their support in reassigning
 the 232/8 address range to SSM.
 Brian Haberman contributed to the IPv6 portion of this document.
+Thanks to Pekka Savola for a careful review.
 .NH 1
 Normative References
 .PP
@@ -771,6 +803,9 @@
 .PP
 [RFC2771] Finlayson, R., "An Abstract API for Multicast Address Allocation," RFC 2771, February 2000.
 .PP
+[SCOPINGV6] Deering, S. et. al, "IP Version 6 Scoped Address Architecture",
+Work in Progress.
+.PP
 [SIMPLE] R. Perlman, C-Y Lee, A. Ballardie, J. Crowcroft, Z. Wang, T. Maufer, C. Diot, and M. Green. 
 "Simple Multicast: A Design for Simple, Low-Overhead Multicast."  Work in Progress.
 .PP
@@ -850,5 +885,5 @@
 .\" .bp
 .\" .ls 1
 .\" Comment out the table of contents for now .PX
-This document expires Sep 2, 2003.
+This document expires Nov 7, 2003.
_______________________________________________
ssm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ssm