idnits 2.17.1 draft-ietf-ssm-arch-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 9 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 729 has weird spacing: '...imed to perta...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (18 Jul 2004) is 7221 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IPv6-UBM' is mentioned on line 61, but not defined == Missing Reference: 'IPv6-MALLOC' is mentioned on line 326, but not defined == Missing Reference: 'RFC 2119' is mentioned on line 133, but not defined == Missing Reference: 'SCOPED-ARCH' is mentioned on line 565, but not defined == Unused Reference: 'IGMPv2' is defined on line 679, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 689, but no explicit reference was found in the text == Unused Reference: 'RFC2710' is defined on line 692, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-holbrook-idmr-igmpv3-ssm-07 ** Obsolete normative reference: RFC 2401 (ref. 'IPSEC') (Obsoleted by RFC 4301) == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-v2-new-10 ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 5226) Summary: 5 errors (**), 0 flaws (~~), 13 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Source-Specific Multicast H. Holbrook 2 Expires Jan 18, 2005 Cisco Systems 3 B. Cain 4 Storigen Systems 5 18 Jul 2004 7 Source-Specific Multicast for IP 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference material 22 or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 IP addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are 33 designated as source-specific multicast (SSM) destination addresses and 34 are reserved for use by source-specific applications and protocols. For 35 IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for 36 source-specific multicast use. This document defines an extension to 37 the Internet network service that applies to datagrams sent to SSM 38 addresses and defines the host and router requirements to support this 39 extension. 41 1. Introduction 43 The Internet Protocol (IP) multicast service model is defined in RFC 44 1112 [RFC1112]. RFC 1112 specifies that a datagram sent to an IP 45 multicast address (224.0.0.0 through 239.255.255.255) G is delivered to 46 each "upper-layer protocol module" that has requested reception of 47 datagrams sent to address G. RFC 1112 calls the network service 48 identified by a multicast destination address G a "host group." This 49 model supports both one-to-many and many-to-many group communication. 50 This document uses the term "Any-Source Multicast" (ASM) to refer to 51 model of multicast defined in RFC 1112. RFC 2373 [RFC2373] specifies 52 the form of IPv6 multicast addresses with ASM semantics. 54 IP addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are 55 currently designated as source-specific multicast (SSM) destination 56 addresses and are reserved for use by source-specific applications and 57 protocols [IANA-ALLOCATION]. 59 For IPv6, the address prefix FF3x::/32 is reserved for source-specific 60 multicast use, where 'x' is any valid scope identifier, by [IPV6-UBM]. 61 Using the terminology of [IPv6-UBM], all SSM addresses must have P=1, 62 T=1, and plen=0. [IPv6-MALLOC] mandates that the network prefix field 63 of an SSM address also be set to zero, hence all SSM addresses fall in 64 the FF3x::/96 range. Future documents may allow a non-zero network 65 prefix field if, for instance, a new IP address to MAC address mapping 66 is defined. Thus, address allocation should occur within the FF3x::/96 67 range, but a system should treat all of FF3x::/32 as SSM addresses, to 68 allow for compatibility with possible future uses of the network prefix 69 field. 71 Addresses in the range FF3x::4000:0000 through FF3x::7FFF:FFFF are 72 reserved in [IPv6-MALLOC] for allocation by IANA. Addresses in the 73 range FF3x::8000:0000 through FF3x::FFFF:FFFF are allowed for dynamic 74 allocation by a host, as described in [IPV6-MALLOC]. Addresses in the 75 range FF3x::0000:0000 through FF3x::3FFF:FFFF are invalid IPv6 SSM 76 addresses. ([IPV6-MALLOC] indicates that FF3x::0000:0001 to 77 FF3x:3FFF:FFFF must set P=0 and T=0, but for SSM, [IPV6-UBM] mandates 78 that P=1 and T=1, hence their designation as invalid). The treatment 79 of a packet sent to such an invalid address is undefined -- a router or 80 host MAY choose to drop such a packet. 82 Source-specific multicast delivery semantics are provided for a datagram 83 sent to an SSM address. That is, a datagram with source IP address S 84 and SSM destination address G is delivered to each upper-layer "socket" 85 that has specifically requested the reception of datagrams sent to 86 address G by source S, and only to those sockets. The network service 87 identified by (S,G), for SSM address G and source host address S, is 88 referred to as a "channel." In contrast to the ASM model of RFC 1112, 89 SSM provides network-layer support for one-to-many delivery only. 91 The benefits of source-specific multicast include: 93 Elimination of cross-delivery of traffic when two sources 94 simultaneously use the same source-specific destination address. 95 The simultaneous use of an SSM destination address by multiple 96 sources and different applications is explicitly supported. 98 Avoidance of the need for inter-host coordination when choosing 99 source-specific addresses, as a consequence of the above. 101 Avoidance of many of the router protocols and algorithms that are 102 needed to provide the ASM service model. For instance, the "shared 103 trees" and Rendezvous Points of the PIM-Sparse Mode (PIM-SM) 104 protocol [PIM-SM] are not necessary to support the source-specific 105 model. The router mechanisms required to support SSM are in fact 106 largely a subset of those that are used to support ASM. For 107 example, the shortest-path tree mechanism of the PIM-SM protocol can 108 be adapted to provide SSM semantics. 110 Like ASM, the set of receivers is unknown to an SSM sender. An SSM 111 source is provided with neither the identity of receivers nor their 112 number. 114 SSM is particularly well-suited to dissemination-style applications with 115 one or more senders whose identities are known before the application 116 begins. For instance, a data dissemination application that desires to 117 provide a secondary data source in case the primary source fails over 118 might implement this by using one channel for each source and 119 advertising both of them to receivers. SSM can be used to build multi- 120 source applications where all participants' identities are not known in 121 advance, but the multi-source "rendezvous" functionality does not occur 122 in the network layer in this case. Just like in an application that 123 uses unicast as the underlying transport, this functionality can be 124 implemented by the application or by an application-layer library. 126 Multicast resource discovery of the form in which a client sends a 127 multicast query directly to a "service location group" to which servers 128 listen is not directly supported by SSM. 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC 2119 [RFC 2119]. 134 This document defines the semantics of source-specific multicast 135 addresses and specifies the policies governing their use. In 136 particular, it defines an extension to the Internet network service that 137 applies to datagrams sent to SSM addresses and defines host extensions 138 to support the network service. Hosts, routers, applications, and 139 protocols that use these addresses MUST comply with the policies 140 outlined in this document. Failure of a host to comply may prevent that 141 host or other hosts on the same LAN from receiving traffic sent to an 142 SSM channel. Failure of a router to comply may cause SSM traffic to be 143 delivered to parts of the network where it is unwanted, unnecessarily 144 burdening the network. 146 2. Semantics of Source-Specific Multicast Addresses 148 The source-specific multicast service is defined as follows: 150 A datagram sent with source IP address S and destination IP address 151 G in the SSM range is delivered to each host socket that has 152 specifically requested delivery of datagrams sent by S to G, and 153 only to those sockets. 155 Where, using the terminology of [IGMPv3], 157 "socket" is an implementation-specific parameter used to distinguish 158 among different requesting entities (e.g., programs or processes or 159 communication end-points within a program or process) within the 160 requesting host; the socket parameter of BSD Unix system calls is a 161 specific example. 163 Any host may send a datagram to any SSM address, and delivery is 164 provided according to the above semantics. 166 The IP module interface to upper-layer protocols is extended to allow a 167 socket to "Subscribe" to or "Unsubscribe" from a particular channel 168 identified by an SSM destination address and a source IP address. The 169 extended interface is defined in section 4.1. It is meaningless for an 170 application or host to request reception of datagrams sent to an SSM 171 destination address G, as is supported in the any-source multicast 172 model, without also specifying a corresponding source address, and 173 routers MUST ignore any such request. 175 Multiple source applications on different hosts can use the same SSM 176 destination address G without conflict because datagrams sent by each 177 source host Si are delivered only to those sockets that requested 178 delivery of datagrams sent to G specifically by Si. 180 The key distinguishing property of the model is that a channel is 181 identified (addressed) by the combination of a unicast source address 182 and a multicast destination address in the SSM range. So, for example, 183 the channel 185 S,G = (192.0.2.1, 232.7.8.9) 187 differs from 189 S,G = (192.0.2.2, 232.7.8.9), 191 even though they have the same destination address portion. Similarly, 192 for IPv6, 194 S,G = (2001:3618::1, FF33::1234) 196 and 198 S,G = (2001:3618::2, FF33::1234) 200 are different channels. 202 3. Terminology 204 To reduce confusion when talking about the any-source and source- 205 specific multicast models, we use different terminology when discussing 206 them. 208 We use the term "channel" to refer to the service associated with an SSM 209 address. A channel is identified by the combination of an SSM 210 destination address and a specific source, e.g., an (S,G) pair. 212 We use the term "host group" (used in RFC 1112) to refer to the service 213 associated with "regular" ASM multicast addresses (excluding those in 214 the SSM range). A host group is identified by a single multicast 215 address. 217 Any host can send to a host group, and similarly, any host can send to 218 an SSM destination address. A packet sent by a host S to an ASM 219 destination address G is delivered to the host group identified by G. A 220 packet sent by host S to an SSM destination address G is delivered to 221 the channel identified by (S,G). The receiver operations allowed on a 222 host group are called "join(G)" and "leave(G)" (as per RFC 1112). The 223 receiver operations allowed on a channel are called "Subscribe(S,G)" and 224 "Unsubscribe(S,G)." 226 The following table summarizes the terminology: 228 Service Model: any-source source-specific 229 Network Abstraction: group channel 230 Identifier: G S,G 231 Receiver Operations: Join, Leave Subscribe, Unsubscribe 233 We note that, although this document specifies a new service model 234 available to applications, the protocols and techniques necessary to 235 support the service model are largely a subset of those used to support 236 ASM. 238 4. Host Requirements 240 This section describes requirements on hosts that support source- 241 specific multicast, including: 243 - Extensions to the IP Module Interface 245 - Extensions to the IP Module 247 - Allocation of SSM Addresses 249 4.1. Extensions to the IP Module Interface 251 The IP module interface to upper-layer protocols is extended to allow 252 protocols to request reception of all datagrams sent to a particular 253 channel. 255 Subscribe ( socket, source-address, group-address, interface ) 257 Unsubscribe ( socket, source-address, group-address, interface ) 259 where 261 "socket" is as previously defined in Section 2, 263 and, paraphrasing [IGMPv3], 265 "interface" is a local identifier of the network interface on which 266 reception of the channel identified by the (source-address,group- 267 address) pair is to be enabled or disabled. A special value may be 268 used to indicate a "default" interface. If reception of the same 269 channel is desired on multiple interfaces, Subscribe is invoked once 270 for each. 272 The above are strictly abstract functional interfaces -- the 273 functionality can be provided in an implementation-specific way. On a 274 host that supports the multicast source filtering application 275 programming interface of [MSFAPI], for instance, the Subscribe and 276 Unsubscribe interfaces may be supported via that API. When a host has 277 been configured to know the SSM address range, (whether the 278 configuration mechanism is manual or through a protocol) the host's 279 operating system SHOULD return an error to an application that makes a 280 non-source-specific request to receive multicast sent to an SSM 281 destination address. 283 Widespread implementations of the IP packet reception interface (e.g., 284 the recvfrom() system call in BSD unix) do not allow a receiver to 285 determine the destination address to which a datagram was sent. On a 286 host with such an implementation, the destination address of a datagram 287 cannot be inferred when the socket on which the datagram is received is 288 Subscribed to multiple channels. Host operating systems SHOULD provide 289 a way for a host to determine both the source and the destination 290 address to which a datagram was sent. (As one example, the Linux 291 operating system provides the destination of a packet as part of the 292 response to the recvmsg() system call.) Until this capability is 293 present, applications may be forced to use higher-layer mechanisms to 294 identify the channel to which a datagram was sent. 296 4.2. Requirements on the Host IP Module 298 An incoming datagram destined to an SSM address MUST be delivered by the 299 IP module to all sockets that have indicated (via Subscribe) a desire to 300 receive data that matches the datagram's source address, destination 301 address, and arriving interface. It MUST NOT be delivered to other 302 sockets. 304 When the first socket on host H subscribes to a channel (S,G) on 305 interface I, the host IP module on H sends a request on interface I to 306 indicate to neighboring routers that the host wishes to receive traffic 307 sent by source S to source-specific multicast destination G. Similarly, 308 when the last socket on a host unsubscribes from a channel on interface 309 I, the host IP module sends an unsubscription request for that channel 310 to interface I. 312 These requests will typically be Internet Group Management Protocol 313 version 3 (IGMPv3) messages for IPv4, or Multicast Listener Discovery 314 Version 2 (MLDv2) messages for IPv6 [IGMPv3,MLDv2]. A host that 315 supports the SSM service model MUST implement the host portion of 316 [IGMPv3] for IPv4 and [MLDv2] for IPv6. It MUST also conform to the 317 IGMPv3/MLDv2 behavior described in [GMP-SSM]. 319 4.3. Allocation of Source-Specific Multicast Addresses 321 The SSM destination address 232.0.0.0 is reserved, and a system MUST NOT 322 send a datagram with a destination address of 232.0.0.0. The address 323 range 232.0.0.1-232.0.0.255 is currently reserved for allocation by 324 IANA. SSM destination addresses in the range FF3x::4000:0000 through 325 FF3x::7FFF:FFFF are similarly reserved for IANA allocation 326 [IPv6-MALLOC]. 328 The policy for allocating the rest of the SSM addresses to sending 329 applications is strictly locally determined by the sending host. 331 When allocating SSM addresses dynamically, a host or host operating 332 system MUST NOT allocate sequentially starting at the first allowed 333 address. It is RECOMMENDED to allocate SSM addresses to applications 334 randomly, while ensuring that allocated addresses are not given 335 simultaneously to multiple applications (and avoiding the reserved 336 addresses). For IPv6, the randomization should apply to the lowest 31 337 bits of the address. 339 As described in Section 6, the mapping of an IP packet with SSM 340 destination address onto a link-layer multicast address does not take 341 into account the datagram's source IP address (on commonly-used link 342 layers like Ethernet). If all hosts started at the first allowed 343 address, then with high probability, many source-specific channels on 344 shared-medium local area networks would use the same link-layer 345 multicast address. As a result, traffic destined for one channel 346 subscriber would be delivered to another's IP module, which would then 347 have to discard the datagram. 349 A host operating system SHOULD provide an interface to allow an 350 application to request a unique allocation of a channel destination 351 address in advance of a session's commencement, and this allocation 352 database SHOULD persist across host reboots. By providing persistent 353 allocations, a host application can advertise the session in advance of 354 its start time on a web page or in another directory. (We note that 355 this issue is not specific to SSM applications -- the same problem 356 arises for ASM.) 358 This document neither defines the interfaces for requesting or returning 359 addresses nor specifies the host algorithms for storing those 360 allocations. One plausible abstract API is defined in RFC 2771 361 [RFC2771]. Note that RFC 2771 allows an application to request an 362 address within a specific range of addresses. If this interface is 363 used, the starting address of the range SHOULD be selected at random by 364 the application. 366 For IPv6, administratively scoped SSM channel addresses are created by 367 choosing an appropriate scope identifier for the SSM destination 368 address. Normal IPv6 multicast scope boundaries [SCOPINGV6] are applied 369 to traffic sent to an SSM destination address, including any relevant 370 boundaries applied to both the source and destination address. 372 No globally agreed-upon administratively-scoped address range [ADMIN- 373 SCOPE] is currently defined for IPv4 source-specific multicast. For 374 IPv4, administrative scoping of SSM addresses can be implemented within 375 an administrative domain by filtering outgoing SSM traffic sent to a 376 scoped address at the domain's boundary routers. 378 5. Router Requirements 380 5.1. Packet Forwarding 382 A router that receives an IP datagram with a source-specific destination 383 address MUST silently drop it unless a neighboring host or router has 384 communicated a desire to receive packets sent from the source and to the 385 destination address of the received packet. 387 5.2. Protocols 389 Certain IP multicast routing protocols already have the ability to 390 communicate source-specific joins to neighboring routers (in particular, 391 PIM-SM [PIM-SM]), and these protocols can, with slight modifications, be 392 used to provide source-specific semantics. A router that supports the 393 SSM service model MUST implement the PIM-SSM subset of the PIM-SM 394 protocol from [PIM-SM] and MUST implement the router portion of [IGMPv3] 395 for IPv4 and [MLDv2] for IPv6. An SSM router MUST also conform to the 396 IGMPv3/MLDv2 behavior described in [GMP-SSM]. 398 With PIM-SSM, successful establishment of an (S,G) forwarding path from 399 the source S to any receiver depends on hop-by-hop forwarding of the 400 explicit join request from the receiver toward the source. The 401 protocol(s) and algorithms that are used to select the forwarding path 402 for this explicit join must provide a loop-free path. When using PIM- 403 SSM, the PIM-SSM implementation MUST (at least) support the ability to 404 use the unicast topology database for this purpose. 406 A network can concurrently support SSM in the SSM address range and any- 407 source multicast in the rest of the multicast address space, and it is 408 expected that this will be commonplace. In such a network, a router may 409 receive a non-source-specific, or "(*,G)" in conventional terminology, 410 request for delivery of traffic in the SSM range from a neighbor that 411 does not implement source-specific multicast in a manner compliant with 412 this document. A router that receives such a non-source-specific 413 request for data in the SSM range MUST NOT use the request to establish 414 forwarding state and MUST NOT propagate the request to other neighboring 415 routers. A router MAY log an error in such a case. This applies both 416 to any request received from a host, e.g., an IGMPv1 or IGMPv2 host 417 report, and to any request received from a routing protocol, e.g., a 418 PIM-SM (*,G) join. The inter-router case is further discussed in 419 section 8, Transition Considerations. 421 It is essential that all routers in the network give source-specific 422 semantics to the same range of addresses in order to achieve the full 423 benefit of SSM. To comply with this specification, a router MUST treat 424 ALL IANA-allocated SSM addresses with source-specific semantics. 426 6. Link-Layer Transmission of Datagrams 428 Source-specific multicast packets are transmitted on link-layer networks 429 as specified in RFC 1112 for IPv4 and as in [ETHERv6] for IPv6. On most 430 shared-medium link-layer networks that support multicast (e.g., 431 Ethernet), the IP source address is not used in the selection of the 432 link-layer destination address. Consequently, on such a network, all 433 packets sent to destination address G will be delivered to any host that 434 has subscribed to any channel (S,G), regardless of S. And therefore, 435 the IP module MUST filter packets it receives from the link layer before 436 delivering them to the socket layer. 438 7. Security Considerations 440 This section outlines security issues pertaining to SSM. The following 441 topics are addressed: limitations of IPSec, denial of service attacks, 442 source spoofing, and security issues related to administrative scoping. 444 7.1. IPSec and SSM 446 The IPSec Authentication Header (AH) and Encapsulating Security Payload 447 (ESP) protocols [IPSEC] can be used to secure SSM traffic. As of this 448 writing, however, the IPSec protocols have some limitations when used 449 with SSM. This section describes those limitations. 451 [IPSEC] specifies that every incoming packet that requires IPSec 452 processing is ultimately looked up in a local Security Association 453 Database (SAD) to determine the Security Association (SA) that is to be 454 applied to the packet. The resulting SA determines the decryption 455 and/or authentication key to use and the anti-replay window, if one is 456 used. The key used for the SAD lookup is: 458 - the packet's destination IP address 460 - the IPSec protocol (ESP or AH) 461 - the Security Parameter Index (SPI) 463 A problem arises for SSM because the source address is not included in 464 the SAD lookup. IPSec does not currently provide any way to ensure that 465 two unrelated SSM channels will have unique SAD entries at all 466 receivers. Two senders that happen to choose the same SSM destination 467 address and the same Security Parameter Index will "collide" in the SAD 468 at any host that is receiving both channels. Because the channel 469 addresses and SPIs are both allocated autonomously by the senders, there 470 is no reasonable means to ensure that each sender uses a unique 471 destination address or SPI. 473 In practice, this problem only arises if a receiver subscribes 474 simultaneously to two unrelated channels using IPSec whose sources 475 happen to have chosen the same IP destination address (IPDA) and the 476 same IPSec SPI. The tuple, however, consists of 56 bits that 477 are generally randomly chosen, and a conflict is unlikely to occur 478 through random chance. 480 But when this problem occurs, however unlikely, a host will not be able 481 to simultaneously receive IPSec-protected traffic from the two colliding 482 sources under the current IPSec model. 484 This problem is under investigation and a solution will appear in a 485 separate document. One possible solution is to include the source 486 address in the SAD lookup when the destination is an SSM address. 488 7.2. Denial of Service 490 A subscription request creates (S,G) state in a router to record the 491 subscription, invokes processing on that router, and possibly causes 492 processing at neighboring routers. A host can mount a denial of service 493 attack by requesting a large number of subscriptions. A denial of 494 service can result if: 496 - a large amount of traffic arrives when it was otherwise undesired, 497 consuming network resources to deliver it and host resources to drop 498 it 500 - a large amount of source-specific multicast state is created in 501 network routers, using router memory and CPU resources to store and 502 process the state 504 - a large amount of control traffic is generated to manage the 505 source-specific state, using router CPU and network bandwidth 507 To reduce the damage from such an attack, a router MAY have 508 configuration options to limit, for example, the following items: 510 - The total rate at which all hosts on any one interface are allowed 511 to initiate subscriptions (to limit the damage caused by forged 512 source-address attacks) 514 - The total number of subscriptions that can be initiated from any 515 single interface or host. 517 Any decision by an implementor to artificially limit the rate or number 518 of subscriptions should be taken carefully, however, as future 519 applications may use large numbers of channels. Tight limits on the 520 rate or number of channel subscriptions would inhibit the deployment of 521 such applications. 523 A router SHOULD verify that the source of a subscription request is a 524 valid address for the interface on which it was received. Failure to do 525 so would exacerbate a spoofed-source address attack. 527 We note that these attacks are not unique to SSM -- they are also 528 present for any-source multicast. 530 7.3. Spoofed Source Addresses 532 By forging the source address in a datagram, an attacker can potentially 533 violate the SSM service model by transmitting datagrams on a channel 534 belonging to another host. Thus, an application requiring strong 535 authentication should not assume that all packets that arrive on a 536 channel were sent by the requested source without higher-layer 537 authentication mechanisms. The IPSEC Authentication Header [IPSEC] may 538 be used to authenticate the source of an SSM transmission, for instance. 540 Some degree of protection against spoofed source addresses in multicast 541 is already fairly widespread, because the commonly deployed IP multicast 542 routing protocols [PIM-DM, PIM-SM, DVMRP] incorporate a "reverse-path 543 forwarding check" that validates that a multicast packet arrived on the 544 expected interface for its source address. Routing protocols used for 545 SSM SHOULD incorporate such a check. 547 Source Routing [RFC791] (both Loose and Strict) in combination with 548 source address spoofing may be used to allow an impostor of the true 549 channel source to inject packets onto an SSM channel. An SSM router 550 SHOULD by default disallow source routing to an SSM destination address. 551 A router MAY have a configuration option to allow source routing. Anti- 552 source spoofing mechanisms such as source address filtering at the edges 553 of the network are also strongly encouraged. 555 7.4. Administrative Scoping 557 Administrative scoping should not be relied upon as a security measure 558 [ADMIN-SCOPE]; however, in some cases it is part of a security solution. 559 It should be noted that no administrative scoping exists for IPv4 560 source-specific multicast. An alternative approach is to manually 561 configure traffic filters to create such scoping if necessary. 563 Furthermore, for IPv6, neither source nor destination address scoping 564 should be used as a security measure. In some currently-deployed IPv6 565 routers (those that do not conform to [SCOPED-ARCH]), scope boundaries 566 are not always applied to all source address (for instance, an 567 implentation may filter link-local addresses but nothing else). Such a 568 router may incorrectly forward an SSM channel (S,G) through a scope 569 boundary for S. 571 8. Transition Considerations 573 A host that complies with this document will send ONLY source-specific 574 host reports for addresses in the SSM range. As stated above, a router 575 that receives a non-source-specific (e.g., IGMPv1 or IGMPv2 or MLDv1) 576 host report for a source-specific multicast destination address MUST 577 ignore these reports. Failure to do so would violate the SSM service 578 model promised to the sender: that a packet sent to (S,G) would only be 579 delivered to hosts that specifically requested delivery of packets sent 580 to G by S. 582 During a transition period, it would be possible to deliver SSM 583 datagrams in a domain where the routers do not support SSM semantics by 584 simply forwarding any packet destined to G to all hosts that have 585 requested subscription of (S,G) for any S. However, this implementation 586 risks unduly burdening the network infrastructure by delivering (S,G) 587 datagrams to hosts that did not request them. Such an implementation 588 for addresses in the SSM range is specifically not compliant with 589 Section 5.2 of this document. 591 9. IANA Considerations 593 Addresses in the range 232.0.0.1 through 232.0.0.255 and IPv6 addresses 594 in the range FF3x:4000:0000 to FF3x::7FFF:FFFF are reserved for services 595 with wide applicability that either require or would strongly benefit if 596 all hosts used a well-known SSM destination address for that service. 597 IANA shall allocate addresses in this range according to IETF Consensus 598 [IANA-CONSIDERATIONS]. Any proposal for allocation must consider the 599 fact that, on an Ethernet network, all datagrams sent to any SSM 600 destination address will be transmitted with the same link-layer 601 destination address, regardless of the source. Furthermore, the fact 602 that SSM destinations in 232.0.0.0/24 and 232.128.0.0/24 use the same 603 link-layer addresses as the reserved IP multicast group range 604 224.0.0.0/24 must also be considered. Similar consideration should be 605 given to the IPv6 reserved multicast addresses. 607 Except for the aforementioned addresses, IANA SHALL NOT allocate any SSM 608 destination address to a particular entity or application. To do so 609 would compromise one of the important benefits of the source-specific 610 model: the ability for a host to simply and autonomously allocate a 611 source-specific multicast address from a large flat address space. 613 10. Acknowledgments 615 The SSM service model draws on a variety of prior work on alternative 616 approaches to IP multicast, including the EXPRESS multicast model of 617 Holbrook and Cheriton [EXPRESS], Green's [SMRP] and the Simple Multicast 618 proposal of Perlman et. al. [SIMPLE]. We would also like to thank Jon 619 Postel and David Cheriton for their support in reassigning the 232/8 620 address range to SSM. Brian Haberman contributed to the IPv6 portion of 621 this document. Thanks to Pekka Savola for a careful review. 623 11. Normative References 625 [ETHERv6] Crawford, M., "Transmission of IPv6 Packets over Ethernet 626 Networks", RFC2464, Dec 1998. 628 [GMP-SSM] H. Holbrook and B. Cain, "IGMPv3/MLDv2 for SSM", draft- 629 holbrook-idmr-igmpv3-ssm-07 (Work in Progress), June 2004. 631 [IGMPv3] Cain, B., Deering, S., and A. Thyagarajan, "Internet Group 632 Management Protocol, Version 3," RFC 3376, October 2002. 634 [IPSEC] S. Kent, R. Atkinson, "Security Architecture for the Internet 635 Protocol.", RFC 2401. 637 [IPV6-UBM] B. Haberman, D. Thaler, "Unicast-Prefix-based IPv6 Multicast 638 Addresses.", RFC 3306, August 2002. 640 [IPV6-MALLOC] B. Haberman, "Dynamic Allocation Guidelines for IPv6 641 Multicast Addresses", RFC 3307, August 2002. 643 [MLDv2] R. Vida, and L. Costa. "Multicast Listener Discovery Version 2 644 (MLDv2) for IPv6," RFC3810, June 2004. 646 [PIM-SM] B. Fenner, M. Handley, H. Holbrook, and I. Kouvelas. "Protocol 647 Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification 648 (Revised)," draft-ietf-pim-sm-v2-new-10.txt (Work in Progress), July 649 2004. 651 [RFC791] Postel, J., ed., "Internet Protocol, Darpa Internet Program 652 Protocol Specification," September 1981. 654 [RFC1112] Deering, S., "Host Extensions for IP Multicasting," RFC 1112, 655 August 1989. 657 [RFC2373] Hinden, R. and Deering, S. "IP Version 6 Addressing 658 Architecture." RFC 2373, July 1998. 660 12. Informative References 662 [ADMIN-SCOPE] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 663 RFC 2365, July 1998. 665 [DVMRP] Waitzman, D., Partridge, C., and S. Deering., "Distance Vector 666 Multicast Routing Protocol," RFC 1075, Nov 1988. 668 [EXPRESS] Holbrook, H., and Cheriton, D. "Explicitly Requested Source- 669 Specific Multicast: EXPRESS support for Large-scale Single-source 670 Applications." Proceedings of ACM SIGCOMM '99, Cambridge, MA, September 671 1999. 673 [IANA-ALLOCATION] Internet Assigned Numbers Authority, 674 http://www.iana.org/assignments/multicast-addresses. 676 [IANA-CONSIDERATIONS] Narten, T., and H. Alvestrand, "Guidelines for 677 Writing an IANA Considerations Section in RFCs," RFC 2434, October 1998. 679 [IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2," 680 RFC 2236, November 1997. 682 [MSFAPI] Thaler, D., Fenner, B., and Quinn, B. "Socket Interface 683 Extensions for Multicast Source Filters." Work in Progress. 685 [PIM-DM] Deering, S., Estrin, D., Farinacci, D., Jacobson, V., Helmy, 686 A., Meyer, D., and L. Wei, "Protocol Independent Multicast Version 2 687 Dense Mode Specification," Work in Progress. 689 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 690 Requirement Levels," RFC 2119, March 1997. 692 [RFC2710] S. Deering, W. Fenner, B. Haberman, "Multicast Listener 693 Discovery (MLD) for IPv6", RFC 2710, October 1999. 695 [RFC2771] Finlayson, R., "An Abstract API for Multicast Address 696 Allocation," RFC 2771, February 2000. 698 [SCOPINGV6] Deering, S. et. al, "IP Version 6 Scoped Address 699 Architecture", Work in Progress. 701 [SIMPLE] R. Perlman, C-Y Lee, A. Ballardie, J. Crowcroft, Z. Wang, T. 702 Maufer, C. Diot, and M. Green. "Simple Multicast: A Design for Simple, 703 Low-Overhead Multicast." Work in Progress. 705 [SMRP] Green, M. "Method and System of Multicast Routing for Groups 706 with a Single Transmitter." United States Patent Number 5,517,494. 708 Authors' Addresses 710 Brad Cain 711 Storigen Systems 712 650 Suffolk St. 713 Lowell, MA 01854 714 bcain@storigen.com 716 Hugh Holbrook 717 Cisco Systems 718 170 W. Tasman Drive 719 San Jose, CA 95134 720 holbrook@cisco.com 722 Intellectual Property Rights Notice 724 The IETF has been notified of intellectual property rights claimed in 725 regard to some or all of the specification contained in this document. 726 For more information consult the online list of claimed rights. 728 The IETF takes no position regarding the validity or scope of any 729 intellectual property or other rights that might be claimed to pertain 730 to the implementation or use of the technology described in this 731 document or the extent to which any license under such rights might or 732 might not be available; neither does it represent that it has made any 733 effort to identify any such rights. Information on the IETF's 734 procedures with respect to rights in standards-track and standards- 735 related documentation can be found in BCP-11. Copies of claims of 736 rights made available for publication and any assurances of licenses to 737 be made available, or the result of an attempt made to obtain a general 738 license or permission for the use of such proprietary rights by 739 implementors or users of this specification can be obtained from the 740 IETF Secretariat. 742 The IETF invites any interested party to bring to its attention any 743 copyrights, patents or patent applications, or other proprietary rights 744 which may cover technology that may be required to practice this 745 standard. Please address the information to the IETF Executive 746 Director. 748 Full Copyright Statement 750 Copyright (C) The Internet Society (2004). All Rights Reserved. 752 This document and translations of it may be copied and furnished to 753 others, and derivative works that comment on or otherwise explain it or 754 assist in its implementation may be prepared, copied, published and 755 distributed, in whole or in part, without restriction of any kind, 756 provided that the above copyright notice and this paragraph are included 757 on all such copies and derivative works. However, this document itself 758 may not be modified in any way, such as by removing the copyright notice 759 or references to the Internet Society or other Internet organizations, 760 except as needed for the purpose of developing Internet standards in 761 which case the procedures for copyrights defined in the Internet 762 Standards process must be followed, or as required to translate it into 763 languages other than English. 765 The limited permissions granted above are perpetual and will not be 766 revoked by the Internet Society or its successors or assigns. 768 This document and the information contained herein is provided on an "AS 769 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 770 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 771 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 772 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 773 FITNESS FOR A PARTICULAR PURPOSE. 775 This document expires Jan 18, 2005.