draft-ietf-ospf-security-extension-manual-keying-07.txt   draft-ietf-ospf-security-extension-manual-keying-08.txt 
OSPF Working Group M. Bhatia OSPF Working Group M. Bhatia
Internet-Draft Alcatel-Lucent Internet-Draft Alcatel-Lucent
Intended status: Standards Track S. Hartman Intended status: Standards Track S. Hartman
Expires: October 10, 2014 Painless Security Expires: November 20, 2014 Painless Security
D. Zhang D. Zhang
Huawei Technologies co., LTD. Huawei Technologies co., LTD.
A. Lindem A. Lindem
Ericsson Ericsson
April 8, 2014 May 19, 2014
Security Extension for OSPFv2 when using Manual Key Management Security Extension for OSPFv2 when using Manual Key Management
draft-ietf-ospf-security-extension-manual-keying-07 draft-ietf-ospf-security-extension-manual-keying-08
Abstract Abstract
The current OSPFv2 cryptographic authentication mechanism as defined The current OSPFv2 cryptographic authentication mechanism as defined
in RFC 2328 and RFC 5709 is vulnerable to both inter-session and in RFC 2328 and RFC 5709 is vulnerable to both inter-session and
intra-session replay attacks when using manual keying. Additionally, intra-session replay attacks when using manual keying. Additionally,
the existing cryptographic authentication mechanism does not cover the existing cryptographic authentication mechanism does not cover
the IP header. This omission can be exploited to carry out various the IP header. This omission can be exploited to carry out various
types of attacks. types of attacks.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 10, 2014. This Internet-Draft will expire on November 20, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 2, line 34 skipping to change at page 2, line 34
4. OSPF Packet Key Selection . . . . . . . . . . . . . . . . . . 6 4. OSPF Packet Key Selection . . . . . . . . . . . . . . . . . . 6
4.1. Key Selection for Unicast OSPF Packet Transmission . . . . 7 4.1. Key Selection for Unicast OSPF Packet Transmission . . . . 7
4.2. Key Selection for Multicast OSPF Packet Transmission . . . 8 4.2. Key Selection for Multicast OSPF Packet Transmission . . . 8
4.3. Key Selection for OSPF Packet Reception . . . . . . . . . 8 4.3. Key Selection for OSPF Packet Reception . . . . . . . . . 8
5. Securing the IP header . . . . . . . . . . . . . . . . . . . . 9 5. Securing the IP header . . . . . . . . . . . . . . . . . . . . 9
6. Mitigating Cross-Protocol Attacks . . . . . . . . . . . . . . 9 6. Mitigating Cross-Protocol Attacks . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 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
against replay attacks. The sequence numbers increase monotonically against replay attacks. The sequence numbers increase monotonically
so that attempts to replay stale packets can be thwarted. The so that attempts to replay stale packets can be thwarted. The
sequence number values are maintained as a part of neighbor adjacency sequence number values are maintained as a part of neighbor adjacency
state. Therefore, if an adjacency is taken down, the associated state. Therefore, if an adjacency is taken down, the associated
sequence numbers get reinitialized and neighbor adjacency formation sequence numbers get reinitialized and neighbor adjacency formation
skipping to change at page 4, line 13 skipping to change at page 4, line 13
"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 RFC2119 [RFC2119]. document are to be interpreted as described in RFC2119 [RFC2119].
When used in lowercase, these words convey their typical use in When used in lowercase, these words convey their typical use in
common language, and are not to be interpreted as described in common language, and are not to be interpreted as described in
RFC2119 [RFC2119]. RFC2119 [RFC2119].
1.2. Acknowledgments 1.2. Acknowledgments
Thanks to Ran Atkinson for help in the analysis of RFC 6506 errata Thanks to Ran Atkinson for help in the analysis of RFC 6506 errata
leading to clarifications in this document. leading to clarifications in this document. Thanks to Gabi Nakibly
for pointing out the possible attack on p2p links.
2. Replay Protection using Extended Sequence Numbers 2. Replay Protection using Extended Sequence Numbers
In order to provide replay protection against both inter-session and In order to provide replay protection against both inter-session and
intra-session replay attacks, the OSPFv2 sequence number is expanded intra-session replay attacks, the OSPFv2 sequence number is expanded
to 64-bits with the least significant 32-bit value containing a to 64-bits with the least significant 32-bit value containing a
strictly increasing sequence number and the most significant 32-bit strictly increasing sequence number and the most significant 32-bit
value containing the boot count. OSPFv2 implementations are required value containing the boot count. OSPFv2 implementations are required
to retain the boot count in non-volatile storage for the deployment to retain the boot count in non-volatile storage for the deployment
life the OSPF router. The requirement to preserve the boot count is life the OSPF router. The requirement to preserve the boot count is
skipping to change at page 11, line 14 skipping to change at page 11, line 14
formation packet exchange. Without adjacency formation, the replay formation packet exchange. Without adjacency formation, the replay
of OSPFv2 hello packets alone for an OSPFv2 router that has been of OSPFv2 hello packets alone for an OSPFv2 router that has been
taken out of service should not result in any serious attack as the taken out of service should not result in any serious attack as the
only consequence is superfluous processing. Of course, this attack only consequence is superfluous processing. Of course, this attack
could also be thwarted by changing the relevant manual keys. could also be thwarted by changing the relevant manual keys.
This document also provides a solution to prevent certain denial of This document also provides a solution to prevent certain denial of
service attacks that can be launched by changing the source address service attacks that can be launched by changing the source address
in the IP header of an OSPFv2 protocol packet. in the IP header of an OSPFv2 protocol packet.
Using a single crypto sequence number can leave the router vulnerable
to a replay attack where it uses the same source IP address on two
different point-to-point unnumbered links. In such environments
where an attacker can actively tap the point-to-point links, its
recommended that the user employes different keys on each of those
unnumbered IP interfaces.
8. IANA Considerations 8. IANA Considerations
This document requests a new code point from the "OSPF Shortest Path This document requests a new code point from the "OSPF Shortest Path
First (OSPF) Authentication Codes" registry: First (OSPF) Authentication Codes" registry:
o 3 - Cryptographic Authentication with Extended Sequence Numbers. o 3 - Cryptographic Authentication with Extended Sequence Numbers.
This document also requests a new code point from the "Authentication This document also requests a new code point from the "Authentication
Cryptographic Protocol ID" registry defined under "Keying and Cryptographic Protocol ID" registry defined under "Keying and
Authentication for Routing Protocols (KARP) Parameters": Authentication for Routing Protocols (KARP) Parameters":
 End of changes. 7 change blocks. 
7 lines changed or deleted 15 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/