draft-ietf-pim-lasthop-threats-01.txt   draft-ietf-pim-lasthop-threats-02.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: December 17, 2007 Arastra Expires: April 7, 2008 Arastra
June 15, 2007 October 5, 2007
Last-hop Threats to Protocol Independent Multicast (PIM) Host Threats to Protocol Independent Multicast (PIM)
draft-ietf-pim-lasthop-threats-01.txt draft-ietf-pim-lasthop-threats-02.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 December 17, 2007. This Internet-Draft will expire on April 7, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
An analysis of security threats has been done for some parts of the This memo complements the list of multicast infrastructure security
multicast infrastructure, but the threats specific to the last-hop threat analysis documents by describing Protocol Independent
("Local Area Network") attacks by hosts on the PIM routing protocol Multicast (PIM) threats specific to router interfaces connecting
have not been well described in the past. This memo aims to fill hosts.
that gap.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Last-hop PIM Vulnerabilities . . . . . . . . . . . . . . . . . 3 2. Host-interface PIM Vulnerabilities . . . . . . . . . . . . . . 3
2.1. Nodes May Send Unauthorized PIM Register Messages . . . . 3 2.1. Nodes May Send Unauthorized PIM Register Messages . . . . 4
2.2. Nodes May Become Unauthorized PIM Neighbors . . . . . . . 4 2.2. Nodes May Become Unauthorized PIM Neighbors . . . . . . . 4
2.3. Routers May Accept PIM Messages From Non-Neighbors . . . . 4 2.3. Routers May Accept PIM Messages From Non-Neighbors . . . . 4
2.4. An Unauthorized Node May Be Elected as the PIM DR . . . . 4 2.4. An Unauthorized Node May Be Elected as the PIM DR or DF . 4
2.4.1. PIM-SM Designated Router Election . . . . . . . . . . 4
2.4.2. BIDIR-PIM Designated Forwarder Election . . . . . . . 4
2.5. A Node May Become an Unauthorized PIM Asserted 2.5. A Node May Become an Unauthorized PIM Asserted
Forwarder . . . . . . . . . . . . . . . . . . . . . . . . 4 Forwarder . . . . . . . . . . . . . . . . . . . . . . . . 5
3. On-link Threats . . . . . . . . . . . . . . . . . . . . . . . 5 2.6. BIDIR-PIM Does Not Use RPF Check . . . . . . . . . . . . . 5
3.1. Denial-of-Service Attack on the Link . . . . . . . . . . . 5 3. On-link Threats . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Denial-of-Service Attack on the Outside . . . . . . . . . 5 3.1. Denial-of-Service Attack on the Link . . . . . . . . . . . 6
3.3. Confidentiality, Integrity or Authorization Violations . . 6 3.2. Denial-of-Service Attack on the Outside . . . . . . . . . 6
4. Mitigation Methods . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Confidentiality, Integrity or Authorization Violations . . 7
4.1. Passive Mode for PIM . . . . . . . . . . . . . . . . . . . 7 4. Mitigation Methods . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Use of IPsec among PIM Routers . . . . . . . . . . . . . . 7 4.1. Passive Mode for PIM . . . . . . . . . . . . . . . . . . . 8
4.3. IP Filtering PIM Messages . . . . . . . . . . . . . . . . 7 4.2. Use of IPsec among PIM Routers . . . . . . . . . . . . . . 8
4.4. Summary of Vulnerabilities and Mitigation Methods . . . . 8 4.3. IP Filtering PIM Messages . . . . . . . . . . . . . . . . 8
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 4.4. Summary of Vulnerabilities and Mitigation Methods . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
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 last-hop ("Local Area Network") links. security threats to PIM at the host-connecting (typically "Local Area
Network") links.
We define PIM last-hop threats to include: We define these PIM host threats to include:
o Nodes -- hosts or unauthorized routers -- using PIM to attack or o Nodes using PIM to attack or deny service to hosts on the same
deny service to hosts on the same link, link,
o Nodes using PIM to attack or deny service to valid multicast o Nodes using PIM to attack or deny service to valid multicast
routers on the link, or routers on the link, or
o Nodes using PIM (Register messages) to bypass the controls of o Nodes using PIM (Register messages) to bypass the controls of
multicast routers on the link. multicast routers on the link.
The attacking node is typically a host or a host acting as an
unauthorized router.
A node originating multicast data can disturb existing receivers of A node originating multicast data can disturb existing receivers of
the group on the same link, but this issue is not PIM-specific so it the group on the same link, but this issue is not PIM-specific so it
is out of scope. The impact on the outside of the link is described is out of scope. The impact on the outside of the link is described
in [RFC4609]. in [RFC4609].
This document analyzes the last-hop PIM vulnerabilities, formulates a This document analyzes the PIM host-interface vulnerabilities,
few specific threats, proposes some potential ways to mitigate these formulates a few specific threats, proposes some potential ways to
problems and analyzes how well those methods accomplish fixing the mitigate these problems and analyzes how well those methods
issues. accomplish fixing the issues.
It is assumed that the reader is familiar with the basic concepts of It is assumed that the reader is familiar with the basic concepts of
PIM. PIM.
2. Last-hop PIM Vulnerabilities 2. Host-interface PIM Vulnerabilities
This section describes briefly the main attacks against last-hop PIM This section describes briefly the main attacks against host-
signalling, before we get to the actual threats and mitigation interface PIM signalling, before we get to the actual threats and
methods in the next sections. mitigation methods in the next sections.
The attacking node may be either a malicious host or an unauthorized The attacking node may be either a malicious host or an unauthorized
router. router.
2.1. Nodes May Send Unauthorized PIM Register Messages 2.1. Nodes May Send Unauthorized PIM Register Messages
PIM Register messages are sent by unicast, and contain encapsulated PIM Register messages are sent by unicast, and contain encapsulated
multicast data packets. Malicious hosts or routers could also send multicast data packets. Malicious hosts or routers could also send
Register messages themselves, for example to get around rate-limits Register messages themselves, for example to get around rate-limits
or to interfere with foreign Rendezvous Points (RPs) as described in or to interfere with foreign Rendezvous Points (RPs) as described in
[RFC4609]. [RFC4609].
The Register message can be targeted to any IP address, whether in or The Register message can be targeted to any IP address, whether in or
out of the local PIM domain. The source address may be spoofed out of the local PIM domain. The source address may be spoofed
unless spoofing has been prevented [RFC3704], to create arbitrary unless spoofing has been prevented [RFC3704], to create arbitrary
state at the RPs. state at the RPs.
2.2. Nodes May Become Unauthorized PIM Neighbors 2.2. Nodes May Become Unauthorized PIM Neighbors
When PIM has been enabled on a router's "host" interface, any node When PIM has been enabled on a router's host interface, any node can
can also become a PIM neighbor using PIM Hello messages. Having also become a PIM neighbor using PIM Hello messages. Having become a
become a PIM neighbor in this way, the node is able to send other PIM PIM neighbor in this way, the node is able to send other PIM messages
messages to the router and may use those messages to attack the to the router and may use those messages to attack the router.
router.
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 BIDIR-PIM [I-D.ietf-pim-bidir] specification (Section 5.2) specifies
implementations may be susceptible to attack from PIM messages sent that packets from non-neighbors "SHOULD NOT" be accepted. However,
by non-neighbors. the specification does not mandate this, and so some implementations
may be susceptible to attack from PIM messages sent 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 or DF
The Designated Router (DR) on a Local Area Network (LAN) is 2.4.1. PIM-SM Designated Router Election
responsible for Register-encapsulating data from new sources on the
LAN, and for generating PIM Join/Prune messages on behalf of group In PIM-SM, the Designated Router (DR) on a Local Area Network (LAN)
members on the LAN. is responsible for Register-encapsulating data from new sources on
the 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.4.2. BIDIR-PIM Designated Forwarder Election
In BIDIR-PIM [I-D.ietf-pim-bidir] a Designated Forwarder (DF) is
elected per link. The DF is responsible for forwarding data
downstream onto the link, and also for forwarding data from its link
upstream.
A node which can become a BIDIR-PIM neighbor (this is just like
becoming a PIM neighbor, except that the PIM Hello messages must
include the Bidirectional Capable PIM-Hello option) can cause itself
to be elected DF by sending DF Offer messages with a better metric
than its neighbors.
There are also some other BIDIR-PIM attacks related to DF election,
including spoofing DF Offer and DF Winner messages (e.g., using a
legitimate router's IP address), making all but the impersonated
router believe that router is the DF. Also an attacker might prevent
the DF election from converging by sending an infinite sequence of DF
Offer messages.
For further discussion of BIDIR-PIM threats we refer to the security
considerations section in [I-D.ietf-pim-bidir].
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.
The specification says that Assert messages should only be accepted The specification says that Assert messages should only be accepted
from known PIM neighbors, and "SHOULD" be discarded otherwise. So, from known PIM neighbors, and "SHOULD" be discarded otherwise. So,
either the node must be able to spoof an IP address of a current either the node must be able to spoof an IP address of a current
neighbor, form a PIM adjacency first, or count on these checks being neighbor, form a PIM adjacency first, or count on these checks being
disabled. disabled.
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
In contrast to all the other PIM multicast routing protocols, BIDIR-
PIM 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
passing packets from interface A to B. This is not believed to
cause significant new risk as with a similar ease such a node
could generate original packets which would loop back to its
another interface.
2. A node may spoof source IP addresses in multicast packets it
sends. Other PIM protocols drop such packets when performing the
RPF check. BIDIR-PIM accepts such packets allowing easier DoS
attacks on the multicast delivery tree and making the attacker
less traceable.
3. On-link Threats 3. On-link Threats
The previous section described some PIM vulnerabilities; this section The previous section described some PIM vulnerabilities; this section
gives an overview of the more concrete threats exploiting those gives an overview of the more concrete threats exploiting those
vulnerabilities. vulnerabilities.
3.1. Denial-of-Service Attack on the Link 3.1. Denial-of-Service Attack on the Link
The easiest attack is to deny the multicast service on the link. The easiest attack is to deny the multicast service on the link.
This could mean either not forwarding all (or parts of) multicast This could mean either not forwarding all (or parts of) multicast
skipping to change at page 5, line 39 skipping to change at page 6, line 40
o Not forward or register any sourced packets, or o Not forward or register any sourced packets, or
o Send PIM Prune messages to cut off existing transmissions because o Send PIM Prune messages to cut off existing transmissions because
Prune messages are accepted from downstream interfaces even if the Prune messages are accepted from downstream interfaces even if the
router is not a DR. router is not a DR.
An alternative mechanism is to send a PIM Assert message, spoofed to 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 come from a valid PIM neighbor or non-spoofed if a PIM adjacency has
already been formed. For the particular (S,G) or (*,G) from the already been formed. For the particular (S,G) or (*,G) from the
Assert message, this creates the same result as getting elected as a Assert message, this creates the same result as getting elected as a
DR. DR. With BIDIR-PIM similar attacks can be done by becoming the DF or
by preventing the DF election from converging.
3.2. Denial-of-Service Attack on the Outside 3.2. Denial-of-Service Attack on the Outside
It is also possible to perform Denial-of-Service attacks on nodes It is also possible to perform Denial-of-Service attacks on nodes
beyond the link, especially in environments where a multicast router beyond the link, especially in environments where a multicast router
and/or a DR is considered to be a trusted node. and/or a DR is considered to be a trusted node.
In particular, if DRs perform some form of rate-limiting, for example In particular, if DRs perform some form of rate-limiting, for example
on new Join/Prune messages, becoming a DR and sending those messages on new Join/Prune messages, becoming a DR and sending those messages
yourself allows one to subvert these restrictions: therefore rate- yourself allows one to subvert these restrictions: therefore rate-
limiting functions need to be deployed at multiple layers as limiting functions need to be deployed at multiple layers as
described in [RFC4609]. described in [RFC4609].
In addition, any host can send PIM Register messages on their own, to In addition, any host can send PIM Register messages on their own, to
whichever RP it wants; further, if unicast RPF mechanisms [RFC3704] whichever RP it wants; further, if unicast RPF (Reverse Path
have not been applied, the packet may be spoofed. This can be done Forwarding) mechanisms [RFC3704] have not been applied, the packet
to get around rate-limits, and/or to attack remote RPs and/or to may be spoofed. This can be done to get around rate-limits, and/or
interfere with the integrity of an ASM group. This attack is also to attack remote RPs and/or to interfere with the integrity of an ASM
described in [RFC4609]. group. This attack is also described in [RFC4609].
Also, BIDIR-PIM does not prevent nodes from using topologically
incorrect addresses (source address spoofing) making such an attack
more difficulty to trace.
3.3. Confidentiality, Integrity or Authorization Violations 3.3. Confidentiality, Integrity or Authorization Violations
Contrary to unicast, any node is able to legitimately receive all Contrary to unicast, any node is able to legitimately receive all
multicast transmission on the link by just adjusting the appropriate multicast transmission on the link by just adjusting the appropriate
link-layer multicast filters. Confidentiality (if needed) must be link-layer multicast filters. Confidentiality (if needed) must be
obtained by cryptography. obtained by cryptography.
If a node can become a DR, it is able to violate the integrity of any If a node can become a DR, it is able to violate the integrity of any
data streams sent by sources on the LAN, by modifying (possibly in data streams sent by sources on the LAN, by modifying (possibly in
skipping to change at page 8, line 30 skipping to change at page 9, line 33
the operational requirements of carefully maintaining these filters the operational requirements of carefully maintaining these filters
could be significant. 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+ | Ysw | | 2.1 | Hosts Registering | N | N+ | Y | N | N+ | Ysw |
+-----+--------------------+-----+-----+-----+-----+-----+-----+ +-----+---------------------+-----+-----+-----+-----+-----+-----+
| 2.2 | Invalid Neighbor | Y | Y | Y | * | Y | Ysw | | 2.2 | Invalid Neighbor | Y | Y | Y | * | Y | Ysw |
+-----+--------------------+-----+-----+-----+-----+-----+-----+ +-----+---------------------+-----+-----+-----+-----+-----+-----+
| 2.3 | Adjacency Not Reqd | Y | Y | Y | * | Y | Ysw | | 2.3 | Adjacency Not Reqd | Y | Y | Y | * | Y | Ysw |
+-----+--------------------+-----+-----+-----+-----+-----+-----+ +-----+---------------------+-----+-----+-----+-----+-----+-----+
| 2.4 | Invalid DR | 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 |
+-----+---------------------+-----+-----+-----+-----+-----+-----+
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
to be applied to prevent originating packets with topologically
incorrect source addresses. This needs to be done in 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. be equivalent approaches. Additionally if BIDIR-PIM is used, ingress
filtering will need to be applied to multicast 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, and Dino Farinacci Ayan Roy-Chowdhury, Beau Williamson, Bharat Joshi, Dino Farinacci,
provided good feedback for this memo. John Zwiebel, Stig Venaas, and Yiqun Cai 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. on host interfaces and proposes some possible mitigation techniques.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-pim-bidir]
Handley, M., "Bi-directional Protocol Independent
Multicast (BIDIR-PIM)", draft-ietf-pim-bidir-09 (work in
progress), February 2007.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"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
skipping to change at page 10, line 20 skipping to change at page 11, line 36
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] [I-D.ietf-pim-sm-linklocal]
Atwood, J. and S. Islam, "Security Issues in PIM-SM Link- Atwood, J. and S. Islam, "Security Issues in PIM-SM Link-
local Messages", draft-ietf-pim-sm-linklocal-00 (work in local Messages", draft-ietf-pim-sm-linklocal-01 (work in
progress), October 2006. progress), July 2007.
[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.
 End of changes. 35 change blocks. 
77 lines changed or deleted 146 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/