draft-ietf-pim-lasthop-threats-00.txt   draft-ietf-pim-lasthop-threats-01.txt 
Internet Engineering Task Force P. Savola PIM WG P. Savola
Internet-Draft CSC/FUNET Internet-Draft CSC/FUNET
Intended status: Informational J. Lingard Intended status: Informational J. Lingard
Expires: April 18, 2007 Arastra Expires: December 17, 2007 Arastra
October 15, 2006 June 15, 2007
Last-hop Threats to Protocol Independent Multicast (PIM) Last-hop Threats to Protocol Independent Multicast (PIM)
draft-ietf-pim-lasthop-threats-00.txt draft-ietf-pim-lasthop-threats-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 18, 2007. This Internet-Draft will expire on December 17, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
An analysis of security threats has been done for some parts of the An analysis of security threats has been done for some parts of the
multicast infrastructure, but the threats specific to the last-hop multicast infrastructure, but the threats specific to the last-hop
("Local Area Network") attacks by hosts on the PIM routing protocol ("Local Area Network") attacks by hosts on the PIM routing protocol
have not been well described in the past. This memo aims to fill have not been well described in the past. This memo aims to fill
that gap. that gap.
Table of Contents Table of Contents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
Forwarder . . . . . . . . . . . . . . . . . . . . . . . . 4 Forwarder . . . . . . . . . . . . . . . . . . . . . . . . 4
3. On-link Threats . . . . . . . . . . . . . . . . . . . . . . . 5 3. On-link Threats . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Denial-of-Service Attack on the Link . . . . . . . . . . . 5 3.1. Denial-of-Service Attack on the Link . . . . . . . . . . . 5
3.2. Denial-of-Service Attack on the Outside . . . . . . . . . 5 3.2. Denial-of-Service Attack on the Outside . . . . . . . . . 5
3.3. Confidentiality, Integrity or Authorization Violations . . 6 3.3. Confidentiality, Integrity or Authorization Violations . . 6
4. Mitigation Methods . . . . . . . . . . . . . . . . . . . . . . 6 4. Mitigation Methods . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Passive Mode for PIM . . . . . . . . . . . . . . . . . . . 7 4.1. Passive Mode for PIM . . . . . . . . . . . . . . . . . . . 7
4.2. Use of IPsec among PIM Routers . . . . . . . . . . . . . . 7 4.2. Use of IPsec among PIM Routers . . . . . . . . . . . . . . 7
4.3. IP Filtering PIM Messages . . . . . . . . . . . . . . . . 7 4.3. IP Filtering PIM Messages . . . . . . . . . . . . . . . . 7
4.4. Summary of Vulnerabilities and Mitigation Methods . . . . 8 4.4. Summary of Vulnerabilities and Mitigation Methods . . . . 8
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 11
1. Introduction 1. Introduction
There has been some analysis of the security threats to the multicast There has been some analysis of the security threats to the multicast
routing infrastructures [RFC4609], some work on implementing routing infrastructures [RFC4609], some work on implementing
confidentiality, integrity and authorization in the multicast payload confidentiality, integrity and authorization in the multicast payload
[RFC3740], and also some analysis of security threats in IGMP/MLD [RFC3740], and also some analysis of security threats in IGMP/MLD
[I-D.daley-magma-smld-prob], but no comprehensive analysis of [I-D.daley-magma-smld-prob], but no comprehensive analysis of
skipping to change at page 4, line 30 skipping to change at page 4, line 30
2.3. Routers May Accept PIM Messages From Non-Neighbors 2.3. Routers May Accept PIM Messages From Non-Neighbors
The PIM-SM specification recommends that PIM messages other than The PIM-SM specification recommends that PIM messages other than
Hellos should not be accepted except from valid PIM neighbors. Hellos should not be accepted except from valid PIM neighbors.
However, the specification does not mandate this, and so some However, the specification does not mandate this, and so some
implementations may be susceptible to attack from PIM messages sent implementations may be susceptible to attack from PIM messages sent
by non-neighbors. by non-neighbors.
2.4. An Unauthorized Node May Be Elected as the PIM DR 2.4. An Unauthorized Node May Be Elected as the PIM DR
The Designated Router (DR) on a LAN is responsible for Register- The Designated Router (DR) on a Local Area Network (LAN) is
encapsulating data from new sources on the LAN, and for generating responsible for Register-encapsulating data from new sources on the
PIM Join/Prune messages on behalf of group members on the LAN. LAN, and for generating PIM Join/Prune messages on behalf of group
members on the LAN.
A node which can become a PIM neighbor can also cause itself to be A node which can become a PIM neighbor can also cause itself to be
elected DR, whether or not the DR Priority option is being used in elected DR, whether or not the DR Priority option is being used in
PIM Hello messages on the LAN. PIM Hello messages on the LAN.
2.5. A Node May Become an Unauthorized PIM Asserted Forwarder 2.5. A Node May Become an Unauthorized PIM Asserted Forwarder
With a PIM Assert message, a router can be elected to be in charge of With a PIM Assert message, a router can be elected to be in charge of
forwarding all traffic for a particular (S,G) or (*,G) onto the LAN. forwarding all traffic for a particular (S,G) or (*,G) onto the LAN.
This overrides DR behaviour. This overrides DR behaviour.
skipping to change at page 7, line 26 skipping to change at page 7, line 27
should provide an option to specify that the interface is "passive" should provide an option to specify that the interface is "passive"
with regard to PIM: no PIM packets are sent or processed (if with regard to PIM: no PIM packets are sent or processed (if
received), but hosts can still send and receive multicast on that received), but hosts can still send and receive multicast on that
interface. interface.
4.2. Use of IPsec among PIM Routers 4.2. Use of IPsec among PIM Routers
Instead of passive mode, or when multiple PIM routers exist on a Instead of passive mode, or when multiple PIM routers exist on a
single link, one could also use IPsec to secure the PIM messaging, to single link, one could also use IPsec to secure the PIM messaging, to
prevent anyone from subverting it. The actual procedures have been prevent anyone from subverting it. The actual procedures have been
described in [RFC4601] and [I-D.atwood-pim-sm-linklocal]. described in [RFC4601] and [I-D.ietf-pim-sm-linklocal].
However, it is worth noting that setting up IPsec Security However, it is worth noting that setting up IPsec Security
Associations (SAs) manually can be a very tedious process, and the Associations (SAs) manually can be a very tedious process, and the
routers might not even support IPsec; further automatic key routers might not even support IPsec; further automatic key
negotiation may not be feasible in these scenarios either. A Group negotiation may not be feasible in these scenarios either. A Group
Domain of Interpretation (GDOI) [RFC3547] server might be able to Domain of Interpretation (GDOI) [RFC3547] server might be able to
mitigate this negotiation. mitigate this negotiation.
4.3. IP Filtering PIM Messages 4.3. IP Filtering PIM Messages
skipping to change at page 8, line 5 skipping to change at page 7, line 51
access-list. This is more effective than PIM passive mode, as this access-list. This is more effective than PIM passive mode, as this
also blocks Register messages. also blocks Register messages.
This is also acceptable when there is more than one PIM router on the This is also acceptable when there is more than one PIM router on the
link if IPsec is used (because the access-list processing sees the link if IPsec is used (because the access-list processing sees the
valid PIM messages as IPsec AH/ESP packets). However, this presumes valid PIM messages as IPsec AH/ESP packets). However, this presumes
that the link is not used to transit unicast packets between the PIM that the link is not used to transit unicast packets between the PIM
routers, or that the Register messages are also being sent with routers, or that the Register messages are also being sent with
IPsec. IPsec.
When multiple routers exist on a link, IPsec is not required if it is
possible to prevent hosts from sending PIM messages at Ethernet
switch (or equivalent) host ports. This could be accomplished in at
least two ways:
1. Use IP access lists on the stub routers to allow PIM messages
from the valid neighbor IP addresses only, and implement IP
spoofing prevention at Ethernet switch port level using
proprietary mechanisms, or
2. Filter out all PIM messages at configured host ports on Ethernet
switches instead of doing it on the routers.
The main benefit of this approach is that multiple stub routers can
still communicate through the LAN without IPsec but hosts are not
able to disturb the PIM protocol. The drawback is that Ethernet
switches need to implement much finer-grained IP layer filtering and
the operational requirements of carefully maintaining these filters
could be significant.
4.4. Summary of Vulnerabilities and Mitigation Methods 4.4. Summary of Vulnerabilities and Mitigation Methods
This section summarizes the vulnerabilities, and how well the This section summarizes the vulnerabilities, and how well the
mitigation methods are able to cope with them. mitigation methods are able to cope with them.
Summary of vulnerabilities and mitigations: Summary of vulnerabilities and mitigations:
+-----+--------------------+-----------------+-----------------+ +-----+--------------------+-----------------+-----------------+
| Sec | Vulnerability | One stub router | >1 stub routers | | Sec | Vulnerability | One stub router | >1 stub routers |
| | | PASV|IPsec|Filt | PASV|IPsec|Filt | | | | PASV|IPsec|Filt | PASV|IPsec|Filt |
+-----+--------------------+-----+-----+-----+-----+-----+-----+ +-----+--------------------+-----+-----+-----+-----+-----+-----+
| 2.1 | Hosts Registering | N | N+ | Y | N | N+ | * | | 2.1 | Hosts Registering | N | N+ | Y | N | N+ | Ysw |
+-----+--------------------+-----+-----+-----+-----+-----+-----+ +-----+--------------------+-----+-----+-----+-----+-----+-----+
| 2.2 | Invalid Neighbor | Y | Y | Y | * | Y | * | | 2.2 | Invalid Neighbor | Y | Y | Y | * | Y | Ysw |
+-----+--------------------+-----+-----+-----+-----+-----+-----+ +-----+--------------------+-----+-----+-----+-----+-----+-----+
| 2.3 | Adjacency Not Reqd | Y | Y | Y | * | Y | * | | 2.3 | Adjacency Not Reqd | Y | Y | Y | * | Y | Ysw |
+-----+--------------------+-----+-----+-----+-----+-----+-----+ +-----+--------------------+-----+-----+-----+-----+-----+-----+
| 2.4 | Invalid DR | Y | Y | Y | * | Y | * | | 2.4 | Invalid DR | Y | Y | Y | * | Y | Ysw |
+-----+--------------------+-----+-----+-----+-----+-----+-----+ +-----+--------------------+-----+-----+-----+-----+-----+-----+
| 2.5 | Invalid Forwarder | Y | Y | Y | * | Y | * | | 2.5 | Invalid Forwarder | Y | Y | Y | * | Y | Ysw |
+-----+--------------------+-----+-----+-----+-----+-----+-----+ +-----+--------------------+-----+-----+-----+-----+-----+-----+
Figure 1 Figure 1
"*" means Yes if IPsec is used in addition; No otherwise. "*" means Yes if IPsec is used in addition; No otherwise
"Ysw" means Yes if IPsec is used in addition or IP filtering is done
on Ethernet switches on all host ports; No otherwise.
"N+" means that the use of IPsec between the on-link routers does not "N+" means that the use of IPsec between the on-link routers does not
protect from this; IPsec would have to be used at RPs. protect from this; IPsec would have to be used at RPs.
To summarize, IP protocol filtering for all PIM messages appears to To summarize, IP protocol filtering for all PIM messages appears to
be the most complete solution when coupled with the use of IPsec 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. between the real stub routers when there are more than one of them.
If hosts performing registering is not considered a serious problem, However, IPsec is not required if PIM message filtering or certain
IP protocol filtering and passive-mode PIM seem to be equivalent kind of IP spoofing prevention is applied on all the host ports on
approaches. Ethernet switches. If hosts performing registering is not considered
a serious problem, IP protocol filtering and passive-mode PIM seem to
be equivalent approaches.
5. Acknowledgements 5. Acknowledgements
Greg Daley and Gopi Durup wrote an excellent analysis of MLD security Greg Daley and Gopi Durup wrote an excellent analysis of MLD security
issues [I-D.daley-magma-smld-prob], which gave inspiration in issues [I-D.daley-magma-smld-prob], which gave inspiration in
exploring the on-link PIM threats problem space. exploring the on-link PIM threats problem space.
Ayan Roy-Chowdhury, Beau Williamson, and Bharat Joshi provided good Ayan Roy-Chowdhury, Beau Williamson, Bharat Joshi, and Dino Farinacci
feedback for this memo. provided good feedback for this memo.
6. IANA Considerations 6. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
7. Security Considerations 7. Security Considerations
This memo analyzes the threats to the PIM multicast routing protocol This memo analyzes the threats to the PIM multicast routing protocol
at the last-hop, and proposes some possible mitigation techniques. at the last-hop, and proposes some possible mitigation techniques.
skipping to change at page 9, line 29 skipping to change at page 10, line 7
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol
Independent Multicast - Sparse Mode (PIM-SM) Multicast Independent Multicast - Sparse Mode (PIM-SM) Multicast
Routing Security Issues and Enhancements", RFC 4609, Routing Security Issues and Enhancements", RFC 4609,
October 2006. October 2006.
8.2. Informative References 8.2. Informative References
[I-D.atwood-pim-sm-linklocal]
Atwood, J. and S. Islam, "Security Issues in PIM-SM Link-
local Messages", draft-atwood-pim-sm-linklocal-01 (work in
progress), June 2006.
[I-D.daley-magma-smld-prob] [I-D.daley-magma-smld-prob]
Daley, G. and G. Kurup, "Trust Models and Security in Daley, G. and G. Kurup, "Trust Models and Security in
Multicast Listener Discovery", Multicast Listener Discovery",
draft-daley-magma-smld-prob-00 (work in progress), draft-daley-magma-smld-prob-00 (work in progress),
July 2004. July 2004.
[I-D.hayashi-igap] [I-D.hayashi-igap]
Hayashi, T., "Internet Group membership Authentication Hayashi, T., "Internet Group membership Authentication
Protocol (IGAP)", draft-hayashi-igap-03 (work in Protocol (IGAP)", draft-hayashi-igap-03 (work in
progress), August 2003. progress), August 2003.
[I-D.ietf-pim-sm-linklocal]
Atwood, J. and S. Islam, "Security Issues in PIM-SM Link-
local Messages", draft-ietf-pim-sm-linklocal-00 (work in
progress), October 2006.
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003. Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
Architecture", RFC 3740, March 2004. Architecture", RFC 3740, March 2004.
Authors' Addresses Authors' Addresses
skipping to change at page 11, line 7 skipping to change at page 11, line 7
James Lingard James Lingard
Arastra, Inc. Arastra, Inc.
P.O. Box 10905 P.O. Box 10905
Palo Alto, CA 94303 Palo Alto, CA 94303
USA USA
Email: jchl@arastra.com Email: jchl@arastra.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 22 change blocks. 
33 lines changed or deleted 59 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/