Skip to main content

7. Security Considerations

This section outlines security issues pertaining to SSM. The following topics are addressed: IPsec, denial-of-service attacks, source spoofing, and security issues related to administrative scoping.

7.1. IPsec and SSM​

The IPsec Authentication Header (AH) and Encapsulating Security Payload (ESP) can be used to secure SSM traffic, if a multicast-capable implementation of IPsec (as required in [RFC4301]) is used by the receivers.

7.2. SSM and RFC 2401 IPsec Caveats​

For existing implementations of RFC 2401 IPsec (now superseded by [RFC4301]), there are a few caveats related to SSM. They are listed here. In RFC 2401 IPsec, the source address is not used as part of the key in the SAD lookup. As a result, two senders that happen to use the same SSM destination address and the same Security Parameter Index (SPI) will "collide" in the SAD at any host that is receiving both channels. Because the channel addresses and SPIs are both allocated autonomously by the senders, there is no reasonable means to ensure that each sender uses a unique destination address or SPI.

A problem arises if a receiver subscribes simultaneously to two unrelated channels using IPsec whose sources happen to be using the same IP destination address (IPDA) and the same IPsec SPI. Because the channel destination addresses are allocated autonomously by the senders, any two hosts can simultaneously use the same destination address, and there is no reasonable means to ensure that this does not happen. The <IPDA,SPI> tuple, however, consists of 56 bits that are generally randomly chosen (24 bits of the IP destination and 32 bits of the SPI), and a conflict is unlikely to occur through random chance.

If such a collision occurs, a receiver will not be able to simultaneously receive IPsec-protected traffic from the two colliding sources. A receiver can detect this condition by noticing that it is receiving traffic from two different sources with the same SPI and the same SSM destination address.

7.3. Denial of Service​

A subscription request creates (S,G) state in a router to record the subscription, invokes processing on that router, and possibly causes processing at neighboring routers. A host can mount a denial-of-service attack by requesting a large number of subscriptions. Denial of service can result if:

  • a large amount of traffic arrives when it was otherwise undesired, consuming network resources to deliver it and host resources to drop it;

  • a large amount of source-specific multicast state is created in network routers, using router memory and CPU resources to store and process the state; or

  • a large amount of control traffic is generated to manage the source-specific state, using router CPU and network bandwidth.

To reduce the damage from such an attack, a router MAY have configuration options to limit, for example, the following items:

  • 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 initiated from any single interface or host.

Any decision by an implementor to artificially limit the rate or number of subscriptions should be taken carefully, however, as future applications may use large numbers of channels. Tight limits on the rate or number of channel subscriptions would inhibit the deployment of such applications.

A router SHOULD verify that the source of a subscription request is a valid address for the interface on which it was received. Failure to do so would exacerbate a spoofed-source address attack.

We note that these attacks are not unique to SSM -- they are also present for any-source multicast.

7.4. Spoofed Source Addresses​

By forging the source address in a datagram, an attacker can potentially violate the SSM service model by transmitting datagrams on a channel belonging to another host. Thus, an application requiring strong authentication should not assume that all packets that arrive on a channel were sent by the requested source without higher-layer authentication mechanisms. The IPSEC Authentication Header [RFC2401, RFC4301] may be used to authenticate the source of an SSM transmission, for instance.

Some degree of protection against spoofed source addresses in multicast is already fairly widespread, because the commonly deployed IP multicast routing protocols [PIM-DM, PIM-SM, DVMRP] incorporate a "reverse-path forwarding check" that validates that a multicast packet arrived on the expected interface for its source address. Routing protocols used for SSM SHOULD incorporate such a check.

Source Routing [RFC791] (both Loose and Strict) in combination with source address spoofing may be used to allow an impostor of the true channel source to inject packets onto an SSM channel. An SSM router SHOULD by default disallow source routing to an SSM destination address. A router MAY have a configuration option to allow source routing. Anti-source spoofing mechanisms, such as source address filtering at the edges of the network, are also strongly encouraged.

7.5. Administrative Scoping​

Administrative scoping should not be 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 to create such scoping if necessary.

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 [SCOPINGv6]), scope boundaries are not always applied to all source address (for instance, an implementation 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.

Last updated on