Internet Engineering Task Force (IETF) W. Atwood Request for Comments: 5796 Concordia University/CSE Updates: 4601 S. Islam Category: Standards Track IRS-EMT ISSN: 2070-1721 M. Siami Concordia University/CIISE March 2010 Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages
AbstractRFC 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) Encapsulating Security Payload (ESP) or (optionally) the Authentication Header (AH). 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, optional support for an automated group key management mechanism is provided. However, the procedures for implementing automated group key management are left to other documents. This document updates RFC 4601. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5796.
Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
1. Introduction ....................................................4 1.1. Goals and Non-Goals ........................................4 2. Terminology .....................................................5 3. Transport Mode versus Tunnel Mode ...............................5 4. Authentication ..................................................5 5. Confidentiality .................................................6 6. IPsec Requirements ..............................................6 7. Key Management ..................................................8 7.1. Manual Key Management ......................................8 7.2. Automated Key Management ...................................8 7.3. Communications Patterns ....................................9 7.4. Neighbor Relationships ....................................10 8. Number of Security Associations ................................11 9. Rekeying .......................................................12 9.1. Manual Rekeying Procedure .................................13 9.2. KeyRolloverInterval .......................................14 9.3. Rekeying Interval .........................................14 10. IPsec Protection Barrier and SPD/GSPD .........................14 10.1. Manual Keying ............................................14 10.1.1. SAD Entries .......................................14 10.1.2. SPD Entries .......................................14 10.2. Automatic Keying .........................................15 10.2.1. SAD Entries .......................................15 10.2.2. GSPD Entries ......................................15 10.2.3. PAD Entries .......................................15 11. Security Association Lookup ...................................16 12. Activating the Anti-Replay Mechanism ..........................16 13. Implementing a Security Policy Database per Interface .........17 14. Extended Sequence Number ......................................17 15. Security Considerations .......................................18 16. Acknowledgements ..............................................18 17. References ....................................................19 17.1. Normative References .....................................19 17.2. Informative References ...................................19
RFC4601] control messages have IP protocol number 103. Some control messages are unicast; the rest are multicast with Time to Live (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 (126.96.36.199 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]. The effects of these forged messages are outlined in Section 6.1 of [RFC4601]. Some of the effects are very severe, whereas some are minor. PIM-SM version 2 was originally specified in RFC 2117 [RFC2117], and revised in RFC 2362 [RFC2362] 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 Authentication Header (AH) specification described in RFC 4302 [RFC4302]. Securing the unicast messages can be achieved by the use of a normal unicast IPsec Security Association (SA) between the two communicants. 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 [RFC4303], and to bring the PIM-SM specification into alignment with the new AH and ESP specifications. In particular, in accordance with RFC 4301, the use of ESP is made mandatory and AH is specified as optional. This document specifies 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 first goal implies that each router has a unique identity. It is possible (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 unique 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 Peer Authorization Database (PAD) (see RFC 4301 [RFC4301]) or the Group Security Policy Database (GSPD) (see RFC 5374 [RFC5374]) in each router. Procedures for controlling the adjacency and building the associated PAD and GSPD are out of scope for this document. RFC2119]. They indicate requirement levels for compliant PIM-SM implementations. Section 3.1 of RFC 5374 [RFC5374]. RFC2404].
In order to provide authentication of PIM-SM link-local messages, implementations MUST support ESP [RFC4303] and MAY support AH [RFC4302]. If ESP in transport mode is used, it will only provide authentication to PIM-SM protocol packets excluding the IP header, extension headers, and options. If AH in transport mode is used, it will provide authentication to PIM-SM protocol packets, selected portions of the IP header, extension headers and options. Note: when authentication for PIM-SM link-local messages is enabled, o PIM-SM link-local packets that are not protected with AH or ESP will be silently discarded by IPsec, although the implementation of IPsec may maintain a counter of such packets. o PIM-SM link-local packets that fail the authentication checks will be silently discarded by IPsec, although the implementation of IPsec may maintain a counter of such packets. RFC3602] with a 128-bit key. If confidentiality is provided, ESP MUST be used. Since authentication MUST be supported by a conforming implementation, an implementation MUST NOT generate the combination of NON-NULL Encryption and NULL Authentication. Note: when confidentiality for PIM-SM link-local packets is enabled, o PIM-SM packets that are not protected with ESP will be silently discarded by IPsec, although the implementation of IPsec may maintain a counter of such packets.
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) on which they arrived. Manual key support It MUST be possible to use manually configured keys to secure the specified traffic. Encryption and authentication algorithms Encryption and authentication algorithm requirements described in RFC 4835 [RFC4835] apply when ESP and AH are used to protect PIM-SM. Implementations MUST support ESP-NULL, and if providing confidentiality, MUST support the ESP transforms providing confidentiality required by [RFC4835]. However, in any case, implementations MUST NOT allow the user to choose a stream cipher or block mode cipher in counter mode for use with manual keys. Encapsulation of ESP packets IP encapsulation of ESP packets MUST be supported. For simplicity, UDP encapsulation of ESP packets SHOULD NOT be used. If the automatic keying features of this specification are implemented, the following additional IPsec capabilities are required: Group Security Policy Database (GSPD) The implementation MUST support the GSPD that is described in RFC 5374 [RFC5374]. Multiple Group Security Policy Databases The implementation MUST support multiple GSPDs with a GSPD selection function that provides an ability to choose a specific GSPD based on interface. Selectors The implementation MUST be able to use source address, destination address, protocol and direction as selectors in the GSPD.
RFC3547] or Group Secure Association Key Management Protocol (GSAKMP) [RFC4535] to establish these SAs. RFC3547], 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 to be trusted parties. It is possible that a subset of GDOI functionalities will be sufficient. Another option is to use the Group Secure Association Key Management Protocol (GSAKMP) [RFC4535].
Section 11), 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, with a separate sequence-number space, 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 Group Controller/Key Server (GC/KS) that is used for the management of the keys 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. As such, this may be a useful approach even in the PIM-SM case. This approach 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. Section 8), then the key server will need to be aware of the adjacencies of each speaker. Procedures for managing and distributing these adjacencies are out of scope for this document.
Figures 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 <------------| +++++ | | +++++ SAb <------------| + + ---->| + + / + A + SAa ------- + + \ + + ---->| +++++ SAc <------------| | +++++ | + C + SAc ------------>| + + SAa <------------| +++++ | | Directly connected network Figure 2: Activate unique Security Association for each peer The first method, shown in Figure 2, SHOULD be supported by every implementation. 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 include the source address when searching the SAD for a match. Router 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 routers is small.
| +++++ | + B + SAo ------------>| + + SAi <------------| +++++ | | +++++ 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 (i.e., SAo and SAi) are used in this method, the SA parameters (keys, Security Parameter Index (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 this second method for manual key configuration. However, it MAY also be used with automated key configuration. RFC4107]. In PIM-SM deployments it is expected that secure sessions will be relatively long-lived, and it is not expected that keys will be significantly exposed through normal operational activity. Manual keying is judged acceptable in the light of the relatively low rate of change that is required.
To maintain the security of a link, the authentication and encryption key values SHOULD be changed periodically, to limit the risk of undetected key disclosure. Keys SHOULD also be changed when there is a change of trusted personnel. Manual keying offers the ability to change keys in a coordinated way, but it has several drawbacks in PIM-SM systems. Some of these are listed in Section 15 ("Security Considerations") of this document. According to an analysis in line with RFC 4107 [RFC4107], PIM-SM would benefit from automated key management and roll over because all the disadvantages of manual keys listed in Section 15 would be eliminated. However, suitable techniques for automated key management do not currently exist. Work is in hand in the IETF to develop suitable solutions. In the meantime, implementations MUST support manual rekeying as described below. Implementers and deployers need to be aware of the requirement to upgrade to support automated key management as soon as suitable techniques are available. RFC4107], the following three-step procedure provides a possible mechanism to rekey the routers on a link without dropping PIM-SM protocol packets or disrupting the adjacency, while ensuring that it is always clear which key is being used. 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 MUST 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 MUST use the same value for KeyRolloverInterval and MUST 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.
RFC4301], 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. This applies to both ESP and AH. The security protocol field is not employed for a multicast SA lookup. Given that, from the prospective of a receiving router, each peer router is an independent sender and given that the destination address will be the same for all senders, the receiving router MUST use SPI plus destination address plus sender address when performing the SA lookup. In effect, link-local communication is an SSM communication that happens to use an Any-Source Multicast (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 is necessary for a receiver to use the interface ID tag to determine 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. Section 2.5 of [RFC4302]) 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. If manual key management is used, the anti- replay SHOULD NOT be activated. If an existing router has to restart, in accordance with RFC 4303 [RFC4303], the sequence-number counter at the sender MUST be correctly maintained across local reboots, etc., until the key is replaced. RFC 4601 suggests that it may be desirable to implement a separate Security Policy Database (SPD) 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 SPDs. 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 SPDs that was present in RFC 2401 [RFC2401]. RFC4302], 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 are 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. In addition,
when an ESN is used with a manually keyed SA, it MUST be saved over a reboot, along with an indication of which sequence numbers have been used. RFC4593]. For further discussion of PIM-SM and multicast security, the reader is referred to RFC 5294 [RFC5294], RFC 4609 [RFC4609], and the Security Considerations section of RFC 4601 [RFC4601]. RFC4552]. The authors of this document thank M. Gupta and N. Melam for permission to do this. The quality of this document was substantially improved after SECDIR pre-review by Brian Weis, and after AD review by Adrian Farrel.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007. [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast Extensions to the Security Architecture for the Internet Protocol", RFC 5374, November 2008. [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998. [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003. [RFC2117] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2117, June 1997. [RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., and V. Jacobson, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006. [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003. [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006. [RFC5294] Savola, P. and J. Lingard, "Host Threats to Protocol Independent Multicast (PIM)", RFC 5294, August 2008. [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements", RFC 4609, October 2006. [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006. [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
http://users.encs.concordia.ca/~bill Salekul Islam INRS Energie, Materiaux et Telecommunications 800 de La Gauchetiere, Suite 800 Montreal, QC H5A 1K6 Canada EMail: Salekul.Islam@emt.inrs.ca URI: http://users.encs.concordia.ca/~salek_is Maziar Siami Concordia University/CIISE 1455 de Maisonneuve Blvd. West Montreal, QC H3G 1M8 Canada EMail: email@example.com