draft-ietf-pim-sm-linklocal-00.txt   draft-ietf-pim-sm-linklocal-01.txt 
PIM Working Group W. Atwood PIM Working Group W. Atwood
Internet-Draft S. Islam Internet-Draft S. Islam
Updates: 4601 (if approved) Concordia University/CSE Updates: 4601 (if approved) Concordia University/CSE
Intended status: Standards Track October 15, 2006 Intended status: Standards Track July 08, 2007
Expires: April 18, 2007 Expires: January 9, 2008
Security Issues in PIM-SM Link-local Messages Security Issues in PIM-SM Link-local Messages
draft-ietf-pim-sm-linklocal-00 draft-ietf-pim-sm-linklocal-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 18, 2007. This Internet-Draft will expire on January 9, 2008.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document outlines the security issues for the link-local RFC 4601 mandates the use of IPsec to ensure authentication of the
messages in the Protocol Independent Multicast - Sparse Mode (PIM-SM) link-local messages in the Protocol Independent Multicast - Sparse
routing protocol. It provides mechanisms to authenticate the PIM-SM Mode (PIM-SM) routing protocol. This document specifies mechanisms
link local messages using the IP security (IPsec) Authentication to authenticate the PIM-SM link local messages using the IP security
Header (AH). (IPsec) Authentication Header (AH) or Encapsulating Security Payload
(ESP). It specifies optional mechanisms to provide confidentiality
using the ESP. Manual keying is specified as the mandatory and
default group key management solution. To deal with issues of
scalability and security that exist with manual keying, an optional
automated group key management mechanism is specified.
1. Introduction 1. Introduction
All the PIM-SM [1] control messages have IP protocol number 103. All the PIM-SM [1] control messages have IP protocol number 103.
These messages are either unicast, or multicast with TTL = 1. The These messages are either unicast, or multicast with TTL = 1. The
source address used for unicast messages is a domain-wide reachable source address used for unicast messages is a domain-wide reachable
address. For the multicast messages, a link-local address of the address. For the multicast messages, a link-local address of the
interface on which the message is being sent is used as the source interface on which the message is being sent is used as the source
address and a special multicast address, ALL_PIM_ROUTERS (224.0.0.13 address and a special multicast address, ALL_PIM_ROUTERS (224.0.0.13
in IPv4 and ff02::d in IPv6) is used as the destination address. in IPv4 and ff02::d in IPv6) is used as the destination address.
skipping to change at page 3, line 30 skipping to change at page 3, line 30
whereas some are minor. whereas some are minor.
PIM-SM version 2 was originally specified in RFC 2117, and revised in PIM-SM version 2 was originally specified in RFC 2117, and revised in
RFC 2362 and RFC 4601. RFC 4601 obsoletes RFC 2362, and corrects a RFC 2362 and RFC 4601. RFC 4601 obsoletes RFC 2362, and corrects a
number of deficiencies. The Security Considerations section of RFC number of deficiencies. The Security Considerations section of RFC
4601 is based primarily on the new Authentication Header (AH) 4601 is based primarily on the new Authentication Header (AH)
specification described in RFC 4302 [2]. specification described in RFC 4302 [2].
Securing the unicast messages can be achieved by the use of a normal Securing the unicast messages can be achieved by the use of a normal
unicast IPsec Security Association between the two communicants. unicast IPsec Security Association between the two communicants.
Securing the user data exchanges is covered in RFC 3740 [5]. This Securing the user data exchanges is covered in RFC 3740 [6]. This
document focuses on the security issues for link-local messages. It document focuses on the security issues for link-local messages. It
provides some guidelines to take advantage of the new permitted AH provides some guidelines to take advantage of the new permitted AH
functionality in RFC 4302, and to bring the PIM-SM specification into functionality in RFC 4302, and to bring the PIM-SM specification into
alignment with the new AH specification. This document recommends alignment with the new AH specification. This document recommends
manual key management as mandatory to implement, i.e., that all manual key management as mandatory to implement, i.e., that all
implementations MUST support, and discusses the need to develop a implementations MUST support, and begins the discussion of an
simple light-weight automated key management protocol that the PIM automated key management protocol that the PIM routers can use.
routers can use.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and
indicate requirement levels for compliant PIM-SM implementations. indicate requirement levels for compliant PIM-SM implementations.
3. Transport Mode vs. Tunnel Mode 3. Transport Mode vs. Tunnel Mode
skipping to change at page 6, line 8 skipping to change at page 6, line 8
between routers. However, since the packets are locally delivered, between routers. However, since the packets are locally delivered,
the routers assume the role of hosts in the context of the tunnel the routers assume the role of hosts in the context of the tunnel
mode SA. All implementations conforming to this specification MUST mode SA. All implementations conforming to this specification MUST
support transport mode SA to provide required IPsec security to support transport mode SA to provide required IPsec security to
PIM-SM link-local messages. They MAY also support tunnel mode SA to PIM-SM link-local messages. They MAY also support tunnel mode SA to
provide required IPsec security to PIM-SM link-local messages. provide required IPsec security to PIM-SM link-local messages.
4. Authentication 4. Authentication
Implementations conforming to this specification MUST support Implementations conforming to this specification MUST support
authentication for PIM-SM link-local messages. In order to provide authentication for PIM-SM link-local messages.
authentication to PIM-SM link-local messages, implementations MUST
support AH in transport mode. In order to provide authentication to PIM-SM link-local messages,
implementations MUST support ESP [5] and MAY support AH [2].
If ESP in transport mode is used, it will only provide authentication
to PIM-SM protocol packets excluding the IPv6 header, extension
headers, and options. (Note: The IPv4 exclusions need to be listed
here as well.)
If AH in transport mode is used, it will provide authentication to
PIM-SM protocol packets, selected portions of the IPv6 header,
extension headers and options. (Note: the IPv4 coverage needs to be
listed here as well.)
When authentication for PIM-SM link-local messages is enabled, When authentication for PIM-SM link-local messages is enabled,
o PIM-SM link-local packets that are not protected with AH MUST be o PIM-SM link-local packets that are not protected with AH or ESP
silently discarded. MUST be silently discarded.
o PIM-SM link-local packets that fail the authentication checks MUST o PIM-SM link-local packets that fail the authentication checks MUST
be silently discarded. be silently discarded.
5. IPsec Requirements 5. Confidentiality
Implementations conforming to this specification SHOULD support
confidentiality for PIM-SM.
If confidentiality is provided, ESP MUST be used.
When PIM-SM confidentiality is enabled,
o PIM-SM packets that are not protected with ESP MUST be silently
discarded.
o PIM-SM packets that fail the confidentiality checks MUST be
silently discarded.
6. IPsec Requirements
In order to implement this specification, the following IPsec In order to implement this specification, the following IPsec
capabilities are required. capabilities are required.
Transport mode Transport mode
IPsec in transport mode MUST be supported. IPsec in transport mode MUST be supported.
Multiple Security Policy Databases (SPDs)
The implementation MUST support multiple SPDs with an SPD
selection function that provides an ability to choose a specific
SPD based on interface.
Selectors Selectors
The implementation MUST be able to use source address and SPI as The implementation MUST be able to use source address, destination
selectors in the SPD. address, protocol, and direction as selectors in the SPD.
Manual key management Interface ID tagging
The implementation MUST be able to tag the inbound packets with
the ID of the interface (physical or virtual) via which it
arrived.
Manual key support
Manually configured keys MUST be able to secure the specified Manually configured keys MUST be able to secure the specified
traffic. traffic.
6. Key Management Encryption and authentication algorithms
The implementation MUST NOT allow the user to choose stream
ciphers as the encryption algorithm for securing PIM-SM packets
since the stream ciphers are not suitable for manual keys. Except
when in conflict with the above statement, the key words "MUST",
"MUST NOT", "REQUIRED", "SHOULD", and "SHOULD NOT" that appear in
RFC 4305 [7] for algorithms to be supported are to be interpreted
as described in RFC 2119 [3] for PIM-SM support as well.
Encapsulation of ESP packet
IP encapsulation of ESP packets MUST be supported. For
simplicity, UDP encapsulation of ESP packets SHOULD NOT be used.
7. Key Management
All the implementations MUST support manual configuration of the SAs All the implementations MUST support manual configuration of the SAs
that will be used to authenticate PIM-SM link-local messages. This that will be used to authenticate PIM-SM link-local messages. This
does not preclude the use of a negotiation protocol such as the does not preclude the use of a negotiation protocol such as the
Internet Key Exchange (IKE) [9] or Group Secure Association Key Internet Key Exchange (IKE) [11] or Group Secure Association Key
Management Protocol (GSAKMP) [10]to establish SAs. Management Protocol (GSAKMP) [12] to establish SAs.
6.1. Manual Key Management 7.1. Manual Key Management
To establish the SAs at PIM-SM routers, manual key configuration will To establish the SAs at PIM-SM routers, manual key configuration will
be feasible when the number of peers (directly connected routers) is be feasible when the number of peers (directly connected routers) is
small. The Network Administrator will configure a router manually small. The Network Administrator will configure a router manually
during its boot up process. At that time, the authentication method during its boot up process. At that time, the authentication method
and the choice of keys SHOULD be configured. The SAD entry will be and the choice of keys SHOULD be configured. The SAD entry will be
created. The Network Administrator will also configure the Security created. The Network Administrator will also configure the Security
Policy Database of a router to ensure the use of the associated SA Policy Database of a router to ensure the use of the associated SA
while sending a link-local message. while sending a link-local message.
6.2. Automated Key Management 7.2. Automated Key Management
All the link-local messages of the PIM-SM protocol are sent to the All the link-local messages of the PIM-SM protocol are sent to the
destination address, ALL_PIM_ROUTERS, which is a multicast address. destination address, ALL_PIM_ROUTERS, which is a multicast address.
By using the sender address in conjunction with the destination By using the sender address in conjunction with the destination
address for Security Association lookup, link-local communication address for Security Association lookup, link-local communication
turns to an SSM or "one to many" communication. Since IKE is based turns to an SSM or "one to many" communication. Since IKE is based
on the Diffie-Hellman key agreement protocol and works only for two on the Diffie-Hellman key agreement protocol and works only for two
communicating parties, it is not possible to use IKE for providing communicating parties, it is not possible to use IKE for providing
the required "one to many" authentication. the required "one to many" authentication.
The other option is to use Group Domain Of Interpretation (GDOI) One option is to use Group Domain Of Interpretation (GDOI) [13],
[11], which enables a group of users or devices to exchange encrypted which enables a group of users or devices to exchange encrypted data
data using IPsec data encryption. GDOI has been developed to be used using IPsec data encryption. GDOI has been developed to be used in
in multicast applications, where the number of end users or devices multicast applications, where the number of end users or devices may
may be large and the end users or devices can dynamically join/leave be large and the end users or devices can dynamically join/leave a
a multicast group. However, a PIM router is not expected to join/ multicast group. However, a PIM router is not expected to join/leave
leave very frequently, and the number of routers is small when very frequently, and the number of routers is small when compared to
compared to the possible number of users of a multicast application. the possible number of users of a multicast application. Moreover,
Moreover, most of the PIM routers will be located inside the same most of the PIM routers will be located inside the same
administrative domain and are considered as trusted parties. administrative domain and are considered as trusted parties. It is
Probably, a GDOI-lite with a subset of GDOI functionalities should be possible that a subset of GDOI functionalities will be sufficient.
designed by the PIM working group.
7. Number of Security Associations 7.3. Communications Patterns
From the perspective of a speaking router, the information from that
router is sent to all of its neighbors. From the perspective of a
listening router, the information coming from each of its neighbors
is distinct from the information coming from every other router.
Thus an administrative region contains many distinct groups, all of
which happen to be using the same destination address
(ALL_PIM_ROUTERS, see Section 11), and each of which is centered on
the speaking router.
7.4. Neighbor Relationships
Each distinct group consists of one speaker, and the set of directly
connected listeners. If the decision is made to maintain one
Security Association per speaker (see Section 8), then the key server
will need to be aware of the adjacencies of each speaker. Procedures
for doing this are under study.
8. Number of Security Associations
The number of Security Associations to be maintained by a PIM router The number of Security Associations to be maintained by a PIM router
depends on the required security level and available key management. depends on the required security level and available key management.
This SHOULD be decided by the Network Administrator. Two different This SHOULD be decided by the Network Administrator. Two different
ways are shown in Figure 1 and 2. It is assumed that A, B and C are ways are shown in Figure 1 and 2. It is assumed that A, B and C are
three PIM routers, where B and C are directly connected with A, and three PIM routers, where B and C are directly connected with A, and
there is no direct link between B and C. there is no direct link between B and C.
A |
SAa ------------>|
SAb <------------|
SAc <------------|
| |
B | B |
SAb ------------>| SAb ------------>|
SAa <------------| SAa <------------|
| |
A |
SAb <------------|
SAa ------------>|
SAc <------------|
|
C | C |
SAc ------------>| SAc ------------>|
SAa <------------| SAa <------------|
| |
Directly connected network Directly connected network
Figure 1: Activate unique Security Association for each peer Figure 1: Activate unique Security Association for each peer
The first method, shown in Figure 1 is OPTIONAL to implement. In The first method, shown in Figure 1 is OPTIONAL to implement. In
this method, each node will use a unique SA for its outbound traffic. this method, each node will use a unique SA for its outbound traffic.
skipping to change at page 10, line 5 skipping to change at page 12, line 5
source address. A will use SAb and SAc for packets received from B source address. A will use SAb and SAc for packets received from B
and C, respectively. The number of SAs to be activated and and C, respectively. The number of SAs to be activated and
maintained by a PIM router will be equal to the number of directly maintained by a PIM router will be equal to the number of directly
connected routers plus one, for sending its own traffic. Also, the connected routers plus one, for sending its own traffic. Also, the
addition of a PIM router in the network will require the addition of addition of a PIM router in the network will require the addition of
another SA on every directly connected PIM router. This solution another SA on every directly connected PIM router. This solution
will be scalable and practically feasible with an automated key will be scalable and practically feasible with an automated key
management protocol. However, it MAY be used with manual key management protocol. However, it MAY be used with manual key
management, if the number of directly connected router(s) is small. management, if the number of directly connected router(s) is small.
A | B |
SAo ------------>| SAo ------------>|
SAi <------------| SAi <------------|
| |
B | A |
SAo ------------>| SAo ------------>|
SAi <------------| SAi <------------|
| |
C | C |
SAo ------------>| SAo ------------>|
SAi <------------| SAi <------------|
| |
Directly connected network Directly connected network
Figure 2: Activate two Security Associations Figure 2: Activate two Security Associations
skipping to change at page 11, line 5 skipping to change at page 13, line 5
The second method, shown in Figure 2, MUST be supported by every The second method, shown in Figure 2, MUST be supported by every
implementation. In this simple method, all the nodes will use two implementation. In this simple method, all the nodes will use two
SAs, one for sending (SAo) and the other for receiving (SAi) traffic. SAs, one for sending (SAo) and the other for receiving (SAi) traffic.
Thus, the number of SAs is always two and will not be affected by Thus, the number of SAs is always two and will not be affected by
addition of a PIM router. This document RECOMMENDS the above method addition of a PIM router. This document RECOMMENDS the above method
for manual key configuration. However, it MAY also be used with for manual key configuration. However, it MAY also be used with
automated key configuration. When manually configured, the method automated key configuration. When manually configured, the method
suffers from impersonation attacks as mentioned in the Security suffers from impersonation attacks as mentioned in the Security
Considerations section. Considerations section.
8. Rekeying 9. Rekeying
This section will provide the rekeying rules. It will be written This section will provide the rekeying rules. It will be written
once is is decided whether or not to specify a re-keying protocol as once is is decided whether or not to specify a re-keying protocol as
part of this document. part of this document.
8.1. Rekeying Procedure 9.1. Rekeying Procedure
TBD TBD
8.2. KeyRolloverInterval 9.2. KeyRollover Interval
TBD TBD
8.3. Rekeying Interval 9.3. Rekeying Interval
TBD TBD
9. IPsec Protection Barrier and SPD 10. IPsec Protection Barrier and SPD
This section will provide the SPD selection function rules. It will This section will provide the SPD selection function rules. It will
be written once it is decided whether we need confidentiality in be written once it is decided whether to retain both confidentiality
addition to authentication. and authentication, or to limit the recommendation to authentication.
10. Security Association Lookup 11. Security Association Lookup
For an SA that carries unicast traffic, three parameters (SPI, For an SA that carries unicast traffic, three parameters (SPI,
destination address and security protocol type (AH or ESP)) are used destination address and security protocol type (AH or ESP)) are used
in the Security Association lookup process for inbound packets. The in the Security Association lookup process for inbound packets. The
SPI is sufficient to specify an SA. However, an implementation may SPI is sufficient to specify an SA. However, an implementation may
use the SPI in conjunction with the IPsec protocol type (AH or ESP) use the SPI in conjunction with the IPsec protocol type (AH or ESP)
for the SA lookup process. According to RFC 4301 [4] and the AH for the SA lookup process. According to RFC 4301 [4] and the AH
specification [2], for multicast SAs, in conjunction with the SPI, specification [2], for multicast SAs, in conjunction with the SPI,
the destination address or the destination address plus the sender the destination address or the destination address plus the sender
address may also be used in the SA lookup. The security protocol address may also be used in the SA lookup. The security protocol
field is not employed for a multicast SA lookup. field is not employed for a multicast SA lookup.
The reason for the various prohibitions in the IPsec RFCs concerning The reason for the various prohibitions in the IPsec RFCs concerning
multisender multicast SAs lies in the difficulty of coordinating the multisender multicast SAs lies in the difficulty of coordinating the
multiple senders. However, if the use of multicast for link-local multiple senders. However, if the use of multicast for link-local
messages is examined, it may be seen that in fact the communication messages is examined, it may be seen that in fact the communication
need not be coordinated---from the prospective of a receiving router, need not be coordinated---from the prospective of a receiving router,
each peer router is an independent sender. In effect, link-local each peer router is an independent sender. In effect, link-local
communication is an SSM communication that happens to use an ASM communication is an SSM communication that happens to use an ASM
address (which is shared among all the routers). Two possibilities address (which is shared among all the routers).
may be envisaged:
1. The address ALL_PIM_ROUTERS can be specified to operate as a set
of SSM Security Associations, when IPsec is enabled;
2. Secure Link-local communication can be specified to occur on an Given that it is always possible to distinguish a connection using
SSM address, instead of ALL_PIM_ROUTERS. IPsec from a connection not using IPsec, it is recommended that the
address ALL_PIM_ROUTERS be used, to maintain consistency with present
practice.
Given that the sender address of an incoming packet will be Given that the sender address of an incoming packet may be only
(globally) unique for a specific sender and in conjunction with the locally unique (because of the use of link-local addresses), it will
SPI it will be possible for a receiver to sort out the associated SA be necessary for a receiver to use the interface ID tag to sort out
for that sender from all the SAD entries (even if a single SAD is the associated SA for that sender. Therefore, this document mandates
maintained regardless of the number of interfaces), this document that the interface ID tag, the SPI and the sender address MUST be
mandates that the SPI and the sender address MUST be used in the SA used in the SA lookup process.
lookup process.
11. Activating the Anti-replay Mechanism 12. Activating the Anti-replay Mechanism
Although link-level messages on a link constitute a multiple-sender, Although link-level messages on a link constitute a multiple-sender,
multiple-receiver group, the use of the sender address for SA lookup multiple-receiver group, the use of the interface ID tag and sender
essentially resolves the communication into a separate SA for each address for SA lookup essentially resolves the communication into a
sender/destination pair, even for the case where only two SAs are separate SA for each sender/destination pair, even for the case where
used for the entire administrative region. Therefore, the statement only two SAs are used for the entire administrative region.
in the AH RFC (section 2.5 of [2]) that "for a multi-sender SA, the Therefore, the statement in the AH RFC (section 2.5 of [2]) that "for
anti-replay features are not available" becomes irrelevant to the a multi-sender SA, the anti-replay features are not available"
PIM-SM link-local message exchange. becomes irrelevant to the PIM-SM link-local message exchange.
To activate the anti-replay mechanism in a unicast communication, the To activate the anti-replay mechanism in a unicast communication, the
receiver uses the sliding window protocol and it maintains a sequence receiver uses the sliding window protocol and it maintains a sequence
number for this protocol. This sequence number starts from zero. number for this protocol. This sequence number starts from zero.
Each time the sender sends a new packet, it increments this number by Each time the sender sends a new packet, it increments this number by
one. In a multi-sender multicast group communication, a single one. In a multi-sender multicast group communication, a single
sequence number for the entire group would not be enough. sequence number for the entire group would not be enough.
The whole scenario is different for PIM link-local messages. These The whole scenario is different for PIM link-local messages. These
messages are sent to local links with TTL = 1. A link-local message messages are sent to local links with TTL = 1. A link-local message
never propagates through one router to another. The use of the never propagates through one router to another. The use of the
sender address for SA lookup converts the relationship from a sender address and the interface ID tag for SA lookup converts the
multiple-sender group to multiple single-sender associations. This relationship from a multiple-sender group to multiple single-sender
specification RECOMMENDS activation of the anti-replay mechanism only associations. This specification RECOMMENDS activation of the anti-
if the SAs are assigned using an automated key management. In manual replay mechanism only if the SAs are assigned using an automated key
key management, the anti-replay SHOULD NOT be activated. If the management. In manual key management, the anti-replay SHOULD NOT be
number of router(s) to be assigned manually is small, the Network activated. If the number of router(s) to be assigned manually is
Administrator MAY consider to activate anti-replay. If anti-replay small, the Network Administrator MAY consider to activate anti-
is activated a PIM router MUST maintain a different sliding window replay. If anti-replay is activated a PIM router MUST maintain a
for each directly connected sender. different sliding window for each directly connected sender.
If the SAs are activated according to Figure 2, that is all the nodes If the SAs are activated according to Figure 2, that is all the nodes
use only two SAs, one SA for sending and the other is for receiving use only two SAs, one SA for sending and the other is for receiving
traffic, a PIM router MAY still activate the anti-replay mechanism. traffic, a PIM router MAY still activate the anti-replay mechanism.
Instead of maintaining only two SAs, the router will maintain the Instead of maintaining only two SAs, the router will maintain the
same number of SAs as explained in the first method (see Figure 1) same number of SAs as explained in the first method (see Figure 1)
(because of the differentiation based on sender address). For each (because of the differentiation based on sender address). For each
active SA a corresponding sequence number MUST be maintained. Thus, active SA a corresponding sequence number MUST be maintained. Thus,
a PIM router will maintain a number of identical SAs, except that the a PIM router will maintain a number of identical SAs, except that the
sender address and the sequence number are different for each SA. In sender address, interface ID tag and the sequence number are
this way a PIM router will be at least free from all the attacks that different for each SA. In this way a PIM router will be at least
can be performed by replaying PIM-SM packets. free from all the attacks that can be performed by replaying PIM-SM
packets.
Note that when activating anti-replay with manual key configuration, Note that when activating anti-replay with manual key configuration,
the following actions must be taken by the network administrator: the following actions must be taken by the network administrator:
a. If a new router is added, the Network Administrator MUST add a a. If a new router is added, the Network Administrator MUST add a
new SA entry in each peer router. new SA entry in each peer router.
b. If an existing router has to restart, the Network Administrator b. If an existing router has to restart, the Network Administrator
MUST refresh the counter (ESN, see section 13) to zero for all MUST refresh the counter (ESN, see Section 14) to zero for all
the peer routers. This implies deleting all the existing SAs and the peer routers. This implies deleting all the existing SAs and
adding a new SA with the same configuration and a re-initialized adding a new SA with the same configuration and a re-initialized
counter. counter.
12. Implementing a Security Association Database per Interface 13. Implementing a Security Association Database per Interface
RFC 4601 suggests that it may be desirable to implement a separate RFC 4601 suggests that it may be desirable to implement a separate
Security Association Database (SPD) for each router interface. The Security Association Database (SAD) for each router interface. The
use of the source address to resolve the SAs implies that the use of use of link-local addresses in certain circumstances implies that
an SAD per interface is not necessary. This is in conformance with differentiation of ambiguous speaker addresses requires the use of
RFC 4301, which explicitly removes the requirement for separate SPDs the interface ID tag in the SA lookup. One way to do this is through
that was present in RFC 2401 [6]. the use of multiple SADs. Alternatively, the interface ID tag may be
a specific component of the selector algorithm. This is in
conformance with RFC 4301, which explicitly removes the requirement
for separate SADs that was present in RFC 2401 [8].
13. Extended Sequence Number 14. Extended Sequence Number
In the [2], there is a provision for a 64-bit Extended Sequence In the [2], there is a provision for a 64-bit Extended Sequence
Number (ESN) as the counter of the sliding window used in the anti- Number (ESN) as the counter of the sliding window used in the anti-
replay protocol. Both the sender and the receiver maintain a 64-bit replay protocol. Both the sender and the receiver maintain a 64-bit
counter for the sequence number, although only the lower order 32 counter for the sequence number, although only the lower order 32
bits is sent in the transmission. In other words, it will not affect bits is sent in the transmission. In other words, it will not affect
the present header format of AH. If ESN is used, a sender router can the present header format of AH. If ESN is used, a sender router can
send 2^64 -1 packets without any intervention. This number is very send 2^64 -1 packets without any intervention. This number is very
large, and from a PIM router's point of view, a PIM router can never large, and from a PIM router's point of view, a PIM router can never
exceed this number in its lifetime. This makes it reasonable to exceed this number in its lifetime. This makes it reasonable to
permit manual configuration for a small number of PIM routers, since permit manual configuration for a small number of PIM routers, since
the sequence number will never roll over. For this reason, when the sequence number will never roll over. For this reason, when
manual configuration is used, ESN SHOULD be deployed as the sequence manual configuration is used, ESN SHOULD be deployed as the sequence
number for the sliding window protocol. number for the sliding window protocol.
14. Security Considerations 15. Security Considerations
The whole document considers the security issues of PIM link-local The whole document considers the security issues of PIM link-local
messages and proposes a mechanism to protect them. messages and proposes a mechanism to protect them.
Limitations of manual keys: Limitations of manual keys:
The following are some of the known limitations of the usage of The following are some of the known limitations of the usage of
manual keys. manual keys.
o If the replay protection cannot be provided, the PIM routers will o If replay protection cannot be provided, the PIM routers will not
not be secured against all the attacks that can be performed by be secured against all the attacks that can be performed by
replaying PIM packets. replaying PIM packets.
o Manual keys are usually long lived (changing them often is a o Manual keys are usually long lived (changing them often is a
tedious task). This gives an attacker enough time to discover the tedious task). This gives an attacker enough time to discover the
keys. keys.
o As the administrator is manually configuring the keys, there is a o As the administrator is manually configuring the keys, there is a
chance that the configured keys are weak (there are known weak chance that the configured keys are weak (there are known weak
keys for DES/3DES at least). keys for DES/3DES at least).
Impersonation attacks: Impersonation attacks:
The usage of the same key on all the PIM routers connected to a link The usage of the same key on all the PIM routers connected to a link
leaves them all insecure against impersonation attacks if any one of leaves them all insecure against impersonation attacks if any one of
the PIM routers is compromised, malfunctioning, or misconfigured. the PIM routers is compromised, malfunctioning, or misconfigured.
Detailed analysis of various vulnerabilities of routing protocols is Detailed analysis of various vulnerabilities of routing protocols is
provided in [12]. For further discussion of PIM-SM and multicast provided in RFC 4593 [14]. For further discussion of PIM-SM and
security the reader is referred to [13], [14] and the Security multicast security the reader is referred to [15], RFC 4609 [16] and
Considerations section of RFC 4601. the Security Considerations section of RFC 4601 [1].
15. References 16. References
15.1. Normative References 16.1. Normative References
[1] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [1] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601, August 2006.
[2] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [2] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[4] Kent, S. and K. Seo, "Security Architecture for the Internet [4] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005. Protocol", RFC 4301, December 2005.
[5] Hardjono, T. and B. Weis, "The Multicast Group Security [5] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
December 2005.
[6] Hardjono, T. and B. Weis, "The Multicast Group Security
Architecture", RFC 3740, March 2004. Architecture", RFC 3740, March 2004.
15.2. Informative References [7] Eastlake, D., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4305, December 2005.
[6] Kent, S. and R. Atkinson, "Security Architecture for the 16.2. Informative References
[8] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[7] Islam, S., "Security Issues in PIM-SM Link-local Messages, [9] Islam, S., "Security Issues in PIM-SM Link-local Messages,
Master's Thesis, Concordia University", December 2003. Master's Thesis, Concordia University", December 2003.
[8] Islam, S., "Security Issues in PIM-SM Link-local Messages, [10] Islam, S., "Security Issues in PIM-SM Link-local Messages,
Proceedings of LCN 2004", November 2004. Proceedings of LCN 2004", November 2004.
[9] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [11] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[10] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: [12] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP:
Group Secure Association Key Management Protocol", RFC 4535, Group Secure Association Key Management Protocol", RFC 4535,
June 2006. June 2006.
[11] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group [13] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group
Domain of Interpretation", RFC 3547, July 2003. Domain of Interpretation", RFC 3547, July 2003.
[12] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to [14] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
Routing Protocols", draft-ietf-rpsec-routing-threats-07 (work Routing Protocols", RFC 4593, October 2006.
in progress), October 2004.
[13] Lingard, J. and P. Savola, "Last-hop Threats to Protocol [15] Savola, P. and J. Lingard, "Last-hop Threats to Protocol
Independent Multicast (PIM)", Independent Multicast (PIM)", draft-ietf-pim-lasthop-threats-01
draft-savola-pim-lasthop-threats-02 (work in progress), (work in progress), June 2007.
June 2006.
[14] Savola, P., Lehtonen, R., and D. Meyer, "PIM-SM Multicast [16] Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent
Routing Security Issues and Enhancements", Multicast - Sparse Mode (PIM-SM) Multicast Routing Security
draft-ietf-mboned-mroutesec-04 (work in progress), Issues and Enhancements", RFC 4609, October 2006.
October 2004.
Authors' Addresses Authors' Addresses
J. William Atwood J. William Atwood
Concordia University/CSE Concordia University/CSE
1455 de Maisonneuve Blvd, West 1455 de Maisonneuve Blvd, West
Montreal, QC H3G 1M8 Montreal, QC H3G 1M8
Canada Canada
Phone: +1(514)848-2424 ext3046 Phone: +1(514)848-2424 ext3046
Email: bill@cse.concordia.ca Email: bill@cse.concordia.ca
URI: http://www.cs.concordia.ca/~bill URI: http://users.encs.concordia.ca/~bill
Salekul Islam Salekul Islam
Concordia University/CSE Concordia University/CSE
1455 de Maisonneuve Blvd, West 1455 de Maisonneuve Blvd, West
Montreal, QC H3G 1M8 Montreal, QC H3G 1M8
Canada Canada
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 61 change blocks. 
132 lines changed or deleted 210 lines changed or added

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