< draft-ietf-ospf-ospfv3-auth-03.txt   draft-ietf-ospf-ospfv3-auth-04.txt >
Network Working Group M. Gupta Network Working Group M. Gupta
Internet Draft Nokia Internet Draft Nokia
Document: draft-ietf-ospf-ospfv3-auth-03.txt N. Melam Document: draft-ietf-ospf-ospfv3-auth-04.txt N. Melam
Expires: February 2003 Nokia Expires: June 2004 Nokia
August 2003 December 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 6 skipping to change at page 2, line 6
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. IPsec Requirements.............................................3 5. IPsec Requirements.............................................3
6. Key Management.................................................4 6. Key Management.................................................4
7. SA Granularity and Selectors...................................5 7. SA Granularity and Selectors...................................5
8. Virtual Links..................................................5 8. Virtual Links..................................................5
9. IPsec rules....................................................6 9. Changing Keys..................................................6
10. Replay Protection.............................................7 10. IPsec rules...................................................7
Security Considerations...........................................7 11. Replay Protection.............................................8
Normative References..............................................7 Security Considerations...........................................8
Informative References............................................8 Normative References..............................................8
Acknowledgments...................................................8 Informative References............................................9
Authors' Addresses................................................8 Acknowledgments...................................................9
Authors' Addresses................................................9
1. Introduction 1. Introduction
In Open Shortest Path First - Version 3 (OSPFv3) for IPv6, In Open Shortest Path First - Version 3 (OSPFv3) for IPv6,
authentication fields have been removed from OSPF headers. When authentication fields have been removed from OSPF headers. When
running over IPv6, OSPF relies on the IPv6 Authentication Header (AH) running over IPv6, OSPF relies on the IPv6 Authentication Header (AH)
and IPv6 Encapsulating Security Payload (ESP) to ensure integrity, and IPv6 Encapsulating Security Payload (ESP) to ensure integrity,
authentication and/or confidentiality of 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
skipping to change at page 6, line 25 skipping to change at page 6, line 29
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. IPsec rules 9. Changing Keys
To maintain the security of a link, it may be desirable to change the
key values from time to time. The following three-step procedure MAY
be provided to rekey the routers on a link without dropping OSPFv3
protocol packets or disrupting the adjacency.
(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.
(2) For every router on the link, replace the original outbound SA
with one using the new SPI and key values. The SA replacement
operation should be atomic with respect to sending OSPFv3 packets
on the link so that no OSPFv3 packets are sent without
authentication/encryption.
(3) For every router on the link, remove the original inbound SA.
Note that all the routers on the link must complete step 1 before any
begin step 2. Likewise, all the routers on the link must complete
step 2 before any begin step 3.
One way to control the progression from one step to the next is for
each router to have a configurable time constant KeyRolloverInterval.
After the router begins step 1 on a given link, it waits for this
interval and then moves to step 2. Likewise, after moving to step 2,
it waits for this interval and then moves to step 3.
In order to achieve smooth key transition, all the routers on a link
should use the same value for KeyRolloverInterval, and should
initiate the key rollover process within this time period.
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
key values.
10. 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::/10 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
skipping to change at page 7, line 30 skipping to change at page 8, line 18
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 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 11. 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
skipping to change at page 8, line 4 skipping to change at page 8, line 41
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.
Normative References Normative References
N1. Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6", RFC 2740, N1. Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6", RFC 2740,
December 1999 December 1999
Authentication/Confidentiality to OSPFv3 August 2003
N2. Kent, S. and R. Atkinson, "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.
N3. Kent, S. and R. Atkinson, "IP Encapsulating Security Payload N3. Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998. (ESP)", RFC 2406, November 1998.
N4. Kent, S. and R. Atkinson, "IP Authentication Header (AH)", RFC N4. Kent, S. and R. Atkinson, "IP Authentication Header (AH)", RFC
2402, November 1998. 2402, November 1998.
skipping to change at page 8, line 26 skipping to change at page 9, line 13
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. Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC
2409, November 1998. 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, Abhay Roy and Paul Wells for
information and critiques in order to write this memo. providing useful 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. 6 change blocks. 
15 lines changed or deleted 52 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/