draft-ietf-ospf-ospfv3-auth-00.txt   draft-ietf-ospf-ospfv3-auth-01.txt 
Network Working Group M. Gupta Network Working Group M. Gupta
Internet Draft Nokia Internet Draft Nokia
Document: draft-ietf-ospf-ospfv3-auth-00.txt N. Melam Document: draft-ietf-ospf-ospfv3-auth-01.txt N. Melam
Expires: May 2003 Nokia Expires: October 2003 Nokia
November 2002 April 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 2, line 9 skipping to change at page 2, line 9
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. Authentication and Encryption Algorithms.......................3
6. Key Management.................................................3 6. Key Management.................................................3
7. SA Granularity and Selectors...................................4 7. SA Granularity and Selectors...................................4
8. Virtual Links..................................................5 8. Virtual Links..................................................5
9. IPsec rules....................................................5 9. IPsec rules....................................................5
10. Replay Protection.............................................6 10. Replay Protection.............................................6
Security Considerations...........................................6 Security Considerations...........................................6
References........................................................6 References........................................................7
Acknowledgments...................................................6 Acknowledgments...................................................7
Authors' Addresses................................................7 Authors' Addresses................................................7
1. Introduction 1. Introduction
In OSPFv3 for IPv6, authentication fields have been removed from OSPF In OSPFv3 for IPv6, authentication fields have been removed from OSPF
headers. When running over IPv6, OSPF relies on the IPv6 headers. When running over IPv6, OSPF relies on the IPv6
Authentication Header (AH) and IPv6 Encapsulating Security Payload Authentication Header (AH) and IPv6 Encapsulating Security Payload
(ESP) to ensure integrity, authentication and/or confidentiality of (ESP) to ensure integrity, authentication and/or confidentiality of
routing exchanges. routing exchanges.
skipping to change at page 3, line 29 skipping to change at page 3, line 29
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 the providing confidentiality to
OSPFv3. OSPFv3.
5. Authentication and Encryption Algorithms 5. Authentication and Encryption Algorithms
hmac-md5-96 must be implemented as the authentication algorithm and The implementations MUST be conformant to the RFCs that describe
DES-CBC must be implemented as the encryption algorithm. mandatory-to-implement algorithms for use with ESP and AH.
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
skipping to change at page 4, line 35 skipping to change at page 4, line 35
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
skipping to change at page 5, line 23 skipping to change at page 5, line 23
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 need
to be setup dynamically. The end point IP addresses of virtual links to be setup dynamically. The end point IP addresses of virtual links
are learnt during the routing table build up process. The packet are learnt during the routing table build up process. The packet
exchange over the virtual links starts only after the discovery of exchange over the virtual links starts only after the discovery of
end point IP addresses. In order to provide security to these end point IP addresses. In order to provide security to these
exchanges, the routing module should setup a secure IPsec channel exchanges, the routing module should setup a secure IPsec channel
dynamically once it acquires the required information. dynamically once it acquires the required information.
According to the OSPFv3 RFC, the virtual neighbor's IP address 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 neighbor. But
when it comes to choosing the source address for the 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. In order to install
the required rules for virtual links, the source address also needs
to be predictable. So the router MUST use the first prefix with the
"LA-bit" set from the list of its own intra-area-prefix-LSAs as the
source address of the packet. This makes both the source and
destination address of the packets exchanged over the virtual link,
predictable on both the routers.
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
1 iface fe80::/16 any OSPF apply 1 iface fe80::/10 any OSPF apply
2 any src/128 dst/128 OSPF apply 2 any 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. interface source destination protocol action
3 iface fe80::/16 any ESP or AH apply 3 iface fe80::/10 any ESP or AH apply
4 iface fe80::/16 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 in-secure 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 are the end point IP addresses of a virtual link. These rules MUST be
installed on all the interfaces. installed on at least the interfaces that are connected to the
transit area for the virtual link. These rules MAY alternatively be
installed on all the interfaces. If these rules are not installed on
all the interfaces, clear text or malicious OSPFv3 packets with same
source and destination addresses as virtual link end point addresses
will be delivered to OSPFv3. Though OSPFv3 drops these packets
because they were not received on the right interface, OSPFv3
receives some clear text or malicious packets even when the security
is on. Installing these rules on all the interfaces insures that
OSPFv3 does not receive these clear text or malicious packets when
security is turned on. On the other hand installing these rules on
all the interfaces increases the processing overhead on the
interfaces where there is no IPsec processing otherwise. The decision
of installing these rules on all the interfaces or on just 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 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
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.
skipping to change at page 6, line 48 skipping to change at page 7, line 29
4. Kent, S. and Atkinson, R., "IP Authentication Header (AH)", RFC 4. Kent, S. and Atkinson, R., "IP Authentication Header (AH)", RFC
2402, November 1998 2402, November 1998
5. Bradner, S., "Key words for use in RFCs to Indicate Requirement 5. 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.
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 and Dhaval Shah for providing useful information Peltonen, John Cruz, Dhaval Shah and Abhay Roy for providing useful
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.
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/