draft-ietf-pim-lasthop-threats-02.txt   draft-ietf-pim-lasthop-threats-03.txt 
PIM WG 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 7, 2008 Arastra Expires: April 12, 2008 Arastra
October 5, 2007 October 10, 2007
Host Threats to Protocol Independent Multicast (PIM) Host Threats to Protocol Independent Multicast (PIM)
draft-ietf-pim-lasthop-threats-02.txt draft-ietf-pim-lasthop-threats-03.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 7, 2008. This Internet-Draft will expire on April 12, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This memo complements the list of multicast infrastructure security This memo complements the list of multicast infrastructure security
threat analysis documents by describing Protocol Independent threat analysis documents by describing Protocol Independent
Multicast (PIM) threats specific to router interfaces connecting Multicast (PIM) threats specific to router interfaces connecting
skipping to change at page 2, line 27 skipping to change at page 2, line 27
2.6. BIDIR-PIM Does Not Use RPF Check . . . . . . . . . . . . . 5 2.6. BIDIR-PIM Does Not Use RPF Check . . . . . . . . . . . . . 5
3. On-link Threats . . . . . . . . . . . . . . . . . . . . . . . 6 3. On-link Threats . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Denial-of-Service Attack on the Link . . . . . . . . . . . 6 3.1. Denial-of-Service Attack on the Link . . . . . . . . . . . 6
3.2. Denial-of-Service Attack on the Outside . . . . . . . . . 6 3.2. Denial-of-Service Attack on the Outside . . . . . . . . . 6
3.3. Confidentiality, Integrity or Authorization Violations . . 7 3.3. Confidentiality, Integrity or Authorization Violations . . 7
4. Mitigation Methods . . . . . . . . . . . . . . . . . . . . . . 8 4. Mitigation Methods . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Passive Mode for PIM . . . . . . . . . . . . . . . . . . . 8 4.1. Passive Mode for PIM . . . . . . . . . . . . . . . . . . . 8
4.2. Use of IPsec among PIM Routers . . . . . . . . . . . . . . 8 4.2. Use of IPsec among PIM Routers . . . . . . . . . . . . . . 8
4.3. IP Filtering PIM Messages . . . . . . . . . . . . . . . . 8 4.3. IP Filtering PIM Messages . . . . . . . . . . . . . . . . 8
4.4. Summary of Vulnerabilities and Mitigation Methods . . . . 9 4.4. Summary of Vulnerabilities and Mitigation Methods . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 13
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
security threats to PIM at the host-connecting (typically "Local Area security threats to PIM at the host-connecting (typically "Local Area
skipping to change at page 5, line 42 skipping to change at page 5, line 42
The Assert Timer, by default, is 3 minutes; the state must be The Assert Timer, by default, is 3 minutes; the state must be
refreshed or it will be removed automatically. refreshed or it will be removed automatically.
As noted before, it is also possible to spoof an Assert (e.g., using As noted before, it is also possible to spoof an Assert (e.g., using
a legitimate router's IP address) to cause a temporary disruption on a legitimate router's IP address) to cause a temporary disruption on
the LAN. the LAN.
2.6. BIDIR-PIM Does Not Use RPF Check 2.6. BIDIR-PIM Does Not Use RPF Check
In contrast to all the other PIM multicast routing protocols, BIDIR- PIM protocols do not perform RPF check on the shared tree (e.g., in
PIM does not use RPF check to verify that the forwarded packets are PIM-SM from the RP to local receivers). On the other hand, RPF check
being received from a "topologically correct" direction. This has is performed e.g., on stub host interfaces. Because all forwarding
two immediately obvious implications: in BIDIR-PIM is based on the shared tree principle, it does not use
RPF check to verify that the forwarded packets are being received
from a "topologically correct" direction. This has two immediately
obvious implications:
1. A node may maintain a forwarding loop until the TTL runs out by 1. A node may maintain a forwarding loop until the TTL runs out by
passing packets from interface A to B. This is not believed to passing packets from interface A to B. This is not believed to
cause significant new risk as with a similar ease such a node cause significant new risk as with a similar ease such a node
could generate original packets which would loop back to its could generate original packets which would loop back to its
another interface. another interface.
2. A node may spoof source IP addresses in multicast packets it 2. A node may spoof source IP addresses in multicast packets it
sends. Other PIM protocols drop such packets when performing the sends. Other PIM protocols drop such packets when performing the
RPF check. BIDIR-PIM accepts such packets allowing easier DoS RPF check. BIDIR-PIM accepts such packets allowing easier DoS
skipping to change at page 10, line 4 skipping to change at page 10, line 25
| 2.3 | Adjacency Not Reqd | Y | Y | Y | * | Y | Ysw | | 2.3 | Adjacency Not Reqd | Y | Y | Y | * | Y | Ysw |
+-----+---------------------+-----+-----+-----+-----+-----+-----+ +-----+---------------------+-----+-----+-----+-----+-----+-----+
| 2.4 | Invalid DR /DF | Y | Y | Y | * | Y | Ysw | | 2.4 | Invalid DR /DF | Y | Y | Y | * | Y | Ysw |
+-----+---------------------+-----+-----+-----+-----+-----+-----+ +-----+---------------------+-----+-----+-----+-----+-----+-----+
| 2.5 | Invalid Forwarder | Y | Y | Y | * | Y | Ysw | | 2.5 | Invalid Forwarder | Y | Y | Y | * | Y | Ysw |
+-----+---------------------+-----+-----+-----+-----+-----+-----+ +-----+---------------------+-----+-----+-----+-----+-----+-----+
| 2.6 | No RPF Check (BIDIR)| x | x | x | x | x | x | | 2.6 | No RPF Check (BIDIR)| x | x | x | x | x | x |
+-----+---------------------+-----+-----+-----+-----+-----+-----+ +-----+---------------------+-----+-----+-----+-----+-----+-----+
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 "Ysw" means Yes if IPsec is used in addition or IP filtering is done
on Ethernet switches on all host ports; No otherwise. 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.
"x" means that with BIDIR-PIM, IP access lists or RPF mechanisms need "x" means that with BIDIR-PIM, IP access lists or RPF mechanisms need
to be applied to prevent originating packets with topologically to be applied in stub interfaces to prevent originating packets with
incorrect source addresses. This needs to be done in addition to any topologically incorrect source addresses. This needs to be done in
other chosen approach. addition to any other chosen approach.
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.
However, IPsec is not required if PIM message filtering or certain However, IPsec is not required if PIM message filtering or certain
kind of IP spoofing prevention is applied on all the host ports on kind of IP spoofing prevention is applied on all the host ports on
Ethernet switches. If hosts performing registering is not considered Ethernet switches. If hosts performing registering is not considered
a serious problem, IP protocol filtering and passive-mode PIM seem to a serious problem, IP protocol filtering and passive-mode PIM seem to
be equivalent approaches. Additionally if BIDIR-PIM is used, ingress be equivalent approaches. Additionally if BIDIR-PIM is used, ingress
filtering will need to be applied to multicast packets as well as filtering will need to be applied in stub interfaces to multicast
unicast to prevent hosts using wrong source addresses. packets as well as unicast to prevent hosts using wrong source
addresses.
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, Bharat Joshi, Dino Farinacci, Ayan Roy-Chowdhury, Beau Williamson, Bharat Joshi, Dino Farinacci,
John Zwiebel, Stig Venaas, and Yiqun Cai provided good feedback for John Zwiebel, Stig Venaas, and Yiqun Cai provided good feedback for
this memo. this memo.
 End of changes. 9 change blocks. 
17 lines changed or deleted 22 lines changed or added

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