draft-ietf-ospf-ospfv3-auth-02.txt   draft-ietf-ospf-ospfv3-auth-03.txt 
Network Working Group M. Gupta Network Working Group M. Gupta
Internet Draft Nokia Internet Draft Nokia
Document: draft-ietf-ospf-ospfv3-auth-02.txt N. Melam Document: draft-ietf-ospf-ospfv3-auth-03.txt N. Melam
Expires: January 2003 Nokia Expires: February 2003 Nokia
July 2003 August 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 6, line 7 skipping to change at page 6, line 7
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 smallest IP address with the "LA-bit" set from the list of its The first IPv6 address with the "LA-bit" set in the list of prefixes
own prefixes being advertised in intra-area-prefix-LSA MUST be used advertised in intra-area-prefix-LSAs in the transit area MUST be used
as the source address. as the source address for packets exchanged over the virtual link.
When multiple intra-area-prefix-LSAs are originated they are
considered as being concatenated and are ordered by ascending Link
State ID.
The smallest IP address with the "LA-bit" set from the list of intra- The first IPv6 address with the "LA-bit" set in the list of prefixes
area-prefix-LSAs originated by the virtual neighbor MUST be used as received in intra-area-prefix-LSAs from the virtual neighbor in the
the destination address. transit area MUST be used as the destination address for packets
exchanged over the virtual link. When multiple intra-area-prefix-
LSAs are received they are considered as being concatenated and are
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.
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
1 iface fe80::/10 any OSPF apply 1 iface fe80::/10 any OSPF apply
skipping to change at page 7, line 50 skipping to change at page 8, line 4
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.
Authentication/Confidentiality to OSPFv3 July 2003
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.
N5. Bradner, S., "Key words for use in RFCs to Indicate Requirement 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.
 End of changes. 

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