doc: Add RFC documents

1 files changed, 1179 insertions, 0 deletions

diff --git a/doc/rfc/rfc5796.txt b/doc/rfc/rfc5796.txt
new file mode 100644
index 0000000..16e2984
--- /dev/null
+++ b/doc/rfc/rfc5796.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+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
+
+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) 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.
+
+
+
+
+
+
+
+
+
+
+Atwood, et al.               Standards Track                    [Page 1]
+
+RFC 5796               PIM-SM Link-local Security             March 2010
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Atwood, et al.               Standards Track                    [Page 2]
+
+RFC 5796               PIM-SM Link-local Security             March 2010
+
+
+Table of Contents
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Atwood, et al.               Standards Track                    [Page 3]
+
+RFC 5796               PIM-SM Link-local Security             March 2010
+
+
+1.  Introduction
+
+   All the PIM-SM [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 (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].
+   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.
+
+1.1.  Goals and Non-Goals
+
+   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.
+
+
+
+
+
+Atwood, et al.               Standards Track                    [Page 4]
+
+RFC 5796               PIM-SM Link-local Security             March 2010
+
+
+   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.
+
+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 [RFC2119].
+   They indicate requirement levels for compliant PIM-SM
+   implementations.
+
+3.  Transport Mode versus Tunnel Mode
+
+   All implementations conforming to this specification MUST support SA
+   in transport mode to provide required IPsec security to PIM-SM link-
+   local messages.  They MAY also support SA in tunnel mode to provide
+   required IPsec security to PIM-SM link-local messages.  If tunnel
+   mode is used, both destination address preservation and source
+   address preservation MUST be used, as described in Section 3.1 of RFC
+   5374 [RFC5374].
+
+4.  Authentication
+
+   Implementations conforming to this specification MUST support
+   authentication for PIM-SM link-local messages.  Implementations
+   conforming to this specification MUST support HMAC-SHA1 [RFC2404].
+
+
+
+
+
+
+
+
+Atwood, et al.               Standards Track                    [Page 5]
+
+RFC 5796               PIM-SM Link-local Security             March 2010
+
+
+   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.
+
+5.  Confidentiality
+
+   Implementations conforming to this specification SHOULD support
+   confidentiality for PIM-SM.  Implementations supporting
+   confidentiality MUST support AES-CBC [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.
+
+6.   IPsec Requirements
+
+   In order to implement this specification, the following IPsec
+   capabilities are required.
+
+   Transport mode
+      IPsec in transport mode MUST be supported.
+
+
+
+
+Atwood, et al.               Standards Track                    [Page 6]
+
+RFC 5796               PIM-SM Link-local Security             March 2010
+
+
+   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.
+
+
+
+
+Atwood, et al.               Standards Track                    [Page 7]
+
+RFC 5796               PIM-SM Link-local Security             March 2010
+
+
+7.  Key Management
+
+   All the implementations MUST support manual configuration of the
+   Security Associations (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 Group Domain Of Interpretation (GDOI) [RFC3547]
+   or Group Secure Association Key Management Protocol (GSAKMP)
+   [RFC4535] to establish these 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.
+   At that time, the authentication method and the choice of keys SHOULD
+   be configured.  The parameters for the Security Association Database
+   (SAD) will be entered.  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 into a Source-Specific Multicast (SSM) or "one-to-many"
+   communication.
+
+   The procedures for automated key management are not specified in this
+   document.
+
+   One option is to use Group Domain Of Interpretation (GDOI) [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].
+
+
+
+
+
+Atwood, et al.               Standards Track                    [Page 8]
+
+RFC 5796               PIM-SM Link-local Security             March 2010
+
+
+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), 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.
+
+
+
+
+Atwood, et al.               Standards Track                    [Page 9]
+
+RFC 5796               PIM-SM Link-local Security             March 2010
+
+
+   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.
+
+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), 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.
+
+
+
+Atwood, et al.               Standards Track                   [Page 10]
+
+RFC 5796               PIM-SM Link-local Security             March 2010
+
+
+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 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.
+
+
+
+
+Atwood, et al.               Standards Track                   [Page 11]
+
+RFC 5796               PIM-SM Link-local Security             March 2010
+
+
+                                       |
+            +++++                      |
+            + 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.
+
+9.  Rekeying
+
+   An analysis of the considerations for key management is provided in
+   RFC 4107 [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.
+
+
+
+
+
+
+Atwood, et al.               Standards Track                   [Page 12]
+
+RFC 5796               PIM-SM Link-local Security             March 2010
+
+
+   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.
+
+9.1.  Manual Rekeying Procedure
+
+   In accordance with the requirements of RFC 4107 [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.
+
+
+
+Atwood, et al.               Standards Track                   [Page 13]
+
+RFC 5796               PIM-SM Link-local Security             March 2010
+
+
+   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.
+
+9.2.  KeyRolloverInterval
+
+   The configured value of KeyRolloverInterval needs to 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
+
+   In keeping with the goal of reducing key exposure, the encryption and
+   authentication keys SHOULD be changed at least every 90 days.
+
+10.  IPsec Protection Barrier and SPD/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 and sent to the
+   Destination Address of ALL_PIM_ROUTERS, is protected by ESP or AH.
+   Note that this characterization includes all the link-local messages
+   (Hello, Join/Prune, Bootstrap, Assert).
+
+
+
+
+
+
+
+
+
+Atwood, et al.               Standards Track                   [Page 14]
+
+RFC 5796               PIM-SM Link-local Security             March 2010
+
+
+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 [RFC5374].
+
+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
+   "sender 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 trigger the installation
+   of the GSPD entries corresponding to each legitimate peer router,
+   with direction "receiver only".  Procedures for achieving the
+   registration exchange are out of scope for this document.
+
+   A router SHOULD NOT dynamically detect new neighbors as the result of
+   receiving an unauthenticated PIM-SM link-local message or an IPsec
+   packet that fails an SAD lookup.  An automated key management
+   protocol SHOULD provide a means of notifying a router of new,
+   legitimate neighbors.
+
+10.2.3.  PAD Entries
+
+   The PAD will be configured with information to permit identification
+   of legitimate group members and senders (i.e., to control the
+   adjacency).  Procedures for doing this are out of scope for this
+   document.
+
+
+
+
+
+
+
+
+Atwood, et al.               Standards Track                   [Page 15]
+
+RFC 5796               PIM-SM Link-local Security             March 2010
+
+
+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], 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.
+
+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]) 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.
+
+
+
+Atwood, et al.               Standards Track                   [Page 16]
+
+RFC 5796               PIM-SM Link-local Security             March 2010
+
+
+   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.
+
+13.  Implementing a Security Policy Database per Interface
+
+   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].
+
+14.  Extended Sequence Number
+
+   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-
+   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,
+
+
+
+
+
+Atwood, et al.               Standards Track                   [Page 17]
+
+RFC 5796               PIM-SM Link-local Security             March 2010
+
+
+   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
+
+   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.
+
+   o  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.
+
+   o  Manual keys are usually long lived (changing them often is a
+      tedious task).  This gives an attacker enough time to discover the
+      keys.
+
+   o  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 [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].
+
+16.  Acknowledgements
+
+   The structure and text of this document draw heavily from RFC 4552
+   [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.
+
+
+
+
+
+Atwood, et al.               Standards Track                   [Page 18]
+
+RFC 5796               PIM-SM Link-local Security             March 2010
+
+
+17.  References
+
+17.1.  Normative References
+
+   [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.
+
+17.2.  Informative References
+
+   [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.
+
+
+
+
+
+Atwood, et al.               Standards Track                   [Page 19]
+
+RFC 5796               PIM-SM Link-local Security             March 2010
+
+
+   [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Atwood, et al.               Standards Track                   [Page 20]
+
+RFC 5796               PIM-SM Link-local Security             March 2010
+
+
+Authors' Addresses
+
+   J. William Atwood
+   Concordia University/CSE
+   1455 de Maisonneuve Blvd. West
+   Montreal, QC  H3G 1M8
+   Canada
+
+   Phone: +1(514)848-2424 ext3046
+   EMail: bill@cse.concordia.ca
+   URI:   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: mzrsm@yahoo.ca
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Atwood, et al.               Standards Track                   [Page 21]
+