draft-ietf-ospf-ospfv3-auth-01.txt   draft-ietf-ospf-ospfv3-auth-02.txt 
Network Working Group M. Gupta Network Working Group M. Gupta
Internet Draft Nokia Internet Draft Nokia
Document: draft-ietf-ospf-ospfv3-auth-01.txt N. Melam Document: draft-ietf-ospf-ospfv3-auth-02.txt N. Melam
Expires: October 2003 Nokia Expires: January 2003 Nokia
April 2003 July 2003
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 This document is an Internet-Draft and is subject to all provisions
of section 10 of RFC2026. of section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 IPv6 AH/ESP Extension
Header. Header.
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 [5]. document are to be interpreted as described in RFC-2119 [N5].
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction...................................................2
2. OSPFv2 to OSPFv3...............................................2 2. OSPFv2 to OSPFv3...............................................2
3. Authentication.................................................2 3. Authentication.................................................2
4. Confidentiality................................................3 4. Confidentiality................................................3
5. Authentication and Encryption Algorithms.......................3 5. IPsec Requirements.............................................3
6. Key Management.................................................3 6. Key Management.................................................4
7. SA Granularity and Selectors...................................4 7. SA Granularity and Selectors...................................5
8. Virtual Links..................................................5 8. Virtual Links..................................................5
9. IPsec rules....................................................5 9. IPsec rules....................................................6
10. Replay Protection.............................................6 10. Replay Protection.............................................7
Security Considerations...........................................6 Security Considerations...........................................7
References........................................................7 Normative References..............................................7
Acknowledgments...................................................7 Informative References............................................8
Authors' Addresses................................................7 Acknowledgments...................................................8
Authors' Addresses................................................8
1. Introduction 1. Introduction
In OSPFv3 for IPv6, authentication fields have been removed from OSPF In Open Shortest Path First - Version 3 (OSPFv3) for IPv6,
headers. When running over IPv6, OSPF relies on the IPv6 authentication fields have been removed from OSPF headers. When
Authentication Header (AH) and IPv6 Encapsulating Security Payload running over IPv6, OSPF relies on the IPv6 Authentication Header (AH)
(ESP) to ensure integrity, authentication and/or confidentiality of and IPv6 Encapsulating Security Payload (ESP) to ensure integrity,
routing exchanges. authentication and/or confidentiality of routing exchanges.
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 [1], AH [4], It is assumed that the reader is familiar with OSPFv3 [N1], AH [N4],
ESP [3], the concept of security associations, tunnel and transport ESP [N3], 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 and IKE) [2]. (manual keying [N2] and Internet Key Exchange (IKE)[I1]).
2. OSPFv2 to OSPFv3 2. OSPFv2 to OSPFv3
Security concerns MUST be taken away from OSPFv3 protocol and IPv6 Security concerns MUST be taken away from OSPFv3 protocol and IPv6
stack MUST provide inherent security to OSPFv3 by using AH/ESP stack MUST provide inherent security to OSPFv3 by using AH/ESP
extension headers. It means OSPFv3 protocol MUST not receive any extension headers. It means OSPFv3 protocol MUST NOT receive any
unauthenticated packets. As OSPFv2 has its own security mechanisms, unauthenticated packets. As OSPFv2 has its own security mechanisms,
no inherent security needs to be provided by the IPv4 stack. As 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 OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, the distinction
between the packets can be easily made by IP version. between the packets can be easily made by IP version.
Authentication and confidentiality, if provided, MUST be provided to Authentication and confidentiality, if provided, MUST be provided to
the entire OSPFv3 header and data. Authentication to the selected the entire OSPFv3 header and data. Authentication to the selected
portions of IPv6 header, selected portions of extension headers and portions of IPv6 header, selected portions of extension headers and
selected options may also be provided optionally. selected options MAY also be provided optionally.
3. Authentication 3. Authentication
Transport mode SA is the security association between two hosts or Transport mode Security Association (SA) is the security association
security gateways that are acting as hosts. SA must be tunnel mode if between two hosts or security gateways that are acting as hosts. SA
either end of the security association is a security gateway. OSPFv3 must be tunnel mode if either end of the security association is a
packets are exchanged between the routers but as the packets are security gateway. OSPFv3 packets are exchanged between the routers
destined to the routers, the routers act like host in this case. So but as the packets are destined to the routers, the routers act like
transport mode SA MUST be used in order to provide required security hosts in this case. So transport mode SA MUST be used in order to
to OSPFv3. provide required security to OSPFv3.
In order to support OSPFv3 authentication, "ESP with NULL encryption" In order to support OSPFv3 authentication, "ESP with NULL encryption"
MUST be supported in transport mode. "AH" in transport mode SHOULD MUST be supported in transport mode. "AH" in transport mode SHOULD
also be provided. AH in transport mode provides authentication to also be provided. AH in transport mode provides authentication to
higher layer protocols, selected portions of IPv6 header, selected higher layer protocols, selected portions of IPv6 header, selected
portions of extension headers and selected options. ESP with NULL portions of extension headers and selected options. ESP with NULL
encryption in transport mode will provide authentication to only encryption in transport mode will provide authentication to only
higher layer protocol data and not to the IPv6 header, extension higher layer protocol data and not to the IPv6 header, extension
headers and options. headers and options.
OSPF packets received in clear text and OSPF received with incorrect OSPF packets received in clear text or with incorrect AH Integrity
AH ICV MUST be dropped when authentication is enabled. Check Value (ICV) MUST be dropped when authentication is enabled.
4. Confidentiality 4. Confidentiality
Providing confidentiality to OSPFv3 in addition to authentication is Providing confidentiality to OSPFv3 in addition to authentication is
optional. Confidentiality must be implemented using ESP extension optional. Confidentiality must be implemented using ESP extension
header of IPv6 if it is being provided. ESP with non-null encryption header of IPv6 if it is being provided. ESP with non-null encryption
in transport mode MUST be used for the providing confidentiality to in transport mode MUST be used for providing the confidentiality to
OSPFv3. OSPFv3. The user MUST be able to configure the encryption key and
the authentication key separately.
5. Authentication and Encryption Algorithms 5. IPsec Requirements
In order to implement this specification, the following IPsec
capabilities are required.
Transport Mode
IPsec in transport mode MUST be supported.
Traffic Selectors
The implementation MUST be able to use interface index, source
address, destination address, protocol and direction for choosing
the right security action.
Manual key support
Manually configured keys MUST be able to secure the specified
traffic.
Encryption and Authentication Algorithms
The implementations MUST be conformant to the RFCs that describe The implementations MUST be conformant to the RFCs that describe
mandatory-to-implement algorithms for use with ESP and AH. mandatory-to-implement algorithms for use with ESP and AH.
Dynamic IPsec rule configuration
Routing module SHOULD be able to configure, modify and delete
IPsec rules on the fly. This is needed mainly for securing
virtual links.
6. Key Management 6. 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 encrypt/authenticate the
data. data.
Since security associations (SAs) are directional, generally As security associations (SAs) are directional, generally different
different security associations are used for inbound and outbound security associations are used for inbound and outbound processing
processing for providing higher security. The following figure for providing higher security. The following figure explains that it
explains that it is not possible to use different security is not possible to use different security associations for inbound
associations for inbound and outbound processing in order to provide and outbound processing in order to provide the required "one to
the required "one to many" security. many" security.
A | A |
SAa ------------>| SAa ------------>|
SAb <------------| SAb <------------|
| |
B | B |
SAb ------------>| SAb ------------>|
SAa <------------| SAa <------------|
| |
C | C |
skipping to change at page 4, line 35 skipping to change at page 5, line 8
Since the packets are multicast packets and they are going to be Since the packets are multicast packets and they are going to be
processed by both A and B, there is no SA for C to use so that A and processed by both A and B, there is no SA for C to use so that A and
B both can understand it. B both can understand it.
The problem can be solved with the following figure where all of them The problem can be solved with the following figure where all of them
use the same SA for incoming and outgoing direction. use the same SA for incoming and outgoing direction.
A | A |
SAs ------------>| SAs ------------>|
SAs <------------| SAs <------------|
|3 |
B | B |
SAs ------------>| SAs ------------>|
SAs <------------| SAs <------------|
| |
C | C |
SAs ------------>| SAs ------------>|
SAs <------------| SAs <------------|
Broadcast Broadcast
Network Network
So, all the adjacent routers on a broadcast medium MUST use the same So, all the neighbor routers on a network/subnet MUST use the same SA
SA and the same SA MUST be used for inbound and outbound processing. and the same SA MUST be used for inbound and outbound processing.
7. SA Granularity and Selectors 7. 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 8. 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 site-
local or global IPv6 addresses as the IPv6 source address and all the local or global 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 should be 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 need the time of configuration, the secure channel for these packets needs
to be setup dynamically. The end point IP addresses of virtual links to be set up dynamically. The end point IP addresses of virtual
are learnt during the routing table build up process. The packet links are learnt during the routing table build up process. The
exchange over the virtual links starts only after the discovery of packet exchange over the virtual links starts only after the
end point IP addresses. In order to provide security to these discovery of end point IP addresses. In order to provide security to
exchanges, the routing module should setup a secure IPsec channel these exchanges, the routing module should setup a secure IPsec
dynamically once it acquires the required information. channel dynamically once it acquires the required information.
According to the OSPFv3 RFC, the virtual neighbor's IP address is set According to the OSPFv3 RFC [N1], the virtual neighbor's IP address
to the first prefix with the "LA-bit" set from the list of prefixes is set to the first prefix with the "LA-bit" set from the list of
in intra-area-prefix-LSAs originated by the virtual neighbor. But prefixes in intra-area-prefix-LSAs originated by the virtual
when it comes to choosing the source address for the packets that are neighbor. But when it comes to choosing the source address for the
sent over the virtual link, the RFC simply suggests using one of the packets that are sent over the virtual link, the RFC simply suggests
router's own site-local or global IPv6 addresses. In order to install using one of the router's own site-local or global IPv6 addresses.
the required rules for virtual links, the source address also needs In order to install the required security rules for virtual links,
to be predictable. So the router MUST use the first prefix with the the source address also needs to be predictable. So the routers that
"LA-bit" set from the list of its own intra-area-prefix-LSAs as the implement this specification MUST change the way the source and
source address of the packet. This makes both the source and destination addresses are chosen for the packets exchanged over
destination address of the packets exchanged over the virtual link, virtual links when the security is enabled on that virtual link.
predictable on both the routers.
The smallest IP address with the "LA-bit" set from the list of its
own prefixes being advertised in intra-area-prefix-LSA MUST be used
as the source address.
The smallest IP address with the "LA-bit" set from the list of intra-
area-prefix-LSAs originated by the virtual neighbor MUST be used as
the destination address.
This makes both the source and destination addresses of the packets
exchanged over the virtual link, predictable on both the routers for
security purposes.
The old behavior specified in OSPFv3 RFC for choosing the source and
destination IP addresses MUST be used when the security is not
enabled on the virtual link. This will insure the interoperability
with the routers that do not implement this specification.
9. IPsec rules 9. IPsec rules
The following set of rules can be installed in a typical IPsec The following set of rules can be installed in a typical IPsec
implementation to provide the authentication/confidentiality to implementation to provide the authentication/confidentiality to
OSPFv3 packets. OSPFv3 packets.
Outbound Rules for interface running OSPFv3 security: Outbound Rules for interface running OSPFv3 security:
No. interface source destination protocol action No. interface source destination protocol action
skipping to change at page 6, line 10 skipping to change at page 6, line 48
No. interface source destination protocol action No. interface source destination protocol action
3 iface fe80::/10 any ESP or AH apply 3 iface fe80::/10 any ESP or AH apply
4 iface fe80::/10 any OSPF drop 4 iface fe80::/10 any OSPF drop
5 any src/128 dst/128 ESP or AH apply 5 any src/128 dst/128 ESP or AH apply
6 any src/128 dst/128 OSPF drop 6 any 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 in-secure OSPFv3 packets without ESP/AH Rules 4 and 6 are to drop the insecure OSPFv3 packets without ESP/AH
headers. headers.
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
receives some clear text or malicious packets even when the security receives some clear text or malicious packets even when the security
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 decision interfaces where there is no IPsec processing otherwise. The
of installing these rules on all the interfaces or on just the decision of installing these rules on all the interfaces or on just
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 Rules 1, 3 and 4 are meant to secure the unicast and multicast
packets that are not being exchanged over the virtual links. These packets that are not being exchanged over the virtual links. These
rules are interface specific. rules are interface specific.
10. Replay Protection 10. 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
skipping to change at page 7, line 9 skipping to change at page 7, line 46
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.
The use of manual keying does not provide very high level of security The use of manual keying does not provide very high level of security
as compared to IKE but the security provided should be adequate for a as compared to IKE but the security provided should be adequate for a
routing protocol. routing protocol.
References Normative References
1. Coltun, R., Ferguson, D. and Moy, J., "OSPF for IPv6", RFC 2740, N1. Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6", RFC 2740,
December 1999 December 1999
2. Kent, S. and Atkinson, R., "Security Architecture for the Internet N2. Kent, S. and R. Atkinson, "Security Architecture for the Internet
Protocol", RFC 2401, November 1998 Protocol", RFC 2401, November 1998.
3. Kent, S. and Atkinson, R., "IP Encapsulating Security Payload Authentication/Confidentiality to OSPFv3 July 2003
(ESP)", RFC 2406, November 1998
4. Kent, S. and Atkinson, R., "IP Authentication Header (AH)", RFC N3. Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
2402, November 1998 (ESP)", RFC 2406, November 1998.
5. Bradner, S., "Key words for use in RFCs to Indicate Requirement N4. Kent, S. and R. Atkinson, "IP Authentication Header (AH)", RFC
2402, November 1998.
N5. 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
I1. Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC
2409, November 1998.
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 and Abhay Roy for providing useful Peltonen, John Cruz, Dhaval Shah and Abhay Roy for providing useful
information and critiques in order to write this memo. information and critiques in order to write this 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.
 End of changes. 

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