draft-ietf-pim-rfc4601bis-04.txt   draft-ietf-pim-rfc4601bis-05.txt 
Network Working Group B. Fenner Network Working Group B. Fenner
Internet Draft AT&T Labs - Research Internet Draft Arista Networks
Intended Status: Internet Standard M. Handley Intended Status: Internet Standard M. Handley
Expires: August 27, 2015 UCL Expires: November 15, 2015 UCL
Obsoletes: 4601 H. Holbrook Obsoletes: 4601 H. Holbrook
Arastra Arastra
I. Kouvelas I. Kouvelas
R. Parekh R. Parekh
Cisco Systems, Inc. Cisco Systems, Inc.
Z. Zhang Z. Zhang
Juniper Networks Juniper Networks
L. Zheng L. Zheng
Huawei Technologies Huawei Technologies
February 23, 2015 May 14, 2015
Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised) Protocol Specification (Revised)
draft-ietf-pim-rfc4601bis-04 draft-ietf-pim-rfc4601bis-05
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on August 27, 2015. This Internet-Draft will expire on November 15, 2015.
Abstract Abstract
This document specifies Protocol Independent Multicast - Sparse Mode This document specifies Protocol Independent Multicast - Sparse Mode
(PIM-SM). PIM-SM is a multicast routing protocol that can use the (PIM-SM). PIM-SM is a multicast routing protocol that can use the
underlying unicast routing information base or a separate multicast- underlying unicast routing information base or a separate multicast-
capable routing information base. It builds unidirectional shared capable routing information base. It builds unidirectional shared
trees rooted at a Rendezvous Point (RP) per group, and optionally trees rooted at a Rendezvous Point (RP) per group, and optionally
creates shortest-path trees per source. creates shortest-path trees per source.
This document obsoletes RFC 4601 by replacing it, addresses the This document obsoletes RFC 4601 by replacing it, addresses the
errata filed against it, removes the optional (*,*,RP) and PIM errata filed against it, removes the optional (*,*,RP),PIM Multicast
Multicast Border Router features that lack sufficient deployment Border Router features and authentication using IPsec that lack
experience (see Appendix A) and moves the PIM specification to sufficient deployment experience (see Appendix A) and moves the PIM
Internet Standard. specification to Internet Standard.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 10 skipping to change at page 3, line 10
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Pseudocode Notation . . . . . . . . . . . . . . . . . . . 7 2.2. Pseudocode Notation . . . . . . . . . . . . . . . . . . . 8
3. PIM-SM Protocol Overview . . . . . . . . . . . . . . . . . . . 8 3. PIM-SM Protocol Overview . . . . . . . . . . . . . . . . . . . 8
3.1. Phase One: RP Tree . . . . . . . . . . . . . . . . . . . . 8 3.1. Phase One: RP Tree . . . . . . . . . . . . . . . . . . . . 9
3.2. Phase Two: Register-Stop . . . . . . . . . . . . . . . . . 9 3.2. Phase Two: Register-Stop . . . . . . . . . . . . . . . . . 9
3.3. Phase Three: Shortest-Path Tree . . . . . . . . . . . . . 10 3.3. Phase Three: Shortest-Path Tree . . . . . . . . . . . . . 10
3.4. Source-Specific Joins . . . . . . . . . . . . . . . . . . 11 3.4. Source-Specific Joins . . . . . . . . . . . . . . . . . . 11
3.5. Source-Specific Prunes . . . . . . . . . . . . . . . . . . 11 3.5. Source-Specific Prunes . . . . . . . . . . . . . . . . . . 12
3.6. Multi-Access Transit LANs . . . . . . . . . . . . . . . . 12 3.6. Multi-Access Transit LANs . . . . . . . . . . . . . . . . 12
3.7. RP Discovery . . . . . . . . . . . . . . . . . . . . . . . 12 3.7. RP Discovery . . . . . . . . . . . . . . . . . . . . . . . 13
4. Protocol Specification . . . . . . . . . . . . . . . . . . . . 13 4. Protocol Specification . . . . . . . . . . . . . . . . . . . . 13
4.1. PIM Protocol State . . . . . . . . . . . . . . . . . . . . 14 4.1. PIM Protocol State . . . . . . . . . . . . . . . . . . . . 14
4.1.1. General Purpose State . . . . . . . . . . . . . . . . 15 4.1.1. General Purpose State . . . . . . . . . . . . . . . . 15
4.1.2. (*,G) State . . . . . . . . . . . . . . . . . . . . . 16 4.1.2. (*,G) State . . . . . . . . . . . . . . . . . . . . . 16
4.1.3. (S,G) State . . . . . . . . . . . . . . . . . . . . . 17 4.1.3. (S,G) State . . . . . . . . . . . . . . . . . . . . . 17
4.1.4. (S,G,rpt) State . . . . . . . . . . . . . . . . . . . 20 4.1.4. (S,G,rpt) State . . . . . . . . . . . . . . . . . . . 20
4.1.5. State Summarization Macros . . . . . . . . . . . . . . 21 4.1.5. State Summarization Macros . . . . . . . . . . . . . . 21
4.2. Data Packet Forwarding Rules . . . . . . . . . . . . . . . 25 4.2. Data Packet Forwarding Rules . . . . . . . . . . . . . . . 25
4.2.1. Last-Hop Switchover to the SPT . . . . . . . . . . . . 27 4.2.1. Last-Hop Switchover to the SPT . . . . . . . . . . . . 27
4.2.2. Setting and Clearing the (S,G) SPTbit . . . . . . . . 28 4.2.2. Setting and Clearing the (S,G) SPTbit . . . . . . . . 28
skipping to change at page 4, line 27 skipping to change at page 4, line 27
4.10. PIM Timers . . . . . . . . . . . . . . . . . . . . . . .116 4.10. PIM Timers . . . . . . . . . . . . . . . . . . . . . . .116
4.11. Timer Values . . . . . . . . . . . . . . . . . . . . . .118 4.11. Timer Values . . . . . . . . . . . . . . . . . . . . . .118
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . .123 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . .123
5.1. PIM Address Family . . . . . . . . . . . . . . . . . . . .123 5.1. PIM Address Family . . . . . . . . . . . . . . . . . . . .123
5.2. PIM Hello Options . . . . . . . . . . . . . . . . . . . .124 5.2. PIM Hello Options . . . . . . . . . . . . . . . . . . . .124
6. Security Considerations . . . . . . . . . . . . . . . . . . .124 6. Security Considerations . . . . . . . . . . . . . . . . . . .124
6.1. Attacks Based on Forged Messages . . . . . . . . . . . . .124 6.1. Attacks Based on Forged Messages . . . . . . . . . . . . .124
6.1.1. Forged Link-Local Messages . . . . . . . . . . . . . .124 6.1.1. Forged Link-Local Messages . . . . . . . . . . . . . .124
6.1.2. Forged Unicast Messages . . . . . . . . . . . . . . .125 6.1.2. Forged Unicast Messages . . . . . . . . . . . . . . .125
6.2. Non-Cryptographic Authentication Mechanisms . . . . . . .125 6.2. Non-Cryptographic Authentication Mechanisms . . . . . . .125
6.3. Authentication Using IPsec . . . . . . . . . . . . . . . .126 6.3. Authentication . . . . . . . . . . . . . . . . . . . . . .126
6.3.1. Protecting Link-Local Multicast Messages . . . . . . .126 6.4. Denial-of-Service Attacks . . . . . . . . . . . . . . . .126
6.3.2. Protecting Unicast Messages . . . . . . . . . . . . .127 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .126
6.3.2.1. Register Messages . . . . . . . . . . . . . . . .127 8. Normative References . . . . . . . . . . . . . . . . . . . . .128
6.3.2.2. Register-Stop Messages . . . . . . . . . . . . . .127 9. Informative References . . . . . . . . . . . . . . . . . . . .128
6.4. Denial-of-Service Attacks . . . . . . . . . . . . . . . .128 Appendix A. Functionality removed from RFC 4601 . . . . . . . . .130
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .131
8. Normative References . . . . . . . . . . . . . . . . . . . . .129
9. Informative References . . . . . . . . . . . . . . . . . . . .129
Appendix A. Functionality removed from RFC 4601 . . . . . . . . .131
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .132
List of Figures List of Figures
Figure 1. Per-(S,G) register state machine at a DR ................38 Figure 1. Per-(S,G) register state machine at a DR ................38
Figure 2. Downstream per-interface (*,G) state machine ............45 Figure 2. Downstream per-interface (*,G) state machine ............45
Figure 3. Downstream per-interface (S,G) state machine ............49 Figure 3. Downstream per-interface (S,G) state machine ............49
Figure 4. Downstream per-interface (S,G,rpt) state machine ........53 Figure 4. Downstream per-interface (S,G,rpt) state machine ........53
Figure 5. Upstream (*,G) state machine ............................58 Figure 5. Upstream (*,G) state machine ............................58
Figure 6. Upstream (S,G) state machine ............................62 Figure 6. Upstream (S,G) state machine ............................62
Figure 7. Upstream (S,G,rpt) state machine for triggered Figure 7. Upstream (S,G,rpt) state machine for triggered
skipping to change at page 6, line 16 skipping to change at page 6, line 16
This document specifies a protocol for efficiently routing multicast This document specifies a protocol for efficiently routing multicast
groups that may span wide-area (and inter-domain) internets. This groups that may span wide-area (and inter-domain) internets. This
protocol is called Protocol Independent Multicast - Sparse Mode protocol is called Protocol Independent Multicast - Sparse Mode
(PIM-SM) because, although it may use the underlying unicast routing (PIM-SM) because, although it may use the underlying unicast routing
to provide reverse-path information for multicast tree building, it to provide reverse-path information for multicast tree building, it
is not dependent on any particular unicast routing protocol. is not dependent on any particular unicast routing protocol.
PIM-SM version 2 was specified in RFC 4601 as a Proposed Standard. PIM-SM version 2 was specified in RFC 4601 as a Proposed Standard.
This document is intended to address the reported errata and to This document is intended to address the reported errata and to
remove the optional (*,*,RP) feature that lacks sufficient deployment remove the optional (*,*,RP), PIM Multicast Border Router features
experience, to advance PIM-SM to Draft Standard. and authentication using IPsec that lacks sufficient deployment
experience, to advance PIM-SM to Internet Standard.
This document specifies the same protocol as RFC 4601 and This document specifies the same protocol as RFC 4601 and
implementations per the specification in this document will be able implementations per the specification in this document will be able
to interoperate successfully with implementations per RFC 4601. to interoperate successfully with implementations per RFC 4601.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
skipping to change at page 43, line 27 skipping to change at page 43, line 27
another router, most Join or Prune messages could affect each another router, most Join or Prune messages could affect each
upstream state machine. upstream state machine.
In general, a PIM Join/Prune message should only be accepted for In general, a PIM Join/Prune message should only be accepted for
processing if it comes from a known PIM neighbor. A PIM router hears processing if it comes from a known PIM neighbor. A PIM router hears
about PIM neighbors through PIM Hello messages. If a router receives about PIM neighbors through PIM Hello messages. If a router receives
a Join/Prune message from a particular IP source address and it has a Join/Prune message from a particular IP source address and it has
not seen a PIM Hello message from that source address, then the not seen a PIM Hello message from that source address, then the
Join/Prune message SHOULD be discarded without further processing. Join/Prune message SHOULD be discarded without further processing.
In addition, if the Hello message from a neighbor was authenticated In addition, if the Hello message from a neighbor was authenticated
using IPsec AH (see Section 6.3), then all Join/Prune messages from (see Section 6.3), then all Join/Prune messages from that neighbor
that neighbor MUST also be authenticated using IPsec AH. MUST also be authenticated.
We note that some older PIM implementations incorrectly fail to send We note that some older PIM implementations incorrectly fail to send
Hello messages on point-to-point interfaces, so we also RECOMMEND Hello messages on point-to-point interfaces, so we also RECOMMEND
that a configuration option be provided to allow interoperation with that a configuration option be provided to allow interoperation with
such older routers, but that this configuration option SHOULD NOT be such older routers, but that this configuration option SHOULD NOT be
enabled by default. enabled by default.
4.5.1. Receiving (*,G) Join/Prune Messages 4.5.1. Receiving (*,G) Join/Prune Messages
When a router receives a Join(*,G), it must first check to see When a router receives a Join(*,G), it must first check to see
skipping to change at page 71, line 38 skipping to change at page 71, line 38
received by downstream routers on the LAN, and these cause subsequent received by downstream routers on the LAN, and these cause subsequent
Join/Prune messages to be sent to the upstream router that won the Join/Prune messages to be sent to the upstream router that won the
Assert. Assert.
In general, a PIM Assert message should only be accepted for In general, a PIM Assert message should only be accepted for
processing if it comes from a known PIM neighbor. A PIM router hears processing if it comes from a known PIM neighbor. A PIM router hears
about PIM neighbors through PIM Hello messages. If a router receives about PIM neighbors through PIM Hello messages. If a router receives
an Assert message from a particular IP source address and it has not an Assert message from a particular IP source address and it has not
seen a PIM Hello message from that source address, then the Assert seen a PIM Hello message from that source address, then the Assert
message SHOULD be discarded without further processing. In addition, message SHOULD be discarded without further processing. In addition,
if the Hello message from a neighbor was authenticated using the if the Hello message from a neighbor was authenticated (see Section
IPsec Authentication Header (AH) (see Section 6.3), then all Assert 6.3), then all Assert messages from that neighbor MUST also be
messages from that neighbor MUST also be authenticated using IPsec authenticated.
AH.
We note that some older PIM implementations incorrectly fail to send We note that some older PIM implementations incorrectly fail to send
Hello messages on point-to-point interfaces, so we also RECOMMEND Hello messages on point-to-point interfaces, so we also RECOMMEND
that a configuration option be provided to allow interoperation with that a configuration option be provided to allow interoperation with
such older routers, but that this configuration option SHOULD NOT be such older routers, but that this configuration option SHOULD NOT be
enabled by default. enabled by default.
4.6.1. (S,G) Assert Message State Machine 4.6.1. (S,G) Assert Message State Machine
The (S,G) Assert state machine for interface I is shown in Figure 8. The (S,G) Assert state machine for interface I is shown in Figure 8.
skipping to change at page 124, line 19 skipping to change at page 124, line 19
Values 17 through 65000 are to be assigned by the IANA. Since the Values 17 through 65000 are to be assigned by the IANA. Since the
space is large, they may be assigned as First Come First Served as space is large, they may be assigned as First Come First Served as
defined in [9]. Such assignments are valid for one year and may be defined in [9]. Such assignments are valid for one year and may be
renewed. Permanent assignments require a specification (see renewed. Permanent assignments require a specification (see
"Specification Required" in [9].) "Specification Required" in [9].)
6. Security Considerations 6. Security Considerations
This section describes various possible security concerns related to This section describes various possible security concerns related to
the PIM-SM protocol, including a description of how to use IPsec to the PIM-SM protocol. The reader is referred to [8], [15] and [16]
secure the protocol. The reader is referred to [15] and [16] for for further discussion of PIM-SM and multicast security.
further discussion of PIM-SM and multicast security. The IPsec
authentication header [8] MAY be used to provide data integrity
protection and groupwise data origin authentication of PIM protocol
messages. Authentication of PIM messages can protect against unwanted
behaviors caused by unauthorized or altered PIM messages.
Note that PIM relies upon an MRIB populated outside of PIM so Note that PIM relies upon an MRIB populated outside of PIM so
securing the sources of change to the MRIB is RECOMMENDED. securing the sources of change to the MRIB is RECOMMENDED.
6.1. Attacks Based on Forged Messages 6.1. Attacks Based on Forged Messages
The extent of possible damage depends on the type of counterfeit The extent of possible damage depends on the type of counterfeit
messages accepted. We next consider the impact of possible messages accepted. We next consider the impact of possible
forgeries, including forged link-local (Join/Prune, Hello, and forgeries, including forged link-local (Join/Prune, Hello, and
Assert) and forged unicast (Register and Register-Stop) messages. Assert) and forged unicast (Register and Register-Stop) messages.
skipping to change at page 125, line 38 skipping to change at page 125, line 32
1. By forging a Register message, an attacker can cause the RP to 1. By forging a Register message, an attacker can cause the RP to
inject forged traffic onto the shared multicast tree. inject forged traffic onto the shared multicast tree.
2. By forging a Register-stop message, an attacker can prevent a 2. By forging a Register-stop message, an attacker can prevent a
legitimate DR from Registering packets to the RP. This can legitimate DR from Registering packets to the RP. This can
prevent local hosts on that LAN from sending multicast packets. prevent local hosts on that LAN from sending multicast packets.
The above two PIM messages are not changed by intermediate routers The above two PIM messages are not changed by intermediate routers
and need only be examined by the intended receiver. Thus, these and need only be examined by the intended receiver. Thus, these
messages can be authenticated end-to-end, using AH. Attacks on messages can be authenticated end-to-end. Attacks on Register and
Register and Register-Stop messages do not apply to a PIM-SSM-only Register-Stop messages do not apply to a PIM-SSM-only implementation,
implementation, as these messages are not required for PIM-SSM. as these messages are not required for PIM-SSM.
6.2. Non-Cryptographic Authentication Mechanisms 6.2. Non-Cryptographic Authentication Mechanisms
A PIM router SHOULD provide an option to limit the set of neighbors A PIM router SHOULD provide an option to limit the set of neighbors
from which it will accept Join/Prune, Assert, and Hello messages. from which it will accept Join/Prune, Assert, and Hello messages.
Either static configuration of IP addresses or an IPsec security Either static configuration of IP addresses or an IPsec security
association MAY be used. Furthermore, a PIM router SHOULD NOT accept association MAY be used. Furthermore, a PIM router SHOULD NOT accept
protocol messages from a router from which it has not yet received a protocol messages from a router from which it has not yet received a
valid Hello message. valid Hello message.
skipping to change at page 126, line 15 skipping to change at page 126, line 10
a Designated Router SHOULD NOT accept a Register-Stop packet whose IP a Designated Router SHOULD NOT accept a Register-Stop packet whose IP
source address is not a valid RP address for the local domain. source address is not a valid RP address for the local domain.
An implementation SHOULD provide a mechanism to allow an RP to An implementation SHOULD provide a mechanism to allow an RP to
restrict the range of source addresses from which it accepts restrict the range of source addresses from which it accepts
Register-encapsulated packets. Register-encapsulated packets.
All options that restrict the range of addresses from which packets All options that restrict the range of addresses from which packets
are accepted MUST default to allowing all packets. are accepted MUST default to allowing all packets.
6.3. Authentication Using IPsec 6.3. Authentication
The IPsec [8] transport mode using the Authentication Header (AH) is
the recommended method to prevent the above attacks against PIM. The
specific AH authentication algorithm and parameters, including the
choice of authentication algorithm and the choice of key, are
configured by the network administrator. When IPsec authentication
is used, a PIM router should reject (drop without processing) any
unauthorized PIM protocol messages.
To use IPsec, the administrator of a PIM network configures each PIM
router with one or more security associations (SAs) and associated
Security Parameter Indexes (SPIs) that are used by senders to
authenticate PIM protocol messages and are used by receivers to
authenticate received PIM protocol messages. This document does not
describe protocols for establishing SAs. It assumes that manual
configuration of SAs is performed, but it does not preclude the use
of a negotiation protocol such as the Internet Key Exchange [14] to
establish SAs.
IPsec [8] provides protection against replayed unicast and multicast
messages. The anti-replay option for IPsec SHOULD be enabled on all
SAs.
The following sections describe the SAs required to protect PIM
protocol messages.
6.3.1. Protecting Link-Local Multicast Messages
The network administrator defines an SA and SPI that are to be used
to authenticate all link-local PIM protocol messages (Hello,
Join/Prune, and Assert) on each link in a PIM domain.
IPsec [8] allows (but does not require) different Security Policy
Databases (SPD) for each router interface. If available, it may be
desirable to configure the Security Policy Database at a PIM router
such that all incoming and outgoing Join/Prune, Assert, and Hello
packets use a different SA for each incoming or outgoing interface.
6.3.2. Protecting Unicast Messages
IPsec can also be used to provide data origin authentication and data
integrity protection for the Register and Register-Stop unicast
messages.
6.3.2.1. Register Messages
The Security Policy Database at every PIM router is configured to
select an SA to use when sending PIM Register packets to each
rendezvous point.
In the most general mode of operation, the Security Policy Database
at each DR is configured to select a unique SA and SPI for traffic
sent to each RP. This allows each DR to have a different
authentication algorithm and key to talk to the RP. However, this
creates a daunting key management and distribution problem for the
network administrator. Therefore, it may be preferable in PIM domains
where all Designated Routers are under a single administrative
control that the same authentication algorithm parameters (including
the key) be used for all Registered packets in a domain, regardless
of who are the RP and the DR.
In this "single shared key" mode of operation, the network
administrator must choose an SPI for each DR that will be used to
send the PIM protocol packets. The Security Policy Database at every
DR is configured to select an SA (including the authentication
algorithm, authentication parameters, and this SPI) when sending
Register messages to the RP.
By using a single authentication algorithm and associated parameters,
the key distribution problem is simplified. Note, however, that this
method has the property that, in order to change the authentication
method or authentication key used, all routers in the domain must be
updated.
6.3.2.2. Register-Stop Messages
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.
In order to simplify the management problem, it may be acceptable to RFC 4601 mandates the use of IPsec to ensure authentication of the
use the same authentication algorithm and authentication parameters, link-local messages in PIM-SM. The description of authentication
regardless of the sending RP and regardless of the destination DR. using IPsec has been removed due to lack of sufficient implementation
Although a unique SA is needed for each DR, the same authentication and deployment experience. RFC 5796 [8] specifies mechanisms to
algorithm and authentication algorithm parameters (secret key) can be authenticate the PIM-SM link-local messages using the IP security
shared by all DRs and by all RPs. (IPsec) Encapsulating Security Payload (ESP) or (optionally) the
Authentication Header (AH). It specifies optional mechanisms to
provide confidentiality using the ESP. The reader is referred to RFC
5796 [8] for detailed discussion of authentication using IPsec.
6.4. Denial-of-Service Attacks 6.4. Denial-of-Service Attacks
There are a number of possible denial-of-service attacks against PIM There are a number of possible denial-of-service attacks against PIM
that can be caused by generating false PIM protocol messages or even that can be caused by generating false PIM protocol messages or even
by generating false traffic. Authenticating PIM protocol traffic by generating false traffic. Authenticating PIM protocol traffic
prevents some, but not all, of these attacks. Three of the possible prevents some, but not all, of these attacks. Three of the possible
attacks include: attacks include:
- Sending packets to many different group addresses quickly can be a - Sending packets to many different group addresses quickly can be a
skipping to change at page 129, line 29 skipping to change at page 128, line 29
[5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) [5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998. Specification", RFC 2460, December 1998.
[6] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", [6] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP",
RFC 4607, August 2006. RFC 4607, August 2006.
[7] IANA, "Address Family Numbers", [7] IANA, "Address Family Numbers",
<http://www.iana.org/assignments/address-family-numbers>. <http://www.iana.org/assignments/address-family-numbers>.
[8] Kent, S. and K. Seo, "Security Architecture for the Internet [8] Atwood, W., Islam, S. and Siami, M. "Authentication and
Protocol", RFC 4301, December 2005. Confidentiality in Protocol Independent Multicast Sparse Mode
(PIM-SM) Link-Local Messages", RFC 5796, March 2010.
[9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
9. Informative References 9. Informative References
[10] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol [10] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol
Extensions for BGP-4", RFC 4760, January 2007. Extensions for BGP-4", RFC 4760, January 2007.
[11] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap [11] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap
Router (BSR) Mechanism for Protocol Independent Multicast Router (BSR) Mechanism for Protocol Independent Multicast
(PIM)", RFC 5059, January 2008. (PIM)", RFC 5059, January 2008.
[12] Black, D., "Differentiated Services and Tunnels", RFC 2983, [12] Black, D., "Differentiated Services and Tunnels", RFC 2983,
October 2000. October 2000.
[13] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, [13] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast" (BIDIR-PIM), RFC "Bidirectional Protocol Independent Multicast" (BIDIR-PIM), RFC
5015, October 2007. 5015, October 2007.
[14] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key [14] Kaufman, C., Hoffman, P., Nir, Y., P. Eronen, and T. Kivinen,
Exchange (IKEv2) Protocol", RFC 5996, September 2010. "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 7296,
October 2014.
[15] Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent [15] Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent
Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Multicast - Sparse Mode (PIM-SM) Multicast Routing Security
Issues and Enhancements", RFC 4609, August 2006. Issues and Enhancements", RFC 4609, August 2006.
[16] Savola, P. and J. Lingard, "Host Threats to Protocol Independent [16] Savola, P. and J. Lingard, "Host Threats to Protocol Independent
Multicast (PIM)", RFC 5294, August 2008. Multicast (PIM)", RFC 5294, August 2008.
[17] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) [17] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP)
Address in an IPv6 Multicast Address", RFC 3956, November 2004. Address in an IPv6 Multicast Address", RFC 3956, November 2004.
skipping to change at page 132, line 4 skipping to change at page 130, line 14
Appendix A. Functionality removed from RFC 4601 Appendix A. Functionality removed from RFC 4601
Based on a survey of PIM implementations and deployments [18], Based on a survey of PIM implementations and deployments [18],
conducted by IETF PIM working group, the following functionality of conducted by IETF PIM working group, the following functionality of
RFC 4601 has been removed due to lack of sufficient implementation RFC 4601 has been removed due to lack of sufficient implementation
and deployment experience. and deployment experience.
o (*,*,RP) State o (*,*,RP) State
o PIM Multicast Border Router (PMBR) o PIM Multicast Border Router (PMBR)
o Authentication using IPsec
Authors' Addresses Authors' Addresses
Bill Fenner Bill Fenner
AT&T Labs - Research Arista Networks
1 River Oaks Place
San Jose, CA 95134
EMail: fenner@research.att.com EMail: fenner@aristanetworks.com
Mark Handley Mark Handley
Department of Computer Science Department of Computer Science
University College London University College London
Gower Street Gower Street
London WC1E 6BT London WC1E 6BT
United Kingdom United Kingdom
EMail: M.Handley@cs.ucl.ac.uk EMail: M.Handley@cs.ucl.ac.uk
skipping to change at page 133, line 13 skipping to change at page 132, line 13
EMail: riparekh@cisco.com EMail: riparekh@cisco.com
Zhaohui (Jeffrey) Zhang Zhaohui (Jeffrey) Zhang
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
Email: zzhang@juniper.net Email: zzhang@juniper.net
Lianshu Zheng Lianshu Zheng
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
No. 3 Xinxi Road, Shang-di, Hai-dian District Huawei Campus, 156 Beiqing Road, Hai-dian District
Beijing 100085 Beijing 100089
China China
Email: verozheng@huawei.com Email: vero.zheng@huawei.com
 End of changes. 25 change blocks. 
140 lines changed or deleted 54 lines changed or added

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