draft-ietf-pim-sm-linklocal-06.txt   draft-ietf-pim-sm-linklocal-07.txt 
PIM Working Group W. Atwood PIM Working Group W. Atwood
Internet-Draft Concordia University/CSE Internet-Draft Concordia University/CSE
Updates: 4601 (if approved) S. Islam Updates: 4601 (if approved) S. Islam
Intended status: Standards Track INRS Energie, Materiaux et Intended status: Standards Track INRS Energie, Materiaux et
Expires: August 8, 2009 Telecommunications Expires: August 30, 2009 Telecommunications
M. Siami M. Siami
Concordia University/CIISE Concordia University/CIISE
February 04, 2009 February 26, 2009
Authentication and Confidentiality in PIM-SM Link-local Messages Authentication and Confidentiality in PIM-SM Link-local Messages
draft-ietf-pim-sm-linklocal-06 draft-ietf-pim-sm-linklocal-07
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 8, 2009. This Internet-Draft will expire on August 30, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
RFC 4601 mandates the use of IPsec to ensure authentication of the RFC 4601 mandates the use of IPsec to ensure authentication of the
link-local messages in the Protocol Independent Multicast - Sparse link-local messages in the Protocol Independent Multicast - Sparse
Mode (PIM-SM) routing protocol. This document specifies mechanisms Mode (PIM-SM) routing protocol. This document specifies mechanisms
to authenticate the PIM-SM link local messages using the IP security to authenticate the PIM-SM link-local messages using the IP security
(IPsec) Encapsulating Security Payload (ESP) or (optionally) the (IPsec) Encapsulating Security Payload (ESP) or (optionally) the
Authentication Header (AH). It specifies optional mechanisms to Authentication Header (AH). It specifies optional mechanisms to
provide confidentiality using the ESP. Manual keying is specified as provide confidentiality using the ESP. Manual keying is specified as
the mandatory and default group key management solution. To deal the mandatory and default group key management solution. To deal
with issues of scalability and security that exist with manual with issues of scalability and security that exist with manual
keying, an optional support for automated group key management keying, an optional support for automated group key management
mechanism is provided. However, the procedures for implementing mechanism is provided. However, the procedures for implementing
automated group key management are left to other documents. This automated group key management are left to other documents. This
document updates RFC 4601. document updates RFC 4601.
skipping to change at page 3, line 21 skipping to change at page 3, line 21
4. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Confidentiality . . . . . . . . . . . . . . . . . . . . . . . 9 5. Confidentiality . . . . . . . . . . . . . . . . . . . . . . . 9
6. IPsec Requirements . . . . . . . . . . . . . . . . . . . . . . 10 6. IPsec Requirements . . . . . . . . . . . . . . . . . . . . . . 10
7. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Manual Key Management . . . . . . . . . . . . . . . . . . 12 7.1. Manual Key Management . . . . . . . . . . . . . . . . . . 12
7.2. Automated Key Management . . . . . . . . . . . . . . . . . 12 7.2. Automated Key Management . . . . . . . . . . . . . . . . . 12
7.3. Communications Patterns . . . . . . . . . . . . . . . . . 13 7.3. Communications Patterns . . . . . . . . . . . . . . . . . 13
7.4. Neighbor Relationships . . . . . . . . . . . . . . . . . . 15 7.4. Neighbor Relationships . . . . . . . . . . . . . . . . . . 15
8. Number of Security Associations . . . . . . . . . . . . . . . 16 8. Number of Security Associations . . . . . . . . . . . . . . . 16
9. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Rekeying Procedure . . . . . . . . . . . . . . . . . . . . 18 9.1. Manual Rekeying Procedure . . . . . . . . . . . . . . . . 18
9.2. KeyRollover Interval . . . . . . . . . . . . . . . . . . . 18 9.2. KeyRollover Interval . . . . . . . . . . . . . . . . . . . 18
9.3. Rekeying Interval . . . . . . . . . . . . . . . . . . . . 19 9.3. Rekeying Interval . . . . . . . . . . . . . . . . . . . . 19
10. IPsec Protection Barrier and SPD/GSPD . . . . . . . . . . . . 20 10. IPsec Protection Barrier and SPD/GSPD . . . . . . . . . . . . 20
10.1. Manual Keying . . . . . . . . . . . . . . . . . . . . . . 20 10.1. Manual Keying . . . . . . . . . . . . . . . . . . . . . . 20
10.1.1. SAD Entries . . . . . . . . . . . . . . . . . . . . . 20 10.1.1. SAD Entries . . . . . . . . . . . . . . . . . . . . . 20
10.1.2. SPD Entries . . . . . . . . . . . . . . . . . . . . . 20 10.1.2. SPD Entries . . . . . . . . . . . . . . . . . . . . . 20
10.2. Automatic Keying . . . . . . . . . . . . . . . . . . . . . 20 10.2. Automatic Keying . . . . . . . . . . . . . . . . . . . . . 20
10.2.1. SAD Entries . . . . . . . . . . . . . . . . . . . . . 20 10.2.1. SAD Entries . . . . . . . . . . . . . . . . . . . . . 20
10.2.2. GSPD Entries . . . . . . . . . . . . . . . . . . . . 20 10.2.2. GSPD Entries . . . . . . . . . . . . . . . . . . . . 20
10.2.3. PAD Entries . . . . . . . . . . . . . . . . . . . . . 21 10.2.3. PAD Entries . . . . . . . . . . . . . . . . . . . . . 21
11. Security Association Lookup . . . . . . . . . . . . . . . . . 22 11. Security Association Lookup . . . . . . . . . . . . . . . . . 22
12. Activating the Anti-replay Mechanism . . . . . . . . . . . . . 23 12. Activating the Anti-replay Mechanism . . . . . . . . . . . . . 23
13. Implementing a Security Association Database per Interface . . 25 13. Implementing a Security Policy Database per Interface . . . . 24
14. Extended Sequence Number . . . . . . . . . . . . . . . . . . . 26 14. Extended Sequence Number . . . . . . . . . . . . . . . . . . . 25
15. Security Considerations . . . . . . . . . . . . . . . . . . . 27 15. Security Considerations . . . . . . . . . . . . . . . . . . . 26
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
18.1. Normative References . . . . . . . . . . . . . . . . . . . 30 18.1. Normative References . . . . . . . . . . . . . . . . . . . 29
18.2. Informative References . . . . . . . . . . . . . . . . . . 30 18.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
All the PIM-SM [RFC4601] control messages have IP protocol number All the PIM-SM [RFC4601] control messages have IP protocol number
103. These messages are either unicast, or multicast with TTL = 1. 103. These messages are either unicast, or multicast with TTL = 1.
The source address used for unicast messages is a domain-wide The source address used for unicast messages is a domain-wide
reachable address. For the multicast messages, a link-local address reachable address. For the multicast messages, a link-local address
of the interface on which the message is being sent is used as the of the interface on which the message is being sent is used as the
source address and a special multicast address, ALL_PIM_ROUTERS 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 (224.0.0.13 in IPv4 and ff02::d in IPv6) is used as the destination
skipping to change at page 4, line 30 skipping to change at page 4, line 30
of the effects are very severe, whereas some are minor. of the effects are very severe, whereas some are minor.
PIM-SM version 2 was originally specified in RFC 2117, and revised in 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 RFC 2362 and RFC 4601. RFC 4601 obsoletes RFC 2362, and corrects a
number of deficiencies. The Security Considerations section of RFC number of deficiencies. The Security Considerations section of RFC
4601 is based primarily on the Authentication Header (AH) 4601 is based primarily on the Authentication Header (AH)
specification described in RFC 4302 [RFC4302]. specification described in RFC 4302 [RFC4302].
Securing the unicast messages can be achieved by the use of a normal Securing the unicast messages can be achieved by the use of a normal
unicast IPsec Security Association between the two communicants. unicast IPsec Security Association between the two communicants.
Securing the user data exchanges is covered in RFC 3740 [RFC3740].
This document focuses on the security issues for link-local messages. This document focuses on the security issues for link-local messages.
It provides some guidelines to take advantage of the new permitted AH It provides some guidelines to take advantage of the new permitted AH
functionality in RFC 4302 and the new permitted ESP functionality in functionality in RFC 4302 and the new permitted ESP functionality in
RFC 4303 [RFC4303], and to bring the PIM-SM specification into RFC 4303 [RFC4303], and to bring the PIM-SM specification into
alignment with the new AH and ESP specifications. In particular, in 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 accordance with RFC 4301, the use of ESP is made mandatory and AH is
specified as optional. This document recommends manual key specified as optional. This document specifies manual key management
management as mandatory to implement, i.e., that all implementations as mandatory to implement, i.e., that all implementations MUST
MUST support, and provides the necessary structure for an automated support, and provides the necessary structure for an automated key
key management protocol that the PIM routers may use. management protocol that the PIM routers may use.
1.1. Goals and Non-goals 1.1. Goals and Non-goals
The primary goal for link-local security is to provide data origin The primary goal for link-local security is to provide data origin
authentication for each link-local message. A secondary goal is to authentication for each link-local message. A secondary goal is to
ensure that communication only happens between legitimate peers ensure that communication only happens between legitimate peers
(i.e., adjacent routers). An optional goal is to provide data (i.e., adjacent routers). An optional goal is to provide data
confidentiality for the link-local messages. confidentiality for the link-local messages.
The first goal implies that each router has a unique identity. It is The first goal implies that each router has a unique identity. It is
skipping to change at page 5, line 16 skipping to change at page 5, line 15
router, or be part of a region-wide public key infrastructure.) The router, or be part of a region-wide public key infrastructure.) The
existence of this unique identity is assumed in this specification, existence of this unique identity is assumed in this specification,
but procedures for establishing it are out-of-scope for this but procedures for establishing it are out-of-scope for this
document. document.
The second goal implies that there is some form of "adjacency matrix" The second goal implies that there is some form of "adjacency matrix"
that controls the establishment of security associations among that controls the establishment of security associations among
adjacent multicast routers. For manual keying, this control will be adjacent multicast routers. For manual keying, this control will be
exercised by the Administrator of the router(s), through the setting exercised by the Administrator of the router(s), through the setting
of initialization parameters. For automated keying, the existence of of initialization parameters. For automated keying, the existence of
this control will be reflected by the contents of the Permitted this control will be reflected by the contents of the Peer
Access Database and the Group Security Policy Database (GSPD) in each Authorization Database (PAD) and the Group Security Policy Database
router. Procedures for controling the adjacency and building the (GSPD) in each router. Procedures for controling the adjacency and
asssociated PAD and GSPD are out-of-scope for this document. building the asssociated PAD and GSPD are out-of-scope for this
document.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
They indicate requirement levels for compliant PIM-SM They indicate requirement levels for compliant PIM-SM
implementations. implementations.
3. Transport Mode vs. Tunnel Mode 3. Transport Mode vs. Tunnel Mode
The transport mode Security Association (SA) is generally used As stated in Section 4.1 of RFC 4301 [RFC4301], a transport mode
between two hosts or routers/gateways when they are acting as hosts. Security Association (SA) is generally used between two hosts or
The SA must be a tunnel mode SA if either end of the security routers/gateways when they are acting as hosts. The SA must be a
association is a router/gateway. Two hosts MAY establish a tunnel tunnel mode SA if either end of the security association is acting as
mode SA between themselves. PIM-SM link-local messages are exchanged a router/gateway. Two hosts MAY establish a tunnel mode SA between
between routers. However, since the packets are locally delivered, themselves. PIM-SM link-local messages are exchanged between
the routers assume the role of hosts in the context of the tunnel routers. However, since the packets are locally delivered, the
mode SA. All implementations conforming to this specification MUST 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 support transport mode SA to provide required IPsec security to
PIM-SM link-local messages. They MAY also support tunnel mode SA to PIM-SM link-local messages. They MAY also support tunnel mode SA to
provide required IPsec security to PIM-SM link-local messages. provide required IPsec security to PIM-SM link-local messages.
4. Authentication 4. Authentication
Implementations conforming to this specification MUST support Implementations conforming to this specification MUST support
authentication for PIM-SM link-local messages. authentication for PIM-SM link-local messages. Implementations
conforming to this specification MUST support HMAC-SHA1.
In order to provide authentication to PIM-SM link-local messages, In order to provide authentication to PIM-SM link-local messages,
implementations MUST support ESP [RFC4303] and MAY support AH implementations MUST support ESP [RFC4303] and MAY support AH
[RFC4302]. [RFC4302].
If ESP in transport mode is used, it will only provide authentication If ESP in transport mode is used, it will only provide authentication
to PIM-SM protocol packets excluding the IP header, extension to PIM-SM protocol packets excluding the IP header, extension
headers, and options. headers, and options.
If AH in transport mode is used, it will provide authentication to If AH in transport mode is used, it will provide authentication to
skipping to change at page 9, line 8 skipping to change at page 9, line 8
o PIM-SM link-local packets that are not protected with AH or ESP o PIM-SM link-local packets that are not protected with AH or ESP
MUST be silently discarded. MUST be silently discarded.
o PIM-SM link-local packets that fail the authentication checks MUST o PIM-SM link-local packets that fail the authentication checks MUST
be silently discarded. be silently discarded.
5. Confidentiality 5. Confidentiality
Implementations conforming to this specification SHOULD support Implementations conforming to this specification SHOULD support
confidentiality for PIM-SM. confidentiality for PIM-SM. Implementations supporting
confidentiality MUST support AES-CBC with a 128-bit key.
If confidentiality is provided, ESP MUST be used. If confidentiality is provided, ESP MUST be used.
When PIM-SM confidentiality is enabled, When PIM-SM confidentiality is enabled,
o PIM-SM packets that are not protected with ESP MUST be silently o PIM-SM packets that are not protected with ESP MUST be silently
discarded. discarded.
o PIM-SM packets that fail the confidentiality checks MUST be o PIM-SM packets that fail the confidentiality checks MUST be
silently discarded. silently discarded.
Note that since authentication MUST be supported by a conforming
implementation, the combination of NON-NULL Encryption and NULL
Authentication is NOT permitted.
6. IPsec Requirements 6. IPsec Requirements
In order to implement this specification, the following IPsec In order to implement this specification, the following IPsec
capabilities are required. capabilities are required.
Transport mode Transport mode
IPsec in transport mode MUST be supported. IPsec in transport mode MUST be supported.
Multiple Security Policy Databases (SPDs) Multiple Security Policy Databases (SPDs)
The implementation MUST support multiple SPDs with an SPD The implementation MUST support multiple SPDs with an SPD
skipping to change at page 10, line 32 skipping to change at page 10, line 32
Interface ID tagging Interface ID tagging
The implementation MUST be able to tag the inbound packets with The implementation MUST be able to tag the inbound packets with
the ID of the interface (physical or virtual) via which it the ID of the interface (physical or virtual) via which it
arrived. arrived.
Manual key support Manual key support
Manually configured keys MUST be able to secure the specified Manually configured keys MUST be able to secure the specified
traffic. traffic.
Encryption and authentication algorithms Encryption and authentication algorithms
The implementation MUST NOT allow the user to choose stream Encryption and authentication algorithm requirements described in
ciphers as the encryption algorithm for securing PIM-SM packets RFC 4835 [RFC4835] apply when ESP and AH are used to protect
since the stream ciphers are not suitable for manual keys. Except PIM-SM. Implementations MUST support ESP-NULL, and if providing
when in conflict with the above statement, the key words "MUST", confidentiality MUST support the RFC4835 [RFC4835] required ESP
"MUST NOT", "REQUIRED", "SHOULD", and "SHOULD NOT" that appear in transforms providing confidentiality. However, in any case,
RFC 4835 [RFC4835] for algorithms to be supported are to be implementations MUST NOT allow the user to choose a stream cipher
interpreted as described in RFC 2119 [RFC2119] for PIM-SM support or block mode cipher in counter mode for use with manual keys.
as well.
Encapsulation of ESP packet Encapsulation of ESP packet
IP encapsulation of ESP packets MUST be supported. For IP encapsulation of ESP packets MUST be supported. For
simplicity, UDP encapsulation of ESP packets SHOULD NOT be used. simplicity, UDP encapsulation of ESP packets SHOULD NOT be used.
If the automatic keying features of this specification are If the automatic keying features of this specification are
implemented, the following additional IPsec capabilities are implemented, the following additional IPsec capabilities are
required: required:
Group Security Policy Database (GSPD) Group Security Policy Database (GSPD)
skipping to change at page 12, line 52 skipping to change at page 12, line 52
using IPsec data encryption. GDOI has been developed to be used in using IPsec data encryption. GDOI has been developed to be used in
multicast applications, where the number of end users or devices may multicast applications, where the number of end users or devices may
be large and the end users or devices can dynamically join/leave a 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 multicast group. However, a PIM router is not expected to join/leave
very frequently, and the number of routers is small when compared to very frequently, and the number of routers is small when compared to
the possible number of users of a multicast application. Moreover, the possible number of users of a multicast application. Moreover,
most of the PIM routers will be located inside the same most of the PIM routers will be located inside the same
administrative domain and are considered as trusted parties. It is administrative domain and are considered as trusted parties. It is
possible that a subset of GDOI functionalities will be sufficient. 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]. A companion modification
for GDOI is presented in [I-D.weis-gdoi-for-rsvp].
Another option is to use the Group Secure Association Key Management Another option is to use the Group Secure Association Key Management
Protocol (GSAKMP) [RFC4535]. Protocol (GSAKMP) [RFC4535].
7.3. Communications Patterns 7.3. Communications Patterns
Before discussing the set of security associations that are required Before discussing the set of security associations that are required
to properly manage a multicast region that is under the control of a to properly manage a multicast region that is under the control of a
single administration, it is necessary to understand the single administration, it is necessary to understand the
communications patterns that will exist among the routers in this communications patterns that will exist among the routers in this
region. From the perspective of a speaking router, the information region. From the perspective of a speaking router, the information
skipping to change at page 16, line 36 skipping to change at page 16, line 36
SAc <------------| SAc <------------|
| |
C | C |
SAc ------------>| SAc ------------>|
SAa <------------| SAa <------------|
| |
Directly connected network Directly connected network
Figure 2: Activate unique Security Association for each peer Figure 2: Activate unique Security Association for each peer
The first method, shown in Figure 2 is OPTIONAL to implement. In 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. 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 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 traffic. Each node will include the source address when searching
source address. A will use SAb and SAc for packets received from B the SAD for a match. A will use SAb and SAc for packets received
and C, respectively. The number of SAs to be activated and 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 maintained by a PIM router will be equal to the number of directly
connected routers, plus one for sending its own traffic. Also, the connected routers, plus one for sending its own traffic. Also, the
addition of a PIM router in the network will require the addition of addition of a PIM router in the network will require the addition of
another SA on every directly connected PIM router. This solution another SA on every directly connected PIM router. This solution
will be scalable and practically feasible with an automated key will be scalable and practically feasible with an automated key
management protocol. However, it MAY be used with manual key management protocol. However, it MAY be used with manual key
management, if the number of directly connected routers is small. management, if the number of directly connected routers is small.
B | B |
SAo ------------>| SAo ------------>|
skipping to change at page 17, line 35 skipping to change at page 17, line 35
The second method, shown in Figure 3, MUST be supported by every The second method, shown in Figure 3, MUST be supported by every
implementation. In this simple method, all the nodes will use two implementation. In this simple method, all the nodes will use two
SAs, one for sending (SAo) and the other for receiving (SAi) traffic. 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 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 addition of a PIM router. Although two different SAs are used in
this method, the SA parameters (keys, Security Parameter Index (SPI), this method, the SA parameters (keys, Security Parameter Index (SPI),
etc.) for the two SAs are identical, i.e., the same information is etc.) for the two SAs are identical, i.e., the same information is
shared among all the routers in an administrative region. This shared among all the routers in an administrative region. This
document RECOMMENDS the above method for manual key configuration. document RECOMMENDS the above method for manual key configuration.
However, it MAY also be used with automated key configuration. When However, it MAY also be used with automated key configuration.
manually configured, the method suffers from impersonation attacks as
mentioned in the Security Considerations section.
9. Rekeying 9. Rekeying
To maintain the security of a link, the authentication and encryption To maintain the security of a link, the authentication and encryption
key values SHOULD be changed periodically. 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.
9.1. Rekeying Procedure 9.1. Manual Rekeying Procedure
The following three-step procedure SHOULD be provided to rekey the The following three-step procedure SHOULD be provided to rekey the
routers on a link without dropping PIM-SM protocol packets or routers on a link without dropping PIM-SM protocol packets or
disrupting the adjacency. disrupting the adjacency.
1. For every router on the link, create an additional inbound SA for 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. the interface being rekeyed using a new SPI and the new key.
2. For every router on the link, replace the original outbound SA 2. For every router on the link, replace the original outbound SA
with one using the new SPI and key values. The SA replacement with one using the new SPI and key values. The SA replacement
skipping to change at page 19, line 7 skipping to change at page 19, line 8
9.2. KeyRollover Interval 9.2. KeyRollover Interval
The configured value of KeyRolloverInterval should be long enough to The configured value of KeyRolloverInterval should be long enough to
allow the administrator to change keys on all the PIM-SM routers. As allow the administrator to change keys on all the PIM-SM routers. As
this value can vary significantly depending on the implementation and this value can vary significantly depending on the implementation and
the deployment, it is left to the administrator to choose an the deployment, it is left to the administrator to choose an
appropriate value. appropriate value.
9.3. Rekeying Interval 9.3. Rekeying Interval
This section analyzes the security provided by manual keying and In keeping with the goal of reducing key exposure, the encryption and
recommends that the encryption and authentication keys SHOULD be authentication keys SHOULD be changed at least every 90 days.
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:
o NULL Encryption and HMAC-SHA-1 Authentication will be more secure
as HMAC-SHA-1 is considered to be more secure than HMAC-MD5.
o NON-NULL Encryption and NULL Authentication combination is not
applicable as this specification mandates authentication when
PIM-SM security is enabled.
o Data Encryption Security (DES) Encryption and HMAC-MD5
Authentication will be more secure because of the additional
security provided by DES.
o Other encryption algorithms such as 3DES and the Advanced
Encryption Standard (AES) will be more secure than DES.
RFC 3562 [RFC3562] 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 SPD/GSPD 10. IPsec Protection Barrier and SPD/GSPD
10.1. Manual Keying 10.1. Manual Keying
10.1.1. SAD Entries 10.1.1. SAD Entries
The Administrator must configure the necessary Security Associations. The Administrator must configure the necessary Security Associations.
Each SA entry has the Source Address of an authorized peer, and a Each SA entry has the Source Address of an authorized peer, and a
Destination Address of ALL_PIM_ROUTERS. Unique SPI values for the Destination Address of ALL_PIM_ROUTERS. Unique SPI values for the
manually configured SAs MUST be assigned by the Administrator, to manually configured SAs MUST be assigned by the Administrator, to
ensure that the SPI does not conflict with existing SPI values in the ensure that the SPI does not conflict with existing SPI values in the
SAD. SAD.
10.1.2. SPD Entries 10.1.2. SPD Entries
The Administrator must configure the necessary SPD entries. The SPD The Administrator must configure the necessary SPD entries. The SPD
entry must ensure that any outbound IP traffic packet traversing the entry must ensure that any outbound IP traffic packet traversing the
IPsec boundary, with PIM as its next layer protocol, PIM message type IPsec boundary, with PIM as its next layer protocol, and sent to the
of Hello, Join/Prune, Bootstrap or Assert, sent to the Destination Destination Address of ALL_PIM_ROUTERS, is protected by ESP or AH.
Address of ALL_PIM_ROUTERS, is protected by ESP or AH. If the IPsec Note that this characterization includes all the link-local messages
implementation does not identify PIM message types as a selector, the (Hello, Join/Prune, Bootstrap, Assert).
"local port" selector can be used, with suitable adjustment.
10.2. Automatic Keying 10.2. Automatic Keying
When automatic keying is used, the SA creation is done dynamically When automatic keying is used, the SA creation is done dynamically
using a group key management protocol. The GSPD and PAD tables are using a group key management protocol. The GSPD and PAD tables are
configured by the Administrator. The PAD table provides the link configured by the Administrator. The PAD table provides the link
between the IPsec subsystem and the group key management protocol. between the IPsec subsystem and the group key management protocol.
For automatic keying, the implementation MUST support the multicast For automatic keying, the implementation MUST support the multicast
extensions described in [RFC5374]. extensions described in [RFC5374].
skipping to change at page 21, line 5 skipping to change at page 20, line 52
10.2.2. GSPD Entries 10.2.2. GSPD Entries
The Administrator must configure the necessary GSPD entries for "send The Administrator must configure the necessary GSPD entries for "send
only" directionality. This rule MUST trigger the group key only" directionality. This rule MUST trigger the group key
management protocol for a registration exchange. This exchange will management protocol for a registration exchange. This exchange will
set up the outbound SAD entry that encrypts the multicast PIM control set up the outbound SAD entry that encrypts the multicast PIM control
message. Considering that this rule is "sender only", no inbound SA message. Considering that this rule is "sender only", no inbound SA
is created in the reverse direction. is created in the reverse direction.
In addition, either the registration exchange or the arrival of a In addition, the registration exchange will trigger the installation
PIM-SM link-local message will trigger the installation of the GSPD of the GSPD entries corresponding to each legitimate peer router,
entries corresponding to each legitimate peer router, with direction with direction "receive only". Procedures for achieving the
"receive only". Procedures for achieving the registration exchange registration exchange are out-of-scope for this document.
are out-of-scope for this document.
To account for new, legitimate neighbors, the Administrator MUST A router SHOULD NOT dynamically detect new neighbors as the result of
configure a GSPD entry for "any" peer router, destined to the receiving an unauthenticated PIM-SM link-local message or an IPsec
ALL_PIM_ROUTERS address. This entry will trigger a query to the packet that fails an SAD lookup. An automated key management
group key management protocol, to establish the legitimacy (or lack protocol SHOULD provide a means of notifying a router of new,
of it) of the new peer, and (if the peer is legitimate) to install legitimate neighbors.
the necessary SAD "receive only" entry.
10.2.3. PAD Entries 10.2.3. PAD Entries
The PAD will be configured with information to permit identification The PAD will be configured with information to permit identification
of legitimate group members and senders (i.e., to control the of legitimate group members and senders (i.e., to control the
adjacency). Procedures for doing this are out-of-scope for this adjacency). Procedures for doing this are out-of-scope for this
document. document.
11. Security Association Lookup 11. Security Association Lookup
skipping to change at page 22, line 18 skipping to change at page 22, line 18
destination address and security protocol type (AH or ESP)) are used destination address and security protocol type (AH or ESP)) are used
in the Security Association lookup process for inbound packets. The in the Security Association lookup process for inbound packets. The
SPI is sufficient to specify an SA. However, an implementation may SPI is sufficient to specify an SA. However, an implementation may
use the SPI in conjunction with the IPsec protocol type (AH or ESP) use the SPI in conjunction with the IPsec protocol type (AH or ESP)
for the SA lookup process. According to RFC 4301 [RFC4301], for for the SA lookup process. According to RFC 4301 [RFC4301], for
multicast SAs, in conjunction with the SPI, the destination address multicast SAs, in conjunction with the SPI, the destination address
or the destination address plus the sender address may also be used 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 in the SA lookup. This applies to both ESP and AH. The security
protocol field is not employed for a multicast SA lookup. protocol field is not employed for a multicast SA lookup.
The reason for the various prohibitions in the IPsec RFCs concerning Given that, from the prospective of a receiving router, each peer
multisender multicast SAs lies in the difficulty of coordinating the router is an independent sender and given that the destination
multiple senders. However, if the use of multicast for link-local address will be the same for all senders, the receiving router MUST
messages is examined, it may be seen that in fact the communication use SPI plus destination address plus sender address when performing
need not be coordinated---from the prospective of a receiving router, the SA lookup. In effect, link-local communication is an SSM
each peer router is an independent sender. In effect, link-local communication that happens to use an ASM address (which is shared
communication is an SSM communication that happens to use an ASM among all the routers).
address (which is shared among all the routers).
Given that it is always possible to distinguish a connection using Given that it is always possible to distinguish a connection using
IPsec from a connection not using IPsec, it is recommended that the IPsec from a connection not using IPsec, it is recommended that the
address ALL_PIM_ROUTERS be used, to maintain consistency with present address ALL_PIM_ROUTERS be used, to maintain consistency with present
practice. practice.
Given that the sender address of an incoming packet may be only Given that the sender address of an incoming packet may be only
locally unique (because of the use of link-local addresses), it is 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 necessary for a receiver to use the interface ID tag to determine the
associated SA for that sender. Therefore, this document mandates associated SA for that sender. Therefore, this document mandates
skipping to change at page 23, line 31 skipping to change at page 23, line 31
one. In a multi-sender multicast group communication, a single one. In a multi-sender multicast group communication, a single
sequence number for the entire group would not be enough. sequence number for the entire group would not be enough.
The whole scenario is different for PIM link-local messages. These The whole scenario is different for PIM link-local messages. These
messages are sent to local links with TTL = 1. A link-local message messages are sent to local links with TTL = 1. A link-local message
never propagates through one router to another. The use of the never propagates through one router to another. The use of the
sender address and the interface ID tag for SA lookup converts the sender address and the interface ID tag for SA lookup converts the
relationship from a multiple-sender group to multiple single-sender relationship from a multiple-sender group to multiple single-sender
associations. This specification RECOMMENDS activation of the anti- associations. This specification RECOMMENDS activation of the anti-
replay mechanism only if the SAs are assigned using an automated key replay mechanism only if the SAs are assigned using an automated key
management procedure. In manual key management, the anti-replay management procedure. If manual key management is used, the anti-
SHOULD NOT be activated. If the number of router(s) to be assigned replay SHOULD NOT be activated.
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 If an existing router has to restart, in accordance with RFC 4303
MUST refresh the counter (ESN, see Section 14) to zero for all [RFC4303], the sequence number counter at the sender MUST be
the peer routers. This implies deleting all the existing SAs and correctly maintained across local reboots, etc., until the key is
adding a new SA with the same configuration and a re-initialized replaced.
counter.
13. Implementing a Security Association Database per Interface 13. Implementing a Security Policy Database per Interface
RFC 4601 suggests that it may be desirable to implement a separate RFC 4601 suggests that it may be desirable to implement a separate
Security Association Database (SAD) for each router interface. The Security Policy Database (SPD) for each router interface. The use of
use of link-local addresses in certain circumstances implies that link-local addresses in certain circumstances implies that
differentiation of ambiguous speaker addresses requires the use of 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 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 the use of multiple SPDs. Alternatively, the interface ID tag may be
a specific component of the selector algorithm. This is in a specific component of the selector algorithm. This is in
conformance with RFC 4301, which explicitly removes the requirement conformance with RFC 4301, which explicitly removes the requirement
for separate SADs that was present in RFC 2401 [RFC2401]. for separate SPDs that was present in RFC 2401 [RFC2401].
14. Extended Sequence Number 14. Extended Sequence Number
In the [RFC4302], there is a provision for a 64-bit Extended Sequence In the [RFC4302], there is a provision for a 64-bit Extended Sequence
Number (ESN) as the counter of the sliding window used in the anti- 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 replay protocol. Both the sender and the receiver maintain a 64-bit
counter for the sequence number, although only the lower order 32 counter for the sequence number, although only the lower order 32
bits are sent in the transmission. In other words, it will not 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 affect the present header format of AH. If ESN is used, a sender
router can send 2^64 -1 packets without any intervention. This 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 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 router can never exceed this number in its lifetime. This makes it
reasonable to permit manual configuration for a small number of PIM reasonable to permit manual configuration for a small number of PIM
routers, since the sequence number will never roll over. For this routers, since the sequence number will never roll over. For this
reason, when manual configuration is used, ESN SHOULD be deployed as reason, when manual configuration is used, ESN SHOULD be deployed as
the sequence number for the sliding window protocol. 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.
15. Security Considerations 15. Security Considerations
The whole document considers the security issues of PIM link-local The whole document considers the security issues of PIM link-local
messages and proposes a mechanism to protect them. messages and proposes a mechanism to protect them.
Limitations of manual keys: Limitations of manual keys:
The following are some of the known limitations of the usage of The following are some of the known limitations of the usage of
manual keys. manual keys.
skipping to change at page 30, line 5 skipping to change at page 28, line 11
16. IANA Considerations 16. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
17. Acknowledgements 17. Acknowledgements
The structure and text of this document draw heavily from RFC 4552 The structure and text of this document draw heavily from RFC 4552
[RFC4552]. The authors of this document thank M. Gupta and N. Melam [RFC4552]. The authors of this document thank M. Gupta and N. Melam
for permisison to do this. for permisison to do this.
The quality of this document was substiantially improved after SECDIR
pre-review by Brian Weis.
18. References 18. References
18.1. Normative References 18.1. Normative References
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
skipping to change at page 30, line 38 skipping to change at page 29, line 38
[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast
Extensions to the Security Architecture for the Internet Extensions to the Security Architecture for the Internet
Protocol", RFC 5374, November 2008. Protocol", RFC 5374, November 2008.
18.2. Informative References 18.2. Informative References
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5
Signature Option", RFC 3562, July 2003.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross,
"GSAKMP: Group Secure Association Key Management "GSAKMP: Group Secure Association Key Management
Protocol", RFC 4535, June 2006. Protocol", RFC 4535, June 2006.
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003. Group Domain of Interpretation", RFC 3547, July 2003.
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
Routing Protocols", RFC 4593, October 2006. Routing Protocols", RFC 4593, October 2006.
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
Architecture", RFC 3740, March 2004.
[RFC5294] Savola, P. and J. Lingard, "Host Threats to Protocol [RFC5294] Savola, P. and J. Lingard, "Host Threats to Protocol
Independent Multicast (PIM)", RFC 5294, August 2008. Independent Multicast (PIM)", RFC 5294, August 2008.
[RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol
Independent Multicast - Sparse Mode (PIM-SM) Multicast Independent Multicast - Sparse Mode (PIM-SM) Multicast
Routing Security Issues and Enhancements", RFC 4609, Routing Security Issues and Enhancements", RFC 4609,
October 2006. October 2006.
[I-D.ietf-tsvwg-rsvp-security-groupkeying]
Behringer, M. and F. Faucheur, "Applicability of Keying
Methods for RSVP Security",
draft-ietf-tsvwg-rsvp-security-groupkeying-02 (work in
progress), November 2008.
[I-D.weis-gdoi-for-rsvp]
Weis, B., "Group Domain of Interpretation (GDOI) support
for RSVP", draft-weis-gdoi-for-rsvp-01 (work in progress),
February 2008.
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv3", RFC 4552, June 2006. for OSPFv3", RFC 4552, June 2006.
Authors' Addresses Authors' Addresses
J. William Atwood J. William Atwood
Concordia University/CSE Concordia University/CSE
1455 de Maisonneuve Blvd, West 1455 de Maisonneuve Blvd, West
Montreal, QC H3G 1M8 Montreal, QC H3G 1M8
Canada Canada
 End of changes. 38 change blocks. 
165 lines changed or deleted 101 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/