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

Versions: 00 01

Network Working Group                                          M. Bhatia
Internet-Draft                                            Alcatel-Lucent
Intended status: Standards Track                         M. Jethanandani
Expires: June 19, 2014                                 Ciena Corporation
                                                                D. Zhang
                                            Huawei Technologies Co. LTD.
                                                       December 16, 2013


Analysis of Protocol Independent Multicast Sparse Mode (PIM-SM) Security
                     According to KARP Design Guide
                 draft-bhatia-karp-pim-gap-analysis-01

Abstract

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

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 June 19, 2014.

Copyright Notice

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



Bhatia, et al.            Expires June 19, 2014                 [Page 1]


Internet-Draft             PIM-SM Gap Analysis             December 2013


   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 KARP Design Guidelines [RFC6518]

   The base PIM-SM specification [RFC4601] introduces the use non-
   cryptographic authentication approaches to protect PIM-SM packets and
   recommends the use of transport mode of IPsec AH [RFC4302] to protect
   PIM-SM unicast and multicast packets.  The memo assumes that the SAs
   are manually deployed.

   Authentication and Confidentiality in PIM-SM Link-Local Messages
   [RFC5796] proposes the mechanisms to authenticate the PIM-SM
   multicast messages using the IP security (IPsec) Encapsulating
   Security Payload (ESP) [RFC4303] or (optionally) the IP
   Authentication Header (AH) [RFC4302] .

   The document specifies manual key management as mandatory to
   implement 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
   [RFC6862] document.  This document explores these gaps and proposes
   directions for addressing the gaps.

2.  Current State

   Unlike OSPFv2 [RFC2328], PIM-SM does not propose any in-band security
   solution.  Instead, IPsec is used to protect both unicast and
   muticast control packets.

   Authentication and Confidentiality in PIM-SM Link-Local Messages
   [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.

   The mechanism proposed in Authentication and Confidentiality in PIM-
   SM Link-Local Messages [RFC5796] supports packet level integrity
   protection using a wide variety of cryptographic algorithms.  In
   addition, the Security Parameter Index (SPI) [RFC4301] provides an



Bhatia, et al.            Expires June 19, 2014                 [Page 2]


Internet-Draft             PIM-SM Gap Analysis             December 2013


   identifier for the security association.  Along with other IPsec
   facilities, SPI provides a mechanism for moving from one key to
   another, meeting the key rollover requirements.  Because the
   algorithm can be changed as part of rekeying, algorithm agility is
   provided.

   Authentication and Confidentiality in PIM-SM Link-Local Messages
   [RFC5796] uses manually configured keys, rather than some automated
   key management protocol, since no suitable key management mechanism
   was 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 authentication
   and confidentiality in PIM-SM Link-Local Messages [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 various ways.  For instance, by replaying the
   Join message sent by a legitimate requester, an attacker can direct
   multicast traffic to be delivered to links where it is not required.
   Similarly, replaying a Prune Message can deprive the receivers from
   that multicast traffic.

3.  Deployment Issues Imposed by IPsec and Manual Keying

   Since multiple PIM-SM routers can exist on a single link, it would be
   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).

   PIM-SM [RFC4601] requires all PIM-SM routers to configure an IPsec
   Security Association (SA) when sending PIM Register packets to each
   Rendezvous 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, PIM-SM [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



Bhatia, et al.            Expires June 19, 2014                 [Page 3]


Internet-Draft             PIM-SM Gap Analysis             December 2013


   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.

4.  Gap Analysis

   In PIM-SM, multiple types of PIM messages (Hello, Join/Prune,
   Bootstrap, Assert) are delivered with multicast.  As it exists today,
   PIM-SM supports only manual key management.  When using manual
   keying, the replay protection mechanism (replay protection window) of
   IPSec will be switched off.  That is why IPSec cannot protect against
   any replay protection in this case.  In addition, the PIM messages do
   not have any replay protection mechanism, e.g. nonce or sequence
   numbers.  Therefore, PIM-SM is subject to both inter- and intra-
   connection replay attacks.  From the aspect of meeting the
   requirements for replay protection, a significant gap exists between
   the optimal state and where PIM-SM is today.

   In order to encourage deployment of PIM-SM security, an
   authentication option is required that does not have the deployment
   challenges of IPSec.  We therefore need an alternate authentication
   mechanism to IPSec as suggested by the first phase of the KARP design
   guide, where the guide suggests securing 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
   [RFC6862] document.

5.  Security Considerations

   TBD

6.  IANA Considerations

   This document places no new request to IANA

7.  Acknowledgements

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

8.  References

8.1.  Normative References

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



Bhatia, et al.            Expires June 19, 2014                 [Page 4]


Internet-Draft             PIM-SM Gap Analysis             December 2013


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

8.2.  Informative References

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

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

   [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", RFC
              4306, December 2005.

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

   [RFC6518]  Lebovitz, G. and M. Bhatia, "Keying and Authentication for
              Routing Protocols (KARP) Design Guidelines", RFC 6518,
              February 2012.

   [RFC6862]  Lebovitz, G., Bhatia, M., and B. Weis, "Keying and
              Authentication for Routing Protocols (KARP) Overview,
              Threats, and Requirements", RFC 6862, March 2013.

Authors' Addresses

   Manav Bhatia
   Alcatel-Lucent
   India

   Email: manav.bhatia@alcatel-lucent.com









Bhatia, et al.            Expires June 19, 2014                 [Page 5]


Internet-Draft             PIM-SM Gap Analysis             December 2013


   Mahesh Jethanandani
   Ciena Corporation
   3939 North 1st Street
   San Jose, CA  95134
   USA

   Phone: +1 (408) 904-2160
   Email: mjethanandani@gmail.com


   Dacheng Zhang
   Huawei Technologies Co. LTD.
   Beijing
   China

   Email: zhangdacheng@huawei.com



































Bhatia, et al.            Expires June 19, 2014                 [Page 6]


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