Analysis of Protocol Independent
Multicast Sparse Mode (PIM-SM) Security According to KARP Design
Guide
Alcatel-Lucent
India
manav.bhatia@alcatel-lucent.com
Ciena Corporation
3939 North 1st Street
San Jose
CA
95134
USA
+1 (408) 904-2160
mjethanandani@gmail.com
Huawei Technologies Co. LTD.
Beijing
China
zhangdacheng@huawei.com
This document analyzes the Protocol Independent Multicast Sparse Mode
(PIM-SM) according to the guidelines set forth in the KARP Design
Guide.
This document performs the initial analysis of the current state of
Protocol Independent Multicast Sparse Mode
(PIM-SM) according to the requirements of KARP Design Guidelines
The base PIM-SM specification
introduces the use non-cryptographic authentication approaches to
protect PIM-SM packets and recommends the use of transport mode of IPsec AH to protect PIM-SM unicast and
multicast packets. The memo assumes that the SAs are manually
deployed.
Authentication and Confidentiality in PIM-SM
Link-Local Messages proposes the mechanisms to authenticate the
PIM-SM multicast messages using the IP security
(IPsec) Encapsulating Security Payload (ESP) or (optionally) the
IP Authentication Header (AH) .
The document specifies manual key management as mandatory to
implement and provides the necessary structure for an automated key
management protocol that the PIM routers may use.
However, some gaps remain between the current state and the
requirements for manually keyed routing security expressed in the document. This document explores these gaps and
proposes directions for addressing the gaps.
Unlike OSPFv2 , PIM-SM does not propose
any in-band security solution. Instead, IPsec is used to protect both
unicast and muticast control packets.
Authentication and Confidentiality in PIM-SM
Link-Local Messages describes how IPsec can be used to secure
and authenticate PIM-SM protocol packets. It mandates the use of manual
keying and optionally provides support for an automated group key
management mechanism. However, it leaves the procedures for implementing
automated group key management to other documents and does not discuss
how this can be done.
The mechanism proposed in Authentication and
Confidentiality in PIM-SM Link-Local Messages supports packet
level integrity protection using a wide variety of cryptographic
algorithms. In addition, the Security Parameter
Index (SPI) provides an identifier for the security association.
Along with other IPsec facilities, SPI provides a mechanism for moving
from one key to another, meeting the key rollover requirements. Because
the algorithm can be changed as part of rekeying, algorithm agility is
provided.
Authentication and Confidentiality in PIM-SM
Link-Local Messages uses manually configured keys, rather than
some automated key management protocol, since no suitable key management
mechanism was available at this time. This is because PIM-SM adjacencies
are formed on a one-to-many basis and most key management mechanisms are
designed for a one-to-one communication model. Since authentication and confidentiality in PIM-SM Link-Local
Messages uses manual keying it clearly states that it provides
no protection against both inter-session and intra-session replay
attacks. This can be exploited in various ways. For instance, by
replaying the Join message sent by a legitimate requester, an attacker
can direct multicast traffic to be delivered to links where it is not
required. Similarly, replaying a Prune Message can deprive the receivers
from that multicast traffic.
Since multiple PIM-SM routers can exist on a single link, it would be
worth noting that setting up IPsec Security Associations (SAs) manually
can be a very tedious process. The routers might not even support IPsec,
rendering automatic key negotiation either impractical (in those
platforms where an extra license has to be obtained for using IPsec) or
infeasible (in those platforms where IPsec support is not available at
all).
PIM-SM requires all PIM-SM routers to
configure an IPsec Security Association (SA) when sending PIM Register
packets to each Rendezvous Point (RP). This can become highly unscalable
as the number of RPs increase or in case of Anycast-RP deployment where each PIM-SM router
close to the source will need to establish IPsec tunnels to all PIM-SM
routers in the Anycast-RP set.
Similarly, the Security Policy Database at each Rendezvous Point
should be configured to choose an SA to use when sending Register-Stop
messages. Because Register-Stop messages are unicast to the destination
DR, a different SA and a potentially unique SPI are required for each
DR.
In order to simplify the management problem, PIM-SM suggests using the same authentication
algorithm and authentication parameters, regardless of the sending RP
and regardless of the destination DR. While this alleviates the
management problem by some extent it still requires a unique SA on each
DR which can result in a significant scaling issue as the size of the
PIM-SM network grows.
In PIM-SM, multiple types of PIM messages (Hello, Join/Prune,
Bootstrap, Assert) are delivered with multicast. As it exists today,
PIM-SM supports only manual key management. When using manual keying,
the replay protection mechanism (replay protection window) of IPSec will
be switched off. That is why IPSec cannot protect against any replay
protection in this case. In addition, the PIM messages do not have any
replay protection mechanism, e.g. nonce or sequence numbers. Therefore,
PIM-SM is subject to both inter- and intra-connection replay attacks.
From the aspect of meeting the requirements for replay protection, a
significant gap exists between the optimal state and where PIM-SM is
today.
In order to encourage deployment of PIM-SM security, an
authentication option is required that does not have the deployment
challenges of IPSec. We therefore need an alternate authentication
mechanism to IPSec as suggested by the first phase of the KARP design
guide, where the guide suggests securing the routing protocols using
manual keying.
The new mechanism should work for both the unicast and multicast
PIM-SM routing exchanges. It should also provide both inter-session and
intra-session replay protection that has been spelled out in the document.
This document places no new request to IANA
We would like to thank Stig Venaas and Bill Atwood for reviewing and
providing feedback on this draft.