draft-ietf-mpls-ldp-hello-crypto-auth-09.txt   draft-ietf-mpls-ldp-hello-crypto-auth-10.txt 
Network Working Group L. Zheng Network Working Group L. Zheng
Internet-Draft M. Chen Internet-Draft M. Chen
Intended status: Standards Track Huawei Technologies Intended status: Standards Track Huawei Technologies
Expires: December 20, 2014 M. Bhatia Expires: December 21, 2014 M. Bhatia
Ionos Networks Ionos Networks
June 18, 2014 June 19, 2014
LDP Hello Cryptographic Authentication LDP Hello Cryptographic Authentication
draft-ietf-mpls-ldp-hello-crypto-auth-09.txt draft-ietf-mpls-ldp-hello-crypto-auth-10.txt
Abstract Abstract
This document introduces a new optional Cryptographic Authentication This document introduces a new optional Cryptographic Authentication
TLV that LDP can use to secure its Hello messages. It secures the TLV that LDP can use to secure its Hello messages. It secures the
Hello messages against spoofing attacks and some well known attacks Hello messages against spoofing attacks and some well known attacks
against the IP header. This document describes a mechanism to secure against the IP header. This document describes a mechanism to secure
the LDP Hello messages using Hashed Message Authentication Code the LDP Hello messages using Hashed Message Authentication Code
(HMAC) with National Institute of Standards and Technology (NIST) (HMAC) with National Institute of Standards and Technology (NIST)
Secure Hash Standard family of algorithms. Secure Hash Standard family of algorithms.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 December 20, 2014. This Internet-Draft will expire on December 21, 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
skipping to change at page 11, line 16 skipping to change at page 11, line 16
6.2. Receipt Using Cryptographic Authentication 6.2. Receipt Using Cryptographic Authentication
The receiving LSR applies acceptability criteria for received Hellos The receiving LSR applies acceptability criteria for received Hellos
using cryptographic authentication. If the Cryptographic using cryptographic authentication. If the Cryptographic
Authentication TLV is unknown to the receiving LSR, the received Authentication TLV is unknown to the receiving LSR, the received
packet MUST be discarded according to Section 3.5.1.2.2 of [RFC5036]. packet MUST be discarded according to Section 3.5.1.2.2 of [RFC5036].
The receiving router MUST determine whether to accept a Hello Message The receiving router MUST determine whether to accept a Hello Message
from a particular source IP address as follows. First, if the router from a particular source IP address as follows. First, if the router
has, for that source IP address, any LDP Hello authentication has, for that source IP address, a stored LDP Hello cryptographic
information, such as a stored cryptographic sequence number or that sequence number, or is configured to require LDP Hello
LDP Hello authentication is required, then the router MUST discard authentication, then the router MUST discard any unauthenticated
any unauthenticated Hello packets. As specified later in this Hello packets. As specified later in this section, a cryptographic
section, a cryptographic sequence number is only stored for a source sequence number is only stored for a source IP address as a result of
IP address as a result of receiving a valid authenticated Hello. receiving a valid authenticated Hello.
The receiving LSR locates the LDP SA using the Security Association The receiving LSR locates the LDP SA using the Security Association
ID field carried in the message. If the SA is not found, or if the ID field carried in the message. If the SA is not found, or if the
SA is not valid for reception (i.e., current time < KeyStartAccept or SA is not valid for reception (i.e., current time < KeyStartAccept or
current time >= KeyStopAccept), LDP Hello message MUST be discarded, current time >= KeyStopAccept), LDP Hello message MUST be discarded,
and an error event SHOULD be logged. and an error event SHOULD be logged.
If the cryptographic sequence number in the LDP Hello message is less If the cryptographic sequence number in the LDP Hello message is less
than or equal to the last sequence number received from the same than or equal to the last sequence number received from the same
neighbor, the LDP Hello message MUST be discarded, and an error event neighbor, the LDP Hello message MUST be discarded, and an error event
skipping to change at page 11, line 51 skipping to change at page 11, line 51
normal checks and processing as described in [RFC5036]. Otherwise, normal checks and processing as described in [RFC5036]. Otherwise,
if the locally computed Hash is not equal to the received value of if the locally computed Hash is not equal to the received value of
the Authentication Data field, the received LDP Hello message MUST be the Authentication Data field, the received LDP Hello message MUST be
discarded, and an error event SHOULD be logged. The foresaid logging discarded, and an error event SHOULD be logged. The foresaid logging
need to be carefully rate limited, since while a LDP router is under need to be carefully rate limited, since while a LDP router is under
attack of a storm of spoofed hellos, the resource taking for logging attack of a storm of spoofed hellos, the resource taking for logging
could be overwelming. could be overwelming.
After the LDP Hello message has been successfully authenticated, After the LDP Hello message has been successfully authenticated,
implementations MUST store the 64-bit cryptographic sequence number implementations MUST store the 64-bit cryptographic sequence number
for the LDP Hello message received from the neighbor. The saved for the LDP Hello message received from the source IP address. The
cryptographic sequence numbers will be used for replay checking for saved cryptographic sequence numbers will be used for replay checking
subsequent packets received from the neighbor. for subsequent packets received from the source IP address.
7. Operational Considerations 7. Operational Considerations
Careful consideration must be given to when and how to enable and Careful consideration must be given to when and how to enable and
disable authentication on LDP Hellos. On the one hand, it is disable authentication on LDP Hellos. On the one hand, it is
critical that an attack cannot cause the authentication to be critical that an attack cannot cause the authentication to be
disabled. On the other hand, it is equally important that an disabled. On the other hand, it is equally important that an
operator can change the hardware and/or software associated with a operator can change the hardware and/or software associated with a
neighbor's IP address and successfully bring up an LDP adjacency with neighbor's IP address and successfully bring up an LDP adjacency with
the desired level of authentication, which may be with different or the desired level of authentication, which may be with different or
 End of changes. 6 change blocks. 
13 lines changed or deleted 13 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/