Internet Engineering Task Force                                P. Savola
Internet-Draft                                                 CSC/FUNET
Expires: May 24, 2005                                  November 23, 2004


        Last-hop Threats to Protocol Independent Multicast (PIM)
                draft-savola-pim-lasthop-threats-00.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.

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

   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
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 24, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   Security threats analysis has been done on some parts of the
   multicast infrastructure, but the threats specific to the last-hop
   attacks by hosts on the PIM routing protocol have not been well
   described in the past.  This memo aims to fill that gap.







Savola                    Expires May 24, 2005                  [Page 1]


Internet-Draft            Last-hop PIM Threats             November 2004


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Last-hop PIM Vulnerabilities . . . . . . . . . . . . . . . . .  3
     2.1   Sending PIM Register Messages on Your Own  . . . . . . . .  3
     2.2   Becoming an Illegitimate PIM Neighbor  . . . . . . . . . .  3
     2.3   Becoming an Illegitimate PIM DR  . . . . . . . . . . . . .  3
     2.4   Becoming an Illegitimate PIM Asserted Forwarder  . . . . .  4
   3.  On-link Threats  . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1   Denial-of-Service Attack on the Link . . . . . . . . . . .  4
     3.2   Denial-of-Service Attack on the Outside  . . . . . . . . .  5
     3.3   Confidentiality, Integrity or Authorization Violations . .  5
   4.  Mitigation Methods . . . . . . . . . . . . . . . . . . . . . .  6
     4.1   Passive Mode for PIM . . . . . . . . . . . . . . . . . . .  6
     4.2   Use of IPsec among PIM Routers . . . . . . . . . . . . . .  6
     4.3   IP Filtering PIM Messages  . . . . . . . . . . . . . . . .  6
     4.4   Summary of Vulnerabilities and Mitigation Methods  . . . .  7
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   8.1   Normative References . . . . . . . . . . . . . . . . . . . .  8
   8.2   Informative References . . . . . . . . . . . . . . . . . . .  8
       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  9
       Intellectual Property and Copyright Statements . . . . . . . . 10


























Savola                    Expires May 24, 2005                  [Page 2]


Internet-Draft            Last-hop PIM Threats             November 2004


1.  Introduction

   There has been some analysis on the security threats to the multicast
   routing infrastructures [I-D.ietf-mboned-mroutesec], work on
   implementing confidentiality, integrity and authorization in the
   multicast payload [RFC3740], and also some analysis of security
   threats in IGMP/MLD [I-D.daley-magma-smld-prob], but no comprehensive
   analysis of security threats of PIM at the last-hop links.

   This document analyzes the last-hop PIM vulnerabilities, formulates a
   couple of specific threats, proposes a couple of potential ways to
   mitigate these problems and analyzes how well those methods
   accomplish fixing the issues.

2.  Last-hop PIM Vulnerabilities

   This section describes briefly the main attacks against last-hop PIM
   signalling, before we get to the actual threats and mitigation
   methods in the next sections.

2.1  Sending PIM Register Messages on Your Own

   PIM Register messages are sent as unicast-encapsulated messages.
   Maliscious hosts could also send registers themselves for example to
   get around the rate-limiters, to interfere with foreign RPs, etc.

2.2  Becoming an Illegitimate PIM Neighbor

   When PIM has been enabled on a router's "host" interface, any host
   can also become a PIM neighbor using PIM Hello messages unless
   special, rare precautions, such as protecting all the PIM traffic on
   the link using IPsec, have been taken.

   Further PIM messaged should not be accepted except from valid PIM
   neighbors; if implementations are compliant to this recommendation in
   the PIM-SM specification, becoming a PIM Neighbor using Hello
   messages is the first step to be able to send other PIM messages.

2.3  Becoming an Illegitimate PIM DR

   Designated Router is in "charge" of a particular LAN, for example,
   for registering new sources, generating PIM Join/Prune messages and
   forwarding multicast traffic.

   A host which can became a PIM neighbor, can also, as part of becoming
   the neighbor, influence the DR election process: basically, if at
   least one neighbor did not have "DR Priority" field in the Hello
   message (a "bidding-down" attack), the neighbor with the numerically



Savola                    Expires May 24, 2005                  [Page 3]


Internet-Draft            Last-hop PIM Threats             November 2004


   highest IP address wins the election; if DR priority existed, the DR
   priority is first checked and only then the IP addresses are
   compared.

   Further, it is not sufficient to secure DR election, because Assert
   messages can be used to obtain the responsibility for forwarding
   upstream traffic as described in the next section.

   It seems that a DR can send PIM messages (like Prune/Join) to the
   non-DR to be forwarded upstream on behalf of directly connected (to
   both DR and non-DR) sources.  In other words, a host on a stub LAN
   can be elected as a DR and act as a "man-in-the-middle" between the
   other hosts and the real PIM router.  [XXX: Is this correct?  Should
   non-DRs reject forwarding upstream messages from downstream LAN's
   DRs, because a real DR should have its own upstream connectivity?]

2.4  Becoming an Illegitimate PIM Asserted Forwarder

   With a PIM Assert, a router can be elected to be in charge of
   handling all traffic from a particular (S,G) (where S might also be
   all of S? [XXX: true?]).  This overrides DR behaviour.

   PIM Assert messages can be used to obtain the responsibility for
   forwarding upstream traffic.  The specification says that Asserts
   should only be accepted from known PIM neighbors, and "SHOULD" be
   discarded otherwise.  So, either the host must be able to spoof an IP
   address of a current neighbor, form a PIM adjacency first, or count
   on these checks being disabled.

   Assert Timer, by default, is 3 minutes; the state must be refreshed
   or it will be removed automatically.

   As noted before, it is also possible to spoof an Assert on someone
   else's behalf to cause a temporary disruption on the LAN.  However,
   it is not 100% clear what happens when the router which was spoofed
   receives "it's own assert" and CouldAssert(S,G,I) is False?  [XXX: a
   PIM expert should say something?  Is this an issue in the state
   machine?]

3.  On-link Threats

   The last section described some PIM vulnerabilities; this section
   gives an overview of the more concrete threats using these
   vulnerabilities.

3.1  Denial-of-Service Attack on the Link

   The easiest attack is to deny the multicast service on the link.



Savola                    Expires May 24, 2005                  [Page 4]


Internet-Draft            Last-hop PIM Threats             November 2004


   This could mean either not forwarding all (or parts of) multicast
   from upstream on the link, or not registering or forwarding the
   multicast transmissions originated on the link upstream.

   These attacks can be done multiple ways: the most typical one would
   be becoming the DR through becoming a neighbor with Hello messages
   and winning the DR election: after that, one could just not send any
   PIM Join/Prune messages based on the IGMP reports, not forward or
   Register any sourced packets, and maybe even send PIM Prune messages
   to cut off existings transmissions because Prune messages are
   accepted from downstream interfaces even if the router is not a DR.
   An alternative mechanism is to send a PIM Assert message, spoofed to
   come from a valid PIM neighbor or non-spoofed if a PIM adjacency has
   already been formed.  This results in the same as getting elected as
   a DR.

3.2  Denial-of-Service Attack on the Outside

   It is also possible to perform Denial-of-Service attacks on the nodes
   beyond the link, especially in the environments where being a
   multicast router and/or a DR is considered to be a trusted node.

   In particular, if DRs perform some form of rate-limiting, for example
   on new Join/Prune messages, becoming a DR and sending those messages
   yourself allows one to subvert these restrictions: therefore
   rate-limiting functions need to be deployed at multiple layers as
   described in [I-D.ietf-mboned-mroutesec].

   In addition to PIM messaging requiring establishing a PIM adjacency,
   any host can send PIM Register messages on their own: to whichever RP
   it wants; further, if unicast RPF mechanisms [RFC3704] have not been
   applied, the packet may be spoofed.  This can be done to get around
   rate-limits, and/or to attack remote RPs and/or to interfere with
   integrity of an ASM group.  This attack is also described in
   [I-D.ietf-mboned-mroutesec].

3.3  Confidentiality, Integrity or Authorization Violations

   If a node can get to be a DR or craft an appropriate Assert, in
   addition to or instead of performing Denial-of-Service, it can also
   just operate as normal for some traffic, while violating
   confidentiality, integrity or authorization for some other traffic.

   Some packets, whether sent by received, could be modified (possibly
   in a subtle, unnoticable ways) in transit resulting in an integrity
   violation.  The packets can obviously be observed as well, so any
   data sent can be compromised.




Savola                    Expires May 24, 2005                  [Page 5]


Internet-Draft            Last-hop PIM Threats             November 2004


   A more elaborate attack is on authorization.  There are some models
   [I-D.hayashi-igap] where the current multicast architecture is used
   to provide paid multicast service, and where the
   authorization/authentication is added to the group management
   protocols such as IGMP.  Needless to say, if a host would be able to
   act as a router, it might be possible to perform all kinds of
   attacks: subscribe to multicast service without using IGMP (i.e.,
   without having to pay for it), deny the service of the others on the
   same link, etc.

4.  Mitigation Methods

   This section lists some ways to mitigate the vulnerabilities and
   threats listed in previous sections.

4.1  Passive Mode for PIM

   The current PIM specification seems to mandate running the PIM Hello
   messages on all PIM-enabled interfaces.  Most implementations also
   require PIM to be enabled on the interface to send PIM registers from
   sourced data or to do any other PIM processing.

   As described in [I-D.ietf-mboned-mroutesec], running full PIM, with
   Hello messages and all, is unnecessary for those stub networks for
   which only one router is providing multicast service.  Therefore such
   implementations should provide an option to specify that the
   interface is "passive" with regard to PIM: no PIM packets are sent or
   processed (if received), but hosts can still send and receive
   multicast on that interface.

4.2  Use of IPsec among PIM Routers

   Instead of Passive mode, or when multiple PIM routers exist for a
   single link, one could also use IPsec to secure the PIM messaging, to
   prevent anyone from subverting it.  The actual procedures have been
   described in [I-D.ietf-pim-sm-v2-new] and
   [I-D.atwood-pim-sm-linklocal].

   However, it is worth noting that setting up IPsec SAs manually can be
   a very tedious process, and the routers might not even support IPsec;
   further automatic key negotiation may not be feasible in these
   scenarios either.

4.3  IP Filtering PIM Messages

   To eliminate the PIM messages, and other PIM signalling, in the
   similar scenarios as with PIM Passive Mode, it might be possible to
   block IP protocol 103 (all PIM messages) as an input access-list.



Savola                    Expires May 24, 2005                  [Page 6]


Internet-Draft            Last-hop PIM Threats             November 2004


   This is also acceptable when IPsec is used with more than just one
   PIM router on the link.

4.4  Summary of Vulnerabilities and Mitigation Methods

   This section summarizes the vulnerabilities, and how well the
   mitigation methods are able to cope with them.

   Summary of vulnerabilities and mitigations:

      +-----+--------------------+-----------------+----------------+
      | Sec | Vulnerability      | One stub router |>1 stub routers |
      |     |                    | PASV|IPsec|Filt |PASV|IPsec|Filt |
      +-----+--------------------+-----+-----+-----+----+-----+-----+
      | 2.1 | Hosts Registering  |  N  |  N  |  Y  | N  |  N  |  *  |
      +-----+--------------------+-----+-----+-----+----+-----+-----+
      | 2.2 | Invalid Neighbor   |  Y  |  Y  |  Y  | *  |  Y  |  *  |
      +-----+--------------------+-----+-----+-----+----+-----+-----+
      | 2.3 | Invalid DR         |  Y  |  Y  |  Y  | *  |  Y  |  *  |
      +-----+--------------------+-----+-----+-----+----+-----+-----+
      | 2.3 | Adjacency not reqd |  Y  |  Y  |  Y  | *  |  Y  |  *  |
      +-----+--------------------+-----+-----+-----+----+-----+-----+
      | 2.4 | Invalid Forwarder  |  Y  |  Y  |  Y  | *  |  Y  |  *  |
      +-----+--------------------+-----+-----+-----+----+-----+-----+

                                Figure 1

   "*" means Yes if IPsec is used in addition; No otherwise.

   To summarize, IP protocol filtering for all PIM messages appears to
   be the most complete solution when coupled with the use of IPsec
   between the real stub routers when there are more than one of them.
   If hosts performing registering is not considered a serious problem,
   IP protocol filtering and passive-mode PIM seem to be equivalent
   approaches.

5.  Acknowledgements

   Greg Daley and Gopi Durup wrote an excellent analysis of MLD security
   issues [I-D.daley-magma-smld-prob], which gave inspiration in
   exploring the on-link PIM threats problem space.

6.  IANA Considerations

   This memo includes no request to IANA.






Savola                    Expires May 24, 2005                  [Page 7]


Internet-Draft            Last-hop PIM Threats             November 2004


7.  Security Considerations

   This memo analyzes the threats at PIM multicast routing protocol at
   the last-hop, and proposes some possible mitigation techniques.

8.  References

8.1  Normative References

   [I-D.ietf-mboned-mroutesec]
              Savola, P., Lehtonen, R. and D. Meyer, "PIM-SM Multicast
              Routing Security Issues and Enhancements",
              draft-ietf-mboned-mroutesec-04 (work in progress), October
              2004.

   [I-D.ietf-pim-sm-v2-new]
              Fenner, B., Handley, M., Holbrook, H. and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode PIM-SM):
              Protocol Specification  (Revised)",
              draft-ietf-pim-sm-v2-new-11 (work in progress), October
              2004.

8.2  Informative References

   [I-D.atwood-pim-sm-linklocal]
              Atwood, J., "Security Issues in PIM-SM Link-local
              Messages", draft-atwood-pim-sm-linklocal-00 (work in
              progress), October 2004.

   [I-D.daley-magma-smld-prob]
              Daley, G. and G. Kurup, "Trust Models and Security in
              Multicast Listener Discovery",
              draft-daley-magma-smld-prob-00 (work in progress), July
              2004.

   [I-D.hayashi-igap]
              Hayashi, T., "Internet Group membership Authentication
              Protocol (IGAP)", draft-hayashi-igap-03 (work in
              progress), August 2003.

   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
              Networks", BCP 84, RFC 3704, March 2004.

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






Savola                    Expires May 24, 2005                  [Page 8]


Internet-Draft            Last-hop PIM Threats             November 2004


Author's Address

   Pekka Savola
   CSC - Scientific Computing Ltd.
   Espoo
   Finland

   EMail: psavola@funet.fi











































Savola                    Expires May 24, 2005                  [Page 9]


Internet-Draft            Last-hop PIM Threats             November 2004


Intellectual Property Statement

   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
   http://www.ietf.org/ipr.

   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
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2004).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Savola                    Expires May 24, 2005                 [Page 10]