draft-ietf-pim-sm-linklocal-05.txt   draft-ietf-pim-sm-linklocal-06.txt 
PIM Working Group W. Atwood PIM Working Group W. Atwood
Internet-Draft Concordia University/CSE Internet-Draft Concordia University/CSE
Updates: 4601 (if approved) S. Islam Updates: 4601 (if approved) S. Islam
Intended status: Standards Track INRS Energie, Materiaux et Intended status: Standards Track INRS Energie, Materiaux et
Expires: May 7, 2009 Telecommunications Expires: August 8, 2009 Telecommunications
M. Siami M. Siami
Concordia University/CIISE Concordia University/CIISE
November 03, 2008 February 04, 2009
Authentication and Confidentiality in PIM-SM Link-local Messages Authentication and Confidentiality in PIM-SM Link-local Messages
draft-ietf-pim-sm-linklocal-05 draft-ietf-pim-sm-linklocal-06
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
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 May 7, 2009. This Internet-Draft will expire on August 8, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
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) Encapsulating Security Payload (ESP) or (optionally) the
(ESP). It specifies optional mechanisms to provide confidentiality Authentication Header (AH). It specifies optional mechanisms to
using the ESP. Manual keying is specified as the mandatory and provide confidentiality using the ESP. Manual keying is specified as
default group key management solution. To deal with issues of the mandatory and default group key management solution. To deal
scalability and security that exist with manual keying, an optional with issues of scalability and security that exist with manual
automated group key management mechanism is specified. keying, an optional support for automated group key management
mechanism is provided. However, the procedures for implementing
automated group key management are left to other documents. This
document updates RFC 4601.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Goals and Non-goals . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Transport Mode vs. Tunnel Mode . . . . . . . . . . . . . . . . 7 3. Transport Mode vs. Tunnel Mode . . . . . . . . . . . . . . . . 7
4. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Confidentiality . . . . . . . . . . . . . . . . . . . . . . . 9 5. Confidentiality . . . . . . . . . . . . . . . . . . . . . . . 9
6. IPsec Requirements . . . . . . . . . . . . . . . . . . . . . . 10 6. IPsec Requirements . . . . . . . . . . . . . . . . . . . . . . 10
7. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Manual Key Management . . . . . . . . . . . . . . . . . . 11 7.1. Manual Key Management . . . . . . . . . . . . . . . . . . 12
7.2. Automated Key Management . . . . . . . . . . . . . . . . . 11 7.2. Automated Key Management . . . . . . . . . . . . . . . . . 12
7.3. Communications Patterns . . . . . . . . . . . . . . . . . 12 7.3. Communications Patterns . . . . . . . . . . . . . . . . . 13
7.4. Neighbor Relationships . . . . . . . . . . . . . . . . . . 13 7.4. Neighbor Relationships . . . . . . . . . . . . . . . . . . 15
8. Number of Security Associations . . . . . . . . . . . . . . . 14 8. Number of Security Associations . . . . . . . . . . . . . . . 16
9. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Rekeying Procedure . . . . . . . . . . . . . . . . . . . . 16 9.1. Rekeying Procedure . . . . . . . . . . . . . . . . . . . . 18
9.2. KeyRollover Interval . . . . . . . . . . . . . . . . . . . 16 9.2. KeyRollover Interval . . . . . . . . . . . . . . . . . . . 18
9.3. Rekeying Interval . . . . . . . . . . . . . . . . . . . . 17 9.3. Rekeying Interval . . . . . . . . . . . . . . . . . . . . 19
10. IPsec Protection Barrier and GSPD . . . . . . . . . . . . . . 18 10. IPsec Protection Barrier and SPD/GSPD . . . . . . . . . . . . 20
10.1. Manual Keying . . . . . . . . . . . . . . . . . . . . . . 18 10.1. Manual Keying . . . . . . . . . . . . . . . . . . . . . . 20
10.1.1. SAD Entries . . . . . . . . . . . . . . . . . . . . . 18 10.1.1. SAD Entries . . . . . . . . . . . . . . . . . . . . . 20
10.1.2. SPD Entries . . . . . . . . . . . . . . . . . . . . . 18 10.1.2. SPD Entries . . . . . . . . . . . . . . . . . . . . . 20
10.2. Automatic Keying . . . . . . . . . . . . . . . . . . . . . 18 10.2. Automatic Keying . . . . . . . . . . . . . . . . . . . . . 20
10.2.1. SAD Entries . . . . . . . . . . . . . . . . . . . . . 18 10.2.1. SAD Entries . . . . . . . . . . . . . . . . . . . . . 20
10.2.2. GSPD Entries . . . . . . . . . . . . . . . . . . . . 18 10.2.2. GSPD Entries . . . . . . . . . . . . . . . . . . . . 20
10.2.3. PAD Entries . . . . . . . . . . . . . . . . . . . . . 19 10.2.3. PAD Entries . . . . . . . . . . . . . . . . . . . . . 21
11. Security Association Lookup . . . . . . . . . . . . . . . . . 20 11. Security Association Lookup . . . . . . . . . . . . . . . . . 22
12. Activating the Anti-replay Mechanism . . . . . . . . . . . . . 21 12. Activating the Anti-replay Mechanism . . . . . . . . . . . . . 23
13. Implementing a Security Association Database per Interface . . 23 13. Implementing a Security Association Database per Interface . . 25
14. Extended Sequence Number . . . . . . . . . . . . . . . . . . . 24 14. Extended Sequence Number . . . . . . . . . . . . . . . . . . . 26
15. Security Considerations . . . . . . . . . . . . . . . . . . . 25 15. Security Considerations . . . . . . . . . . . . . . . . . . . 27
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
17.1. Normative References . . . . . . . . . . . . . . . . . . . 27 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
17.2. Informative References . . . . . . . . . . . . . . . . . . 27 18.1. Normative References . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 18.2. Informative References . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
All the PIM-SM [RFC4601] control messages have IP protocol number All the PIM-SM [RFC4601] control messages have IP protocol number
103. These messages are either unicast, or multicast with TTL = 1. 103. These messages are either unicast, or multicast with TTL = 1.
The source address used for unicast messages is a domain-wide The source address used for unicast messages is a domain-wide
reachable address. For the multicast messages, a link-local address reachable address. For the multicast messages, a link-local address
of the interface on which the message is being sent is used as the of the interface on which the message is being sent is used as the
source address and a special multicast address, ALL_PIM_ROUTERS source 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 (224.0.0.13 in IPv4 and ff02::d in IPv6) is used as the destination
skipping to change at page 4, line 25 skipping to change at page 4, line 25
Join/Prune and Assert messages are included in this category. A Join/Prune and Assert messages are included in this category. A
forged link-local message may be sent to the ALL_PIM_ROUTERS forged link-local message may be sent to the ALL_PIM_ROUTERS
multicast address by an attacker. This type of message affects the multicast address by an attacker. This type of message affects the
construction of the distribution tree [RFC4601]. The effects of construction of the distribution tree [RFC4601]. The effects of
these forged messages are outlined in section 6.1 of [RFC4601]. Some these forged messages are outlined in section 6.1 of [RFC4601]. Some
of the effects are very severe, whereas some are minor. of the effects are very severe, 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 Authentication Header (AH)
specification described in RFC 4302 [RFC4302]. specification described in RFC 4302 [RFC4302].
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 [RFC3740]. Securing the user data exchanges is covered in RFC 3740 [RFC3740].
This document focuses on the security issues for link-local messages. This document focuses on the security issues for link-local messages.
It provides some guidelines to take advantage of the new permitted AH It provides some guidelines to take advantage of the new permitted AH
functionality in RFC 4302 and the new permitted ESP functionality in functionality in RFC 4302 and the new permitted ESP functionality in
RFC 4303, and to bring the PIM-SM specification into alignment with RFC 4303 [RFC4303], and to bring the PIM-SM specification into
the new AH and ESP specifications. This document recommends manual alignment with the new AH and ESP specifications. In particular, in
key management as mandatory to implement, i.e., that all accordance with RFC 4301, the use of ESP is made mandatory and AH is
implementations MUST support, and provides the necessary structure specified as optional. This document recommends manual key
for an automated key management protocol that the PIM routers may management as mandatory to implement, i.e., that all implementations
use. MUST support, and provides the necessary structure for an automated
key management protocol that the PIM routers may use.
1.1. Goals and Non-goals
The primary goal for link-local security is to provide data origin The primary goal for link-local security is to provide data origin
authentication for each link-local message. A secondary goal is to authentication for each link-local message. A secondary goal is to
ensure that communication only happens between legitimate peers ensure that communication only happens between legitimate peers
(i.e., adjacent routers). An optional goal is to provide data (i.e., adjacent routers). An optional goal is to provide data
confidentiality for the link-local messages. confidentiality for the link-local messages.
The first goal implies that each router has a unique identity. It is The first goal implies that each router has a unique identity. It is
likely (but not mandatory) that this identity will be based on the possible (but not mandatory) that this identity will be based on the
unicast identity of the router. (The unicast identity could be, for unicast identity of the router. (The unicast identity could be, for
example, based on some individually-configured property of the example, based on some individually-configured property of the
router, or be part of a region-wide public key infrastructure.) The router, or be part of a region-wide public key infrastructure.) The
existence of this identity is assumed in this specification, but existence of this unique identity is assumed in this specification,
procedures for establishing it are out-of-scope for this document. but procedures for establishing it are out-of-scope for this
document.
The second goal implies that there is some form of "adjacency matrix" The second goal implies that there is some form of "adjacency matrix"
that controls the establishment of security associations among that controls the establishment of security associations among
adjacent multicast routers. For manual keying, this control will be adjacent multicast routers. For manual keying, this control will be
exercised by the Administrator of the router(s), through the setting exercised by the Administrator of the router(s), through the setting
of initialization parameters. For automated keying, the existence of of initialization parameters. For automated keying, the existence of
this control will be reflected by the contents of the Group Security this control will be reflected by the contents of the Permitted
Policy Database (GSPD) in each router. Procedures for building this Access Database and the Group Security Policy Database (GSPD) in each
GSPD are out-of-scope for this document. router. Procedures for controling the adjacency and building the
asssociated PAD and GSPD are out-of-scope for this document.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
They indicate requirement levels for compliant PIM-SM They indicate requirement levels for compliant PIM-SM
implementations. implementations.
3. Transport Mode vs. Tunnel Mode 3. Transport Mode vs. Tunnel Mode
skipping to change at page 8, line 15 skipping to change at page 8, line 15
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. authentication for PIM-SM link-local messages.
In order to provide authentication to PIM-SM link-local messages, In order to provide authentication to PIM-SM link-local messages,
implementations MUST support ESP [RFC4303] and MAY support AH implementations MUST support ESP [RFC4303] and MAY support AH
[RFC4302]. [RFC4302].
If ESP in transport mode is used, it will only provide authentication If ESP in transport mode is used, it will only provide authentication
to PIM-SM protocol packets excluding the IPv6 header, extension to PIM-SM protocol packets excluding the IP header, extension
headers, and options. (Note: The IPv4 exclusions need to be listed headers, and options.
here as well.)
If AH in transport mode is used, it will provide authentication to If AH in transport mode is used, it will provide authentication to
PIM-SM protocol packets, selected portions of the IPv6 header, PIM-SM protocol packets, selected portions of the IP header,
extension headers and options. (Note: the IPv4 coverage needs to be extension headers and options.
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 or ESP o PIM-SM link-local packets that are not protected with AH or ESP
MUST be 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. Confidentiality 5. Confidentiality
skipping to change at page 11, line 5 skipping to change at page 10, line 45
when in conflict with the above statement, the key words "MUST", when in conflict with the above statement, the key words "MUST",
"MUST NOT", "REQUIRED", "SHOULD", and "SHOULD NOT" that appear in "MUST NOT", "REQUIRED", "SHOULD", and "SHOULD NOT" that appear in
RFC 4835 [RFC4835] for algorithms to be supported are to be RFC 4835 [RFC4835] for algorithms to be supported are to be
interpreted as described in RFC 2119 [RFC2119] for PIM-SM support interpreted as described in RFC 2119 [RFC2119] for PIM-SM support
as well. as well.
Encapsulation of ESP packet Encapsulation of ESP packet
IP encapsulation of ESP packets MUST be supported. For IP encapsulation of ESP packets MUST be supported. For
simplicity, UDP encapsulation of ESP packets SHOULD NOT be used. simplicity, UDP encapsulation of ESP packets SHOULD NOT be used.
If the automatic keying features of this specification are
implemented, the following additional IPsec capabilities are
required:
Group Security Policy Database (GSPD)
The implementation MUST support the GSPD that is described in RFC
5374 [RFC5374].
Multiple Group Security Policy Databases
The implementation MUST support multiple GSPDs with a GSPD
selection function that provides an ability to choose a specific
GSPD based on interface.
Selectors
The implementation MUST be able to use source address, destination
address, protocol and direction as selectors in the GSPD.
7. Key Management 7. Key Management
All the implementations MUST support manual configuration of the SAs All the implementations MUST support manual configuration of the
that will be used to authenticate PIM-SM link-local messages. This Security Associations (SAs) that will be used to authenticate PIM-SM
does not preclude the use of a negotiation protocol such as the link-local messages. This does not preclude the use of a negotiation
Internet Key Exchange (IKE) [RFC4306] or Group Secure Association Key protocol such as the Internet Key Exchange (IKE) [RFC4306] or Group
Management Protocol (GSAKMP) [RFC4535] to establish SAs. Secure Association Key Management Protocol (GSAKMP) [RFC4535] to
establish SAs.
7.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 Security
created. The Network Administrator will also configure the Security Association Database (SAD) entry will be created. The Network
Policy Database of a router to ensure the use of the associated SA Administrator will also configure the Security Policy Database of a
while sending a link-local message. router to ensure the use of the associated SA while sending a link-
local message.
7.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 into 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 procedures for automated key management are not specified in this
document.
One option is to use Group Domain Of Interpretation (GDOI) [RFC3547], One option is to use Group Domain Of Interpretation (GDOI) [RFC3547],
which enables a group of users or devices to exchange encrypted data which enables a group of users or devices to exchange encrypted data
using IPsec data encryption. GDOI has been developed to be used in using IPsec data encryption. GDOI has been developed to be used in
multicast applications, where the number of end users or devices may multicast applications, where the number of end users or devices may
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
skipping to change at page 13, line 18 skipping to change at page 14, line 48
the routers R2 through R11. Similarly, from the perspective of R9 as the routers R2 through R11. Similarly, from the perspective of R9 as
a speaking router, if a Security Association is assigned to protect a speaking router, if a Security Association is assigned to protect
the outgoing packets from R9, then it is necessary to distribute the 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 key for this association to each of the routers R1, R8, and R10
through R14. through R14.
From the perspective of R1 as a listening router, all packets From the perspective of R1 as a listening router, all packets
arriving from R2 through R11 need to be distinguished from each arriving from R2 through R11 need to be distinguished from each
other, to permit selecting the correct Security Association in the other, to permit selecting the correct Security Association in the
SAD. (Packets from each of the peer routers (R2 through R11) SAD. (Packets from each of the peer routers (R2 through R11)
represent communication from a different speaker, even though they represent communication from a different speaker, with a separate
are sent using the same destination address.) For a multicast sequence number space, even though they are sent using the same
Security Association, RFC 4301 permits using the Source Address in destination address.) For a multicast Security Association, RFC 4301
the selection function. If the source addresses used by routers R2 permits using the Source Address in the selection function. If the
through R11 are globally unique, then the source addresses of the source addresses used by routers R2 through R11 are globally unique,
peer routers are sufficient to achieve the differentiation. If the then the source addresses of the peer routers are sufficient to
sending routers use link-local addresses, then these addresses are achieve the differentiation. If the sending routers use link-local
unique only on a per-interface basis, and it is necessary to use the addresses, then these addresses are unique only on a per-interface
Interface ID tag as an additional selector, i.e., either the basis, and it is necessary to use the Interface ID tag as an
selection function has to have the Interface ID tag as one of its additional selector, i.e., either the selection function has to have
inputs, or separate SADs have to be maintained for each interface. 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 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 (which is true in the PIM-SM case), then the Group Controller/Key
located (and duplicated for reliability). If this assumption cannot Server (GC/KS) that is used for the management of the keys can be
be made (i.e., in the case of adjacencies for a unicast router), then centrally located (and duplicated for reliability). If this
some form of "local" key server must be available for each group. assumption cannot be made (i.e., in the case of adjacencies for a
Given that the listening routers are never more than one hop away unicast router), then some form of "local" key server must be
from the speaking router, the speaking router is the obvious place to available for each group. Given that the listening routers are never
locate the "local" key server. This has the additional advantage more than one hop away from the speaking router, the speaking router
that there is no need to duplicate the local key server for is the obvious place to locate the "local" key server. As such, this
reliability, since if the key server is down, it is very likely that may be a useful approach even in the PIM-SM case. This approach has
the speaking router is also down. 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 out-of-scope for this document. for managing and distributing these adjacencies are out-of-scope for
this document.
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 2 and 3. 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 2: Activate unique Security Association for each peer Figure 2: Activate unique Security Association for each peer
The first method, shown in Figure 2 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
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 routers is small.
B | B |
SAo ------------>| SAo ------------>|
SAi <------------| SAi <------------|
| |
A | A |
SAo ------------>| SAi <------------|
---->|
/
SAo -------
\
---->|
SAi <------------| SAi <------------|
| |
C | C |
SAo ------------>| SAo ------------>|
SAi <------------| SAi <------------|
| |
Directly connected network Directly connected network
Figure 3: Activate two Security Associations Figure 3: Activate two Security Associations
The second method, shown in Figure 3, 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. Although two different SAs are used in addition of a PIM router. Although two different SAs are used in
this method, the SA parameters (keys, SPI, etc.) for the two SAs are this method, the SA parameters (keys, Security Parameter Index (SPI),
identical, i.e., the same information is shared among all the routers etc.) for the two SAs are identical, i.e., the same information is
in an administrative region. This document RECOMMENDS the above shared among all the routers in an administrative region. This
method for manual key configuration. However, it MAY also be used document RECOMMENDS the above method for manual key configuration.
with automated key configuration. When manually configured, the However, it MAY also be used with automated key configuration. When
method suffers from impersonation attacks as mentioned in the manually configured, the method suffers from impersonation attacks as
Security Considerations section. mentioned in the Security Considerations section.
9. Rekeying 9. Rekeying
To maintain the security of a link, the authentication and encryption To maintain the security of a link, the authentication and encryption
key values SHOULD be changed periodically. key values SHOULD be changed periodically.
9.1. Rekeying Procedure 9.1. Rekeying Procedure
The following three-step procedure SHOULD be provided to rekey the The following three-step procedure SHOULD be provided to rekey the
routers on a link without dropping PIM-SM protocol packets or routers on a link without dropping PIM-SM protocol packets or
skipping to change at page 18, line 5 skipping to change at page 20, line 5
security provided by DES. security provided by DES.
o Other encryption algorithms such as 3DES and the Advanced o Other encryption algorithms such as 3DES and the Advanced
Encryption Standard (AES) will be more secure than DES. Encryption Standard (AES) will be more secure than DES.
RFC 3562 [RFC3562] analyzes the rekeying requirements for the TCP MD5 RFC 3562 [RFC3562] analyzes the rekeying requirements for the TCP MD5
signature option. The analysis provided in RFC 3562 is also signature option. The analysis provided in RFC 3562 is also
applicable to this specification as the analysis is independent of applicable to this specification as the analysis is independent of
data patterns. data patterns.
10. IPsec Protection Barrier and GSPD 10. IPsec Protection Barrier and SPD/GSPD
10.1. Manual Keying 10.1. Manual Keying
10.1.1. SAD Entries 10.1.1. SAD Entries
The Administrator must configure the necessary Security Associations. The Administrator must configure the necessary Security Associations.
Each SA entry has the Source Address of an authorized peer, and a Each SA entry has the Source Address of an authorized peer, and a
Destination Address of ALL_PIM_ROUTERS. Unique SPI values for the Destination Address of ALL_PIM_ROUTERS. Unique SPI values for the
manually configured SAs MUST be assigned by the Administrator, to manually configured SAs MUST be assigned by the Administrator, to
ensure that the SPI does not conflict with existing SPI values in the ensure that the SPI does not conflict with existing SPI values in the
SAD. SAD.
10.1.2. SPD Entries 10.1.2. SPD Entries
The Administrator must configure the necessary SPD entries. The SPD The Administrator must configure the necessary SPD entries. The SPD
entry must ensure that any outbound IP traffic packet traversing the entry must ensure that any outbound IP traffic packet traversing the
IPsec boundary, with PIM as its next layer protocol, PIM message type IPsec boundary, with PIM as its next layer protocol, PIM message type
of Hello, Join/Prune, bootstrap or Assert, sent to the Destination of Hello, Join/Prune, Bootstrap or Assert, sent to the Destination
Address of ALL_PIM_ROUTERS, is protected by AH. If the IPsec Address of ALL_PIM_ROUTERS, is protected by ESP or AH. If the IPsec
implementation does not identify PIM message types as a selector, the implementation does not identify PIM message types as a selector, the
"local port" selector can be used, with suitable adjustment. "local port" selector can be used, with suitable adjustment.
10.2. Automatic Keying 10.2. Automatic Keying
When automatic keying is used, the SA creation is done dynamically When automatic keying is used, the SA creation is done dynamically
using a group key management protocol. The GSPD and PAD tables are using a group key management protocol. The GSPD and PAD tables are
configured by the Administrator. The PAD table provides the link configured by the Administrator. The PAD table provides the link
between the IPsec subsystem and the group key management protocol. between the IPsec subsystem and the group key management protocol.
For automatic keying, the implementation MUST support the multicast For automatic keying, the implementation MUST support the multicast
extensions described in [I-D.ietf-msec-ipsec-extensions]. extensions described in [RFC5374].
10.2.1. SAD Entries 10.2.1. SAD Entries
All PIM routers participate in an authentication scheme that All PIM routers participate in an authentication scheme that
identifies permitted neighbors and achieves peer authentication identifies permitted neighbors and achieves peer authentication
during SA negotiation, leading to child SAs being established and during SA negotiation, leading to child SAs being established and
saved in the SAD. saved in the SAD.
10.2.2. GSPD Entries 10.2.2. GSPD Entries
The Administrator must configure the necessary GSPD entries for "send The Administrator must configure the necessary GSPD entries for "send
only" directionality. This rule MUST trigger the group key only" directionality. This rule MUST trigger the group key
management protocol for a registration exchange. This exchange will management protocol for a registration exchange. This exchange will
set up the outbound SAD entry that encrypts the multicast PIM control set up the outbound SAD entry that encrypts the multicast PIM control
message. Considering that this rule is "sender only", no inbound SA message. Considering that this rule is "sender only", no inbound SA
is created in the reverse direction. is created in the reverse direction.
In addition, the registration exchange will install GSPD entries In addition, either the registration exchange or the arrival of a
corresponding to each legitimate peer router, with direction "receive PIM-SM link-local message will trigger the installation of the GSPD
only". entries corresponding to each legitimate peer router, with direction
"receive only". Procedures for achieving the registration exchange
are out-of-scope for this document.
To account for new, legitimate neighbors, the Administrator MUST To account for new, legitimate neighbors, the Administrator MUST
configure a GSPD entry for "any" peer router, destined to the configure a GSPD entry for "any" peer router, destined to the
ALL_PIM_ROUTERS address. This entry will trigger a query to the ALL_PIM_ROUTERS address. This entry will trigger a query to the
group key management protocol, to establish the legitimacy (or lack group key management protocol, to establish the legitimacy (or lack
of it) of the new peer, and install the necessary SAD "receive only" of it) of the new peer, and (if the peer is legitimate) to install
entry. the necessary SAD "receive only" entry.
10.2.3. PAD Entries 10.2.3. PAD Entries
The PAD will be configured with information to permit identification The PAD will be configured with information to permit identification
of legitimate group members and senders. Procedures for doing this of legitimate group members and senders (i.e., to control the
are out-of-scope for this document. adjacency). Procedures for doing this are out-of-scope for this
document.
11. 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 [RFC4301] and the for the SA lookup process. According to RFC 4301 [RFC4301], for
AH specification [RFC4302], for multicast SAs, in conjunction with multicast SAs, in conjunction with the SPI, the destination address
the SPI, the destination address or the destination address plus the or the destination address plus the sender address may also be used
sender address may also be used in the SA lookup. The security in the SA lookup. This applies to both ESP and AH. The security
protocol field is not employed for a multicast SA lookup. protocol 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). address (which is shared among all the routers).
Given that it is always possible to distinguish a connection using Given that it is always possible to distinguish a connection using
IPsec from a connection not using IPsec, it is recommended that the IPsec from a connection not using IPsec, it is recommended that the
address ALL_PIM_ROUTERS be used, to maintain consistency with present address ALL_PIM_ROUTERS be used, to maintain consistency with present
practice. practice.
Given that the sender address of an incoming packet may be only Given that the sender address of an incoming packet may be only
locally unique (because of the use of link-local addresses), it will locally unique (because of the use of link-local addresses), it is
be necessary for a receiver to use the interface ID tag to sort out necessary for a receiver to use the interface ID tag to determine the
the associated SA for that sender. Therefore, this document mandates 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 (with identical SA parameters) are used for the entire only two SAs (with identical SA parameters) are used for the entire
skipping to change at page 24, line 11 skipping to change at page 26, line 11
a specific component of the selector algorithm. This is in a specific component of the selector algorithm. This is in
conformance with RFC 4301, which explicitly removes the requirement conformance with RFC 4301, which explicitly removes the requirement
for separate SADs that was present in RFC 2401 [RFC2401]. for separate SADs that was present in RFC 2401 [RFC2401].
14. Extended Sequence Number 14. Extended Sequence Number
In the [RFC4302], there is a provision for a 64-bit Extended Sequence In the [RFC4302], 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 are sent in the transmission. In other words, it will not
the present header format of AH. If ESN is used, a sender router can affect the present header format of AH. If ESN is used, a sender
send 2^64 -1 packets without any intervention. This number is very router can send 2^64 -1 packets without any intervention. This
large, and from a PIM router's point of view, a PIM router can never number is very large, and from a PIM router's point of view, a PIM
exceed this number in its lifetime. This makes it reasonable to router can never exceed this number in its lifetime. This makes it
permit manual configuration for a small number of PIM routers, since reasonable to permit manual configuration for a small number of PIM
the sequence number will never roll over. For this reason, when routers, since the sequence number will never roll over. For this
manual configuration is used, ESN SHOULD be deployed as the sequence reason, when manual configuration is used, ESN SHOULD be deployed as
number for the sliding window protocol. the sequence number for the sliding window protocol.
15. 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.
skipping to change at page 27, line 5 skipping to change at page 29, line 5
Detailed analysis of various vulnerabilities of routing protocols is Detailed analysis of various vulnerabilities of routing protocols is
provided in RFC 4593 [RFC4593]. For further discussion of PIM-SM and provided in RFC 4593 [RFC4593]. For further discussion of PIM-SM and
multicast security the reader is referred to RFC 5294 [RFC5294], RFC multicast security the reader is referred to RFC 5294 [RFC5294], RFC
4609 [RFC4609] and the Security Considerations section of RFC 4601 4609 [RFC4609] and the Security Considerations section of RFC 4601
[RFC4601]. [RFC4601].
16. IANA Considerations 16. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
17. References 17. Acknowledgements
17.1. Normative References The structure and text of this document draw heavily from RFC 4552
[RFC4552]. The authors of this document thank M. Gupta and N. Melam
for permisison to do this.
18. References
18.1. Normative References
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 27, line 29 skipping to change at page 30, line 29
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation [RFC4835] Manral, V., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4835, April 2007. Authentication Header (AH)", RFC 4835, April 2007.
[I-D.ietf-msec-ipsec-extensions] [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast
Weis, B., Gross, G., and D. Ignjatic, "Multicast
Extensions to the Security Architecture for the Internet Extensions to the Security Architecture for the Internet
Protocol", draft-ietf-msec-ipsec-extensions-09 (work in Protocol", RFC 5374, November 2008.
progress), June 2008.
17.2. Informative References 18.2. Informative References
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5
Signature Option", RFC 3562, July 2003. Signature Option", RFC 3562, July 2003.
[IslamThesis]
Islam, S., "Security Issues in PIM-SM Link-local Messages,
Master's Thesis, Concordia University", December 2003.
[IslamLCN2004]
Islam, S., "Security Issues in PIM-SM Link-local Messages,
Proceedings of LCN 2004", November 2004.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross,
"GSAKMP: Group Secure Association Key Management "GSAKMP: Group Secure Association Key Management
Protocol", RFC 4535, June 2006. Protocol", RFC 4535, June 2006.
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003. Group Domain of Interpretation", RFC 3547, July 2003.
skipping to change at page 29, line 5 skipping to change at page 31, line 27
Behringer, M. and F. Faucheur, "Applicability of Keying Behringer, M. and F. Faucheur, "Applicability of Keying
Methods for RSVP Security", Methods for RSVP Security",
draft-ietf-tsvwg-rsvp-security-groupkeying-02 (work in draft-ietf-tsvwg-rsvp-security-groupkeying-02 (work in
progress), November 2008. progress), November 2008.
[I-D.weis-gdoi-for-rsvp] [I-D.weis-gdoi-for-rsvp]
Weis, B., "Group Domain of Interpretation (GDOI) support Weis, B., "Group Domain of Interpretation (GDOI) support
for RSVP", draft-weis-gdoi-for-rsvp-01 (work in progress), for RSVP", draft-weis-gdoi-for-rsvp-01 (work in progress),
February 2008. February 2008.
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv3", RFC 4552, June 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
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
skipping to change at page 30, line 4 skipping to change at line 931
Email: Salekul.Islam@emt.inrs.ca Email: Salekul.Islam@emt.inrs.ca
URI: http://users.encs.concordia.ca/~salek_is URI: http://users.encs.concordia.ca/~salek_is
Maziar Siami Maziar Siami
Concordia University/CIISE Concordia University/CIISE
1455 de Maisonneuve Blvd, West 1455 de Maisonneuve Blvd, West
Montreal, QC H3G 1M8 Montreal, QC H3G 1M8
Canada Canada
Email: m_siamis@ciise.concordia.ca Email: m_siamis@ciise.concordia.ca
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 45 change blocks. 
147 lines changed or deleted 201 lines changed or added

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