receipt.
Metric Preference
The preference value assigned to the unicast routing protocol that
provided the route to the source.
Metric
The cost metric of the unicast route to the source. The metric is
in units applicable to the unicast routing protocol used.
Masklen
The length of the address mask of the unicast route to the source.
TTL
Time To Live of the State Refresh message. Decremented each time
the message is forwarded. Note that this is different from the IP
Header TTL, which is always set to 1.
P
Prune indicator flag. This MUST be set to 1 if the State Refresh
is to be sent on a Pruned interface. Otherwise, it MUST be set to
0.
N
Prune Now flag. This SHOULD be set to 1 by the State Refresh
originator on every third State Refresh message and SHOULD be
ignored upon receipt. This is for compatibility with earlier
versions of state refresh.
O
Assert Override flag. This SHOULD be set to 1 by upstream routers
on a LAN if the Assert Timer (AT(S,G)) is not running and SHOULD be
ignored upon receipt. This is for compatibility with earlier
versions of state refresh.
Reserved
Set to zero and ignored upon receipt.
Interval
Set by the originating router to the interval (in seconds) between
consecutive State Refresh messages for this (S,G) pair.
4.8. PIM-DM Timers
PIM-DM maintains the following timers. All timers are countdown
timers -- they are set to a value and count down to zero, at which
point they typically trigger an action. Of course they can just as
easily be implemented as count-up timers, where the absolute expiry
time is stored and compared against a real-time clock, but the
language in this specification assumes that they count downward
towards zero.
Global Timers
Hello Timer: HT
Per interface (I):
Per neighbor (N):
Neighbor Liveness Timer: NLT(N,I)
Per (S,G) Pair:
(S,G) Assert Timer: AT(S,G,I)
(S,G) Prune Timer: PT(S,G,I)
(S,G) PrunePending Timer: PPT(S,G,I)
Per (S,G) Pair:
(S,G) Graft Retry Timer: GRT(S,G)
(S,G) Upstream Override Timer: OT(S,G)
(S,G) Prune Limit Timer: PLT(S,G)
(S,G) Source Active Timer: SAT(S,G)
(S,G) State Refresh Timer: SRT(S,G)
When timer values are started or restarted, they are set to default
values. The following tables summarize those default values.
Timer Name: Hello Timer (HT)
+----------------------+--------+--------------------------------------+
| Value Name | Value | Explanation |
+----------------------+--------+--------------------------------------+
|Hello_Period | 30 sec | Periodic interval for hello messages |
+----------------------+--------+--------------------------------------+
|Triggered_Hello_Delay | 5 sec | Random interval for initial Hello |
| | | message on bootup or triggered Hello |
| | | message to a rebooting neighbor |
+----------------------+--------+--------------------------------------+
Hello messages are sent on every active interface once every
Hello_Period seconds. At system power-up, the timer is initialized
to rand(0,Triggered_Hello_Delay) to prevent synchronization. When a
new or rebooting neighbor is detected, a responding Hello is sent
within rand(0,Triggered_Hello_Delay).
Timer Name: Neighbor Liveness Timer (NLT(N,I))
+-------------------+-----------------+--------------------------------+
| Value Name | Value | Explanation |
+-------------------+-----------------+--------------------------------+
| Hello Holdtime | From message | Hold Time from Hello Message |
+-------------------+-----------------+--------------------------------+
Timer Name: PrunePending Timer (PPT(S,G,I))
+-----------------------+---------------+------------------------------+
| Value Name | Value | Explanation |
+-----------------------+---------------+------------------------------+
| J/P_Override_Interval | OI(I) + PD(I) | Short time after a Prune to |
| | | allow other routers on the |
| | | LAN to send a Join |
+-----------------------+---------------+------------------------------+
The J/P_Override_Interval is the sum of the interface’s
Override_Interval (OI(I)) and Propagation_Delay (PD(I)). If all
routers on a LAN are using the LAN Prune Delay option, both
parameters MUST be set to the largest value on the LAN. Otherwise,
the Override_Interval (OI(I)) MUST be set to 2.5 seconds, and the
Propagation_Delay (PD(I)) MUST be set to 0.5 seconds.
Timer Name: Prune Timer (PT(S,G,I))
+----------------+----------------+------------------------------------+
| Value Name | Value | Explanation |
+----------------+----------------+------------------------------------+
| Prune Holdtime | From message | Hold Time read from Prune Message |
+----------------+----------------+------------------------------------+
Timer Name: Assert Timer (AT(S,G,I))
+--------------------------+---------+---------------------------------+
| Value Name | Value | Explanation |
+--------------------------+---------+---------------------------------+
| Assert Time | 180 sec | Period after last assert before |
| | | assert state is timed out |
+--------------------------+---------+---------------------------------+
Note that, for historical reasons, the Assert message lacks a
Holdtime field. Thus, changing the Assert Time from the default
value is not recommended. If all members of a LAN are state refresh
enabled, the Assert Time will be three times the received
RefreshInterval(S,G).
Timer Name: Graft Retry Timer (GRT(S,G))
+--------------------+-------+-----------------------------------------+
| Value Name | Value | Explanation |
+--------------------+-------+-----------------------------------------+
| Graft_Retry_Period | 3 sec | In the absence of receipt of a GraftAck |
| | | message, the time before retransmission |
| | | of a Graft message |
+--------------------+-------+-----------------------------------------+
Timer Name: Upstream Override Timer (OT(S,G))
+------------+----------------+----------------------------------------+
| Value Name | Value | Explanation |
+------------+----------------+----------------------------------------|
| t_override | rand(0, OI(I)) | Randomized delay to prevent response |
| | | implosion when sending a join message |
| | | to override someone else’s prune |
+------------+----------------+----------------------------------------+
t_override is a random value between 0 and the interface’s
Override_Interval (OI(I)). If all routers on a LAN are using the LAN
Prune Delay option, the Override_Interval (OI(I)) MUST be set to the
largest value on the LAN. Otherwise, the Override_Interval (OI(I))
MUST be set to 2.5 seconds.
Timer Name: Prune Limit Timer (PLT(S,G))
+------------+--------------------+------------------------------------+
| Value Name | Value | Explanation |
+------------+--------------------+------------------------------------|
| t_limit | Default: 210 secs | Used to prevent Prune storms on a |
| | | LAN |
+------------+--------------------+------------------------------------+
Timer Name: Source Active Timer (SAT(S,G))
+----------------+-------------------+---------------------------------+
| Value Name | Value | Explanation |
+----------------+-------------------+---------------------------------+
| SourceLifetime | Default: 210 secs | Period of time after receiving |
| | | a multicast message a directly |
| | | attached router will continue |
| | | to send State Refresh messages |
+----------------+-------------------+---------------------------------+
Timer Name: State Refresh Timer (SRT(S,G))
+-----------------+------------------+---------------------------------+
| Value Name | Value | Explanation |
+-----------------+------------------+---------------------------------+
| RefreshInterval | Default: 60 secs | Interval between successive |
| | | state refresh messages |
+-----------------+------------------+---------------------------------+
5. Protocol Interaction Considerations
PIM-DM is designed to be independent of underlying unicast routing
protocols and will interact only to the extent needed to perform RPF
checks. It is generally assumed that multicast area and autonomous
system boundaries will correspond to the same boundaries for unicast
routing, though a deployment that does not follow this assumption is
not precluded by this specification.
In general, PIM-DM interactions with other multicast routing
protocols should be in compliance with RFC 2715 [7]. Other specific
interactions are noted below.
5.1. PIM-SM Interactions
PIM-DM is not intended to interact directly with PIM-SM, even though
they share a common packet format. It is particularly important to
note that a router cannot differentiate between a PIM-DM neighbor and
a PIM-SM neighbor based on Hello messages.
In the event that a PIM-DM router becomes a neighbor of a PIM-SM
router, the two will effectively form a simplex link, with the PIM-DM
router sending all multicast messages to the PIM-SM router while the
PIM-SM router sends no multicast messages to the PIM-DM router.
The common packet format permits a hybrid PIM-SM/DM implementation
that would use PIM-SM when a rendezvous point is known and PIM-DM
when one is not. Such an implementation is outside the scope of this
document.
5.2. IGMP Interactions
PIM-DM will forward received multicast data packets to neighboring
host group members in all cases except when the PIM-DM router is in
an Assert Loser state on that interface. Note that a PIM Prune
message is not permitted to prevent the delivery of messages to a
network with group members.
A PIM-DM Router MAY use the DR Priority option described in PIM-SM
[14] to elect an IGMP v1 querier.
5.3. Source Specific Multicast (SSM) Interactions
PIM-DM makes no special considerations for SSM [15]. All Prunes and
Grafts within the protocol are for a specific source, so no
additional checks have to be made.
5.4. Multicast Group Scope Boundary Interactions
Although multicast group scope boundaries are generally identical to
routing area boundaries, it is conceivable that a routing area might
be partitioned for a particular multicast group. PIM-DM routers MUST
NOT send any messages concerning a particular group across that
group’s scope boundary.
6. IANA Considerations
6.1. PIM Address Family
The PIM Address Family field was chosen to be 8 bits as a tradeoff
between packet format and use of the IANA assigned numbers. When the
PIM packet format was designed, only 15 values were assigned for
Address Families, and large numbers of new Address Families were not
envisioned; 8 bits seemed large enough. However, the IANA assigns
Address Families in a 16 bit value. Therefore, the PIM Address
Family is allocated as follows:
Values 0 - 127 are designated to have the same meaning as IANA
assigned Address Family Numbers [9].
Values 128 - 250 are designated to be assigned by the IANA based on
IESG approval, as defined in [8].
Values 251 - 255 are designated for Private Use, as defined in [8].
6.2. PIM Hello Options
Values 17 - 65000 are to be assigned by the IANA. Since the space is
large, they may be assigned as First Come First Served, as defined in
[8]. Assignments are valid for one year and may be renewed.
Permanent assignments require a specification, as defined in [8].
7. Security Considerations
The IPsec authentication header [10] 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. In any case, a PIM router SHOULD NOT accept and process
PIM messages from neighbors unless a valid Hello message has been
received from that neighbor.
Note that PIM-DM has no rendezvous point, and therefore no single
point of failure that may be vulnerable. Because PIM-DM uses unicast
routes provided by an unknown routing protocol, it may suffer
collateral effects if the unicast routing protocol is attacked.
7.1. Attacks Based on Forged Messages
The extent of possible damage depends on the type of counterfeit
messages accepted. We next consider the impact of possible
forgeries. A forged PIM-DM message is link local and can only reach a
LAN if it was sent by a local host or if it was allowed onto the LAN
by a compromised or non-compliant router.
1. A forged Hello message can cause multicast traffic to be delivered
to links where there are no legitimate requestors, potentially
wasting bandwidth on that link. On a multi-access LAN, the
effects are limited without the capability to forge a Join
message, as other routers will Prune the link if the traffic is
not desired.
2. A forged Join/Prune message can cause multicast traffic to be
delivered to links where there are no legitimate requestors,
potentially wasting bandwidth on that link. A forged Prune
message on a multi-access LAN is generally not a significant
attack in PIM, because any legitimately joined router on the LAN
would override the Prune with a Join before the upstream router
stops forwarding data to the LAN.
3. A forged Graft message can cause multicast traffic to be delivered
to links where there are no legitimate requestors, potentially
wasting bandwidth on that link. In principle, Graft messages
could be sent multiple hops because they are unicast to the
upstream router. This should not be a problem, as the remote
forger should have no way to get a Hello message to the target of
the attack. Without a valid Hello message, the receiving router
SHOULD NOT accept the Graft.
4. A forged GraftAck message has no impact, as it will be ignored
unless the router has recently sent a Graft to its upstream
router.
5. By forging an Assert message on a multi-access LAN, an attacker
could cause the legitimate forwarder to stop forwarding traffic to
the LAN. Such a forgery would prevent any hosts downstream of
that LAN from receiving traffic.
6. A forged State Refresh message on a multi-access LAN would have
the same impact as a forged Assert message, having the same
general functions. In addition, forged State Refresh messages
would be propagated downstream and might be used in a denial of
service attack. Therefore, a PIM-DM router SHOULD rate limit
State Refresh messages propagated.
7.2. Non-cryptographic Authentication Mechanisms
A PIM-DM router SHOULD provide an option to limit the set of
neighbors from which it will accept PIM-DM messages. Either static
configuration of IP addresses or an IPSec security association may be
used. All options that restrict the range of addresses from which
packets are accepted MUST default to allowing all packets.
Furthermore, a PIM router SHOULD NOT accept protocol messages from a
router from which it has not yet received a valid Hello message.
7.3. Authentication Using IPsec
The IPSec [10] transport mode using the Authentication Header (AH) is
the recommended method to prevent the above attacks in 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. The Encapsulating Security
Payload (ESP) MAY also be used to provide both encryption and
authentication of PIM protocol messages. 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 and associated Security
Parameters Indices 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 Security Associations. It assumes that manual
configuration of Security Associations is performed, but it does not
preclude the use of some future negotiation protocol such as GDOI
[17] to establish Security Associations.
The network administrator defines a Security Association (SA) and
Security Parameters Index (SPI) to be used to authenticate all PIM-DM
protocol messages from each router on each link in a PIM-DM domain.
In order to avoid the problem of allocating individual keys for each
neighbor on a link to each individual router, it is acceptable to
establish only one authentication key for all PIM-DM routers on a
link. This will not specifically authenticate the individual router
sending the message, but will ensure that the sender is a PIM-DM
router on that link. If this method is used, the receiver of the
message MUST ignore the received sequence number, thus disabling
anti-replay mechanisms. The effects of disabling anti-replay
mechanisms are essentially the same as the effects of forged
messages, described in Section 7.1, with the additional protection
that the forger can only reuse legitimate messages.
The Security Policy Database at a PIM-DM router should be configured
to ensure that all incoming and outgoing PIM-DM packets use the SA
associated with the interface to which the packet is sent. Note
that, according to [10], there is nominally a different Security
Association Database (SAD) for each router interface. Thus, the
selected Security Association for an inbound PIM-DM packet can vary
depending on the interface on which the packet arrived. This fact
allows the network administrator to use different authentication
methods for each link, even though the destination address is the
same for most PIM-DM packets, regardless of interface.
7.4. Denial of Service Attacks
There are a number of possible denial of service attacks against PIM
that can be caused by generating false PIM protocol messages or even
by generating false data traffic. Authenticating PIM protocol
traffic prevents some, but not all, of these attacks. The possible
attacks include the following:
* Sending packets to many different group addresses quickly can
amount to a denial of service attack in and of itself. These
messages will initially be flooded throughout the network before
they are pruned back. The maintenance of state machines and State
Refresh messages will be a continual drain on network resources.
* Forged State Refresh messages sent quickly could be propagated by
downstream routers, creating a potential denial of service attack.
Therefore, a PIM-DM router SHOULD limit the rate of State Refresh
messages propagated.
8. Acknowledgments
The major features of PIM-DM were originally designed by Stephen
Deering, Deborah Estrin, Dino Farinacci, Van Jacobson, Ahmed Helmy,
David Meyer, and Liming Wei. Additional features for state refresh
were designed by Dino Farinacci, Isidor Kouvelas, and Kurt Windisch.
This revision was undertaken to incorporate some of the lessons
learned during the evolution of the PIM-SM specification and early
deployments of PIM-DM.
Thanks the PIM Working Group for their comments.
9. References
9.1. Normative References
[1] Deering, S., "Host extensions for IP multicasting", STD 5, RFC
1112, August 1989.
[2] Fenner, W., "Internet Group Management Protocol, Version 2", RFC
2236, November 1997.
[3] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version 3",
RFC 3376, October 2002.
[4] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S.,
Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. Wei,
"Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol
Specification", RFC 2362, June 1998.
[5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[6] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999.
[7] Thaler, D., "Interoperability Rules for Multicast Routing
Protocols", RFC 2715, October 1999.
[8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[9] IANA, "Address Family Numbers", linked from
http://www.iana.org/numbers.html.
[10] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[11] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[12] Deering, S.E., "Multicast Routing in a Datagram Internetwork",
Ph.D. Thesis, Electrical Engineering Dept., Stanford University,
December 1991.
[13] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector
Multicast Routing Protocol", RFC 1075, November 1988.
[14] Fenner, W., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised)", Work in Progress.
[15] Holbrook, H. and B. Cain, "Source Specific Multicast for IP",
Work in Progress.
[16] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bi-
directional Protocol Independent Multicast", Work in Progress.
[17] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group
Domain of Interpretation", RFC 3547, July 2003.
[18] Fenner, W., Handley, M., Kermode, R., and D. Thaler, "Bootstrap
Router (BSR) Mechanism for PIM Sparse Mode", Work in Progress.
Authors’ Addresses
Andrew Adams
NextHop Technologies
825 Victors Way, Suite 100
Ann Arbor, MI 48108-2738
EMail: ala@nexthop.com
Jonathan Nicholas
ITT Industries
Aerospace/Communications Division
100 Kingsland Rd
Clifton, NJ 07014
EMail: jonathan.nicholas@itt.com
William Siadak
NextHop Technologies
825 Victors Way, Suite 100
Ann Arbor, MI 48108-2738
EMail: wfs@nexthop.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS