draft-ietf-ospf-ospfv3-auth-08.txt   rfc4552.txt 
Network Working Group M. Gupta Network Working Group M. Gupta
Internet Draft Tropos Networks Request for Comments: 4552 Tropos Networks
Document: draft-ietf-ospf-ospfv3-auth-08.txt N. Melam Category: Standards Track N. Melam
Expires: Aug 2006 Juniper Networks Juniper Networks
February 2006
Authentication/Confidentiality for OSPFv3 Authentication/Confidentiality for OSPFv3
Status of this Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes means/mechanisms to provide This document specifies an Internet standards track protocol for the
authentication/confidentiality to OSPFv3 using an IPv6 AH/ESP Internet community, and requests discussion and suggestions for
Extension Header. improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Conventions used in this document Abstract
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This document describes means and mechanisms to provide
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this authentication/confidentiality to OSPFv3 using an IPv6 Authentication
document are to be interpreted as described in RFC-2119 [N7]. Header/Encapsulating Security Payload (AH/ESP) extension header.
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction ....................................................2
2. Transport Mode vs Tunnel Mode..................................3 1.1. Conventions Used in This Document ..........................2
3. Authentication.................................................3 2. Transport Mode vs. Tunnel Mode ..................................3
4. Confidentiality................................................3 3. Authentication ..................................................3
5. Distinguishing OSPFv3 from OSPFv2..............................4 4. Confidentiality .................................................3
6. IPsec Requirements.............................................4 5. Distinguishing OSPFv3 from OSPFv2 ...............................4
7. Key Management.................................................5 6. IPsec Requirements ..............................................4
8. SA Granularity and Selectors...................................7 7. Key Management ..................................................5
9. Virtual Links..................................................7 8. SA Granularity and Selectors ....................................7
10. Rekeying......................................................9 9. Virtual Links ...................................................8
10.1 Rekeying Procedure........................................9 10. Rekeying .......................................................9
10.2 KeyRolloverInterval.......................................9 10.1. Rekeying Procedure ........................................9
10.3 Rekeying Interval........................................10 10.2. KeyRolloverInterval .......................................9
11. IPsec Protection Barrier and SPD.............................10 10.3. Rekeying Interval ........................................10
12. Entropy of manual keys.......................................11 11. IPsec Protection Barrier and SPD ..............................10
13. Replay Protection............................................12 12. Entropy of Manual Keys ........................................12
Security Considerations..........................................12 13. Replay Protection .............................................12
IANA Considerations..............................................13 14. Security Considerations .......................................12
Normative References.............................................13 15. References ....................................................13
Informative References...........................................13 15.1. Normative References .....................................13
Acknowledgments..................................................14 15.2. Informative References ...................................13
Authors' Addresses...............................................14
1. Introduction 1. Introduction
OSPF (Open Shortest Path First) Version 2 [N1] defines the fields OSPF (Open Shortest Path First) Version 2 [N1] defines the fields
AuType and Authentication in its protocol header to provide security. AuType and Authentication in its protocol header to provide security.
In OSPF for IPv6 (OSPFv3) [N2], both of the authentication fields In OSPF for IPv6 (OSPFv3) [N2], both of the authentication fields
were removed from OSPF headers. OSPFv3 relies on the IPv6 were removed from OSPF headers. OSPFv3 relies on the IPv6
Authentication Header (AH) and IPv6 Encapsulating Security Payload Authentication Header (AH) and IPv6 Encapsulating Security Payload
(ESP) to provide integrity, authentication and/or confidentiality. (ESP) to provide integrity, authentication, and/or confidentiality.
This document describes how IPv6 AH/ESP extension headers can be used This document describes how IPv6 AH/ESP extension headers can be used
to provide authentication/confidentiality to OSPFv3. to provide authentication/confidentiality to OSPFv3.
It is assumed that the reader is familiar with OSPFv3 [N2], AH [N5], It is assumed that the reader is familiar with OSPFv3 [N2], AH [N5],
ESP [N4], the concept of security associations, tunnel and transport ESP [N4], the concept of security associations, tunnel and transport
mode of IPsec and the key management options available for AH and ESP mode of IPsec, and the key management options available for AH and
(manual keying [N3] and Internet Key Exchange (IKE)[I1]). ESP (manual keying [N3] and Internet Key Exchange (IKE)[I1]).
2. Transport Mode vs Tunnel Mode 1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [N7].
2. Transport Mode vs. Tunnel Mode
The transport mode Security Association (SA) is generally used The transport mode Security Association (SA) is generally used
between two hosts or routers/gateways when they are acting as hosts. between two hosts or routers/gateways when they are acting as hosts.
The SA must be a tunnel mode SA if either end of the security The SA must be a tunnel mode SA if either end of the security
association is a router/gateway. Two hosts MAY establish a tunnel association is a router/gateway. Two hosts MAY establish a tunnel
mode SA between themselves. OSPFv3 packets are exchanged between mode SA between themselves. OSPFv3 packets are exchanged between
routers. However, since the packets are locally delivered, the routers. However, since the packets are locally delivered, the
routers assume the role of hosts in the context of tunnel mode SA. routers assume the role of hosts in the context of tunnel mode SA.
All implementations confirming to this specification MUST support All implementations conforming to this specification MUST support
Transport mode SA to provide required IPsec security to OSPFv3 transport mode SA to provide required IPsec security to OSPFv3
packets. They MAY also support Tunnel mode SA to provide required packets. They MAY also support tunnel mode SA to provide required
IPsec security to OSPFv3 packets. IPsec security to OSPFv3 packets.
3. Authentication 3. Authentication
Implementations conforming to this specification MUST support Implementations conforming to this specification MUST support
Authentication for OSPFv3. authentication for OSPFv3.
In order to provide authentication to OSPFv3, implementations MUST In order to provide authentication to OSPFv3, implementations MUST
support ESP and MAY support AH. support ESP and MAY support AH.
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 OSPFv3 protocol packet excluding the IPv6 header, extension to OSPFv3 protocol packets excluding the IPv6 header, extension
headers and options. headers, and options.
If AH in transport mode is used, it will provide authentication to If AH in transport mode is used, it will provide authentication to
OSPFv3 protocol packet, selected portions of IPv6 header, selected OSPFv3 protocol packets, selected portions of IPv6 header, selected
portions of extension headers and selected options. portions of extension headers, and selected options.
When OSPFv3 authentication is enabled, When OSPFv3 authentication is enabled,
O OSPFv3 packets that are not protected with AH or ESP MUST be o OSPFv3 packets that are not protected with AH or ESP MUST be
silently discarded. silently discarded.
O OSPFv3 packets that fail the authentication checks MUST be o OSPFv3 packets that fail the authentication checks MUST be
silently discarded. silently discarded.
4. Confidentiality 4. Confidentiality
Implementations conforming to this specification SHOULD support Implementations conforming to this specification SHOULD support
confidentiality for OSPFv3. confidentiality for OSPFv3.
If confidentiality is provided, ESP MUST be used. If confidentiality is provided, ESP MUST be used.
When OSPFv3 confidentiality is enabled, When OSPFv3 confidentiality is enabled,
O OSPFv3 packets that are not protected with ESP MUST be silently
o OSPFv3 packets that are not protected with ESP MUST be silently
discarded. discarded.
O OSPFv3 packets that fail the confidentiality checks MUST be o OSPFv3 packets that fail the confidentiality checks MUST be
silently discarded. silently discarded.
5. Distinguishing OSPFv3 from OSPFv2 5. Distinguishing OSPFv3 from OSPFv2
The IP/IPv6 Protocol Type for OSPFv2 and OSPFv3 is the same (89) and The IP/IPv6 Protocol Type for OSPFv2 and OSPFv3 is the same (89), and
OSPF distinguishes them based on the OSPF header version number. OSPF distinguishes them based on the OSPF header version number.
However, current IPsec standards do not allow using arbitrary However, current IPsec standards do not allow using arbitrary
protocol specific header fields as the selectors. Therefore, the protocol-specific header fields as the selectors. Therefore, the
OSPF version field in the OSPF header cannot be used in order to OSPF version field in the OSPF header cannot be used to distinguish
distinguish OSPFv3 packets from OSPFv2 packets. As OSPFv2 is only OSPFv3 packets from OSPFv2 packets. As OSPFv2 is only for IPv4 and
for IPv4 and OSPFv3 is only for IPv6, version field in IP header can OSPFv3 is only for IPv6, the version field in the IP header can be
be used to distinguish OSPFv3 packets from OSPFv2 packets. used to distinguish OSPFv3 packets from OSPFv2 packets.
6. IPsec Requirements 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. [N3] IPsec in transport mode MUST be supported. [N3]
Multiple SPDs Multiple Security Policy Databases (SPDs)
The implementation MUST support multiple SPDs with a SPD selection The implementation MUST support multiple SPDs with an SPD
function that provides an ability to choose a specific SPD based selection function that provides an ability to choose a specific
on interface. [N3] SPD based on interface. [N3]
Selectors Selectors
The implementation MUST be able to use source address, destination The implementation MUST be able to use source address, destination
address, protocol and direction as selectors in the SPD. address, protocol, and direction as selectors in the SPD.
Interface ID tagging Interface ID tagging
The implementation MUST be able to tag the inbound packets with The implementation MUST be able to tag the inbound packets with
the ID of the interface (physical or virtual) via which it the ID of the interface (physical or virtual) via which it
arrived. [N3] arrived. [N3]
Manual key support Manual key support
Manually configured keys MUST be able to secure the specified Manually configured keys MUST be able to secure the specified
traffic. [N3] traffic. [N3]
Encryption and authentication algorithms
Encryption and Authentication Algorithms
The implementation MUST NOT allow the user to choose stream The implementation MUST NOT allow the user to choose stream
ciphers as the encryption algorithm for securing OSPFv3 packets ciphers as the encryption algorithm for securing OSPFv3 packets
since the stream ciphers are not suitable for manual keys. since the stream ciphers are not suitable for manual keys.
Except when in conflict with the above statement, the Keywords Except when in conflict with the above statement, the key words
"MUST", "MUST NOT", "REQUIRED", "SHOULD" and "SHOULD NOT" that "MUST", "MUST NOT", "REQUIRED", "SHOULD", and "SHOULD NOT" that
appear in the [N6] document for algorithms to be supported are to appear in the [N6] document for algorithms to be supported are to
be interpreted as described in [N7] for OSPFv3 support as well. be interpreted as described in [N7] for OSPFv3 support as well.
Dynamic IPsec rule configuration Dynamic IPsec rule configuration
The routing module SHOULD be able to configure, modify and delete The routing module SHOULD be able to configure, modify, and delete
IPsec rules on the fly. This is needed mainly for securing IPsec rules on the fly. This is needed mainly for securing
virtual links. virtual links.
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.
Different SAs for different DSCPs Different SAs for different Differentiated Services Code Points
(DSCPs)
As per [N3], the IPsec implementation MUST support the As per [N3], the IPsec implementation MUST support the
establishment and maintenance of multiple SAs with the same establishment and maintenance of multiple SAs with the same
selectors between a given sender and receiver. This allows the selectors between a given sender and receiver. This allows the
implementation to associate different classes of traffic with same implementation to associate different classes of traffic with the
selector values in support of QoS. same selector values in support of Quality of Service (QoS).
7. Key Management 7. Key Management
OSPFv3 exchanges both multicast and unicast packets. While running OSPFv3 exchanges both multicast and unicast packets. While running
OSPFv3 over a broadcast interface, the authentication/confidentiality OSPFv3 over a broadcast interface, the authentication/confidentiality
required is "one to many". Since IKE is based on the Diffie-Hellman required is "one to many". Since IKE is based on the Diffie-Hellman
key agreement protocol and works only for two communicating parties, key agreement protocol and works only for two communicating parties,
it is not possible to use IKE for providing the required "one to it is not possible to use IKE for providing the required "one to
many" authentication/confidentiality. This specification mandates many" authentication/confidentiality. This specification mandates
the usage of Manual Keying to work with the current IPsec the usage of Manual Keying with current IPsec implementations.
implementations. Future specifications can explore the usage of Future specifications can explore the usage of protocols like
protocols like KINK/GSAKMP when they are widely available. In manual Kerberized Internet Negotiation of Keys/Group Secure Association Key
keying, SAs are statically installed on the routers and these static Management Protocol (KINK/GSAKMP) when they are widely available. In
SAs are used to authenticate/encrypt packets. manual keying, SAs are statically installed on the routers and these
static SAs are used to authenticate/encrypt packets.
The following discussion explains that it is not scalable and is The following discussion explains that it is not scalable and is
practically infeasible to use different security associations for practically infeasible to use different security associations for
inbound and outbound traffic to provide the required "one to many" inbound and outbound traffic to provide the required "one to many"
security. Therefore, the implementations MUST use manually security. Therefore, the implementations MUST use manually
configured keys with the same SA parameters (SPI, keys etc.,) for configured keys with the same SA parameters (Security Parameter Index
both inbound and outbound SA (as shown in Figure 3). (SPI), keys, etc.) for both inbound and outbound SAs (as shown in
Figure 3).
A | A |
SAa ------------>| SAa ------------>|
SAb <------------| SAb <------------|
| |
B | B |
SAb ------------>| SAb ------------>|
SAa <------------| Figure: 1 SAa <------------| Figure 1
| |
C | C |
SAa/SAb ------------>| SAa/SAb ------------>|
SAa/SAb <------------| SAa/SAb <------------|
| |
Broadcast Broadcast
Network Network
If we consider communication between A and B in Figure 1, everything If we consider communication between A and B in Figure 1, everything
seems to be fine. A uses security association SAa for outbound seems to be fine. A uses security association SAa for outbound
packets and B uses the same for inbound packets and vice versa. Now packets and B uses the same for inbound packets and vice versa. Now
if we include C in the group and C sends a packet using SAa then only if we include C in the group and C sends a packet using SAa, then
A will be able to understand it. Similarly, if C sends a packet only A will be able to understand it. Similarly, if C sends a packet
using SAb then only B will be able to understand it. Since the using SAb, then only B will be able to understand it. Since the
packets are multicast and they are going to be processed by both A packets are multicast and they are going to be processed by both A
and B, there is no SA for C to use so that both A and B can and B, there is no SA for C to use so that both A and B can
understand them. understand them.
A | A |
SAa ------------>| SAa ------------>|
SAb <------------| SAb <------------|
SAc <------------| SAc <------------|
| |
B | B |
SAb ------------>| SAb ------------>|
SAa <------------| Figure: 2 SAa <------------| Figure 2
SAc <------------| SAc <------------|
| |
C | C |
SAc ------------>| SAc ------------>|
SAa <------------| SAa <------------|
SAb <------------| SAb <------------|
| |
Broadcast Broadcast
Network Network
The problem can be solved by configuring SAs for all the nodes on The problem can be solved by configuring SAs for all the nodes on
every other node as shown in Figure 2. So A, B and C will use SAa, every other node as shown in Figure 2. So A, B, and C will use SAa,
SAb and SAc respectively for outbound traffic. Each node will lookup SAb, and SAc, respectively, for outbound traffic. Each node will
the SA to be used based on the source (A will use SAb and SAc for lookup the SA to be used based on the source (A will use SAb and SAc
packets received from B and C respectively). This solution is not for packets received from B and C, respectively). This solution is
scalable and practically infeasible because a large number of SAs not scalable and practically infeasible because a large number of SAs
will need to be configured on each node. Also, the addition of a will need to be configured on each node. Also, the addition of a
node in the broadcast network will require the addition of another SA node in the broadcast network will require the addition of another SA
on every other node. on every other node.
A | A |
SAo ------------>| SAo ------------>|
SAi <------------| SAi <------------|
| |
B | B |
SAo ------------>| SAo ------------>|
SAi <------------| Figure: 3 SAi <------------| Figure 3
| |
C | C |
SAo ------------>| SAo ------------>|
SAi <------------| SAi <------------|
| |
Broadcast Broadcast
Network Network
The problem can be solved by using the same SA parameters (SPI, Keys The problem can be solved by using the same SA parameters (SPI, keys,
etc.,) for both inbound (SAi) and outbound (SAo) SAs as shown in etc.) for both inbound (SAi) and outbound (SAo) SAs as shown in
Figure 3. Figure 3.
8. SA Granularity and Selectors 8. SA Granularity and Selectors
The user SHOULD be given the choice of sharing the same SA among The user SHOULD be given the choice of sharing the same SA among
multiple interfaces or using a unique SA per interface. multiple interfaces or using a unique SA per interface.
OSPFv3 supports running multiple instances over one interface using OSPFv3 supports running multiple instances over one interface using
the "Instance Id" field contained in the OSPFv3 header. As IPsec the "Instance Id" field contained in the OSPFv3 header. As IPsec
does not support arbitrary fields in protocol header to be used as does not support arbitrary fields in the protocol header to be used
the selectors, it is not possible to use different SAs for different as the selectors, it is not possible to use different SAs for
OSPFv3 instances running over the same interface. Therefore, all different OSPFv3 instances running over the same interface.
OSPFv3 instances running over the same interface will have to use the Therefore, all OSPFv3 instances running over the same interface will
same SA. In OSPFv3 RFC terminology, SAs are per-link and not per- have to use the same SA. In OSPFv3 RFC terminology, SAs are per-link
interface. and not per-interface.
9. Virtual Links 9. Virtual Links
A different SA than the SA of the underlying interface MUST be A different SA than the SA of the underlying interface MUST be
provided for virtual links. Packets sent on virtual links use provided for virtual links. Packets sent on virtual links use
unicast non-link local IPv6 addresses as the IPv6 source address unicast non-link local IPv6 addresses as the IPv6 source address,
while packets sent on other interfaces use multicast and unicast link while packets sent on other interfaces use multicast and unicast link
local addresses. This difference in the IPv6 source address local addresses. This difference in the IPv6 source address
differentiates the packets sent on virtual links from other OSPFv3 differentiates the packets sent on virtual links from other OSPFv3
interface types. interface types.
As the virtual link end point IPv6 addresses are not known, it is not As the virtual link end point IPv6 addresses are not known, it is not
possible to install SPD/SAD entries at the time of configuration. possible to install SPD/Security Association Database (SAD) entries
The virtual link end point IPv6 addresses are learned during the at the time of configuration. The virtual link end point IPv6
routing table computation process. The packet exchange over the addresses are learned during the routing table computation process.
virtual links starts only after the discovery of the end point IPv6 The packet exchange over the virtual links starts only after the
addresses. In order to protect these exchanges, the routing module discovery of the end point IPv6 addresses. In order to protect these
must install the corresponding SPD/SAD entries before starting these exchanges, the routing module must install the corresponding SPD/SAD
exchanges. Note that manual SA parameters are preconfigured but not entries before starting these exchanges. Note that manual SA
installed in the SAD until the end point addresses are learned. parameters are preconfigured but not installed in the SAD until the
end point addresses are learned.
According to the OSPFv3 RFC [N2], the virtual neighbor's IP address According to the OSPFv3 RFC [N2], the virtual neighbor's IP address
is set to the first prefix with the "LA-bit" set from the list of is set to the first prefix with the "LA-bit" set from the list of
prefixes in intra-area-prefix-LSAs originated by the virtual prefixes in intra-area-prefix-Link State Advertisements (LSAs)
neighbor. But when it comes to choosing the source address for the originated by the virtual neighbor. But when it comes to choosing
packets that are sent over the virtual link, the RFC simply suggests the source address for the packets that are sent over the virtual
using one of the router's own global IPv6 addresses. In order to link, the RFC [N2] simply suggests using one of the router's own
install the required security rules for virtual links, the source global IPv6 addresses. In order to install the required security
address also needs to be predictable. Hence, routers that implement rules for virtual links, the source address also needs to be
this specification MUST change the way the source and destination predictable. Hence, routers that implement this specification MUST
addresses are chosen for packets exchanged over virtual links when change the way the source and destination addresses are chosen for
IPsec is enabled. packets exchanged over virtual links when IPsec is enabled.
The first IPv6 address with the "LA-bit" set in the list of prefixes The first IPv6 address with the "LA-bit" set in the list of prefixes
advertised in intra-area-prefix-LSAs in the transit area MUST be used advertised in intra-area-prefix-LSAs in the transit area MUST be used
as the source address for packets exchanged over the virtual link. as the source address for packets exchanged over the virtual link.
When multiple intra-area-prefix-LSAs are originated they are When multiple intra-area-prefix-LSAs are originated, they are
considered as being concatenated and are ordered by ascending Link considered concatenated and are ordered by ascending Link State ID.
State ID.
The first IPv6 address with the "LA-bit" set in the list of prefixes The first IPv6 address with the "LA-bit" set in the list of prefixes
received in intra-area-prefix-LSAs from the virtual neighbor in the received in intra-area-prefix-LSAs from the virtual neighbor in the
transit area MUST be used as the destination address for packets transit area MUST be used as the destination address for packets
exchanged over the virtual link. When multiple intra-area-prefix- exchanged over the virtual link. When multiple intra-area-prefix-
LSAs are received they are considered as being concatenated and are LSAs are received, they are considered concatenated and are ordered
ordered by ascending Link State ID. by ascending Link State ID.
This makes both the source and destination addresses of packets This makes both the source and destination addresses of packets
exchanged over the virtual link predictable when IPsec is enabled. exchanged over the virtual link predictable when IPsec is enabled.
10. Rekeying 10. 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 from periodically. key values SHOULD be changed periodically.
10.1 Rekeying Procedure 10.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 OSPFv3 protocol packets or routers on a link without dropping OSPFv3 protocol packets or
disrupting the adjacency. disrupting the adjacency.
(1) For every router on the link, create an additional inbound SA for (1) For every router on the link, create an additional inbound SA for
the interface being rekeyed using a new SPI and the new key. the interface being rekeyed using a new SPI and the new key.
(2) For every router on the link, replace the original outbound SA (2) For every router on the link, replace the original outbound SA
with one using the new SPI and key values. The SA replacement with one using the new SPI and key values. The SA replacement
skipping to change at page 9, line 45 skipping to change at page 9, line 45
it waits for this interval and then moves to step 3. it waits for this interval and then moves to step 3.
In order to achieve smooth key transition, all routers on a link In order to achieve smooth key transition, all routers on a link
should use the same value for KeyRolloverInterval and should initiate should use the same value for KeyRolloverInterval and should initiate
the key rollover process within this time period. the key rollover process within this time period.
At the end of this procedure, all the routers on the link will have a At the end of this procedure, all the routers on the link will have a
single inbound and outbound SA for OSPFv3 with the new SPI and key single inbound and outbound SA for OSPFv3 with the new SPI and key
values. values.
10.2 KeyRolloverInterval 10.2. KeyRolloverInterval
The configured value of KeyRolloverInterval should be long enough to The configured value of KeyRolloverInterval should be long enough to
allow the administrator to change keys on all the OSPFv3 routers. As allow the administrator to change keys on all the OSPFv3 routers. As
this value can vary significantly depending upon the implementation this value can vary significantly depending upon the implementation
and the deployment, it is left to the administrator to choose the and the deployment, it is left to the administrator to choose an
appropriate value. appropriate value.
10.3 Rekeying Interval 10.3. Rekeying Interval
This section analyzes the security provided by manual keying and This section analyzes the security provided by manual keying and
recommends that the encryption and authentication keys SHOULD be recommends that the encryption and authentication keys SHOULD be
changed at least every 90 days. changed at least every 90 days.
The weakest security provided by the security mechanisms discussed in The weakest security provided by the security mechanisms discussed in
this specification is when NULL encryption (for ESP) or no encryption this specification is when NULL encryption (for ESP) or no encryption
(for AH) is used with the HMAC-MD5 authentication. Any other (for AH) is used with the HMAC-MD5 authentication. Any other
algorithm combinations will at least be as hard to break as the ones algorithm combinations will at least be as hard to break as the ones
mentioned above. This is shown by the following reasonable mentioned above. This is shown by the following reasonable
assumptions: assumptions:
O NULL Encryption and HMAC-SHA-1 Authentication will be more secure o NULL Encryption and HMAC-SHA-1 Authentication will be more
as HMAC-SHA-1 is considered to be more secure than HMAC-MD5. secure as HMAC-SHA-1 is considered to be more secure than
HMAC-MD5.
O NON-NULL Encryption and NULL Authentication is not applicable as o NON-NULL Encryption and NULL Authentication combination is not
this specification mandates authentication when OSPFv3 security is applicable as this specification mandates authentication when
enabled. OSPFv3 security is enabled.
O DES Encryption and HMAC-MD5 Authentication will be more secure o Data Encryption Security (DES) Encryption and HMAC-MD5
because of the additional security provided by DES. Authentication will be more secure because of the additional
security provided by DES.
O Other encryption algorithms like 3DES and AES will be more secure o Other encryption algorithms like 3DES and the Advanced
than DES. Encryption Standard (AES) will be more secure than DES.
RFC 3562 [I4] analyzes the rekeying requirements for the TCP MD5 RFC 3562 [I4] analyzes the rekeying requirements for the TCP MD5
signature option. The analysis provided in this RFC 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.
11. IPsec Protection Barrier and SPD 11. IPsec Protection Barrier and SPD
The IPsec protection barrier MUST BE around the OSPF protocol. The IPsec protection barrier MUST be around the OSPF protocol.
Therefore, all the inbound and outbound OSPF traffic goes through Therefore, all the inbound and outbound OSPF traffic goes through
IPsec processing. IPsec processing.
The SPD selection function MUST return a SPD with the following rule The SPD selection function MUST return an SPD with the following rule
for all the interfaces that have OSPFv3 for all the interfaces that have OSPFv3
authentication/confidentiality disabled. authentication/confidentiality disabled.
No. source destination protocol action No. source destination protocol action
1 any any OSPF bypass 1 any any OSPF bypass
The SPD selection function MUST return an SPD with the following
The SPD selection function MUST return a SPD with the following rules rules for all the interfaces that have OSPFv3
for all the interfaces that have OSPFv3
authentication/confidentiality enabled. authentication/confidentiality enabled.
No. source destination protocol action No. source destination protocol action
2 fe80::/10 any OSPF protect 2 fe80::/10 any OSPF protect
3 fe80::/10 any ESP/OSPF or AH/OSPF protect 3 fe80::/10 any ESP/OSPF or AH/OSPF protect
4 src/128 dst/128 OSPF protect 4 src/128 dst/128 OSPF protect
5 src/128 dst/128 ESP/OSPF or AH/OSPF protect 5 src/128 dst/128 ESP/OSPF or AH/OSPF protect
For rules 2 and 4, action "protect" means encrypting/calculating ICV For rules 2 and 4, action "protect" means encrypting/calculating
and adding an ESP or AH header. For rules 3 and 5, action "protect" Integrity Check Value (ICV) and adding an ESP or AH header. For
means decrypting/authenticating the packets and stripping the ESP or rules 3 and 5, action "protect" means decrypting/authenticating the
AH header. packets and stripping the ESP or AH header.
Rule 1 will bypass the OSPFv3 packets without any IPsec processing on Rule 1 will bypass the OSPFv3 packets without any IPsec processing on
the interfaces that have OSPFv3 authentication/confidentiality the interfaces that have OSPFv3 authentication/confidentiality
disabled. disabled.
Rules 2 and 4 will drop the inbound OSPFv3 packets that have not been Rules 2 and 4 will drop the inbound OSPFv3 packets that have not been
secured with ESP/AH headers. secured with ESP/AH headers.
ESP/OSPF or AH/OSPF in rules 3 and 5 mean that it is an OSPF packet ESP/OSPF or AH/OSPF in rules 3 and 5 mean that it is an OSPF packet
secured with ESP or AH. secured with ESP or AH.
skipping to change at page 11, line 35 skipping to change at page 11, line 40
packets that are not being exchanged over the virtual links. packets that are not being exchanged over the virtual links.
Rules 4 and 5 are meant to secure the packets being exchanged over Rules 4 and 5 are meant to secure the packets being exchanged over
virtual links. These rules are installed after learning the virtual virtual links. These rules are installed after learning the virtual
link end point IPv6 addresses. These rules MUST be installed in the link end point IPv6 addresses. These rules MUST be installed in the
SPD for the interfaces that are connected to the transit area for the SPD for the interfaces that are connected to the transit area for the
virtual link. These rules MAY alternatively be installed on all the virtual link. These rules MAY alternatively be installed on all the
interfaces. If these rules are not installed on all the interfaces, interfaces. If these rules are not installed on all the interfaces,
clear text or malicious OSPFv3 packets with the same source and clear text or malicious OSPFv3 packets with the same source and
destination addresses as the virtual link end point IPv6 addresses destination addresses as the virtual link end point IPv6 addresses
will be delivered to OSPFv3. Though OSPFv3 drops these packets will be delivered to OSPFv3. Though OSPFv3 drops these packets as
because they were not received on the right interface, OSPFv3 they were not received on the right interface, OSPFv3 receives some
receives some clear text or malicious packets even when the security clear text or malicious packets even when the security is enabled.
is enabled. Installing these rules on all the interfaces insures Installing these rules on all the interfaces ensures that OSPFv3 does
that OSPFv3 does not receive these clear text or malicious packets not receive these clear text or malicious packets when security is
when security is turned enabled. On the other hand, installing these enabled. On the other hand, installing these rules on all the
rules on all the interfaces increases the processing overhead on the interfaces increases the processing overhead on the interfaces where
interfaces where there is no other IPsec processing. The decision of there is no other IPsec processing. The decision of whether to
installing these rules on all the interfaces or on just the install these rules on all the interfaces or on just the interfaces
interfaces that are connected to the transit area is a private that are connected to the transit area is a private decision and
decision and doesn't affect the interoperability in any way. Hence doesn't affect the interoperability in any way. Hence it is an
it is an implementation choice. implementation choice.
12. Entropy of Manual Keys
12. Entropy of manual keys
The implementations MUST allow the administrator to configure the The implementations MUST allow the administrator to configure the
cryptographic and authentication keys in hexadecimal format rather cryptographic and authentication keys in hexadecimal format rather
than restricting it to a subset of ASCII characters (letters, numbers than restricting it to a subset of ASCII characters (letters,
etc). A restricted character set will reduce key entropy numbers, etc.). A restricted character set will reduce key entropy
significantly as discussed in [I2]. significantly as discussed in [I2].
13. Replay Protection 13. Replay Protection
Since it is not possible using the current standards to provide Since it is not possible using the current standards to provide
complete replay protection while using manual keying, the proposed complete replay protection while using manual keying, the proposed
solution will not provide protection against replay attacks. solution will not provide protection against replay attacks.
Detailed analysis of various vulnerabilities of the routing protocols Detailed analysis of various vulnerabilities of the routing protocols
and OSPF in particular is discussed in [I3] and [I2]. The conclusion and OSPF in particular is discussed in [I3] and [I2]. The conclusion
is that "Replay of OSPF packets can cause adjacencies to be is that replay of OSPF packets can cause adjacencies to be disrupted,
disrupted, which can lead to a DoS attack on the network. It can also which can lead to a DoS attack on the network. It can also cause
cause database exchange process to occur continuously thus causing database exchange process to occur continuously thus causing CPU
CPU overload as well as micro loops in the network". overload as well as micro loops in the network.
Security Considerations 14. Security Considerations
This memo discusses the use of IPsec AH and ESP headers in order to This memo discusses the use of IPsec AH and ESP headers to provide
provide security to OSPFv3 for IPv6. Hence security permeates security to OSPFv3 for IPv6. Hence, security permeates throughout
throughout this document. this document.
OSPF Security Vulnerabilities Analysis [I2] identifies OSPF OSPF Security Vulnerabilities Analysis [I2] identifies OSPF
vulnerabilities in two scenarios - One with no authentication or vulnerabilities in two scenarios -- one with no authentication or
simple password authentication and the other with cryptographic simple password authentication and the other with cryptographic
authentication. The solution described in this specification authentication. The solution described in this specification
provides protection against all the vulnerabilities identified for provides protection against all the vulnerabilities identified for
scenarios with cryptographic authentication with the following scenarios with cryptographic authentication with the following
exceptions: exceptions:
Limitations of manual key: Limitations of manual key:
This specification mandates the usage of manual keys. The following This specification mandates the usage of manual keys. The following
are the known limitations of the usage of manual keys. are the known limitations of the usage of manual keys.
O As the sequence numbers can not be negotiated, replay protection o As the sequence numbers cannot be negotiated, replay protection
can not be provided. This leaves OSPF insecure against all the can not be provided. This leaves OSPF insecure against all the
attacks that can be performed by replaying OSPF packets. attacks that can be performed by replaying OSPF packets.
O Manual keys are usually long lived (changing them often is o Manual keys are usually long lived (changing them often is a
a tedious task). This gives an attacker enough time to discover tedious task). This gives an attacker enough time to discover
the keys. the keys.
O As the administrator is manually configuring the keys, there is o As the administrator is manually configuring the keys, there is
a chance that the configured keys are weak (there are known weak a chance that the configured keys are weak (there are known
keys for DES/3DES at least). weak keys for DES/3DES at least).
Impersonating Attacks: Impersonating attacks:
The usage of the same key on all the OSPF routers connected to a link The usage of the same key on all the OSPF routers connected to a link
leaves them all insecure against impersonating attacks if any one of leaves them all insecure against impersonating attacks if any one of
the OSPF routers is compromised, malfunctioning or misconfigured. the OSPF routers is compromised, malfunctioning, or misconfigured.
Detailed analysis of various vulnerabilities of routing protocols is Detailed analysis of various vulnerabilities of routing protocols is
discussed in [I3]. discussed in [I3].
IANA Considerations 15. References
This document has no IANA considerations.
This section should be removed by the RFC Editor to final
publication.
Normative References 15.1. Normative References
N1. Moy, J., "OSPF version 2", RFC 2328, April 1998. [N1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
N2. Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6", RFC 2740, [N2] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740,
December 1999. December 1999.
N3. Kent, S. and K. Seo, "Security Architecture for the Internet [N3] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005. Protocol", RFC 4301, December 2005.
N4. Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, [N4] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
December 2005. December 2005.
N5. Kent, S., "IP Authentication Header (AH)", RFC 4302, December [N5] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
2005.
N6. Eastlake, D., "Cryptographic Algorithm Implementation Requirements
For ESP And AH", RFC 4305, December 2005.
N7. Bradner, S., "Key words for use in RFCs to Indicate Requirement
Level", BCP 14, RFC 2119, March 1997.
N8. Frankel, S., Glenn, R. and S. Kelly, "The AES-CBC Cipher Algorithm [N6] Eastlake 3rd, D., "Cryptographic Algorithm Implementation
and Its Use with IPsec", RFC 3602, September 2003. Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4305, December 2005.
N9. Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and [N7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
AH", RFC 2404, November 1998. Levels", BCP 14, RFC 2119, March 1997.
Informative References 15.2. Informative References
I1. Kaufman, C., "The Internet Key Exchange (IKEv2) Protocol", RFC [I1] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
4306, December 2005. December 2005.
I2. Jones, E. and O. Moigne, "OSPF Security Vulnerabilities Analysis", [I2] Jones, E. and O. Moigne, "OSPF Security Vulnerabilities
draft-ietf-rpsec-ospf-vuln-01.txt, work in progress. Analysis", Work in Progress.
I3. Barbir, A., Murphy, S. and Y. Yang, "Generic Threats to Routing [I3] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing
Protocols", draft-ietf-rpsec-routing-threats-07.txt, work in Protocols", Work in Progress.
progress.
I4. Leech, M., "Key Management Considerations for the TCP MD5 [I4] Leech, M., "Key Management Considerations for the TCP MD5
Signature Option", RFC 3562, July 2003. Signature Option", RFC 3562, July 2003.
Acknowledgments Acknowledgements
Authors would like to extend sincere thanks to Marc Solsona, Janne The authors would like to extend sincere thanks to Marc Solsona,
Peltonen, John Cruz, Dhaval Shah, Abhay Roy, Paul Wells, Vishwas Janne Peltonen, John Cruz, Dhaval Shah, Abhay Roy, Paul Wells,
Manral and Sam Hartman for providing useful information and critiques Vishwas Manral, and Sam Hartman for providing useful information and
in order to write this memo. Authors would like to extend special critiques on this memo. The authors would like to extend special
thanks to Acee Lindem for lots of editorial changes. thanks to Acee Lindem for many editorial changes.
We would also like to thank IPsec and OSPF WG people to provide We would also like to thank members of the IPsec and OSPF WG for
valuable review comments. providing valuable review comments.
Authors' Addresses Authors' Addresses
Mukesh Gupta Mukesh Gupta
Tropos Networks Tropos Networks
555 Del Rey Ave 555 Del Rey Ave
Sunnyvale, CA 94085 Sunnyvale, CA 94085
Phone: 408-331-6889 Phone: 408-331-6889
Email: mukesh.gupta@tropos.com EMail: mukesh.gupta@tropos.com
Nagavenkata Suresh Melam Nagavenkata Suresh Melam
Juniper Networks Juniper Networks
1194 N. Mathilda Ave 1194 N. Mathilda Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Phone: 408-505-4392 Phone: 408-505-4392
Email: nmelam@juniper.net EMail: nmelam@juniper.net
Full copyright statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
skipping to change at page 15, line 23 skipping to change at page 15, line 37
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
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. The IETF invites any interested party to http://www.ietf.org/ipr.
bring to its attention any copyrights, patents or patent
applications, or other proprietary rights that may cover technology The IETF invites any interested party to bring to its attention any
that may be required to implement this standard. Please address the copyrights, patents or patent applications, or other proprietary
information to the IETF at ietf-ipr@ietf.org. 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.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 93 change blocks. 
241 lines changed or deleted 224 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/