[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01

Network Working Group                                          M. Bhatia
Internet-Draft                                            Alcatel-Lucent
Intended status: Standards Track                          April 14, 2011
Expires: October 16, 2011

    Analysis of Protocol Independent Multicast  Sparse Mode (PIM-SM)
                Security According to  KARP Design Guide


   This document analyzes Protocol Independent Multicast Sparse Mode
   (PIM-SM) according to the guidelines set forth in the KARP Design

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on October 16, 2011.

Copyright Notice

   Copyright (c) 2011 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

Bhatia                  Expires October 16, 2011                [Page 1]

Internet-Draft             PIM-SM Gap Analysis                April 2011

   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

1.  Introduction

   This document performs the initial analysis of the current state of
   Protocol Independent Multicast Sparse Mode (PIM-SM) [RFC4601]
   according to the requirements of [I-D.ietf-karp-design-guide]

   [RFC5796] describes mechanisms to authenticate the PIM-SM link-local
   messages using the IP security (IPsec) Encapsulating Security Payload
   (ESP) [RFC4303] or (optionally) the Authentication Header (AH)
   [RFC4302] .

   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.

   However, some gaps remain between the current state and the
   requirements for manually keyed routing security expressed in the
   [I-D.ietf-karp-threats-reqs] document.  This document explores these
   gaps and proposes directions for addressing the gaps.

2.  Current State and Gap Analysis

   [RFC5796] describes how IPsec can be used to secure and authenticate
   PIM-SM protocol packets.  It mandates the use of manual keying and
   optionally provides support for an automated group key management
   mechanism.  However, it leaves the procedures for implementing
   automated group key management to other documents and does not
   discuss how this can be done.

   [RFC5796] uses manually configured keys, rather than some automated
   key management protocol , since no suitable key management mechanism
   is available at this time.  This is because PIM-SM adjacencies are
   formed on a one-to-many basis and most key management mechanisms are
   designed for a one-to-one communication model.  Since [RFC5796] uses
   manual keying it clearly states that it provides no protection
   against both inter-session and intra-session replay attacks.  This
   can be exploited in several ways.

   Since multiple PIM-SM routers can exist on a single link, it would be

Bhatia                  Expires October 16, 2011                [Page 2]

Internet-Draft             PIM-SM Gap Analysis                April 2011

   worth noting that setting up IPsec Security Associations (SAs)
   manually can be a very tedious process.  The routers might not even
   support IPsec, rendering automatic key negotiation either impractical
   (in those platforms where an extra license has to be obtained for
   using IPsec) or infeasible (in those platforms where IPsec support is
   not available at all).

   While I don't yet see a need to prioritize certain PIM-SM packets
   over the others, it should be noted that this would be extremely
   difficult to achieve since PIM-SM uses IPsec for its security and

   [RFC4601] requires all PIM-SM routers to configure an IPsec Security
   Association (SA) when sending PIM Register packets to each Rendezous
   Point (RP).  This can become highly unscalable as the number of RPs
   increase or in case of Anycast-RP [RFC4610] deployment where each
   PIM-SM router close to the source will need to establish IPsec
   tunnels to all PIM-SM routers in the Anycast-RP set.

   Similarly, the Security Policy Database at each Rendezvous Point
   should be configured to choose an SA to use when sending Register-
   Stop messages.  Because Register-Stop messages are unicast to the
   destination DR, a different SA and a potentially unique SPI are
   required for each DR.

   In order to simplify the management problem, [RFC4601] suggests using
   the same authentication algorithm and authentication parameters,
   regardless of the sending RP and regardless of the destination DR.
   While this alleviates the management problem by some extent it still
   requires a unique SA on each DR which can result in a significant
   scaling issue as the size of the PIM-SM network grows.

   In order to encourage deployment of PIM-SM security, an
   authentication option is required that does not have the deployment
   challenges of IPsec.  We thus need an authentication mechanism
   alternate to IPsec as part of the first phase of the KARP design
   guide where we secure the routing protocols using manual keying.

   The new mechanism should work for both the Unicast and Multicast
   PIM-SM routing exchanges.  It should also provide both inter-session
   and intra-session replay protection that has been spelled out in the
   [I-D.ietf-karp-threats-reqs] document.

3.  Security Considerations


Bhatia                  Expires October 16, 2011                [Page 3]

Internet-Draft             PIM-SM Gap Analysis                April 2011

4.  IANA Considerations

   This document places no new request to IANA

5.  Acknowledgements

   I would like to thank Stig Venaas and Bill Atwood for reviewing and
   providing feedback on this draft.

6.  References

6.1.  Normative References

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

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

   [RFC5796]  Atwood, W., Islam, S., and M. Siami, "Authentication and
              Confidentiality in Protocol Independent Multicast Sparse
              Mode (PIM-SM) Link-Local Messages", RFC 5796, March 2010.

6.2.  Informative References

              Lebovitz, G. and M. Bhatia, "Keying and Authentication for
              Routing Protocols (KARP) Design Guidelines",
              draft-ietf-karp-design-guide-02 (work in progress),
              March 2011.

              Lebovitz, G., Bhatia, M., and R. White, "The Threat
              Analysis and Requirements for Cryptographic Authentication
              of Routing Protocols' Transports",
              draft-ietf-karp-threats-reqs-01 (work in progress),
              October 2010.

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

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

   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",

Bhatia                  Expires October 16, 2011                [Page 4]

Internet-Draft             PIM-SM Gap Analysis                April 2011

              RFC 4306, December 2005.

   [RFC4610]  Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol
              Independent Multicast (PIM)", RFC 4610, August 2006.

Author's Address

   Manav Bhatia

   Email: manav.bhatia@alcatel-lucent.com

Bhatia                  Expires October 16, 2011                [Page 5]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/