Authentication and Confidentiality in PIM-SM Link-local Messages
draft-ietf-pim-sm-linklocal-05

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on May 7, 2009.

Abstract

RFC 4601 mandates the use of IPsec to ensure authentication of the link-local messages in the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol. This document specifies mechanisms to authenticate the PIM-SM link local messages using the IP security (IPsec) Authentication Header (AH) or Encapsulating Security Payload (ESP). It specifies optional mechanisms to provide confidentiality using the ESP. Manual keying is specified as the mandatory and default group key management solution. To deal with issues of scalability and security that exist with manual keying, an optional automated group key management mechanism is specified.

Table of Contents

1.  Introduction
2.  Terminology
3.  Transport Mode vs. Tunnel Mode
4.  Authentication
5.  Confidentiality
6.  IPsec Requirements
7.  Key Management
    7.1.  Manual Key Management
    7.2.  Automated Key Management
    7.3.  Communications Patterns
    7.4.  Neighbor Relationships
8.  Number of Security Associations
9.  Rekeying
    9.1.  Rekeying Procedure
    9.2.  KeyRollover Interval
    9.3.  Rekeying Interval
10.  IPsec Protection Barrier and GSPD
    10.1.  Manual Keying
        10.1.1.  SAD Entries
        10.1.2.  SPD Entries
    10.2.  Automatic Keying
        10.2.1.  SAD Entries
        10.2.2.  GSPD Entries
        10.2.3.  PAD Entries
11.  Security Association Lookup
12.  Activating the Anti-replay Mechanism
13.  Implementing a Security Association Database per Interface
14.  Extended Sequence Number
15.  Security Considerations
16.  IANA Considerations
17.  References
    17.1.  Normative References
    17.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

All the PIM-SM [RFC4601] (Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, “Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised),” August 2006.) control messages have IP protocol number 103. These messages are either unicast, or multicast with TTL = 1. The source address used for unicast messages is a domain-wide reachable address. For the multicast messages, a link-local address of the interface on which the message is being sent is used as the source address and a special multicast address, ALL_PIM_ROUTERS (224.0.0.13 in IPv4 and ff02::d in IPv6) is used as the destination address. These messages are called link-local messages. Hello, Join/Prune and Assert messages are included in this category. A forged link-local message may be sent to the ALL_PIM_ROUTERS multicast address by an attacker. This type of message affects the construction of the distribution tree [RFC4601] (Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, “Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised),” August 2006.). The effects of these forged messages are outlined in section 6.1 of [RFC4601] (Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, “Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised),” August 2006.). Some of the effects are very severe, whereas some are minor.

PIM-SM version 2 was originally specified in RFC 2117, and revised in RFC 2362 and RFC 4601. RFC 4601 obsoletes RFC 2362, and corrects a number of deficiencies. The Security Considerations section of RFC 4601 is based primarily on the new Authentication Header (AH) specification described in RFC 4302 (Kent, S., “IP Authentication Header,” December 2005.) [RFC4302].

Securing the unicast messages can be achieved by the use of a normal unicast IPsec Security Association between the two communicants. Securing the user data exchanges is covered in RFC 3740 (Hardjono, T. and B. Weis, “The Multicast Group Security Architecture,” March 2004.) [RFC3740].

This document focuses on the security issues for link-local messages. It provides some guidelines to take advantage of the new permitted AH functionality in RFC 4302 and the new permitted ESP functionality in RFC 4303, and to bring the PIM-SM specification into alignment with the new AH and ESP specifications. This document recommends manual key management as mandatory to implement, i.e., that all implementations MUST support, and provides the necessary structure for an automated key management protocol that the PIM routers may use.

The primary goal for link-local security is to provide data origin authentication for each link-local message. A secondary goal is to ensure that communication only happens between legitimate peers (i.e., adjacent routers). An optional goal is to provide data confidentiality for the link-local messages.

The first goal implies that each router has a unique identity. It is likely (but not mandatory) that this identity will be based on the unicast identity of the router. (The unicast identity could be, for example, based on some individually-configured property of the router, or be part of a region-wide public key infrastructure.) The existence of this identity is assumed in this specification, but procedures for establishing it are out-of-scope for this document.

The second goal implies that there is some form of "adjacency matrix" that controls the establishment of security associations among adjacent multicast routers. For manual keying, this control will be exercised by the Administrator of the router(s), through the setting of initialization parameters. For automated keying, the existence of this control will be reflected by the contents of the Group Security Policy Database (GSPD) in each router. Procedures for building this GSPD are out-of-scope for this document.

2.  Terminology

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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119]. They indicate requirement levels for compliant PIM-SM implementations.

3.  Transport Mode vs. Tunnel Mode

The transport mode Security Association (SA) is generally used between two hosts or routers/gateways when they are acting as hosts. The SA must be a tunnel mode SA if either end of the security association is a router/gateway. Two hosts MAY establish a tunnel mode SA between themselves. PIM-SM link-local messages are exchanged between routers. However, since the packets are locally delivered, the routers assume the role of hosts in the context of the tunnel mode SA. All implementations conforming to this specification MUST support transport mode SA to provide required IPsec security to PIM-SM link-local messages. They MAY also support tunnel mode SA to provide required IPsec security to PIM-SM link-local messages.

4.  Authentication

Implementations conforming to this specification MUST support authentication for PIM-SM link-local messages.

In order to provide authentication to PIM-SM link-local messages, implementations MUST support ESP (Kent, S., “IP Encapsulating Security Payload (ESP),” December 2005.) [RFC4303] and MAY support AH (Kent, S., “IP Authentication Header,” December 2005.) [RFC4302].

If ESP in transport mode is used, it will only provide authentication to PIM-SM protocol packets excluding the IPv6 header, extension headers, and options. (Note: The IPv4 exclusions need to be listed here as well.)

If AH in transport mode is used, it will provide authentication to PIM-SM protocol packets, selected portions of the IPv6 header, extension headers and options. (Note: the IPv4 coverage needs to be listed here as well.)

When authentication for PIM-SM link-local messages is enabled,

• PIM-SM link-local packets that are not protected with AH or ESP MUST be silently discarded.
• PIM-SM link-local packets that fail the authentication checks MUST be silently discarded.

5.  Confidentiality

Implementations conforming to this specification SHOULD support confidentiality for PIM-SM.

If confidentiality is provided, ESP MUST be used.

When PIM-SM confidentiality is enabled,

• PIM-SM packets that are not protected with ESP MUST be silently discarded.
• PIM-SM packets that fail the confidentiality checks MUST be silently discarded.

6.  IPsec Requirements

In order to implement this specification, the following IPsec capabilities are required.

Transport mode

IPsec in transport mode MUST be supported.

Multiple Security Policy Databases (SPDs)

The implementation MUST support multiple SPDs with an SPD selection function that provides an ability to choose a specific SPD based on interface.

Selectors

The implementation MUST be able to use source address, destination address, protocol, and direction as selectors in the SPD.

Interface ID tagging

The implementation MUST be able to tag the inbound packets with the ID of the interface (physical or virtual) via which it arrived.

Manual key support

Manually configured keys MUST be able to secure the specified traffic.

Encryption and authentication algorithms

The implementation MUST NOT allow the user to choose stream ciphers as the encryption algorithm for securing PIM-SM packets since the stream ciphers are not suitable for manual keys. Except when in conflict with the above statement, the key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", and "SHOULD NOT" that appear in RFC 4835 (Manral, V., “Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH),” April 2007.) [RFC4835] for algorithms to be supported are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119] for PIM-SM support as well.

Encapsulation of ESP packet

IP encapsulation of ESP packets MUST be supported. For simplicity, UDP encapsulation of ESP packets SHOULD NOT be used.

7.  Key Management

All the implementations MUST support manual configuration of the SAs that will be used to authenticate PIM-SM link-local messages. This does not preclude the use of a negotiation protocol such as the Internet Key Exchange (IKE) [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.) or Group Secure Association Key Management Protocol (GSAKMP) [RFC4535] (Harney, H., Meth, U., Colegrove, A., and G. Gross, “GSAKMP: Group Secure Association Key Management Protocol,” June 2006.) to establish SAs.

7.1.  Manual Key Management

To establish the SAs at PIM-SM routers, manual key configuration will be feasible when the number of peers (directly connected routers) is small. The Network Administrator will configure a router manually during its boot up process. At that time, the authentication method and the choice of keys SHOULD be configured. The SAD entry will be created. The Network Administrator will also configure the Security Policy Database of a router to ensure the use of the associated SA while sending a link-local message.

7.2.  Automated Key Management

All the link-local messages of the PIM-SM protocol are sent to the destination address, ALL_PIM_ROUTERS, which is a multicast address. By using the sender address in conjunction with the destination address for Security Association lookup, link-local communication turns to an SSM or "one to many" communication. Since IKE is based on the Diffie-Hellman key agreement protocol and works only for two communicating parties, it is not possible to use IKE for providing the required "one to many" authentication.

One option is to use Group Domain Of Interpretation (GDOI) [RFC3547] (Baugher, M., Weis, B., Hardjono, T., and H. Harney, “The Group Domain of Interpretation,” July 2003.), which enables a group of users or devices to exchange encrypted data using IPsec data encryption. GDOI has been developed to be used in multicast applications, where the number of end users or devices may be large and the end users or devices can dynamically join/leave a multicast group. However, a PIM router is not expected to join/leave very frequently, and the number of routers is small when compared to the possible number of users of a multicast application. Moreover, most of the PIM routers will be located inside the same administrative domain and are considered as trusted parties. It is possible that a subset of GDOI functionalities will be sufficient.

A framework for automating key management for RSVP is given in [I‑D.ietf‑tsvwg‑rsvp‑security‑groupkeying] (Behringer, M. and F. Faucheur, “Applicability of Keying Methods for RSVP Security,” June 2009.). A companion modification for GDOI is presented in [I‑D.weis‑gdoi‑for‑rsvp] (Weis, B., “Group Domain of Interpretation (GDOI) support for RSVP,” February 2008.).

Another option is to use the Group Secure Association Key Management Protocol (GSAKMP) [RFC4535] (Harney, H., Meth, U., Colegrove, A., and G. Gross, “GSAKMP: Group Secure Association Key Management Protocol,” June 2006.).

7.3.  Communications Patterns

Before discussing the set of security associations that are required to properly manage a multicast region that is under the control of a single administration, it is necessary to understand the communications patterns that will exist among the routers in this region. From the perspective of a speaking router, the information from that router is sent (multicast) to all of its neighbors. From the perspective of a listening router, the information coming from each of its neighbors is distinct from the information coming from every other router to which it is directly connected. Thus an administrative region contains many (small) distinct groups, all of which happen to be using the same multicast destination address (e.g., ALL_PIM_ROUTERS, see Section 11 (Security Association Lookup)), and each of which is centered on the associated speaking router.

Consider the example configuration as shown in Figure 1.

 R2    R3    R4    R5    R6
 |     |     |     |     |
 |     |     |     |     |
---------   ---------------
        |     |
        |     |
         \   /
           R1
         /   \
        |     |
        |     |
---------    --------------------
       |       |    |    |    |
       |       |    |    |    |
      R7      R8   R9   R10  R11
       |       |    |    |    |
                    |
                    |
                -------------
                 |    |    |
                 |    |    |
                R12  R13  R14

       Figure 1: Set of router interconnections

In this configuration, router R1 has four interfaces, and is the speaking router for a group whose listening routers are routers R2 through R11. Router R9 is the speaking router for a group whose listening routers are routers R1, R8 and R10-R14.

From the perspective of R1 as a speaking router, if a Security Association SA1 is assigned to protect outgoing packets from R1, then it is necessary to distribute the key for this association to each of the routers R2 through R11. Similarly, from the perspective of R9 as a speaking router, if a Security Association is assigned to protect the outgoing packets from R9, then it is necessary to distribute the key for this association to each of the routers R1, R8, and R10 through R14.

From the perspective of R1 as a listening router, all packets arriving from R2 through R11 need to be distinguished from each other, to permit selecting the correct Security Association in the SAD. (Packets from each of the peer routers (R2 through R11) represent communication from a different speaker, even though they are sent using the same destination address.) For a multicast Security Association, RFC 4301 permits using the Source Address in the selection function. If the source addresses used by routers R2 through R11 are globally unique, then the source addresses of the peer routers are sufficient to achieve the differentiation. If the sending routers use link-local addresses, then these addresses are unique only on a per-interface basis, and it is necessary to use the Interface ID tag as an additional selector, i.e., either the selection function has to have the Interface ID tag as one of its inputs, or separate SADs have to be maintained for each interface.

If the assumption of connectivity to the key server can be made (which is true in the PIM-SM case), then the GC/KS can be centrally located (and duplicated for reliability). If this assumption cannot be made (i.e., in the case of adjacencies for a unicast router), then some form of "local" key server must be available for each group. Given that the listening routers are never more than one hop away from the speaking router, the speaking router is the obvious place to locate the "local" key server. This has the additional advantage that there is no need to duplicate the local key server for reliability, since if the key server is down, it is very likely that the speaking router is also down.

7.4.  Neighbor Relationships

Each distinct group consists of one speaker, and the set of directly connected listeners. If the decision is made to maintain one Security Association per speaker (see Section 8 (Number of Security Associations)), then the key server will need to be aware of the adjacencies of each speaker. Procedures for doing this are out-of-scope for this document.

8.  Number of Security Associations

The number of Security Associations to be maintained by a PIM router depends on the required security level and available key management. This SHOULD be decided by the Network Administrator. Two different ways are shown in Figure 2 and 3. It is assumed that A, B and C are three PIM routers, where B and C are directly connected with A, and there is no direct link between B and C.

                                     |
                  B                  |
                SAb     ------------>|
                SAa     <------------|
                                     |
                  A                  |
                SAb     <------------|
                SAa     ------------>|
                SAc     <------------|
                                     |
                  C                  |
                SAc     ------------>|
                SAa     <------------|
                                     |
                        Directly connected network

       Figure 2: Activate unique Security Association for each peer

The first method, shown in Figure 2 is OPTIONAL to implement. In this method, each node will use a unique SA for its outbound traffic. A, B, and C will use SAa, SAb, and SAc, respectively for sending any traffic. Each node will look up the SA to be used based on the source address. A will use SAb and SAc for packets received from B and C, respectively. The number of SAs to be activated and maintained by a PIM router will be equal to the number of directly connected routers plus one, for sending its own traffic. Also, the addition of a PIM router in the network will require the addition of another SA on every directly connected PIM router. This solution will be scalable and practically feasible with an automated key management protocol. However, it MAY be used with manual key management, if the number of directly connected router(s) is small.

                 B                   |
                SAo     ------------>|
                SAi     <------------|
                                     |
                 A                   |
                SAo     ------------>|
                SAi     <------------|
                                     |
                 C                   |
                SAo     ------------>|
                SAi     <------------|
                                     |
                        Directly connected network

       Figure 3: Activate two Security Associations

The second method, shown in Figure 3, MUST be supported by every implementation. In this simple method, all the nodes will use two SAs, one for sending (SAo) and the other for receiving (SAi) traffic. Thus, the number of SAs is always two and will not be affected by addition of a PIM router. Although two different SAs are used in this method, the SA parameters (keys, SPI, etc.) for the two SAs are identical, i.e., the same information is shared among all the routers in an administrative region. This document RECOMMENDS the above method for manual key configuration. However, it MAY also be used with automated key configuration. When manually configured, the method suffers from impersonation attacks as mentioned in the Security Considerations section.

9.  Rekeying

To maintain the security of a link, the authentication and encryption key values SHOULD be changed periodically.

9.1.  Rekeying Procedure

The following three-step procedure SHOULD be provided to rekey the routers on a link without dropping PIM-SM protocol packets or disrupting the adjacency.

1. For every router on the link, create an additional inbound SA for the interface being rekeyed using a new SPI and the new key.
2. For every router on the link, replace the original outbound SA with one using the new SPI and key values. The SA replacement operation should be atomic with respect to sending PIM-SM packets on the link, so that no PIM-SM packets are sent without authentication/encryption
3. For every router on the link, remove the original inbound SA.

Note that all routers on the link must complete step 1 before any begin step 2. Likewise, all the routers on the link must complete step 2 before any begin step 3.

One way to control the progression from one step to another is for each router to have a configurable time constant KeyRolloverInterval. After the router begins step 1 on a given link, it waits for this interval and then moves to step 2. Likewise, after moving to step 2, it waits for this interval and then moves to step 3.

In order to achieve smooth key transition, all routers on a link should use the same value for KeyRolloverInterval and should initiate the key rollover process within this time period.

At the end of this time period, all the routers on the link will have a single inbound and outbound SA for PIM-SM with the new SPI and key values.

9.2.  KeyRollover Interval

The configured value of KeyRolloverInterval should be long enough to allow the administrator to change keys on all the PIM-SM routers. As this value can vary significantly depending on the implementation and the deployment, it is left to the administrator to choose an appropriate value.

9.3.  Rekeying Interval

This section analyzes the security provided by manual keying and recommends that the encryption and authentication keys SHOULD be changed at least every 90 days.

The weakest security provided by the security mechanisms discussed in this specification is when NULL encryption (for ESP) or no encryption (for AH) is used with the HMAC-MD5 authentication. Any other algorithm combinations will be at least as hard to break as the ones mentioned above. This is shown by the following reasonable assumptions:

• NULL Encryption and HMAC-SHA-1 Authentication will be more secure as HMAC-SHA-1 is considered to be more secure than HMAC-MD5.
• NON-NULL Encryption and NULL Authentication combination is not applicable as this specification mandates authentication when PIM-SM security is enabled.
• Data Encryption Security (DES) Encryption and HMAC-MD5 Authentication will be more secure because of the additional security provided by DES.
• Other encryption algorithms such as 3DES and the Advanced Encryption Standard (AES) will be more secure than DES.

RFC 3562 [RFC3562] (Leech, M., “Key Management Considerations for the TCP MD5 Signature Option,” July 2003.) analyzes the rekeying requirements for the TCP MD5 signature option. The analysis provided in RFC 3562 is also applicable to this specification as the analysis is independent of data patterns.

10.  IPsec Protection Barrier and GSPD

10.1.  Manual Keying

10.1.1.  SAD Entries

The Administrator must configure the necessary Security Associations. Each SA entry has the Source Address of an authorized peer, and a Destination Address of ALL_PIM_ROUTERS. Unique SPI values for the manually configured SAs MUST be assigned by the Administrator, to ensure that the SPI does not conflict with existing SPI values in the SAD.

10.1.2.  SPD Entries

The Administrator must configure the necessary SPD entries. The SPD entry must ensure that any outbound IP traffic packet traversing the IPsec boundary, with PIM as its next layer protocol, PIM message type of Hello, Join/Prune, bootstrap or Assert, sent to the Destination Address of ALL_PIM_ROUTERS, is protected by AH. If the IPsec implementation does not identify PIM message types as a selector, the "local port" selector can be used, with suitable adjustment.

10.2.  Automatic Keying

When automatic keying is used, the SA creation is done dynamically using a group key management protocol. The GSPD and PAD tables are configured by the Administrator. The PAD table provides the link between the IPsec subsystem and the group key management protocol. For automatic keying, the implementation MUST support the multicast extensions described in [I‑D.ietf‑msec‑ipsec‑extensions] (Weis, B., Gross, G., and D. Ignjatic, “Multicast Extensions to the Security Architecture for the Internet Protocol,” June 2008.).

10.2.1.  SAD Entries

All PIM routers participate in an authentication scheme that identifies permitted neighbors and achieves peer authentication during SA negotiation, leading to child SAs being established and saved in the SAD.

10.2.2.  GSPD Entries

The Administrator must configure the necessary GSPD entries for "send only" directionality. This rule MUST trigger the group key management protocol for a registration exchange. This exchange will set up the outbound SAD entry that encrypts the multicast PIM control message. Considering that this rule is "sender only", no inbound SA is created in the reverse direction.

In addition, the registration exchange will install GSPD entries corresponding to each legitimate peer router, with direction "receive only".

To account for new, legitimate neighbors, the Administrator MUST configure a GSPD entry for "any" peer router, destined to the ALL_PIM_ROUTERS address. This entry will trigger a query to the group key management protocol, to establish the legitimacy (or lack of it) of the new peer, and install the necessary SAD "receive only" entry.

10.2.3.  PAD Entries

The PAD will be configured with information to permit identification of legitimate group members and senders. Procedures for doing this are out-of-scope for this document.

11.  Security Association Lookup

For an SA that carries unicast traffic, three parameters (SPI, destination address and security protocol type (AH or ESP)) are used in the Security Association lookup process for inbound packets. The SPI is sufficient to specify an SA. However, an implementation may use the SPI in conjunction with the IPsec protocol type (AH or ESP) for the SA lookup process. According to RFC 4301 [RFC4301] (Kent, S. and K. Seo, “Security Architecture for the Internet Protocol,” December 2005.) and the AH specification [RFC4302] (Kent, S., “IP Authentication Header,” December 2005.), for multicast SAs, in conjunction with the SPI, the destination address or the destination address plus the sender address may also be used in the SA lookup. The security protocol field is not employed for a multicast SA lookup.

The reason for the various prohibitions in the IPsec RFCs concerning multisender multicast SAs lies in the difficulty of coordinating the multiple senders. However, if the use of multicast for link-local messages is examined, it may be seen that in fact the communication need not be coordinated---from the prospective of a receiving router, each peer router is an independent sender. In effect, link-local communication is an SSM communication that happens to use an ASM address (which is shared among all the routers).

Given that it is always possible to distinguish a connection using IPsec from a connection not using IPsec, it is recommended that the address ALL_PIM_ROUTERS be used, to maintain consistency with present practice.

Given that the sender address of an incoming packet may be only locally unique (because of the use of link-local addresses), it will be necessary for a receiver to use the interface ID tag to sort out the associated SA for that sender. Therefore, this document mandates that the interface ID tag, the SPI and the sender address MUST be used in the SA lookup process.

12.  Activating the Anti-replay Mechanism

Although link-level messages on a link constitute a multiple-sender, multiple-receiver group, the use of the interface ID tag and sender address for SA lookup essentially resolves the communication into a separate SA for each sender/destination pair, even for the case where only two SAs (with identical SA parameters) are used for the entire administrative region. Therefore, the statement in the AH RFC (section 2.5 of [RFC4302] (Kent, S., “IP Authentication Header,” December 2005.)) that "for a multi-sender SA, the anti-replay features are not available" becomes irrelevant to the PIM-SM link-local message exchange.

To activate the anti-replay mechanism in a unicast communication, the receiver uses the sliding window protocol and it maintains a sequence number for this protocol. This sequence number starts from zero. Each time the sender sends a new packet, it increments this number by one. In a multi-sender multicast group communication, a single sequence number for the entire group would not be enough.

The whole scenario is different for PIM link-local messages. These messages are sent to local links with TTL = 1. A link-local message never propagates through one router to another. The use of the sender address and the interface ID tag for SA lookup converts the relationship from a multiple-sender group to multiple single-sender associations. This specification RECOMMENDS activation of the anti-replay mechanism only if the SAs are assigned using an automated key management procedure. In manual key management, the anti-replay SHOULD NOT be activated. If the number of router(s) to be assigned manually is small, the Network Administrator MAY consider to activate anti-replay. If anti-replay is activated a PIM router MUST maintain a different sliding window for each directly connected sender.

If the SAs are activated according to Figure 3, that is all the nodes use only two SAs, one SA for sending and the other is for receiving traffic, a PIM router MAY still activate the anti-replay mechanism. Instead of maintaining only two SAs, the router will maintain the same number of SAs as explained in the first method (see Figure 2) (because of the differentiation based on sender address). For each active SA a corresponding sequence number MUST be maintained. Thus, a PIM router will maintain a number of identical SAs, except that the sender address, interface ID tag and the sequence number are different for each SA. In this way a PIM router will be at least free from all the attacks that can be performed by replaying PIM-SM packets.

Note that when activating anti-replay with manual key configuration, the following actions must be taken by the network administrator:

a.

If a new router is added, the Network Administrator MUST add a new SA entry in each peer router.

b.

If an existing router has to restart, the Network Administrator MUST refresh the counter (ESN, see Section 14 (Extended Sequence Number)) to zero for all the peer routers. This implies deleting all the existing SAs and adding a new SA with the same configuration and a re-initialized counter.

13.  Implementing a Security Association Database per Interface

RFC 4601 suggests that it may be desirable to implement a separate Security Association Database (SAD) for each router interface. The use of link-local addresses in certain circumstances implies that differentiation of ambiguous speaker addresses requires the use of the interface ID tag in the SA lookup. One way to do this is through the use of multiple SADs. Alternatively, the interface ID tag may be a specific component of the selector algorithm. This is in conformance with RFC 4301, which explicitly removes the requirement for separate SADs that was present in RFC 2401 [RFC2401] (Kent, S. and R. Atkinson, “Security Architecture for the Internet Protocol,” November 1998.).

14.  Extended Sequence Number

In the [RFC4302] (Kent, S., “IP Authentication Header,” December 2005.), there is a provision for a 64-bit Extended Sequence Number (ESN) as the counter of the sliding window used in the anti-replay protocol. Both the sender and the receiver maintain a 64-bit counter for the sequence number, although only the lower order 32 bits is sent in the transmission. In other words, it will not affect the present header format of AH. If ESN is used, a sender router can send 2^64 -1 packets without any intervention. This number is very large, and from a PIM router's point of view, a PIM router can never exceed this number in its lifetime. This makes it reasonable to permit manual configuration for a small number of PIM routers, since the sequence number will never roll over. For this reason, when manual configuration is used, ESN SHOULD be deployed as the sequence number for the sliding window protocol.

15.  Security Considerations

The whole document considers the security issues of PIM link-local messages and proposes a mechanism to protect them.

Limitations of manual keys:

The following are some of the known limitations of the usage of manual keys.

• If replay protection cannot be provided, the PIM routers will not be secured against all the attacks that can be performed by replaying PIM packets.
• Manual keys are usually long lived (changing them often is a tedious task). This gives an attacker enough time to discover the keys.
• As the administrator is manually configuring the keys, there is a chance that the configured keys are weak (there are known weak keys for DES/3DES at least).

Impersonation attacks:

The usage of the same key on all the PIM routers connected to a link leaves them all insecure against impersonation attacks if any one of the PIM routers is compromised, malfunctioning, or misconfigured.

Detailed analysis of various vulnerabilities of routing protocols is provided in RFC 4593 (Barbir, A., Murphy, S., and Y. Yang, “Generic Threats to Routing Protocols,” October 2006.) [RFC4593]. For further discussion of PIM-SM and multicast security the reader is referred to RFC 5294 (Savola, P. and J. Lingard, “Host Threats to Protocol Independent Multicast (PIM),” August 2008.) [RFC5294], RFC 4609 (Savola, P., Lehtonen, R., and D. Meyer, “Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements,” October 2006.) [RFC4609] and the Security Considerations section of RFC 4601 (Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, “Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised),” August 2006.) [RFC4601].

16.  IANA Considerations

This document has no actions for IANA.

17.  References

17.1. Normative References

17.2. Informative References

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.