draft-ietf-mpls-ldp-hello-crypto-auth-06.txt   draft-ietf-mpls-ldp-hello-crypto-auth-07.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: November 22, 2014 M. Bhatia Expires: November 30, 2014 M. Bhatia
Alcatel-Lucent Alcatel-Lucent
May 21, 2014 May 29, 2014
LDP Hello Cryptographic Authentication LDP Hello Cryptographic Authentication
draft-ietf-mpls-ldp-hello-crypto-auth-06.txt draft-ietf-mpls-ldp-hello-crypto-auth-07.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 National Institute of Standards and the LDP Hello messages using National Institute of Standards and
Technology (NIST) Secure Hash Standard family of algorithms. Technology (NIST) Secure Hash Standard family of algorithms.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 22, 2014. This Internet-Draft will expire on November 30, 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 4, line 25 skipping to change at page 4, line 25
message contains zero or more Optional Parameters, each encoded as a message contains zero or more Optional Parameters, each encoded as a
TLV. Three Optional Parameters are defined by [RFC5036]. This TLV. Three Optional Parameters are defined by [RFC5036]. This
document defines a new Optional Parameter: the Cryptographic document defines a new Optional Parameter: the Cryptographic
Authentication parameter. Authentication parameter.
Optional Parameter Type Optional Parameter Type
------------------------------- -------- ------------------------------- --------
IPv4 Transport Address 0x0401 (RFC5036) IPv4 Transport Address 0x0401 (RFC5036)
Configuration Sequence Number 0x0402 (RFC5036) Configuration Sequence Number 0x0402 (RFC5036)
IPv6 Transport Address 0x0403 (RFC5036) IPv6 Transport Address 0x0403 (RFC5036)
Cryptographic Authentication 0x0404 (this document, TBD1 by IANA) Cryptographic Authentication TBD1 (this document, TBD1 by IANA)
The Cryptographic Authentication TLV Encoding is described in section The Cryptographic Authentication TLV Encoding is described in section
2.3. 2.3.
2.2. LDP Security Association 2.2. LDP Security Association
An LDP Security Association (SA) contains a set of parameters shared An LDP Security Association (SA) contains a set of parameters shared
between any two legitimate LDP speakers. between any two legitimate LDP speakers.
Parameters associated with an LDP SA are as follows: Parameters associated with an LDP SA are as follows:
skipping to change at page 12, line 5 skipping to change at page 12, line 5
a packet but is rather being used to confirm that the packet has a packet but is rather being used to confirm that the packet has
indeed been issued by a router that has access to the Authentication indeed been issued by a router that has access to the Authentication
Key. Key.
Deployments SHOULD use sufficiently long and random values for the Deployments SHOULD use sufficiently long and random values for the
Authentication Key so that guessing and other cryptographic attacks Authentication Key so that guessing and other cryptographic attacks
on the key are not feasible in their environments. In support of on the key are not feasible in their environments. In support of
these recommendations, management systems SHOULD support hexadecimal these recommendations, management systems SHOULD support hexadecimal
input of Authentication Keys. input of Authentication Keys.
The mechanism described herein is not perfect . However, this The mechanism described herein is not perfect . However, this
mechanism introduces a significant increase in the effort required mechanism introduces a significant increase in the effort required
for an adversary to successfully attack the LDP Hello protocol while for an adversary to successfully attack the LDP Hello protocol while
not causing undue implementation, deployment, or operational not causing undue implementation, deployment, or operational
complexity. complexity.
8. IANA Considerations 8. IANA Considerations
The IANA is requested to as assign a new TLV from the "Multiprotocol The IANA is requested to as assign a new TLV from the "Label
Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Distribution Protocol (LDP) Parameters" registry, "TLV Type Name
Parameters - TLVs" registry, "TLVs and sub-TLVs" sub- registry. Space".
Value Meaning Reference Value Meaning Reference
----- -------------------------------- --------- ----- -------------------------------- ------------------------
TBD1 Cryptographic Authentication TLV this document (sect 2.3) TBD1 Cryptographic Authentication TLV this document (sect 2.3)
The IANA is also requested to as assign value from the The IANA is also requested to as assign value from the
"Authentication Cryptographic Protocol ID", registry under the "Authentication Cryptographic Protocol ID", registry under the
"Keying and Authentication for Routing Protocols (KARP) Parameters" "Keying and Authentication for Routing Protocols (KARP) Parameters"
category. category.
Value Meaning Reference Value Meaning Reference
----- -------------------------------- --------- ----- -------------------------------- ----------------------
TBD2 LDP Cryptographic Protocol ID this document (sect 4) TBD2 LDP Cryptographic Protocol ID this document (sect 4)
9. Acknowledgements 9. Acknowledgements
We are indebted to Yaron Sheffer who helped us enormously in We are indebted to Yaron Sheffer who helped us enormously in
rewriting the draft to get rid of the redundant crypto mathematics rewriting the draft to get rid of the redundant crypto mathematics
that we had added here. that we had added here.
We would also like to thank Liu Xuehu for his work on background and We would also like to thank Liu Xuehu for his work on background and
motivation for LDP Hello authentication. And last but not the least, motivation for LDP Hello authentication. And last but not the least,
we would also thank Adrian Farrel, Eric Rosen, Sam Hartman, Stephen we would also thank Adrian Farrel, Eric Rosen, Sam Hartman, Stephen
 End of changes. 9 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/