< draft-ietf-ospf-security-extension-manual-keying-08.txt   draft-ietf-ospf-security-extension-manual-keying-09.txt >
OSPF Working Group M. Bhatia OSPF Working Group M. Bhatia
Internet-Draft Alcatel-Lucent Internet-Draft Ionos Networks
Intended status: Standards Track S. Hartman Intended status: Standards Track S. Hartman
Expires: November 20, 2014 Painless Security Expires: April 9, 2015 Painless Security
D. Zhang D. Zhang
Huawei Technologies co., LTD. Huawei Technologies co., LTD.
A. Lindem A. Lindem
Ericsson Cisco
May 19, 2014 October 6, 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-08 draft-ietf-ospf-security-extension-manual-keying-09
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 November 20, 2014. This Internet-Draft will expire on April 9, 2015.
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 9, line 15 skipping to change at page 9, line 15
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
must be computed. It requires the OSPFv2 packet's Authentication must be computed. In RFC 5709, the First-Hash includes the OSPF
Trailer (which is the appendage described in RFC 2328, Section D.4.3, packet and Authentication Trailer. With this specification, the 64-
Page 233, items (6)(a) and (6)(d)) to be filled with the value Apad. bit sequence number will be included in the First-Hash along with the
Apad is a hexadecimal constant with the value 0x878FE1F3 repeated Authentication Trailer and OSPF packet.
(L/4) times, where L is the length of the hash being used and is
measured in octets rather than bits. RFC 5709, Section 3.3 also requires the OSPFv2 packet's
Authentication Trailer (which is the appendage described in RFC 2328,
Section D.4.3, Page 233, items (6)(a) and (6)(d)) to be filled with
the value Apad. Apad is a hexadecimal constant with the value
0x878FE1F3 repeated (L/4) times, where L is the length of the hash
being used and is measured in octets rather than bits.
OSPF routers sending OSPF packets must initialize Apad to the value OSPF routers sending OSPF packets must initialize Apad to the value
of the IP source address that would be used when sending an OSPFv2 of the IP source address that would be used when sending an OSPFv2
packet, repeated L/4 times, where L is the length of the hash, packet, repeated L/4 times, where L is the length of the hash,
measured in octets. The basic idea is to incorporate the IP source measured in octets. The basic idea is to incorporate the IP source
address from the IP header in the cryptographic authentication address from the IP header in the cryptographic authentication
computation so that any change of IP source address in a replayed computation so that any change of IP source address in a replayed
packet can be detected. packet can be detected.
When an OSPF packet is received, implementations MUST initialize Apad When an OSPF packet is received, implementations MUST initialize Apad
skipping to change at page 13, line 12 skipping to change at page 13, line 13
Authentication for Routing Protocols (KARP) Overview, Authentication for Routing Protocols (KARP) Overview,
Threats, and Requirements", RFC 6862, March 2013. Threats, and Requirements", RFC 6862, March 2013.
[RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security [RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security
According to the Keying and Authentication for Routing According to the Keying and Authentication for Routing
Protocols (KARP) Design Guide", RFC 6863, March 2013. Protocols (KARP) Design Guide", RFC 6863, March 2013.
Authors' Addresses Authors' Addresses
Manav Bhatia Manav Bhatia
Alcatel-Lucent Ionos Networks
Bangalore, Bangalore,
India India
Phone: Phone:
Email: manav.bhatia@alcatel-lucent.com Email: manav@ionosnetworks.com
Sam Hartman Sam Hartman
Painless Security Painless Security
Email: hartmans@painless-security.com Email: hartmans@painless-security.com
Dacheng Zhang Dacheng Zhang
Huawei Technologies co., LTD. Huawei Technologies co., LTD.
Beijing, Beijing,
China China
Phone: Phone:
Fax: Fax:
Email: zhangdacheng@huawei.com Email: zhangdacheng@huawei.com
URI: URI:
Acee Lindem Acee Lindem
Ericsson Cisco
301 Midenhall Way
Cary, NC 27513
USA USA
Phone: Phone:
Email: acee.lindem@ericsson.com Email: acee@cisco.com
 End of changes. 10 change blocks. 
17 lines changed or deleted 20 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/