PIM Working Group                                              W. Atwood
Internet-Draft                                                  S. Islam
Updates: 4601 (if approved)                     Concordia University/CSE
Intended status: Standards Track                       November 18, 2007                                M. Siami
Expires: May 21, August 28, 2008                      Concordia University/CIISE
                                                       February 25, 2008

    Authentication and Confidentiality in PIM-SM Link-local Messages

Status of this Memo

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

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

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

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on May 21, August 28, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007). (2008).


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

Table of Contents

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

1.  Introduction

   All the PIM-SM [1] control messages have IP protocol number 103.
   These messages are either unicast, or multicast with TTL = 1.  The
   source address used for unicast messages is a domain-wide reachable
   address.  For the multicast messages, a link-local address of the
   interface on which the message is being sent is used as the source
   address and a special multicast address, ALL_PIM_ROUTERS (
   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 [1].  The effects of these forged messages are
   outlined in section 6.1 of [1].  Some of the effects are very severe,
   whereas some are minor.

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

   Securing the unicast messages can be achieved by the use of a normal
   unicast IPsec Security Association between the two communicants.
   Securing the user data exchanges is covered in RFC 3740 [6].  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 to bring the PIM-SM specification into
   alignment with the new AH specification.  This document recommends
   manual key management as mandatory to implement, i.e., that all
   implementations MUST support, and begins the discussion of an
   automated key management protocol that the PIM routers can use.

2.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and
   indicate requirement levels for compliant PIM-SM implementations.

3.  Transport Mode vs. Tunnel Mode

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

4.  Authentication

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

   In order to provide authentication to PIM-SM link-local messages,
   implementations MUST support ESP [5] and MAY support AH [2].

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

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

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

   o  PIM-SM link-local packets that are not protected with AH or ESP
      MUST be silently discarded.

   o  PIM-SM link-local packets that fail the authentication checks MUST
      be silently discarded.

5.  Confidentiality

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

   If confidentiality is provided, ESP MUST be used.

   When PIM-SM confidentiality is enabled,

   o  PIM-SM packets that are not protected with ESP MUST be silently

   o  PIM-SM packets that fail the confidentiality checks MUST be
      silently discarded.

6.   IPsec Requirements

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

   Transport mode
      IPsec in transport mode MUST be supported.

   Multiple Security Policy Databases (SPDs)
      The implementation MUST support multiple SPDs with an SPD
      selection function that provides an ability to choose a specific
      SPD based on interface.

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

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

   Manual key support
      Manually configured keys MUST be able to secure the specified

   Encryption and authentication algorithms
      The implementation MUST NOT allow the user to choose stream
      ciphers as the encryption algorithm for securing PIM-SM packets
      since the stream ciphers are not suitable for manual keys.  Except
      when in conflict with the above statement, the key words "MUST",
      "MUST NOT", "REQUIRED", "SHOULD", and "SHOULD NOT" that appear in
      RFC 4305 4835 [7] for algorithms to be supported are to be interpreted
      as described in RFC 2119 [3] for PIM-SM support as well.

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

7.  Key Management

   All the implementations MUST support manual configuration of the SAs
   that will be used to authenticate PIM-SM link-local messages.  This
   does not preclude the use of a negotiation protocol such as the
   Internet Key Exchange (IKE) [11] or Group Secure Association Key
   Management Protocol (GSAKMP) [12] to establish SAs.

7.1.  Manual Key Management

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

7.2.  Automated Key Management

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

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

   A framework for automating key management for RSVP is given in [17].
   A companion modification for GDOI is presented in [18].  NOTE: A
   similar pair of documents will be prepared for PIM-SM.

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
    |     |     |     |     |
    |     |     |     |     |
   ---------   ---------------
           |     |
           |     |
            \   /
            /   \
           |     |
           |     |
   ---------    --------------------
          |       |    |    |    |
          |       |    |    |    |
         R7      R8   R9   R10  R11
          |       |    |    |    |
                    |    |    |
                    |    |    |
                   R12  R13  R14

          Figure 1: Set of router interconnections

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

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

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

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

7.4.  Neighbor Relationships

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

8.  Number of Security Associations

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

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

          Figure 2: Activate unique Security Association for each peer

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

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

          Figure 3: Activate two Security Associations

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

9.  Rekeying

   This section will provide the rekeying rules.  It will be written
   once is is decided whether or not to specify a re-keying protocol as
   part of this document.

9.1.  Rekeying Procedure


9.2.  KeyRollover Interval


9.3.  Rekeying Interval


10.  IPsec Protection Barrier and GSPD

10.1.  Manual Keying

10.1.1.  SAD Entries

   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

10.1.2.  SPD

   This section will provide Entries

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

10.2.  Automatic Keying

   When automatic keying is decided whether 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 [19].

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 retain both confidentiality child SAs being established and authentication, or
   saved in the SAD.

10.2.2.  GSPD Entries

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

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

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

10.2.3.  PAD Entries

   The PAD must be configured by the Administrator with information to
   permit identification of legitimate group members and senders.  This
   will be detailed in a companion document (to be written).

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 [4] and the AH
   specification [2], for multicast SAs, in conjunction with the SPI,
   the destination address or the destination address plus the sender
   address may also be used in the SA lookup.  The security protocol
   field is not employed for a multicast SA lookup.

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

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

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

12.  Activating the Anti-replay Mechanism

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

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

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

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

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

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

13.  Implementing a Security Association Database per Interface

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

14.  Extended Sequence Number

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

15.  Security Considerations

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

   Limitations of manual keys:

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

   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

   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 [14].  For further discussion of PIM-SM and
   multicast security the reader is referred to [15], RFC 4609 [16] and
   the Security Considerations section of RFC 4601 [1].

16.  IANA Considerations

   This document has no actions for IANA.

17.  References


17.1.  Normative References

   [1]   Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
         "Protocol Independent Multicast - Sparse Mode (PIM-SM):
         Protocol Specification (Revised)", RFC 4601, August 2006.

   [2]   Kent, S., "IP Authentication Header", RFC 4302, December 2005.

   [3]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [4]   Kent, S. and K. Seo, "Security Architecture for the Internet
         Protocol", RFC 4301, December 2005.

   [5]   Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
         December 2005.

   [6]   Hardjono, T. and B. Weis, "The Multicast Group Security
         Architecture", RFC 3740, March 2004.

   [7]   Eastlake, D.,   Manral, V., "Cryptographic Algorithm Implementation
         Requirements for Encapsulating Security Payload (ESP) and
         Authentication Header (AH)", RFC 4305, December 2005.

16.2. 4835, April 2007.

17.2.  Informative References

   [8]   Kent, S. and R. Atkinson, "Security Architecture for the
         Internet Protocol", RFC 2401, November 1998.

   [9]   Islam, S., "Security Issues in PIM-SM Link-local Messages,
         Master's Thesis, Concordia University", December 2003.

   [10]  Islam, S., "Security Issues in PIM-SM Link-local Messages,
         Proceedings of LCN 2004", November 2004.

   [11]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
         RFC 4306, December 2005.

   [12]  Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP:
         Group Secure Association Key Management Protocol", RFC 4535,
         June 2006.

   [13]  Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group
         Domain of Interpretation", RFC 3547, July 2003.

   [14]  Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
         Routing Protocols", RFC 4593, October 2006.

   [15]  Savola, P. and J. Lingard, "Host Threats to Protocol
         Independent Multicast (PIM)", draft-ietf-pim-lasthop-threats-03
         (work in progress), October 2007.

   [16]  Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent
         Multicast - Sparse Mode (PIM-SM) Multicast Routing Security
         Issues and Enhancements", RFC 4609, October 2006.

   [17]  Behringer, M. and F. Faucheur, "Applicability of Keying Methods
         for RSVP Security",
         draft-ietf-tsvwg-rsvp-security-groupkeying-00 (work in
         progress), February 2008.

   [18]  Weis, B., "Group Domain of Interpretation (GDOI) support for
         RSVP", draft-weis-gdoi-for-rsvp-01 (work in progress),
         February 2008.

   [19]  Weis, B., Gross, G., and D. Ignjatic, "Multicast Extensions to
         the Security Architecture for the Internet  Protocol",
         draft-ietf-msec-ipsec-extensions-08 (work in progress),
         February 2008.

Authors' Addresses

   J. William Atwood
   Concordia University/CSE
   1455 de Maisonneuve Blvd, West
   Montreal, QC  H3G 1M8

   Phone: +1(514)848-2424 ext3046
   Email: bill@cse.concordia.ca
   URI:   http://users.encs.concordia.ca/~bill

   Salekul Islam
   Concordia University/CSE
   1455 de Maisonneuve Blvd, West
   Montreal, QC  H3G 1M8

   Email: salek_is@cse.concordia.ca
   URI:   http://users.encs.concordia.ca/~salek_is

   Maziar Siami
   Concordia University/CIISE
   1455 de Maisonneuve Blvd, West
   Montreal, QC  H3G 1M8

   Email: m_siamis@ciise.concordia.ca

Full Copyright Statement

   Copyright (C) The IETF Trust (2007). (2008).

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

   This document and the information contained herein are provided on an

Intellectual Property

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

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

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


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).