draft-ietf-pim-sm-v2-new-06.txt   draft-ietf-pim-sm-v2-new-07.txt 
Internet Engineering Task Force PIM WG Internet Engineering Task Force PIM WG
INTERNET-DRAFT Bill Fenner/AT&T INTERNET-DRAFT Bill Fenner/AT&T
draft-ietf-pim-sm-v2-new-06.txt Mark Handley/ICIR draft-ietf-pim-sm-v2-new-07.txt Mark Handley/ICIR
Hugh Holbrook/Cisco Hugh Holbrook/Cisco
Isidor Kouvelas/Cisco Isidor Kouvelas/Cisco
10 December 2002 2 March 2003
Expires: June 2003 Expires: September 2003
Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised) Protocol Specification (Revised)
Status of this Document Status of this Document
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
skipping to change at page 3, line 39 skipping to change at page 3, line 39
4.4.2. Receiving Register Messages at the RP . . . . . . 39 4.4.2. Receiving Register Messages at the RP . . . . . . 39
4.5. PIM Join/Prune Messages. . . . . . . . . . . . . . . 41 4.5. PIM Join/Prune Messages. . . . . . . . . . . . . . . 41
4.5.1. Receiving (*,*,RP) Join/Prune Messages. . . . . . 42 4.5.1. Receiving (*,*,RP) Join/Prune Messages. . . . . . 42
4.5.2. Receiving (*,G) Join/Prune Messages . . . . . . . 45 4.5.2. Receiving (*,G) Join/Prune Messages . . . . . . . 45
4.5.3. Receiving (S,G) Join/Prune Messages . . . . . . . 49 4.5.3. Receiving (S,G) Join/Prune Messages . . . . . . . 49
4.5.4. Receiving (S,G,rpt) Join/Prune Messages . . . . . 52 4.5.4. Receiving (S,G,rpt) Join/Prune Messages . . . . . 52
4.5.5. Sending (*,*,RP) Join/Prune Messages. . . . . . . 58 4.5.5. Sending (*,*,RP) Join/Prune Messages. . . . . . . 58
4.5.6. Sending (*,G) Join/Prune Messages . . . . . . . . 62 4.5.6. Sending (*,G) Join/Prune Messages . . . . . . . . 62
4.5.7. Sending (S,G) Join/Prune Messages . . . . . . . . 66 4.5.7. Sending (S,G) Join/Prune Messages . . . . . . . . 66
4.5.8. (S,G,rpt) Periodic Messages . . . . . . . . . . . 71 4.5.8. (S,G,rpt) Periodic Messages . . . . . . . . . . . 71
4.5.9. State Machine for (S,G,rpt) Triggered 4.5.9. State Machine for (S,G,rpt) Triggered Mes-
Messages . . . . . . . . . . . . . . . . . . . . . . . . 72 sages. . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.6. PIM Assert Messages. . . . . . . . . . . . . . . . . 76 4.6. PIM Assert Messages. . . . . . . . . . . . . . . . . 76
4.6.1. (S,G) Assert Message State Machine. . . . . . . . 76 4.6.1. (S,G) Assert Message State Machine. . . . . . . . 76
4.6.2. (*,G) Assert Message State Machine. . . . . . . . 84 4.6.2. (*,G) Assert Message State Machine. . . . . . . . 84
4.6.3. Assert Metrics. . . . . . . . . . . . . . . . . . 91 4.6.3. Assert Metrics. . . . . . . . . . . . . . . . . . 91
4.6.4. AssertCancel Messages . . . . . . . . . . . . . . 92 4.6.4. AssertCancel Messages . . . . . . . . . . . . . . 92
4.6.5. Assert State Macros . . . . . . . . . . . . . . . 93 4.6.5. Assert State Macros . . . . . . . . . . . . . . . 93
4.7. PIM Multicast Border Router Behavior . . . . . . . . 96 4.7. PIM Multicast Border Router Behavior . . . . . . . . 96
4.7.1. Sources External to the PIM-SM Domain . . . . . . 96 4.7.1. Sources External to the PIM-SM Domain . . . . . . 96
4.7.2. Sources Internal to the PIM-SM Domain . . . . . . 97 4.7.2. Sources Internal to the PIM-SM Domain . . . . . . 97
4.8. PIM Bootstrap and RP Discovery . . . . . . . . . . . 98 4.8. PIM Bootstrap and RP Discovery . . . . . . . . . . . 98
skipping to change at page 4, line 43 skipping to change at page 4, line 43
6.3.2.2. Register Stop messages . . . . . . . . . . . . 132 6.3.2.2. Register Stop messages . . . . . . . . . . . . 132
6.4. Denial of Service Attacks. . . . . . . . . . . . . . 133 6.4. Denial of Service Attacks. . . . . . . . . . . . . . 133
7. Authors' Addresses. . . . . . . . . . . . . . . . . . . 133 7. Authors' Addresses. . . . . . . . . . . . . . . . . . . 133
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 134 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 134
9. References. . . . . . . . . . . . . . . . . . . . . . . 134 9. References. . . . . . . . . . . . . . . . . . . . . . . 134
10. Index. . . . . . . . . . . . . . . . . . . . . . . . . 136 10. Index. . . . . . . . . . . . . . . . . . . . . . . . . 136
List of Figures List of Figures
Figure 1. Per-(S,G) register state-machine at a DR . . . . 36 Figure 1. Per-(S,G) register state-machine at a DR . . . . 36
Figure 2. Downstream (*,*,RP) per-interface Figure 2. Downstream (*,*,RP) per-interface state-
state-machine. . . . . . . . . . . . . . . . . . . . . . . 42 machine. . . . . . . . . . . . . . . . . . . . . . . . . . 42
Figure 3. Downstream (*,G) per-interface Figure 3. Downstream (*,G) per-interface state-
state-machine. . . . . . . . . . . . . . . . . . . . . . . 46 machine. . . . . . . . . . . . . . . . . . . . . . . . . . 46
Figure 4. Downstream per-interface (S,G) Figure 4. Downstream per-interface (S,G) state-
state-machine. . . . . . . . . . . . . . . . . . . . . . . 50 machine. . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figure 5. Downstream per-interface (S,G,rpt) Figure 5. Downstream per-interface (S,G,rpt) state-
state-machine. . . . . . . . . . . . . . . . . . . . . . . 53 machine. . . . . . . . . . . . . . . . . . . . . . . . . . 53
Figure 6. Upstream (*,*,RP) state-machine. . . . . . . . . 58 Figure 6. Upstream (*,*,RP) state-machine. . . . . . . . . 58
Figure 7. Upstream (*,G) state-machine . . . . . . . . . . 62 Figure 7. Upstream (*,G) state-machine . . . . . . . . . . 62
Figure 8. Upstream (S,G) state-machine . . . . . . . . . . 67 Figure 8. Upstream (S,G) state-machine . . . . . . . . . . 67
Figure 9. Upstream (S,G,rpt) state-machine for trig- Figure 9. Upstream (S,G,rpt) state-machine for trig-
gered messages . . . . . . . . . . . . . . . . . . . . . . 72 gered messages . . . . . . . . . . . . . . . . . . . . . . 72
Figure 10. Per-interface (S,G) Assert Figure 10. Per-interface (S,G) Assert
State-machine. . . . . . . . . . . . . . . . . . . . . . . 78 State-machine. . . . . . . . . . . . . . . . . . . . . . . 78
Figure 11. (*,G) Assert State-machine. . . . . . . . . . . 85 Figure 11. (*,G) Assert State-machine. . . . . . . . . . . 85
1. Introduction 1. Introduction
skipping to change at page 87, line 8 skipping to change at page 87, line 8
(*,G,I) -> better than (RP(G)) stops Join(*,G) or (*,G,I) -> better than (RP(G)) stops Join(*,G) or
FALSE Winner's being I Join(*,*,RP(G)) FALSE Winner's being I Join(*,*,RP(G))
metric on Interface I metric on Interface I
------------------------------------------------------------------------- -------------------------------------------------------------------------
-> NI state -> NI state -> NI state -> NI State -> NI state -> NI state -> NI state -> NI State
[Actions A5] [Actions A5] [Actions A5] [Actions A5] [Actions A5] [Actions A5] [Actions A5] [Actions A5]
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
INTERNET-DRAFT | Expires: June 2003 | December 2002| INTERNET-DRAFT | Expires: September 2003 | March 2003|
| | | | | | | | | |
| | | | | | | | | |
+---------------+-----------------+-----------------+-------------------+ +---------------+-----------------+-----------------+-------------------+
The state machine uses the following macros: The state machine uses the following macros:
CouldAssert(*,G,I) = CouldAssert(*,G,I) =
( I in ( joins(*,*,RP(G)) (+) joins(*,G) ( I in ( joins(*,*,RP(G)) (+) joins(*,G)
(+) pim_include(*,G)) ) (+) pim_include(*,G)) )
AND RPF_interface(RP(G)) != I AND RPF_interface(RP(G)) != I
skipping to change at page 96, line 28 skipping to change at page 96, line 28
Rationale: This allows switching back to the RPT after the last SPT Rationale: This allows switching back to the RPT after the last SPT
member leaves. member leaves.
4.7. PIM Multicast Border Router Behavior 4.7. PIM Multicast Border Router Behavior
In some cases PIM-SM domains will interconnect with non-PIM domains. In In some cases PIM-SM domains will interconnect with non-PIM domains. In
these cases, the border routers of the PIM domain speak PIM-SM on some these cases, the border routers of the PIM domain speak PIM-SM on some
interfaces and speak other multicast routing protocols on other interfaces and speak other multicast routing protocols on other
interfaces. Such routers are termed PIM Multicast Border Routers or interfaces. Such routers are termed PIM Multicast Border Routers or
PMBRs. In general, RFC 2715 [13] provides rules for interoperability PMBRs. In general, RFC 2715 [14] provides rules for interoperability
between different multicast routing protocols. In this section we between different multicast routing protocols. In this section we
specify how PMBRs differ from regular PIM-SM routers. specify how PMBRs differ from regular PIM-SM routers.
>From the point of view of PIM-SM, a PMBR has two tasks: >From the point of view of PIM-SM, a PMBR has two tasks:
o To ensure that traffic from sources outside the PIM-SM domain reaches o To ensure that traffic from sources outside the PIM-SM domain reaches
receivers inside the domain. receivers inside the domain.
o To ensure that traffic from sources inside the PIM-SM domain reaches o To ensure that traffic from sources inside the PIM-SM domain reaches
receives outside the domain. receivers outside the domain.
We note that multiple PIM-SM domains are sometimes connected together We note that multiple PIM-SM domains are sometimes connected together
using protocols such as MSDP, which provides information about active using protocols such as MSDP, which provides information about active
external sources, but does not follow RFC 2715. In such cases the external sources, but does not follow RFC 2715. In such cases the
domains are not connected via PMBRs because Join(S,G) messages traverse domains are not connected via PMBRs because Join(S,G) messages traverse
the border between domains. A PMBR is required when no PIM messages can the border between domains. A PMBR is required when no PIM messages can
traverse the border; typically this is because the routing protocol in traverse the border; typically this is because the routing protocol in
the neighboring domain is not PIM-SM. the neighboring domain is not PIM-SM.
4.7.1. Sources External to the PIM-SM Domain 4.7.1. Sources External to the PIM-SM Domain
skipping to change at page 105, line 37 skipping to change at page 105, line 37
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Unicast Address | Addr Family | Encoding Type | Unicast Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Addr Family Addr Family
The PIM address family of the `Unicast Address' field of this The PIM address family of the `Unicast Address' field of this
address. address.
Values of 0-127 are as assigned by the IANA for Internet Address Values of 0-127 are as assigned by the IANA for Internet Address
Families in [8]. Values 128-250 are reserved to be assigned by the Families in [11]. Values 128-250 are reserved to be assigned by the
IANA for PIM-specific Address Families. Values 251 though 255 are IANA for PIM-specific Address Families. Values 251 though 255 are
designated for private use. As there is no assignment authority designated for private use. As there is no assignment authority
for this space, collisions should be expected. for this space, collisions should be expected.
Encoding Type Encoding Type
The type of encoding used within a specific Address Family. The The type of encoding used within a specific Address Family. The
value `0' is reserved for this field, and represents the native value `0' is reserved for this field, and represents the native
encoding of the Address Family. encoding of the Address Family.
Unicast Address Unicast Address
skipping to change at page 106, line 25 skipping to change at page 106, line 25
| Group multicast Address | Group multicast Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Addr Family Addr Family
described above. described above.
Encoding Type Encoding Type
described above. described above.
[B]idirectional PIM [B]idirectional PIM
indicates the group range should use Bidirectional PIM [9]. For indicates the group range should use Bidirectional PIM [8]. For
PIM-SM defined in this specification, this bit MUST be zero. PIM-SM defined in this specification, this bit MUST be zero.
Reserved Reserved
Transmitted as zero. Ignored upon receipt. Transmitted as zero. Ignored upon receipt.
Admin Scope [Z]one Admin Scope [Z]one
indicates the group range is an admin scope zone. This is used in indicates the group range is an admin scope zone. This is used in
the Bootstrap Router Mechanism [7] only. For all other purposes, the Bootstrap Router Mechanism [7] only. For all other purposes,
this bit is set to zero and ignored on receipt. this bit is set to zero and ignored on receipt.
skipping to change at page 110, line 36 skipping to change at page 110, line 36
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Generation ID | | Generation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Generation ID is a random 32-bit value for the interface on which Generation ID is a random 32-bit value for the interface on which
the Hello message is sent. The Generation ID is regenerated the Hello message is sent. The Generation ID is regenerated
whenever PIM forwarding is started or restarted on the interface. whenever PIM forwarding is started or restarted on the interface.
OptionTypes 17 thru 65000 are assigned by the IANA. OptionTypes OptionTypes 17 thru 65000 are assigned by the IANA. OptionTypes
65001 through 65535 are reserved for Private Use, as defined in 65001 through 65535 are reserved for Private Use, as defined in
[12]. [13].
Unknown options may be ignored. The "Holdtime" option MUST be Unknown options may be ignored. The "Holdtime" option MUST be
implemented; the "DR Priority" and "Generation ID" options SHOULD implemented; the "DR Priority" and "Generation ID" options SHOULD
be implemented. be implemented.
4.10.3. Register Message Format 4.10.3. Register Message Format
A Register message is sent by the DR or a PMBR to the RP when a A Register message is sent by the DR or a PMBR to the RP when a
multicast packet needs to be transmitted on the RP-tree. The IP source multicast packet needs to be transmitted on the RP-tree. The IP source
address is set to the address of the DR, the destination address to the address is set to the address of the DR, the destination address to the
RP's address. The IP TTL of the PIM packet is the system's normal RP's address. The IP TTL of the PIM packet is the system's normal
skipping to change at page 115, line 41 skipping to change at page 115, line 41
The wildcard group set is represented by the entire multicast range The wildcard group set is represented by the entire multicast range
- the beginning of the multicast address range in the group address - the beginning of the multicast address range in the group address
field and the prefix length of the multicast address range in the field and the prefix length of the multicast address range in the
mask length field of the Multicast Group Address, e.g. 224.0.0.0/4 mask length field of the Multicast Group Address, e.g. 224.0.0.0/4
for IPv4 or ff00::/8 for IPv6. Each wildcard group set may contain for IPv4 or ff00::/8 for IPv6. Each wildcard group set may contain
one or more (*,*,RP) source list entries in either the Join or one or more (*,*,RP) source list entries in either the Join or
Prune lists. Prune lists.
A (*,*,RP) source list entry may only exist in a wildcard group A (*,*,RP) source list entry may only exist in a wildcard group
set. When added to a Join source list, this type of source entry set. When added to a Join source list, this type of source entry
expresses the routers interest in receiving traffic for all groups expresses the router's interest in receiving traffic for all groups
mapping to the specified RP. When added to a Prune source list a mapping to the specified RP. When added to a Prune source list a
(*,*,RP) entry expresses the routers interest to stop receiving (*,*,RP) entry expresses the router's interest to stop receiving
such traffic. Note that as indicated by the Join/Prune state such traffic. Note that as indicated by the Join/Prune state
machines, such a Join or Prune will NOT override Join/Prune state machines, such a Join or Prune will NOT override Join/Prune state
created using a Group-Specific Set (see below). created using a Group-Specific Set (see below).
(*,*,RP) source list entries have the Source-Address set to the (*,*,RP) source list entries have the Source-Address set to the
address of the RP, the Source-Address Mask-Len set to the full address of the RP, the Source-Address Mask-Len set to the full
length of the IP address and both the WC and RPT bits of the length of the IP address and both the WC and RPT bits of the
Source-Address set to 1. Source-Address set to 1.
Group Specific Set Group Specific Set
skipping to change at page 119, line 22 skipping to change at page 119, line 22
convey to the neighbor as possible. This implies adding one group set convey to the neighbor as possible. This implies adding one group set
for each multicast group that has information pending transmission and for each multicast group that has information pending transmission and
within each set including all relevant source list entries. within each set including all relevant source list entries.
On a router with a large amount of multicast state the number of entries On a router with a large amount of multicast state the number of entries
that must be included may result in packets that are larger in the that must be included may result in packets that are larger in the
maximum IP packet size. In most such cases the information may be split maximum IP packet size. In most such cases the information may be split
into multiple messages. into multiple messages.
There is an exception with group sets that contain a (*,G) Join source There is an exception with group sets that contain a (*,G) Join source
list entry. The group set expresses the routers interest in receiving list entry. The group set expresses the router's interest in receiving
all traffic for the specified group on the shared tree and it MUST all traffic for the specified group on the shared tree and it MUST
include an (S,G,rpt) Prune source list entry for every source that the include an (S,G,rpt) Prune source list entry for every source that the
router does not wish to receive. This list of (S,G,rpt) Prune source- router does not wish to receive. This list of (S,G,rpt) Prune source-
list entries MUST not be split in multiple messages. list entries MUST not be split in multiple messages.
If only N (S,G,rpt) Prune entries fit into a maximum-sized Join / Prune If only N (S,G,rpt) Prune entries fit into a maximum-sized Join / Prune
message, but the router has more than N (S,G,rpt) Prunes to add, then message, but the router has more than N (S,G,rpt) Prunes to add, then
the router MUST choose to include the first N (numerically smallest in the router MUST choose to include the first N (numerically smallest in
network byte order) IP addresses. network byte order) IP addresses.
skipping to change at page 128, line 42 skipping to change at page 128, line 42
The PIM Address Family field was chosen to be 8 bits as a tradeoff The PIM Address Family field was chosen to be 8 bits as a tradeoff
between between
packet format and use of the IANA assigned numbers. Since when the PIM packet format and use of the IANA assigned numbers. Since when the PIM
packet format was designed only 15 values were assigned for Address packet format was designed only 15 values were assigned for Address
Families, and large numbers of new Address Family values were not Families, and large numbers of new Address Family values were not
envisioned, 8 bits seemed large enough. However, the IANA assigns envisioned, 8 bits seemed large enough. However, the IANA assigns
Address Families in a 16-bit field. Therefore, the PIM Address Family Address Families in a 16-bit field. Therefore, the PIM Address Family
is allocated as follows: is allocated as follows:
Values 0 through 127 are designated to have the same meaning as Values 0 through 127 are designated to have the same meaning as
IANA-assigned Address Family Numbers [8]. IANA-assigned Address Family Numbers [11].
Values 128 through 250 are designated to be assigned by the IANA Values 128 through 250 are designated to be assigned by the IANA
based upon IESG Approval, as defined in [12]. based upon IESG Approval, as defined in [13].
Values 251 through 255 are designated for Private Use, as defined Values 251 through 255 are designated for Private Use, as defined
in [12]. in [13].
5.2. PIM Hello Options 5.2. PIM Hello Options
Values 17 through 65000 are to be assigned by the IANA. Since the space 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 defined in is large, they may be assigned as First Come First Served as defined in
[12]. Such assignments are valid for one year, and may be renewed. [13]. Such assignments are valid for one year, and may be renewed.
Permanent assignments require a specification (see "Specification Permanent assignments require a specification (see "Specification
Required" in [12].) Required" in [13].)
6. Security Considerations 6. Security Considerations
The IPsec authentication header [11] MAY be used to provide data The IPsec authentication header [12] MAY be used to provide data
integrity protection and groupwise data origin authentication of PIM integrity protection and groupwise data origin authentication of PIM
protocol messages. Authentication of PIM messages can protect against protocol messages. Authentication of PIM messages can protect against
unwanted behaviors caused by unauthorized or altered PIM messages. unwanted behaviors caused by unauthorized or altered PIM messages.
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 forgeries, messages accepted. We next consider the impact of possible forgeries,
including forged link-local (Join/Prune, Hello, and Assert) and forged including forged link-local (Join/Prune, Hello, and Assert) and forged
unicast (Register and RegisterStop) messages. unicast (Register and RegisterStop) messages.
skipping to change at page 130, line 12 skipping to change at page 130, line 12
receive multicast traffic may be compromised by a forged Hello receive multicast traffic may be compromised by a forged Hello
message. message.
3. By forging an Assert message on a multi-access LAN, an attacker 3. By forging an Assert message on a multi-access LAN, an attacker
could cause the legitimate designated forwarder to stop forwarding could cause the legitimate designated forwarder to stop forwarding
traffic to the LAN. Such a forgery would prevent any hosts traffic to the LAN. Such a forgery would prevent any hosts
downstream of that LAN from receiving traffic. downstream of that LAN from receiving traffic.
6.1.2. Forged unicast messages 6.1.2. Forged unicast messages
Register messages and RegisterStop messages are sent by a source and Register messages and RegisterStop messages are forwarded by
forwarded by intermediate routers to their destination using normal IP intermediate routers to their destination using normal IP forwarding.
forwarding. Therefore, without data origin authentication, an attacker Without data origin authentication, an attacker who is located anywhere
who is located anywhere in the network may be able to forge a Register in the network may be able to forge a Register or RegisterStop message.
or RegisterStop message. The following attacks do not apply to a PIM-
SSM-only implementation, as these messages are not required for PIM-SSM.
We consider the effect of a forgery of each of these messages next. We consider the effect of a forgery of each of these messages next.
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 prevent legitimate DR from Registering packets to the RP. This can prevent
local hosts on that LAN from sending multicast packets. local hosts on that LAN from sending multicast packets.
The above two PIM messages are not changed by intermediate routers and The above two PIM messages are not changed by intermediate routers and
need only be examined by the intended receiver. Thus these messages can need only be examined by the intended receiver. Thus these messages can
be authenticated end-to-end, using AH. be authenticated end-to-end, using AH. Attacks on Register and
RegisterStop messages do not apply to a PIM-SSM-only implementation, 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 from A PIM router SHOULD provide an option to limit the set of neighbors from
which it will accept Join/Prune, Assert, and Hello messages. Either which it will accept Join/Prune, Assert, and Hello messages. Either
static configuration of IP addresses or an IPsec security association static configuration of IP addresses or an IPsec security association
may be used. Furthermore, a PIM router SHOULD NOT accept protocol may be used. Furthermore, a PIM router SHOULD NOT accept protocol
messages from a router from which it has not yet received a valid Hello messages from a router from which it has not yet received a valid Hello
message. message.
skipping to change at page 131, line 7 skipping to change at page 131, line 7
An implementation SHOULD provide a mechanism to allow an RP to restrict An implementation SHOULD provide a mechanism to allow an RP to restrict
the range of source addresses from which it accepts Register- the range of source addresses from which it accepts Register-
encapsulated packets. encapsulated packets.
All options that restrict the range of addresses from which packets are All options that restrict the range of addresses from which packets are
accepted MUST default to allowing all packets. accepted MUST default to allowing all packets.
6.3. Authentication using IPsec 6.3. Authentication using IPsec
The IPsec [11] transport mode using the Authentication Header (AH) is The IPsec [12] transport mode using the Authentication Header (AH) is
the recommended method to prevent the above attacks PIM. The anti- the recommended method to prevent the above attacks against PIM. The
replay option provided by IPsec SHOULD also be enabled. The specific AH specific AH authentication algorithm and parameters, including the
authentication algorithm and parameters, including the choice of choice of authentication algorithm and the choice of key, are configured
authentication algorithm and the choice of key, are configured by the by the network administrator. When IPsec authentication is used, a PIM
network administrator. The Encapsulating Security Payload (ESP) MAY router should reject (drop without processing) any unauthorized PIM
also be used to provide both encryption and authentication of PIM protocol messages.
protocol messages. When IPsec authentication is used, a PIM router
should reject (drop without processing) any unauthorized PIM protocol As of this writing, the IPsec anti-replay option does not handle the
messages. case of a Security Association identified by a multicast destination
address. Thus, the anti-replay option currently must be disabled on
these Security Associations. The anti-replay option SHOULD be enabled
on all security associations having a unicast destination address.
To use IPsec, the administrator of a PIM network configures each PIM To use IPsec, the administrator of a PIM network configures each PIM
router with one or more Security Associations and associated SPI(s) that router with one or more Security Associations and associated SPI(s) that
are used by senders to sign PIM protocol messages and are used by are used by senders to sign PIM protocol messages and are used by
receivers to authenticate received PIM protocol messages. This document receivers to authenticate received PIM protocol messages. This document
does not describe protocols for establishing Security Associations. It does not describe protocols for establishing Security Associations. It
assumes that manual configuration of Security Associations is performed, assumes that manual configuration of Security Associations is performed,
but it does not preclude the use of some future negotiation protocol to but it does not preclude the use of a negotiation protocol such as The
establish Security Associations. Internet Key Exchange [9] to establish Security Associations.
The following sections describe the Security Associations required to The following sections describe the Security Associations required to
protect PIM protocol messages. protect PIM protocol messages.
6.3.1. Protecting link-local multicast messages 6.3.1. Protecting link-local multicast messages
The network administrator defines a Security Association (SA) and The network administrator defines a Security Association (SA) and
Security Parameters Index (SPI) that is to be used to authenticate all Security Parameters Index (SPI) that is to be used to authenticate all
link-local PIM protocol messages (Hello, Join/Prune, and Assert) on each link-local PIM protocol messages (Hello, Join/Prune, and Assert) on each
link in a PIM domain. All link-local PIM protocol messages use SPI 0. link in a PIM domain. All link-local PIM protocol messages use SPI 0.
The Security Policy Database at a PIM router should be configured to The Security Policy Database at a PIM router should be configured to
ensure that all incoming and outgoing Join/Prune, Assert, and Hello ensure that all incoming and outgoing Join/Prune, Assert, and Hello
packets use the SA associated with the interface to which the packet is packets use the SA associated with the interface to which the packet is
sent. sent.
Note that, according to [11] there is nominally a different Security Note that, according to [12] there is nominally a different Security
Association Database (SAD) for each router interface. Thus, the Association Database (SAD) for each router interface. Thus, the
selected Security Association for an inbound PIM packet can vary selected Security Association for an inbound PIM packet can vary
depending on the interface on which the packet arrived. This fact depending on the interface on which the packet arrived. This fact
allows the network administrator to use different authentication methods allows the network administrator to use different authentication methods
for each link, even though the destination address is the same for all for each link, even though the destination address is the same for all
link-local PIM packets, regardless of interface. link-local PIM packets, regardless of interface.
6.3.2. Protecting unicast messages 6.3.2. Protecting unicast messages
IPSec can also be used to provide data origin authentication and data IPSec can also be used to provide data origin authentication and data
skipping to change at page 132, line 48 skipping to change at page 132, line 48
updated. updated.
6.3.2.2. Register Stop messages 6.3.2.2. Register Stop messages
Similarly, the Security Policy Database at each Rendezvous Point should Similarly, the Security Policy Database at each Rendezvous Point should
be configured to choose a Security Association to use when sending be configured to choose a Security Association to use when sending
Register Stop messages. Because Register Stop messages are unicast to Register Stop messages. Because Register Stop messages are unicast to
the destination DR, a different Security Association and a potentially the destination DR, a different Security Association and a potentially
unique SPI is required for each DR. unique SPI is required for each DR.
[XXX Can we reserve a single SPI at all routers in the domain to
simplify the configuration problem?]
In order to simplify the management problem, it may be acceptable to use In order to simplify the management problem, it may be acceptable to use
the same authentication algorithm and authentication parameters, the same authentication algorithm and authentication parameters,
regardless of the sending RP and regardless of the destination DR. regardless of the sending RP and regardless of the destination DR.
Although a unique Security Association is needed for each DR, the same Although a unique Security Association is needed for each DR, the same
authentication algorithm and authentication algorithm parameters (secret authentication algorithm and authentication algorithm parameters (secret
key) can be shared by all DRs and by all RPs. key) can be shared by all DRs and by all RPs.
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 by that can be caused by generating false PIM protocol messages or even by
generating data false traffic. Authenticating PIM protocol traffic generating data false traffic. Authenticating PIM protocol traffic
prevents some, but not all of these attacks. The possible attacks prevents some, but not all of these attacks. Two of the possible
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
denial of service attack in and of itself. This will cause many denial of service attack in and of itself. This will cause many
register-encapsulated packets, loading the DR, the RP, and the register-encapsulated packets, loading the DR, the RP, and the
routers between the DR and the RP. routers between the DR and the RP.
- Forging Join messages can cause a multicast tree to get set up. A - Forging Join messages can cause a multicast tree to get set up. A
large number of forged joins can consume router resources and large number of forged joins can consume router resources and
result in denial of service. result in denial of service.
- [XXX Many others]
7. Authors' Addresses 7. Authors' Addresses
Bill Fenner Bill Fenner
AT&T Labs - Research AT&T Labs - Research
75 Willow Road 75 Willow Road
Menlo Park, CA 94025 Menlo Park, CA 94025
fenner@research.att.com fenner@research.att.com
Mark Handley Mark Handley
ICIR/ICSI ICIR/ICSI
skipping to change at page 134, line 39 skipping to change at page 134, line 39
[3] S.E. Deering, "Host extensions for IP multicasting", RFC 1112, Aug [3] S.E. Deering, "Host extensions for IP multicasting", RFC 1112, Aug
1989. 1989.
[4] S. Deering, W. Fenner, B. Haberman, "Multicast Listener Discovery [4] S. Deering, W. Fenner, B. Haberman, "Multicast Listener Discovery
(MLD) for IPv6", RFC 2710. (MLD) for IPv6", RFC 2710.
[5] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) [5] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460. Specification", RFC 2460.
[6] W. Fenner, "Internet Group Management Protocol, Version 2", RFC [6] B. Cain, S. Deering, I. Kouvelas, B. Fenner, A. Thyagarajan,
2236. "Internet Group Management Protocol, Version 3", RFC 3376.
[7] W. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Bootstrap Router [7] W. Fenner, M. Handley, R. Kermode, D. Thaler, "Bootstrap Router
(BSR) Mechanism for PIM Sparse Mode", draft-ietf-pim-sm-bsr-02.txt, (BSR) Mechanism for PIM Sparse Mode", draft-ietf-pim-sm-bsr-03.txt,
work in progress. work in progress.
[8] IANA, "Address Family Numbers", linked from [8] M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, "Bi-directional
http://www.iana.org/numbers.html Protocol Independent Multicast", draft-ietf-pim-bidir-04.txt, work
[9] M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, "Bi-directional
Protocol Independent Multicast", draft-ietf-pim-bidir-02.txt, work
in progress. in progress.
[9] D. Harkins , D. Carrell, "The Internet Key Exchange (IKE)", RFC
2409.
[10] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", draft- [10] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", draft-
holbrook-ssm-00.txt, work in progress. holbrook-ssm-00.txt, work in progress.
[11] S. Kent, R. Atkinson, "Security Architecture for the Internet [11] IANA, "Address Family Numbers", linked from
http://www.iana.org/numbers.html
[12] S. Kent, R. Atkinson, "Security Architecture for the Internet
Protocol.", RFC 2401. Protocol.", RFC 2401.
[12] T. Narten , H. Alvestrand, "Guidelines for Writing an IANA [13] T. Narten , H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434. [13] D. Thaler, Considerations Section in RFCs", RFC 2434.
"Interoperability Rules for Multicast Routing Protocols", RFC 2715.
[14] D. Thaler, "Interoperability Rules for Multicast Routing
Protocols", RFC 2715.
10. Index 10. Index
Assert(*,G). . . . . . . . . . . . . . . . . . . . . . . . . . . .26,121 Assert(*,G). . . . . . . . . . . . . . . . . . . . . . . . . . . .26,121
Assert(S,G). . . . . . . . . . . . . . . . . . . . . . . . . . . .26,121 Assert(S,G). . . . . . . . . . . . . . . . . . . . . . . . . . . .26,121
AssertCancel(*,G). . . . . . . . . . . . . . . . . . . . . . . . . 90,92 AssertCancel(*,G). . . . . . . . . . . . . . . . . . . . . . . . . 90,92
AssertCancel(S,G). . . . . . . . . . . . . . . . . . . . . . . .75,84,92 AssertCancel(S,G). . . . . . . . . . . . . . . . . . . . . . . .75,84,92
AssertTimer(*,G,I) . . . . . . . . . . . . . . . . . . . . .16,24,84,125 AssertTimer(*,G,I) . . . . . . . . . . . . . . . . . . . . .16,24,84,125
AssertTimer(S,G,I) . . . . . . . . . . . . . . . . . . . . .18,24,77,125 AssertTimer(S,G,I) . . . . . . . . . . . . . . . . . . . . .18,24,77,125
AssertTrackingDesired(*,G,I) . . . . . . . . . . . . . . . . . .87,88,90 AssertTrackingDesired(*,G,I) . . . . . . . . . . . . . . . . . .87,88,90
AssertTrackingDesired(S,G,I) . . . . . . . . . . . . . . . . 79,79,81,83 AssertTrackingDesired(S,G,I) . . . . . . . . . . . . . . . . 79,79,81,83
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/