draft-ietf-pim-sm-linklocal-01.txt   draft-ietf-pim-sm-linklocal-02.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 July 08, 2007 Intended status: Standards Track November 18, 2007
Expires: January 9, 2008 Expires: May 21, 2008
Security Issues in PIM-SM Link-local Messages Authentication and Confidentiality in PIM-SM Link-local Messages
draft-ietf-pim-sm-linklocal-01 draft-ietf-pim-sm-linklocal-02
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 January 9, 2008. This Internet-Draft will expire on May 21, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
RFC 4601 mandates the use of IPsec to ensure authentication of the RFC 4601 mandates the use of IPsec to ensure authentication of the
link-local messages in the Protocol Independent Multicast - Sparse link-local messages in the Protocol Independent Multicast - Sparse
Mode (PIM-SM) routing protocol. This document specifies mechanisms Mode (PIM-SM) routing protocol. This document specifies mechanisms
to authenticate the PIM-SM link local messages using the IP security to authenticate the PIM-SM link local messages using the IP security
(IPsec) Authentication Header (AH) or Encapsulating Security Payload (IPsec) Authentication Header (AH) or Encapsulating Security Payload
(ESP). It specifies optional mechanisms to provide confidentiality (ESP). It specifies optional mechanisms to provide confidentiality
using the ESP. Manual keying is specified as the mandatory and using the ESP. Manual keying is specified as the mandatory and
default group key management solution. To deal with issues of default group key management solution. To deal with issues of
scalability and security that exist with manual keying, an optional scalability and security that exist with manual keying, an optional
automated group key management mechanism is specified. automated group key management mechanism is specified.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Transport Mode vs. Tunnel Mode . . . . . . . . . . . . . . . . 5
4. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Confidentiality . . . . . . . . . . . . . . . . . . . . . . . 7
6. IPsec Requirements . . . . . . . . . . . . . . . . . . . . . . 8
7. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Manual Key Management . . . . . . . . . . . . . . . . . . 9
7.2. Automated Key Management . . . . . . . . . . . . . . . . . 9
7.3. Communications Patterns . . . . . . . . . . . . . . . . . 9
7.4. Neighbor Relationships . . . . . . . . . . . . . . . . . . 11
8. Number of Security Associations . . . . . . . . . . . . . . . 12
9. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Rekeying Procedure . . . . . . . . . . . . . . . . . . . . 14
9.2. KeyRollover Interval . . . . . . . . . . . . . . . . . . . 14
9.3. Rekeying Interval . . . . . . . . . . . . . . . . . . . . 14
10. IPsec Protection Barrier and SPD . . . . . . . . . . . . . . . 15
11. Security Association Lookup . . . . . . . . . . . . . . . . . 16
12. Activating the Anti-replay Mechanism . . . . . . . . . . . . . 17
13. Implementing a Security Association Database per Interface . . 19
14. Extended Sequence Number . . . . . . . . . . . . . . . . . . . 20
15. Security Considerations . . . . . . . . . . . . . . . . . . . 21
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
16.1. Normative References . . . . . . . . . . . . . . . . . . . 22
16.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 25
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.
These messages are called link-local messages. Hello, Join/Prune and These messages are called link-local messages. Hello, Join/Prune and
skipping to change at page 9, line 49 skipping to change at page 9, line 49
be large and the end users or devices can dynamically join/leave a be large and the end users or devices can dynamically join/leave a
multicast group. However, a PIM router is not expected to join/leave multicast group. However, a PIM router is not expected to join/leave
very frequently, and the number of routers is small when compared to very frequently, and the number of routers is small when compared to
the possible number of users of a multicast application. Moreover, the possible number of users of a multicast application. 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. It is administrative domain and are considered as trusted parties. It is
possible that a subset of GDOI functionalities will be sufficient. possible that a subset of GDOI functionalities will be sufficient.
7.3. Communications Patterns 7.3. Communications Patterns
From the perspective of a speaking router, the information from that Before discussing the set of security associations that are required
router is sent to all of its neighbors. From the perspective of a to properly manage a multicast region that is under the control of a
listening router, the information coming from each of its neighbors single administration, it is necessary to understand the
is distinct from the information coming from every other router. communications patterns that will exist among the routers in this
region. From the perspective of a speaking router, the information
from that router is sent (multicast) 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 to which it is directly connected. Thus an
administrative region contains many (small) distinct groups, all of
which happen to be using the same multicast destination address
(e.g., ALL_PIM_ROUTERS, see Section 11), and each of which is
centered on the associated speaking router.
Thus an administrative region contains many distinct groups, all of Consider the example configuration as shown in Figure 1.
which happen to be using the same destination address
(ALL_PIM_ROUTERS, see Section 11), and each of which is centered on R2 R3 R4 R5 R6
the speaking router. | | | | |
| | | | |
--------- ---------------
| |
| |
\ /
R1
/ \
| |
| |
--------- --------------------
| | | | |
| | | | |
R7 R8 R9 R10 R11
| | | | |
|
|
-------------
| | |
| | |
R12 R13 R14
Figure 1: Set of router interconnections
In this configuration, router R1 has four interfaces, and is the
speaking router for a group whose listening routers are routers R2
through R11. Router R9 is the speaking router for a group whose
listening routers are routers R1, R8 and R10-R14.
From the perspective of R1 as a speaking router, if a Security
Association SA1 is assigned to protect outgoing packets from R1, then
it is necessary to distribute the key for this association to each of
the routers R2 through R11. Similarly, from the perspective of R9 as
a speaking router, if a Security Association is assigned to protect
the outgoing packets from R9, then it is necessary to distribute the
key for this association to each of the routers R1, R8, and R10
through R14.
From the perspective of R1 as a listening router, all packets
arriving from R2 through R11 need to be distinguished from each
other, to permit selecting the correct Security Association in the
SAD. (Packets from each of the peer routers (R2 through R11)
represent communication from a different speaker, even though they
are sent using the same destination address.) For a multicast
Security Association, RFC 4301 permits using the Source Address in
the selection function. If the source addresses used by routers R2
through R11 are globally unique, then the source addresses of the
peer routers are sufficient to achieve the differentiation. If the
sending routers use link-local addresses, then these addresses are
unique only on a per-interface basis, and it is necessary to use the
Interface ID tag as an additional selector, i.e., either the
selection function has to have the Interface ID tag as one of its
inputs, or separate SADs have to be maintained for each interface.
If the assumption of connectivity to the key server can be made
(which is true in the PIM-SM case), then the GC/KS can be centrally
located (and duplicated for reliability). If this assumption cannot
be made (i.e., in the case of adjacencies for a unicast router), then
some form of "local" key server must be available for each group.
Given that the listening routers are never more than one hop away
from the speaking router, the speaking router is the obvious place to
locate the "local" key server. This has the additional advantage
that there is no need to duplicate the local key server for
reliability, since if the key server is down, it is very likely that
the speaking router is also down.
7.4. Neighbor Relationships 7.4. Neighbor Relationships
Each distinct group consists of one speaker, and the set of directly Each distinct group consists of one speaker, and the set of directly
connected listeners. If the decision is made to maintain one connected listeners. If the decision is made to maintain one
Security Association per speaker (see Section 8), then the key server Security Association per speaker (see Section 8), then the key server
will need to be aware of the adjacencies of each speaker. Procedures will need to be aware of the adjacencies of each speaker. Procedures
for doing this are under study. for doing this are under study.
8. Number of Security Associations 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 2 and 3. 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.
| |
B | B |
SAb ------------>| SAb ------------>|
SAa <------------| SAa <------------|
| |
A | A |
SAb <------------| SAb <------------|
SAa ------------>| SAa ------------>|
SAc <------------| SAc <------------|
| |
C | C |
SAc ------------>| SAc ------------>|
SAa <------------| SAa <------------|
| |
Directly connected network Directly connected network
Figure 1: Activate unique Security Association for each peer Figure 2: 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 2 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.
A, B, and C will use SAa, SAb, and SAc, respectively for sending any A, B, and C will use SAa, SAb, and SAc, respectively for sending any
traffic. Each node will look up the SA to be used based on the traffic. Each node will look up the SA to be used based on the
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
skipping to change at page 12, line 19 skipping to change at page 13, line 19
A | A |
SAo ------------>| SAo ------------>|
SAi <------------| SAi <------------|
| |
C | C |
SAo ------------>| SAo ------------>|
SAi <------------| SAi <------------|
| |
Directly connected network Directly connected network
Figure 2: Activate two Security Associations Figure 3: Activate two Security Associations
The second method, shown in Figure 2, MUST be supported by every The second method, shown in Figure 3, 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. Although two different SAs are used in
for manual key configuration. However, it MAY also be used with this method, the encryption key for the two SAs is identical, i.e.,
automated key configuration. When manually configured, the method it is a single key shared among all the routers in an administrative
suffers from impersonation attacks as mentioned in the Security region. This document RECOMMENDS the above method for manual key
Considerations section. configuration. However, it MAY also be used with automated key
configuration. When manually configured, the method suffers from
impersonation attacks as mentioned in the Security Considerations
section.
9. 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.
9.1. Rekeying Procedure 9.1. Rekeying Procedure
TBD TBD
skipping to change at page 16, line 11 skipping to change at page 17, line 11
the associated SA for that sender. Therefore, this document mandates the associated SA for that sender. Therefore, this document mandates
that the interface ID tag, the SPI and the sender address MUST be that the interface ID tag, the SPI and the sender address MUST be
used in the SA lookup process. used in the SA lookup process.
12. 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 interface ID tag and sender multiple-receiver group, the use of the interface ID tag and sender
address for SA lookup essentially resolves the communication into a address for SA lookup essentially resolves the communication into a
separate SA for each sender/destination pair, even for the case where separate SA for each sender/destination pair, even for the case where
only two SAs are used for the entire administrative region. only two SAs (and one shared key) are used for the entire
Therefore, the statement in the AH RFC (section 2.5 of [2]) that "for administrative region. Therefore, the statement in the AH RFC
a multi-sender SA, the anti-replay features are not available" (section 2.5 of [2]) that "for a multi-sender SA, the anti-replay
becomes irrelevant to the PIM-SM link-local message exchange. features are not available" 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
skipping to change at page 16, line 36 skipping to change at page 17, line 37
sender address and the interface ID tag for SA lookup converts the sender address and the interface ID tag for SA lookup converts the
relationship from a multiple-sender group to multiple single-sender relationship from a multiple-sender group to multiple single-sender
associations. This specification RECOMMENDS activation of the anti- associations. This specification RECOMMENDS activation of the anti-
replay mechanism only if the SAs are assigned using an automated key replay mechanism only if the SAs are assigned using an automated key
management. In manual key management, the anti-replay SHOULD NOT be management. In manual key management, the anti-replay SHOULD NOT be
activated. If the number of router(s) to be assigned manually is activated. If the number of router(s) to be assigned manually is
small, the Network Administrator MAY consider to activate anti- small, the Network Administrator MAY consider to activate anti-
replay. If anti-replay is activated a PIM router MUST maintain a replay. If anti-replay is activated a PIM router MUST maintain a
different sliding window 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 3, 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 2)
(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, interface ID tag and the sequence number are sender address, interface ID tag and the sequence number are
different for each SA. In this way a PIM router will be at least different for each SA. In this way a PIM router will be at least
free from all the attacks that can be performed by replaying PIM-SM free from all the attacks that can be performed by replaying PIM-SM
packets. 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:
skipping to change at page 22, line 6 skipping to change at page 23, line 6
[12] 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.
[13] 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.
[14] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to [14] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
Routing Protocols", RFC 4593, October 2006. Routing Protocols", RFC 4593, October 2006.
[15] Savola, P. and J. Lingard, "Last-hop Threats to Protocol [15] Savola, P. and J. Lingard, "Host Threats to Protocol
Independent Multicast (PIM)", draft-ietf-pim-lasthop-threats-01 Independent Multicast (PIM)", draft-ietf-pim-lasthop-threats-03
(work in progress), June 2007. (work in progress), October 2007.
[16] Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent [16] Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent
Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Multicast - Sparse Mode (PIM-SM) Multicast Routing Security
Issues and Enhancements", RFC 4609, October 2006. Issues and Enhancements", RFC 4609, October 2006.
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
 End of changes. 16 change blocks. 
32 lines changed or deleted 139 lines changed or added

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