draft-ietf-ospf-ospfv3-auth-04.txt   draft-ietf-ospf-ospfv3-auth-05.txt 
Network Working Group M. Gupta Network Working Group M. Gupta
Internet Draft Nokia Internet Draft Nokia
Document: draft-ietf-ospf-ospfv3-auth-04.txt N. Melam Document: draft-ietf-ospf-ospfv3-auth-05.txt N. Melam
Expires: June 2004 Nokia Expires: April 2005 Nokia
December 2003 October 2004
Authentication/Confidentiality for OSPFv3 Authentication/Confidentiality for OSPFv3
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of section 10 of RFC2026. 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 RFC 3668.
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."
skipping to change at page 1, line 28 skipping to change at page 1, line 29
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.
Abstract Abstract
This document describes means/mechanisms to provide This document describes means/mechanisms to provide
authentication/confidentiality to OSPFv3 using IPv6 AH/ESP Extension authentication/confidentiality to OSPFv3 using an IPv6 AH/ESP
Header. Extension Header.
Copyright Notice
Copyright (C) The Internet Society. (2004)
Conventions used in this document Conventions used in this document
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 [N5]. document are to be interpreted as described in RFC-2119 [N7].
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction...................................................2
2. OSPFv2 to OSPFv3...............................................2 2. Transport Mode vs Tunnel Mode..................................2
3. Authentication.................................................2 3. Authentication.................................................3
4. Confidentiality................................................3 4. Confidentiality................................................3
5. IPsec Requirements.............................................3 5. Distinguishing OSPFv3 from OSPFv2..............................4
6. Key Management.................................................4 6. IPsec Requirements.............................................4
7. SA Granularity and Selectors...................................5 7. Key Management.................................................4
8. Virtual Links..................................................5 8. SA Granularity and Selectors...................................6
9. Changing Keys..................................................6 9. Virtual Links..................................................7
10. IPsec rules...................................................7 10. Changing Keys.................................................8
11. Replay Protection.............................................8 11. IPsec rules...................................................8
Security Considerations...........................................8 12. Mandatory Encryption and Authentication Algorithms...........10
Normative References..............................................8 13. Replay Protection............................................10
Informative References............................................9 Security Considerations..........................................10
Acknowledgments...................................................9 Normative References.............................................11
Authors' Addresses................................................9 Informative References...........................................11
Acknowledgments..................................................11
Authors' Addresses...............................................12
1. Introduction 1. Introduction
In Open Shortest Path First - Version 3 (OSPFv3) for IPv6, OSPF (Open Shortest Path First) Version 2 [N1] defines fields AuType
authentication fields have been removed from OSPF headers. When and Authentication in its protocol header in order to provide
running over IPv6, OSPF relies on the IPv6 Authentication Header (AH) security. In OSPF for IPv6 (OSPFv3) [N2], both of the authentication
and IPv6 Encapsulating Security Payload (ESP) to ensure integrity, fields were removed from OSPF headers. OSPFv3 relies on the
authentication and/or confidentiality of routing exchanges. IPv6 Authentication Header (AH) and IPv6 Encapsulating Security
Payload (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 [N1], AH [N4], It is assumed that the reader is familiar with OSPFv3 [N2], AH [N5],
ESP [N3], 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 ESP
(manual keying [N2] and Internet Key Exchange (IKE)[I1]). (manual keying [N3] and Internet Key Exchange (IKE)[I1]).
2. OSPFv2 to OSPFv3
Security concerns MUST be taken away from OSPFv3 protocol and IPv6
stack MUST provide inherent security to OSPFv3 by using AH/ESP
extension headers. It means OSPFv3 protocol MUST NOT receive any
unauthenticated packets. As OSPFv2 has its own security mechanisms,
no inherent security needs to be provided by the IPv4 stack. As
OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, the distinction
between the packets can be easily made by IP version.
Authentication and confidentiality, if provided, MUST be provided to
the entire OSPFv3 header and data. Authentication to the selected
portions of IPv6 header, selected portions of extension headers and
selected options MAY also be provided optionally.
3. Authentication 2. Transport Mode vs Tunnel Mode
Transport mode Security Association (SA) is the security association Transport mode Security Association (SA) is the security association
between two hosts or security gateways that are acting as hosts. SA between two hosts or routers/gateways when they are acting as hosts.
must be tunnel mode if either end of the security association is a SA must be tunnel mode if either end of the security association is a
security gateway. OSPFv3 packets are exchanged between the routers router/gateway. OSPFv3 packets are exchanged between the routers but
but as the packets are destined to the routers, the routers act like as the packets are destined to the routers, the routers act like
hosts in this case. So transport mode SA MUST be used in order to hosts in this case. So transport mode SA MUST be used in order to
provide required security to OSPFv3. provide required security to OSPFv3.
In order to support OSPFv3 authentication, "ESP with NULL encryption" 3. Authentication
MUST be supported in transport mode. "AH" in transport mode SHOULD
also be provided. AH in transport mode provides authentication to
higher layer protocols, selected portions of IPv6 header, selected
portions of extension headers and selected options. ESP with NULL
encryption in transport mode will provide authentication to only
higher layer protocol data and not to the IPv6 header, extension
headers and options.
OSPF packets received in clear text or with incorrect AH Integrity Implementations conforming to this specification MUST support
Check Value (ICV) MUST be dropped when authentication is enabled. Authentication for OSPFv3.
In order to provide authentication to OSPFv3, "ESP with NULL
encryption" MUST be supported and AH SHOULD be supported by the
implementation.
If "ESP with NULL encryption" in transport mode is used, it will
provide authentication to only OSPFv3 protocol headers but not to the
IPv6 header, extension headers and options.
If AH in transport mode is used, it will provide authentication to
OSPFv3 protocol headers, selected portions of IPv6 header, selected
portions of extension headers and selected options.
When OSPFv3 authentication is enabled,
O OSPFv3 packets that are not protected with AH or ESP MUST be
silently discarded.
O OSPFv3 packets that fail the authentication checks MUST be
silently discarded.
4. Confidentiality 4. Confidentiality
Providing confidentiality to OSPFv3 in addition to authentication is Implementations conforming to this specification SHOULD support
optional. Confidentiality must be implemented using ESP extension confidentiality for OSPFv3.
header of IPv6 if it is being provided. ESP with non-null encryption
in transport mode MUST be used for providing the confidentiality to
OSPFv3. The user MUST be able to configure the encryption key and
the authentication key separately.
5. IPsec Requirements If confidentiality is provided, "ESP with non-null encryption" MUST
be used.
When OSPFv3 confidentiality is enabled,
O OSPFv3 packets that are not protected with ESP MUST be silently
discarded.
O OSPFv3 packets that fail the confidentiality checks MUST be
silently discarded.
5. Distinguishing OSPFv3 from OSPFv2
The IP/IPv6 Protocol Type for OSPFv2 and OSPFv3 is same (89) and
OSPF distinguishes them based on the OSPF header version number.
However current IPsec standards do not allow using arbitrary protocol
specific header fields as the selectors. Therefore, in order to
distinguish OSPFv3 packets from the OSPFv2 packets, OSPF version
field in the OSPF header cannot be used. As OSPFv2 is only for IPv4
and OSPFv3 is only for IPv6, version field in IP header can be used
to distinguish OSPFv3 packets from OSPFv2 packets.
6. IPsec Requirements
In order to implement this specification, the following IPsec In order to implement this specification, the following IPsec
capabilities are required. capabilities are required.
Transport Mode Transport Mode
IPsec in transport mode MUST be supported. IPsec in transport mode MUST be supported. [N3]
Traffic Selectors Traffic Selectors
The implementation MUST be able to use interface index, source The implementation MUST be able to use interface index, source
address, destination address, protocol and direction for choosing address, destination address, protocol and direction for choosing
the right security action. the right security action.
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. traffic. [N3]
Encryption and Authentication Algorithms Encryption and Authentication Algorithms
The implementations MUST be conformant to the RFCs that describe AES-CBC and HMAC-SHA1 MUST be supported as the encryption and the
mandatory-to-implement algorithms for use with ESP and AH. authentication algorithms respectively. [N6]
Dynamic IPsec rule configuration Dynamic IPsec rule configuration
Routing module SHOULD be able to configure, modify and delete 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.
6. 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. Manual keying MUST be used for many" authentication/confidentiality. Manual keying MUST be used for
this purpose. In manual keying SAs are statically installed on the this purpose. In manual keying SAs are statically installed on the
routers and these static SAs are used to encrypt/authenticate the routers and these static SAs are used to authenticate/encrypt the
data. packets.
As security associations (SAs) are directional, generally different The following discussion explains that it is not scalable and
security associations are used for inbound and outbound processing practically infeasible to use different security associations for
for providing higher security. The following figure explains that it inbound and outbound traffic in order to provide the required "one to
is not possible to use different security associations for inbound many" security. Therefore, the implementations MUST use manually
and outbound processing in order to provide the required "one to configured keys with same SA for inbound and outbound traffic (as
many" security. shown in Figure 3).
A | A |
SAa ------------>| SAa ------------>|
SAb <------------| SAb <------------|
| |
B | B |
SAb ------------>| SAb ------------>|
SAa <------------| 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 the above diagram, If we consider communication between A and B in Figure 1, everything
everything seems to be fine. A uses security association SAa for seems to be fine. A uses security association SAa for outbound
outgoing packets and B uses the same for incoming packets and vice packets and B uses the same for inbound packets and vice versa. Now
versa. Now if we include C in the group and C sends a packet out if we include C in the group and C sends a packet out using SAa then
using SAa then only A will be able to understand it or if C sends the only A will be able to understand it or if C sends the packets out
packets out using SAb then only B will be able to understand it. using SAb then only B will be able to understand it. Since the
Since the packets are multicast packets and they are going to be packets are multicast packets and they are going to be processed by
processed by both A and B, there is no SA for C to use so that A and both A and B, there is no SA for C to use so that A and B both can
B both can understand it. understand it.
The problem can be solved with the following figure where all of them A |
use the same SA for incoming and outgoing direction. SAa ------------>|
SAb <------------|
SAc <------------|
|
B |
SAb ------------>|
SAa <------------| Figure: 2
SAc <------------|
|
C |
SAc ------------>|
SAa <------------|
SAb <------------|
|
Broadcast
Network
The problem can be solved by configuring SAs for all the nodes on all
the nodes as shown in Figure 2. So A, B and C will use SAa, SAb and
SAc respectively for outbound traffic. Each node will lookup the SA
to be used based on the source (A will use SAb and SAc for packets
received from B and C respectively). This solution is not scalable
and practically infeasible because every node will need to be
configured with a large number of SAs and addition of a node in the
network will cause addition of another SA on all the nodes.
A | A |
SAs ------------>| SAs ------------>|
SAs <------------| SAs <------------|
| |
B | B |
SAs ------------>| SAs ------------>|
SAs <------------| SAs <------------| Figure: 3
| |
C | C |
SAs ------------>| SAs ------------>|
SAs <------------| SAs <------------|
|
Broadcast Broadcast
Network Network
So, all the neighbor routers on a network/subnet MUST use the same SA The problem can also be solved by using the same SA for inbound and
and the same SA MUST be used for inbound and outbound processing. outbound traffic as shown in Figure 3.
7. SA Granularity and Selectors 8. SA Granularity and Selectors
The user SHOULD be given a choice to share the same SA among multiple The user SHOULD be given a choice to share the same SA among multiple
interfaces or using unique SA per interface. interfaces or using unique SA per interface.
8. Virtual Links OSPFv3 supports running multiple instances over one interface using
the "Instance Id" field contained in the OSPFv3 header. As IPsec
does not support arbitrary fields in protocol header to be used as
the selectors, it is not possible to use different SAs for different
instances of OSPFv3 running over the same interface. Therefore, all
the instances of OSPFv3 running over the same interface will have to
use the same SA. In OSPFv3 RFC terminology, SAs are per-link and not
per-interface.
9. Virtual Links
Different SA than the SA of underlying interface MUST be provided for Different SA than the SA of underlying interface MUST be provided for
virtual links. Packets sent out on virtual links use unicast site- virtual links. Packets sent out on virtual links use unicast non-
local or global IPv6 addresses as the IPv6 source address and all the link local IPv6 addresses as the IPv6 source address and all the
other packets use multicast and unicast link local addresses. This other packets use multicast and unicast link local addresses. This
difference in the IPv6 source address is used in order to difference in the IPv6 source address is used in order to
differentiate the packets sent on interfaces and virtual links. differentiate the packets sent on interfaces and virtual links.
As the end point IP addresses of the virtual links are not known at As the end point IP addresses of the virtual links are not known at
the time of configuration, the secure channel for these packets needs the time of configuration, the secure channel for these packets needs
to be set up dynamically. The end point IP addresses of virtual to be set up dynamically. The end point IP addresses of virtual
links are learnt during the routing table build up process. The links are learned during the routing table build up process. The
packet exchange over the virtual links starts only after the packet exchange over the virtual links starts only after the
discovery of end point IP addresses. In order to provide security to discovery of end point IP addresses. In order to provide security to
these exchanges, the routing module should setup a secure IPsec these exchanges, the routing module should setup a secure IPsec
channel dynamically once it acquires the required information. channel dynamically once it acquires the required information.
According to the OSPFv3 RFC [N1], 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-LSAs originated by the virtual
neighbor. But when it comes to choosing the source address for the neighbor. But when it comes to choosing the source address for the
packets that are sent over the virtual link, the RFC simply suggests packets that are sent over the virtual link, the RFC simply suggests
using one of the router's own site-local or global IPv6 addresses. using one of the router's own site-local or global IPv6 addresses.
In order to install the required security rules for virtual links, In order to install the required security rules for virtual links,
the source address also needs to be predictable. So the routers that the source address also needs to be predictable. So the routers that
implement this specification MUST change the way the source and implement this specification MUST change the way the source and
destination addresses are chosen for the packets exchanged over destination addresses are chosen for the packets exchanged over
virtual links when the security is enabled on that virtual link. virtual links when the security is enabled on that virtual link.
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
skipping to change at page 6, line 29 skipping to change at page 8, line 9
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 as being concatenated and are
ordered by ascending Link State ID. ordered by ascending Link State ID.
This makes both the source and destination addresses of the packets This makes both the source and destination addresses of the packets
exchanged over the virtual link, predictable on both the routers for exchanged over the virtual link, predictable on both the routers for
security purposes. security purposes.
9. Changing Keys 10. Changing Keys
To maintain the security of a link, it may be desirable to change the To maintain the security of a link, the key values SHOULD be changed
key values from time to time. The following three-step procedure MAY from time to time. The following three-step procedure SHOULD be
be provided to rekey the routers on a link without dropping OSPFv3 provided to rekey the routers on a link without dropping OSPFv3
protocol packets or disrupting the adjacency. protocol packets or 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
operation should be atomic with respect to sending OSPFv3 packets operation should be atomic with respect to sending OSPFv3 packets
on the link so that no OSPFv3 packets are sent without on the link so that no OSPFv3 packets are sent without
authentication/encryption. authentication/encryption.
skipping to change at page 7, line 15 skipping to change at page 8, 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 the routers on a link In order to achieve smooth key transition, all the routers on a link
should use the same value for KeyRolloverInterval, and should should use the same value for KeyRolloverInterval, and should
initiate the key rollover process within this time period. initiate the key rollover process within this time period.
At the end of this procedure, all the routers will have a single At the end of this procedure, all the routers will have a single
inbound and outbound SA for OSPFv3 on the link with the new SPI and inbound and outbound SA for OSPFv3 on the link with the new SPI and
key values. key values.
10. IPsec rules 11. IPsec rules
The following set of rules can be installed in a typical IPsec The following set of transport mode rules can be installed in a
implementation to provide the authentication/confidentiality to typical IPsec implementation to provide the
OSPFv3 packets. authentication/confidentiality to OSPFv3 packets.
Outbound Rules for interface running OSPFv3 security: Outbound Rules for interface running OSPFv3 security:
No. interface source destination protocol action No. source destination protocol action
1 iface fe80::/10 any OSPF apply 1 fe80::/10 any OSPF apply
2 any src/128 dst/128 OSPF apply
Outbound Rules for virtual links running OSPFv3 security:
No. source destination protocol action
2 src/128 dst/128 OSPF apply
Inbound Rules for interface running OSPFv3 security: Inbound Rules for interface running OSPFv3 security:
No. interface source destination protocol action No. source destination protocol action
3 iface fe80::/10 any ESP or AH apply 3 fe80::/10 any ESP/OSPF or AH/OSPF apply
4 iface fe80::/10 any OSPF drop 4 fe80::/10 any OSPF drop
5 any src/128 dst/128 ESP or AH apply
6 any src/128 dst/128 OSPF drop Inbound Rules for virtual links running OSPFv3 security:
No. source destination protocol action
5 src/128 dst/128 ESP/OSPF or AH/OSPF apply
6 src/128 dst/128 OSPF drop
For outbound rules, action "apply" means encrypting/calculating ICV For outbound rules, action "apply" means encrypting/calculating ICV
and adding ESP or AH header. For inbound rules, action "apply" means and adding ESP or AH header. For inbound rules, action "apply" means
decrypting/authenticating the packets and stripping ESP or AH header. decrypting/authenticating the packets and stripping ESP or AH header.
Rules 4 and 6 are to drop the insecure OSPFv3 packets without ESP/AH Rules 4 and 6 are to drop the insecure OSPFv3 packets without ESP/AH
headers. headers.
ESP/OSPF or AH/OSPF in rules 3 and 5 mean that it is an OSPF packet
secured with ESP or AH.
Rules 1, 3 and 4 are meant to secure the unicast and multicast OSPF
packets that are not being exchanged over the virtual links. These
rules MUST be installed only in the security policy database (SPD) of
the interface running OSPFv3 security.
Rules 2, 5 and 6 are meant to secure the packets being exchanged over Rules 2, 5 and 6 are meant to secure the packets being exchanged over
virtual links. These rules are dynamically installed after learning virtual links. These rules are dynamically installed after learning
the end point IP addresses of a virtual link. These rules MUST be the end point IP addresses of a virtual link. These rules MUST be
installed on at least the interfaces that are connected to the installed on at least the interfaces that are connected to the
transit area for the virtual link. These rules MAY alternatively be transit area for the virtual link. These rules MAY alternatively be
installed on all the interfaces. If these rules are not installed on installed on all the interfaces. If these rules are not installed on
all the interfaces, clear text or malicious OSPFv3 packets with same all the interfaces, clear text or malicious OSPFv3 packets with same
source and destination addresses as virtual link end point addresses source and destination addresses as virtual link end point addresses
will be delivered to OSPFv3. Though OSPFv3 drops these packets will be delivered to OSPFv3. Though OSPFv3 drops these packets
because they were not received on the right interface, OSPFv3 because they were not received on the right interface, OSPFv3
skipping to change at page 8, line 14 skipping to change at page 10, line 13
is on. Installing these rules on all the interfaces insures that is on. Installing these rules on all the interfaces insures that
OSPFv3 does not receive these clear text or malicious packets when OSPFv3 does not receive these clear text or malicious packets when
security is turned on. On the other hand installing these rules on security is turned on. On the other hand installing these rules on
all the interfaces increases the processing overhead on the all the interfaces increases the processing overhead on the
interfaces where there is no IPsec processing otherwise. The interfaces where there is no IPsec processing otherwise. The
decision of installing these rules on all the interfaces or on just decision of installing these rules on all the interfaces or on just
the interfaces that are connected to the transit area is a private the interfaces that are connected to the transit area is a private
decision and doesn't affect the interoperability in any way. So this decision and doesn't affect the interoperability in any way. So this
decision is left to the implementers. decision is left to the implementers.
Rules 1, 3 and 4 are meant to secure the unicast and multicast 12. Mandatory Encryption and Authentication Algorithms
packets that are not being exchanged over the virtual links. These
rules are interface specific.
11. Replay Protection The implementation MUST allow the user to choose AES-CBC as the
encryption algorithm and HMAC-SHA1 as the authentication algorithm
for securing OSPFv3 packets.
The implementation MUST NOT allow the user to choose stream ciphers
as the encryption algorithm for securing OSPFv3 packets as the stream
ciphers are not suitable for manual keys.
13. Replay Protection
As it is not possible as per the current standards to provide As it is not possible as per 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.
Fields LS age, LS Sequence Number and LS checksum in LSA header are Fields LS age, LS Sequence Number and LS checksum in LSA header are
kept intact in OSPFv3. Though these fields do not provide the kept intact in OSPFv3. Though these fields do not provide the
complete protection, they certainly help against replay attacks. complete protection, they certainly help against replay attacks.
Security Considerations 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 in order to
provide security to OSPFv3 for IPv6. provide security to OSPFv3 for IPv6. Hence security permeates
throughout this document.
The use of manual keying does not provide very high level of security This specification mandates the usage of manual keys. The following
as compared to IKE but the security provided should be adequate for a are the known limitations of the usage of manual keys.
routing protocol.
O Manual keys are usually long lived (changing them very often is
a tedious task). This gives an attacker enough time to discover
the keys.
O As the administrator is manually configuring the keys, there is
a chance that the configured keys are weak (there are known weak
keys for DES/3DES at least).
O As the sequence numbers can not be negotiated, replay protection
can not be provided.
Inspite of the above known limitations, the security provided by the
usage of the manual keys should be adequate for a routing protocol.
Normative References Normative References
N1. Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6", RFC 2740, N1. Moy, J., "OSPF version 2", RFC 2328, April 1998
N2. Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6", RFC 2740,
December 1999 December 1999
N2. Kent, S. and R. Atkinson, "Security Architecture for the Internet N3. Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 2401, November 1998. Protocol", RFC XXXX, date [Note to RFC-Editor: Replace XXXX with
the number of the RFC 2401 replacement].
N3. Kent, S. and R. Atkinson, "IP Encapsulating Security Payload N4. Kent, S., "IP Encapsulating Security Payload (ESP)", RFC XXXY,
(ESP)", RFC 2406, November 1998. date [Note to RFC-Editor: Replace XXXY with the number of the RFC
2406 replacement].
N4. Kent, S. and R. Atkinson, "IP Authentication Header (AH)", RFC N5. Kent, S., "IP Authentication Header (AH)", RFC XXXZ, date [Note to
2402, November 1998. RFC-Editor: Replace XXXZ with the number of the RFC 2402
replacement].
N5. Bradner, S., "Key words for use in RFCs to Indicate Requirement N6. Eastlake, D., "Cryptographic Algorithm Implementation Requirements
For ESP And AH", RFC XXYY, date [Note to RFC-Editor: Replace XXYY
with the number of the RFC that the draft draft-ietf-ipsec-esp-ah-
algorithms-02.txt gets].
N7. Bradner, S., "Key words for use in RFCs to Indicate Requirement
Level", BCP 14, RFC 2119, March 1997. Level", BCP 14, RFC 2119, March 1997.
Informative References Informative References
I1. Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC I1. Kaufman, C., "The Internet Key Exchange (IKEv2) Protocol", RFC
2409, November 1998. XXZZ, date [Note to RFC-Editor: Replace XXZZ with the number of the
RFC 2409 replacement].
Acknowledgments Acknowledgments
Authors would like to extend sincere thanks to Marc Solsona, Janne Authors would like to extend sincere thanks to Marc Solsona, Janne
Peltonen, John Cruz, Dhaval Shah, Abhay Roy and Paul Wells for Peltonen, John Cruz, Dhaval Shah, Abhay Roy and Paul Wells for
providing useful information and critiques in order to write this providing useful information and critiques in order to write this
memo. memo.
We would also like to thank IPsec and OSPF WG people to provide We would also like to thank IPsec and OSPF WG people to provide
valuable review comments. valuable review comments.
skipping to change at line 420 skipping to change at page 12, line 23
Mountain View, CA 94043 Mountain View, CA 94043
Phone: 650-625-2264 Phone: 650-625-2264
Email: Mukesh.Gupta@nokia.com Email: Mukesh.Gupta@nokia.com
Nagavenkata Suresh Melam Nagavenkata Suresh Melam
Nokia Nokia
313 Fairchild Drive 313 Fairchild Drive
Mountain View, CA 94043 Mountain View, CA 94043
Phone: 650-625-2949 Phone: 650-625-2949
Email: Nagavenkata.Melam@nokia.com Email: Nagavenkata.Melam@nokia.com
Full copyright statement
Copyright (C) The Internet Society (2004). 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 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. 

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