<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="no"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-bhatia-karp-pim-gap-analysis-01"
     ipr="trust200902">
  <front>
    <title abbrev="PIM-SM Gap Analysis">Analysis of Protocol Independent
    Multicast Sparse Mode (PIM-SM) Security According to KARP Design
    Guide</title>

    <author fullname="Manav Bhatia" initials="M." surname="Bhatia">
      <organization>Alcatel-Lucent</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>India</country>
        </postal>

        <email>manav.bhatia@alcatel-lucent.com</email>
      </address>
    </author>

    <author fullname="Mahesh Jethanandani" initials="M" surname="Jethanandani">
      <organization>Ciena Corporation</organization>

      <address>
        <postal>
          <street>3939 North 1st Street</street>

          <city>San Jose</city>

          <region>CA</region>

          <code>95134</code>

          <country>USA</country>
        </postal>

        <phone>+1 (408) 904-2160</phone>

        <facsimile/>

        <email>mjethanandani@gmail.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Dacheng Zhang" initials="D" surname="Zhang">
      <organization>Huawei Technologies Co. LTD.</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>zhangdacheng@huawei.com</email>

        <uri/>
      </address>
    </author>

    <date day="16" month="December" year="2013"/>

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

  <middle>
    <section title="Introduction">
      <t>This document performs the initial analysis of the current state of
      <xref target="RFC4601">Protocol Independent Multicast Sparse Mode
      (PIM-SM) </xref> according to the requirements of <xref
      target="RFC6518">KARP Design Guidelines </xref></t>

      <t><xref target="RFC4601">The base PIM-SM specification </xref>
      introduces the use non-cryptographic authentication approaches to
      protect PIM-SM packets and recommends the use of transport mode of <xref
      target="RFC4302">IPsec AH </xref> to protect PIM-SM unicast and
      multicast packets. The memo assumes that the SAs are manually
      deployed.</t>

      <t><xref target="RFC5796">Authentication and Confidentiality in PIM-SM
      Link-Local Messages </xref> proposes the mechanisms to authenticate the
      PIM-SM multicast messages using the <xref target="RFC4303">IP security
      (IPsec) Encapsulating Security Payload (ESP) </xref> or (optionally) the
      <xref target="RFC4302">IP Authentication Header (AH) </xref> .</t>

      <t>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.</t>

      <t>However, some gaps remain between the current state and the
      requirements for manually keyed routing security expressed in the <xref
      target="RFC6862"/> document. This document explores these gaps and
      proposes directions for addressing the gaps.</t>
    </section>

    <section title="Current State">
      <t>Unlike <xref target="RFC2328">OSPFv2 </xref>, PIM-SM does not propose
      any in-band security solution. Instead, IPsec is used to protect both
      unicast and muticast control packets.</t>

      <t><xref target="RFC5796">Authentication and Confidentiality in PIM-SM
      Link-Local Messages </xref> 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.</t>

      <t>The mechanism proposed in <xref target="RFC5796">Authentication and
      Confidentiality in PIM-SM Link-Local Messages </xref> supports packet
      level integrity protection using a wide variety of cryptographic
      algorithms. In addition, the <xref target="RFC4301">Security Parameter
      Index (SPI)</xref> provides an 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.</t>

      <t><xref target="RFC5796">Authentication and Confidentiality in PIM-SM
      Link-Local Messages </xref> 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 <xref
      target="RFC5796">authentication and confidentiality in PIM-SM Link-Local
      Messages </xref> 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. </t>
    </section>

    <section title="Deployment Issues Imposed by IPsec and Manual Keying">
      <t>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).</t>

      <t><xref target="RFC4601">PIM-SM</xref> 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 <xref
      target="RFC4610">Anycast-RP </xref> 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.</t>

      <t>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.</t>

      <t>In order to simplify the management problem, <xref
      target="RFC4601">PIM-SM </xref> 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.</t>
    </section>

    <section title="Gap Analysis">
      <t>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.</t>

      <t>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.</t>

      <t>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 <xref
      target="RFC6862"/> document.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>TBD</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document places no new request to IANA</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>We would like to thank Stig Venaas and Bill Atwood for reviewing and
      providing feedback on this draft.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include='reference.RFC.4601'?>

      <?rfc include='reference.RFC.5796'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.4302'?>

      <?rfc include='reference.RFC.4301'?>

      <?rfc include='reference.RFC.4303'?>

      <?rfc include='reference.RFC.2328'?>

      <?rfc include='reference.RFC.4306'?>

      <?rfc include='reference.RFC.4610'?>

      <?rfc include='reference.RFC.6518'?>

      <?rfc include='reference.RFC.6862'?>
    </references>
  </back>
</rfc>
