draft-ietf-ospf-ospfv3-auth-06.txt   draft-ietf-ospf-ospfv3-auth-07.txt 
Network Working Group M. Gupta Network Working Group M. Gupta
Internet Draft Nokia Internet Draft Nokia
Document: draft-ietf-ospf-ospfv3-auth-06.txt N. Melam Document: draft-ietf-ospf-ospfv3-auth-07.txt N. Melam
Expires: June 2005 Nokia Expires: August 2005 Nokia
December 2004 February 2005
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 By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of RFC 3668. aware will be disclosed, in accordance with Section 6 of RFC 3668.
skipping to change at page 2, line 8 skipping to change at page 2, line 8
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 [N7]. document are to be interpreted as described in RFC-2119 [N7].
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction...................................................2
2. Transport Mode vs Tunnel Mode..................................3 2. Transport Mode vs Tunnel Mode..................................2
3. Authentication.................................................3 3. Authentication.................................................3
4. Confidentiality................................................3 4. Confidentiality................................................3
5. Distinguishing OSPFv3 from OSPFv2..............................4 5. Distinguishing OSPFv3 from OSPFv2..............................4
6. IPsec Requirements.............................................4 6. IPsec Requirements.............................................4
7. Key Management.................................................4 7. Key Management.................................................5
8. SA Granularity and Selectors...................................6 8. SA Granularity and Selectors...................................7
9. Virtual Links..................................................7 9. Virtual Links..................................................7
10. Rekeying......................................................8 10. Rekeying......................................................8
10.1 Rekeying Procedure........................................8 10.1 Rekeying Procedure........................................8
10.2 KeyRolloverInterval.......................................9 10.2 KeyRolloverInterval.......................................9
10.3 Rekeying Interval.........................................9 10.3 Rekeying Interval.........................................9
11. IPsec rules...................................................9 11. IPsec rules..................................................10
12. Mandatory Encryption and Authentication Algorithms...........11 12. Entropy of manual keys.......................................11
13. Entropy of manual keys.......................................11 13. Replay Protection............................................11
14. Replay Protection............................................11 Security Considerations..........................................11
Security Considerations..........................................12
Normative References.............................................12 Normative References.............................................12
Informative References...........................................13 Informative References...........................................13
Acknowledgments..................................................13 Acknowledgments..................................................13
Authors' Addresses...............................................14 Authors' Addresses...............................................14
1. Introduction 1. Introduction
OSPF (Open Shortest Path First) Version 2 [N1] defines fields AuType OSPF (Open Shortest Path First) Version 2 [N1] defines fields AuType
and Authentication in its protocol header in order to provide and Authentication in its protocol header in order to provide
security. In OSPF for IPv6 (OSPFv3) [N2], both of the authentication security. In OSPF for IPv6 (OSPFv3) [N2], both of the authentication
skipping to change at page 3, line 7 skipping to change at page 2, line 48
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 ESP
(manual keying [N3] and Internet Key Exchange (IKE)[I1]). (manual keying [N3] and Internet Key Exchange (IKE)[I1]).
2. Transport Mode vs Tunnel Mode 2. Transport Mode vs Tunnel Mode
Transport mode Security Association (SA) is the security association Transport mode Security Association (SA) is generally used between
between two hosts or routers/gateways when they are acting as hosts. two hosts or routers/gateways when they are acting as hosts. SA must
SA must be tunnel mode if either end of the security association is a be a tunnel mode SA if either end of the security association is a
router/gateway. OSPFv3 packets are exchanged between the routers but router/gateway. Two hosts MAY establish a tunnel mode SA between
as the packets are destined to the routers, the routers act like themselves. OSPFv3 packets are exchanged between the routers but as
hosts in this case. So transport mode SA MUST be used in order to the packets are destined to the routers, the routers act like hosts
provide required security to OSPFv3. in this case. All implementations confirming to this specification
MUST support Transport mode SA to provide required IPsec security to
OSPFv3 packets. They MAY also support Tunnel mode SA to provide
required 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, "ESP with NULL In order to provide authentication to OSPFv3, ESP MUST be supported
encryption" MUST be supported and AH SHOULD be supported by the and AH MAY be supported by the implementation.
implementation.
If "ESP with NULL encryption" in transport mode is used, it will If ESP in transport mode is used, it will provide authentication to
provide authentication to only OSPFv3 protocol headers but not to the only OSPFv3 protocol headers but not to the IPv6 header, extension
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 headers, selected portions of IPv6 header, selected OSPFv3 protocol headers, 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 with non-null encryption" MUST If confidentiality is provided, ESP MUST be used.
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
skipping to change at page 4, line 37 skipping to change at page 4, line 34
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. [N3] traffic. [N3]
Encryption and Authentication Algorithms Encryption and Authentication Algorithms
AES-CBC and HMAC-SHA1 MUST be supported as the encryption and the
authentication algorithms respectively. [N6] 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.
Except when in conflict with the above statement, Keywords
"MUST", "MUST NOT", "REQUIRED", "SHOULD" and "SHOULD NOT" that
appear in the [N6] document for algorithms to be supported are to
be interpreted as described in [N7] for OSPFv3 support too.
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.
Encapsulation of ESP packet
IP encapsulation of ESP packets MUST be supported. For
simplicity, UDP encapsulation of ESP packets SHOULD NOT be used.
Different SAs for different DSCPs
As per [N3], IPsec implementation MUST support the establishment
and maintenance of multiple SAs between given sender and receiver,
with the same selectors. This allows the implementation to put
traffic of different classes, but with same selector values, on
different SAs to support QoS appropriately.
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. Manual keying MUST be used for many" authentication/confidentiality. This specification mandates
this purpose. In manual keying SAs are statically installed on the the usage of Manual Keying to work with the current IPsec
routers and these static SAs are used to authenticate/encrypt the implementations. Future specifications can explore the usage of
packets. protocols like KINK/GSAKMP as and when they are widely available. In
manual keying SAs are statically installed on the routers and these
static SAs are used to authenticate/encrypt the packets.
The following discussion explains that it is not scalable and The following discussion explains that it is not scalable and
practically infeasible to use different security associations for practically infeasible to use different security associations for
inbound and outbound traffic in order to provide the required "one to inbound and outbound traffic in order to provide the required "one to
many" security. Therefore, the implementations MUST use manually many" security. Therefore, the implementations MUST use manually
configured keys with same SA for inbound and outbound traffic (as configured keys with same SA for inbound and outbound traffic (as
shown in Figure 3). shown in Figure 3).
A | A |
SAa ------------>| SAa ------------>|
skipping to change at page 9, line 20 skipping to change at page 9, line 38
implementation and the deployment, it is left to the administrator to implementation and the deployment, it is left to the administrator to
choose the appropriate value. choose the appropriate value.
10.3 Rekeying Interval 10.3 Rekeying Interval
This section analyzes the security provided by the manual keying and This section analyzes the security provided by the 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 is used with the HMAC-MD5 this specification is when NULL encryption (for ESP) or no encryption
authentication. Any other algorithm combinations will at least be as (for AH) is used with the HMAC-MD5 authentication. Any other
hard to break as the one mentioned above as shown by the following algorithm combinations will at least be as hard to break as the one
examples: mentioned above as shown by the following examples:
O NULL Encryption and HMAC-SHA-1 Authentication will be more secure O NULL Encryption and HMAC-SHA-1 Authentication will be more secure
as HMAC-SHA-1 is considered to be more secure than HMAC-MD5 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 is not applicable as
this specification mandates the authentication when OSPFv3 security this specification mandates the authentication when OSPFv3 security
is enabled is enabled
O DES Encryption and HMAC-MD5 Authentication will be more secure O DES Encryption and HMAC-MD5 Authentication will be more secure
because of the additional security provided by DES because of the additional security provided by DES
skipping to change at page 11, line 9 skipping to change at page 11, line 28
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.
12. Mandatory Encryption and Authentication Algorithms 12. Entropy of manual keys
The implementation MUST allow the user to choose AES-CBC [N8] as the
encryption algorithm and HMAC-SHA1-96 [N9] 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. 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 instead cryptographic and authentication keys in hexadecimal format instead
of restricting it a subset of ASCII characters (letters, numbers of restricting it a subset of ASCII characters (letters, numbers
etc). Otherwise the entropy of the keys reduces significantly as etc). Otherwise the entropy of the keys reduces significantly as
discussed in [I2]. discussed in [I2].
14. Replay Protection 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. This solution will not provide protection against replay attacks.
section analyzes the protection built in OSPF protocol to guard
itself against replay attacks.
OSPF protocol has the following types of packets:
Hello: OSPF does not have any protection against replayed hello
messages thus OSPF will be vulnerable to the attacks performed by
replaying hello messages even after enabling security.
Database Description: These packets are exchanged while building the
adjacencies to describe the OSPF database. There are no known
threats of replaying these type of packets.
Link State Request, Link State Acknowledgment and Link State Updates:
Fields LS age, LS Sequence Number and LS checksum in LSA header are
kept intact in OSPFv3. Though these fields do not provide the
complete protection, they certainly help against replay attacks of
Link State packets.
Detailed analysis of various vulnerabilities of the routing protocols Detailed analysis of various vulnerabilities of the routing protocols
is discussed in [I3]. and OSPF in particular is discussed in [I3] and [I2], but it can be
summarized that "Replay of OSPF packets can cause adjacencies to be
disrupted, which can lead to DoS attack on the network. It can also
cause database exchange process to occur continuously thus causing
CPU overload as well as micro loops in the network".
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. Hence security permeates provide security to OSPFv3 for IPv6. Hence security permeates
throughout this document. throughout 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 security against all the vulnerabilities identified for provides security against all the vulnerabilities identified for
scenario with cryptographic authentication with the following scenario with cryptographic authentication with the following
skipping to change at page 13, line 50 skipping to change at page 13, line 46
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", draft-ietf-rpsec-routing-threats-07.txt, 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 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, Paul Wells and Vishwas
providing useful information and critiques in order to write this Manral for providing useful information and critiques in order to
memo. 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.
Authors' Addresses Authors' Addresses
Mukesh Gupta Mukesh Gupta
Nokia Nokia
313 Fairchild Drive 313 Fairchild Drive
Mountain View, CA 94043 Mountain View, CA 94043
 End of changes. 

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