rfc7474v3.txt   rfc7474.txt 
skipping to change at page 2, line 24 skipping to change at page 2, line 24
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Replay Protection Using Extended Sequence Numbers . . . . . . 3 2. Replay Protection Using Extended Sequence Numbers . . . . . . 3
3. OSPF Packet Extensions . . . . . . . . . . . . . . . . . . . 4 3. OSPF Packet Extensions . . . . . . . . . . . . . . . . . . . 4
4. OSPF Packet Key Selection . . . . . . . . . . . . . . . . . . 5 4. OSPF Packet Key Selection . . . . . . . . . . . . . . . . . . 5
4.1. Key Selection for Unicast OSPF Packet Transmission . . . 6 4.1. Key Selection for Unicast OSPF Packet Transmission . . . 6
4.2. Key Selection for Multicast OSPF Packet Transmission . . 7 4.2. Key Selection for Multicast OSPF Packet Transmission . . 7
4.3. Key Selection for OSPF Packet Reception . . . . . . . . . 7 4.3. Key Selection for OSPF Packet Reception . . . . . . . . . 8
5. Securing the IP Header . . . . . . . . . . . . . . . . . . . 8 5. Securing the IP Header . . . . . . . . . . . . . . . . . . . 8
6. Mitigating Cross-Protocol Attacks . . . . . . . . . . . . . . 9 6. Mitigating Cross-Protocol Attacks . . . . . . . . . . . . . . 9
7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 9 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The OSPFv2 cryptographic authentication mechanism as described in The OSPFv2 cryptographic authentication mechanism as described in
[RFC2328] uses per-packet sequence numbers to provide protection [RFC2328] uses per-packet sequence numbers to provide protection
skipping to change at page 6, line 29 skipping to change at page 6, line 29
Assume that a router R1 tries to send a unicast OSPF packet from its Assume that a router R1 tries to send a unicast OSPF packet from its
interface I1 to the interface I2 of a remote router R2 using security interface I1 to the interface I2 of a remote router R2 using security
protocol P via interface I at time T. First, consider the protocol P via interface I at time T. First, consider the
circumstances where R1 and R2 are not connected with a virtual link. circumstances where R1 and R2 are not connected with a virtual link.
R1 then needs to select a long-lived symmetric key from its key R1 then needs to select a long-lived symmetric key from its key
table. Because the key should be shared by both R1 and R2 to protect table. Because the key should be shared by both R1 and R2 to protect
the communication between I1 and I2, the key should satisfy the the communication between I1 and I2, the key should satisfy the
following requirements: following requirements:
o The Peers field is unused. OSPF authentication is interface o The Peers field contains the area ID or, if no key containing the
based. area ID is present, the string "all".
o The Interfaces field includes the local IP address of the
interface for numbered interfaces or the MIB-II [RFC1213] ifIndex
for unnumbered interfaces.
o The Direction field is either "out" or "both". o The Direction field is either "out" or "both".
o If multiple keys match the Interfaces field, the key with the most o The Interfaces field matches I1 or "all".
recent SendLifetimeStart time will be selected. This will
facilitate graceful key rollover. o If multiple keys match the Interface field, keys that explicitly
match I1 should be preferred over keys matching "all". If there
are still multiple keys that match, the key with the most recent
SendLifetimeStart will be selected. This will facilitate graceful
key rollover.
o The Key ID field in the OSPFv2 header (refer to Figure 1) will be o The Key ID field in the OSPFv2 header (refer to Figure 1) will be
set to the selected key's LocalKeyName. set to the selected key's LocalKeyName.
When R1 and R2 are connected to a virtual link, the Interfaces field When R1 and R2 are connected to a virtual link, the Peers field must
must identify the virtual endpoint rather than the virtual link. identify the virtual endpoint rather than the virtual link. Since
Since there may be virtual links to the same router, the transit area there may be virtual links to the same router, the transit area ID
ID must be part of the identifier. Hence, the key should satisfy the must be part of the identifier. Hence, the key should satisfy the
following requirements: following requirements:
o The Peers field is unused. OSPF authentication is interface o The Peers field includes both the virtual endpoint's OSPF router
based. ID and the transit area ID for the virtual link in the form of the
transit area ID, followed by a colon, followed by the router ID.
If no such key exists, then a key with the Peers field set to the
transit area ID is used, followed by a key with the Peers field
set to "all".
o The Interfaces field includes both the virtual endpoint's OSPF o The Interfaces field is not used for key selection on virtual
router ID and the transit area ID for the virtual link. links.
o The Direction field is either "out" or "both". o The Direction field is either "out" or "both".
o If multiple keys match the Interfaces field, the key with the most o If multiple keys match the Peers field, keys that explicitly match
recent SendLifetimeStart time will be selected. This will the router ID should be preferred, followed by keys with a transit
area specified, followed by keys with the Peers field set to
"all". If there are still multiple keys that match, the key with
the most recent SendLifetimeStart will be selected. This will
facilitate graceful key rollover. facilitate graceful key rollover.
o The Key ID field in the OSPFv2 header (refer to Figure 1) will be o The Key ID field in the OSPFv2 header (refer to Figure 1) will be
set to the selected key's LocalKeyName. set to the selected key's LocalKeyName.
4.2. Key Selection for Multicast OSPF Packet Transmission 4.2. Key Selection for Multicast OSPF Packet Transmission
If a router R1 sends an OSPF packet from its interface I1 to a If a router R1 sends an OSPF packet from its interface I1 to a
multicast address (i.e., AllSPFRouters or AllDRouters), it needs to multicast address (i.e., AllSPFRouters or AllDRouters), it needs to
select a key according to the following requirements: select a key according to the following requirements:
o The Peers field is unused. OSPF authentication is interface o First, try a key with the Peers field containing the area ID to
based. which the interface belongs. If no key exists, try a key with the
Peers field "all".
o The Interfaces field includes the local IP address of the o The Interfaces field matches the interface over which the packet
interface for numbered interfaces or the MIB-II [RFC1213] ifIndex is sent or "all".
for unnumbered interfaces.
o The Direction field is either "out" or "both". o The Direction field is either "out" or "both".
o If multiple keys match the Interfaces field, the key with the most o If multiple keys match the Interface field, keys that explicitly
recent SendLifetimeStart time will be selected. This will match I1 should be preferred over keys matching "all". If there
facilitate graceful key rollover. are still multiple keys that match, the key with the most resent
SendLifetimeStart will be selected. This will facilitate graceful
key rollover.
o The Key ID field in the OSPFv2 header (refer to Figure 1) will be o The Key ID field in the OSPFv2 header (refer to Figure 1) will be
set to the selected key's LocalKeyName. set to the selected key's LocalKeyName.
4.3. Key Selection for OSPF Packet Reception 4.3. Key Selection for OSPF Packet Reception
When cryptographic authentication is used, the ID of the When cryptographic authentication is used, the ID of the
authentication key is included in the authentication field of the authentication key is included in the authentication field of the
OSPF packet header. Using this Key ID, it is straight forward for a OSPF packet header. Using this Key ID, it is straight forward for a
receiver to locate the corresponding key. The simple requirements receiver to locate the corresponding key. The simple requirements
skipping to change at page 8, line 9 skipping to change at page 8, line 23
o The interface on which the key was received is associated with the o The interface on which the key was received is associated with the
key's interface. key's interface.
o The Key ID obtained from the OSPFv2 packet header corresponds to o The Key ID obtained from the OSPFv2 packet header corresponds to
the neighbor's PeerKeyName. Since OSPFv2 keys are symmetric, the the neighbor's PeerKeyName. Since OSPFv2 keys are symmetric, the
LocalKeyName and PeerKeyName for OSPFv2 keys will be identical. LocalKeyName and PeerKeyName for OSPFv2 keys will be identical.
Hence, the Key ID will be used to select the correct local key. Hence, the Key ID will be used to select the correct local key.
o The Direction field is either "in" or "both". o The Direction field is either "in" or "both".
o The Peers field matches as described in Sections Section 4.1 and
Section 4.2.
5. Securing the IP Header 5. Securing the IP Header
This document updates the definition of the Apad constant, as it is This document updates the definition of the Apad constant, as it is
defined in [RFC5709], to include the IP source address from the IP defined in [RFC5709], to include the IP source address from the IP
header of the OSPFv2 protocol packet. The overall cryptographic header of the OSPFv2 protocol packet. The overall cryptographic
authentication process defined in [RFC5709] remains unchanged. To authentication process defined in [RFC5709] remains unchanged. To
reduce the potential for confusion, this section minimizes the reduce the potential for confusion, this section minimizes the
repetition of text from RFC 5709 [RFC5709]. The changes are: repetition of text from RFC 5709 [RFC5709]. The changes are:
RFC 5709, Section 3.3 describes how the cryptographic authentication RFC 5709, Section 3.3 describes how the cryptographic authentication
skipping to change at page 11, line 34 skipping to change at page 11, line 48
Authentication", RFC 5709, October 2009, Authentication", RFC 5709, October 2009,
<http://www.rfc-editor.org/info/rfc5709>. <http://www.rfc-editor.org/info/rfc5709>.
10.2. Informative References 10.2. Informative References
[FIPS-198] [FIPS-198]
"US National Institute of Standards and Technology, "The "US National Institute of Standards and Technology, "The
Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB
198-1, July 2008. 198-1, July 2008.
[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base
for Network Management of TCP/IP-based internets: MIB-II",
STD 17, RFC 1213, March 1991,
<http://www.rfc-editor.org/info/rfc1213>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February Hashing for Message Authentication", RFC 2104, February
1997, <http://www.rfc-editor.org/info/rfc2104>. 1997, <http://www.rfc-editor.org/info/rfc2104>.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management (USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", STD 62, RFC 3414, December 2002, Protocol (SNMPv3)", STD 62, RFC 3414, December 2002,
<http://www.rfc-editor.org/info/rfc3414>. <http://www.rfc-editor.org/info/rfc3414>.
[RFC4222] Choudhury, G., Ed., "Prioritized Treatment of Specific [RFC4222] Choudhury, G., Ed., "Prioritized Treatment of Specific
skipping to change at page 13, line 40 skipping to change at page 13, line 40
Sam Hartman Sam Hartman
Painless Security Painless Security
EMail: hartmans-ietf@mit.edu EMail: hartmans-ietf@mit.edu
Dacheng Zhang Dacheng Zhang
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
Beijing Beijing
China China
EMail: dacheng.zdc@alibaba-inc.com EMail: dacheng.zhang@gmail.com
Acee Lindem (editor) Acee Lindem (editor)
Cisco Cisco
United States United States
EMail: acee@cisco.com EMail: acee@cisco.com
 End of changes. 15 change blocks. 
36 lines changed or deleted 43 lines changed or added

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