draft-ietf-mpls-ldp-hello-crypto-auth-05.txt   draft-ietf-mpls-ldp-hello-crypto-auth-06.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 5, 2014 M. Bhatia Expires: November 22, 2014 M. Bhatia
Alcatel-Lucent Alcatel-Lucent
May 4, 2014 May 21, 2014
LDP Hello Cryptographic Authentication LDP Hello Cryptographic Authentication
draft-ietf-mpls-ldp-hello-crypto-auth-05.txt draft-ietf-mpls-ldp-hello-crypto-auth-06.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 5, 2014. This Internet-Draft will expire on November 22, 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 2, line 27 skipping to change at page 2, line 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Cryptographic Authentication TLV . . . . . . . . . . . . . . 4 2. Cryptographic Authentication TLV . . . . . . . . . . . . . . 4
2.1. Optional Parameter for Hello Message . . . . . . . . . . 4 2.1. Optional Parameter for Hello Message . . . . . . . . . . 4
2.2. LDP Security Association . . . . . . . . . . . . . . . . 4 2.2. LDP Security Association . . . . . . . . . . . . . . . . 4
2.3. Cryptographic Authentication TLV Encoding . . . . . . . . 6 2.3. Cryptographic Authentication TLV Encoding . . . . . . . . 6
2.4. Sequence Number Wrap . . . . . . . . . . . . . . . . . . 8 2.4. Sequence Number Wrap . . . . . . . . . . . . . . . . . . 8
3. Cryptographic Authentication Procedure . . . . . . . . . . . 8 3. Cryptographic Authentication Procedure . . . . . . . . . . . 8
4. Cross Protocol Attack Mitigation . . . . . . . . . . . . . . 8 4. Cross Protocol Attack Mitigation . . . . . . . . . . . . . . 8
5. Cryptographic Aspects . . . . . . . . . . . . . . . . . . . . 8 5. Cryptographic Aspects . . . . . . . . . . . . . . . . . . . . 8
5.1. Preparing the Cryptographic Key . . . . . . . . . . . . . 9 5.1. Preparing the Cryptographic Key . . . . . . . . . . . . . 9
5.2. Computing the Hash . . . . . . . . . . . . . . . . . . . 10 5.2. Computing the Hash . . . . . . . . . . . . . . . . . . . 9
5.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Processing Hello Message Using Cryptographic Authentication . 10 6. Processing Hello Message Using Cryptographic Authentication . 10
6.1. Transmission Using Cryptographic Authentication . . . . . 10 6.1. Transmission Using Cryptographic Authentication . . . . . 10
6.2. Receipt Using Cryptographic Authentication . . . . . . . 11 6.2. Receipt Using Cryptographic Authentication . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The Label Distribution Protocol (LDP) [RFC5036] sets up LDP sessions The Label Distribution Protocol (LDP) [RFC5036] sets up LDP sessions
that run between LDP peers. The peers could either be directly that run between LDP peers. The peers could either be directly
connected at the link level or could be multiple hops away. An LDP connected at the link level or could be multiple hops away. An LDP
Label Switching Router (LSR) could either be configured with the Label Switching Router (LSR) could either be configured with the
identity of its peers or could discover them using LDP Hello identity of its peers or could discover them using LDP Hello
messages. These messages are sent encapsulated in UDP addressed to messages. These messages are sent encapsulated in UDP addressed to
"all routers on this subnet" or to a specific IP address. Periodic "all routers on this subnet" or to a specific IP address. Periodic
skipping to change at page 4, line 4 skipping to change at page 4, line 4
number carried in the Hello messages that can be used to protect number carried in the Hello messages that can be used to protect
against replay attacks. The LSRs could be configured to only accept against replay attacks. The LSRs could be configured to only accept
Hello messages from specific peers when authentication is in use. Hello messages from specific peers when authentication is in use.
Using this Cryptographic Authentication TLV, one or more secret keys Using this Cryptographic Authentication TLV, one or more secret keys
(with corresponding Security Association (SA) IDs) are configured in (with corresponding Security Association (SA) IDs) are configured in
each system. For each LDP Hello message, the key is used to generate each system. For each LDP Hello message, the key is used to generate
and verify a HMAC Hash that is stored in the LDP Hello message. For and verify a HMAC Hash that is stored in the LDP Hello message. For
cryptographic hash function, this document proposes to use SHA-1, cryptographic hash function, this document proposes to use SHA-1,
SHA-256, SHA-384, and SHA-512 defined in US NIST Secure Hash Standard SHA-256, SHA-384, and SHA-512 defined in US NIST Secure Hash Standard
(SHS) [FIPS-180-3]. The HMAC authentication mode defined in NIST (SHS) [FIPS-180-3]. The HMAC authentication mode defined in
FIPS 198 is used [FIPS-198]. Of the above, implementations MUST [RFC2104] is used. Of the above, implementations MUST include
include support for at least HMAC-SHA-256 and SHOULD include support support for at least HMAC-SHA-256 and SHOULD include support for
for HMAC-SHA-1 and MAY include support for either of HMAC-SHA-384 or HMAC-SHA-1 and MAY include support for either of HMAC-SHA-384 or
HMAC-SHA-512. HMAC-SHA-512.
2. Cryptographic Authentication TLV 2. Cryptographic Authentication TLV
2.1. Optional Parameter for Hello Message 2.1. Optional Parameter for Hello Message
[RFC5036] defines the encoding for the Hello message. Each Hello [RFC5036] defines the encoding for the Hello message. Each Hello
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
skipping to change at page 6, line 20 skipping to change at page 6, line 20
generated with this LDP Security Association. generated with this LDP Security Association.
In order to achieve smooth key transition, KeyStartAccept SHOULD be In order to achieve smooth key transition, KeyStartAccept SHOULD be
less than KeyStartGenerate and KeyStopGenerate SHOULD be less than less than KeyStartGenerate and KeyStopGenerate SHOULD be less than
KeyStopAccept. If KeyStartGenerate or KeyStartAccept are left KeyStopAccept. If KeyStartGenerate or KeyStartAccept are left
unspecified, the time will default to 0 and the key will be used unspecified, the time will default to 0 and the key will be used
immediately. If KeyStopGenerate or KeyStopAccept are left immediately. If KeyStopGenerate or KeyStopAccept are left
unspecified, the time will default to infinity and the key's lifetime unspecified, the time will default to infinity and the key's lifetime
will be infinite. When a new key replaces an old, the will be infinite. When a new key replaces an old, the
KeyStartGenerate time for the new key MUST be less than or equal to KeyStartGenerate time for the new key MUST be less than or equal to
the KeyStopGenerate time of the old key. the KeyStopGenerate time of the old key. Any unspecified values are
encoded as Zero.
Key storage SHOULD persist across a system restart, warm or cold, to Key storage SHOULD persist across a system restart, warm or cold, to
avoid operational issues. In the event that the last key associated avoid operational issues. In the event that the last key associated
with an interface expires, it is unacceptable to revert to an with an interface expires, it is unacceptable to revert to an
unauthenticated condition, and not advisable to disrupt routing. unauthenticated condition, and not advisable to disrupt routing.
Therefore, the router SHOULD send a "last Authentication Key Therefore, the router SHOULD send a "last Authentication Key
expiration" notification to the network manager and treat the key as expiration" notification to the network manager and treat the key as
having an infinite lifetime until the lifetime is extended, the key having an infinite lifetime until the lifetime is extended, the key
is deleted by network management, or a new key is configured is deleted by network management, or a new key is configured
skipping to change at page 8, line 50 skipping to change at page 8, line 50
In order to prevent cross protocol replay attacks for protocols In order to prevent cross protocol replay attacks for protocols
sharing common keys, the two octet LDP Cryptographic Protocol ID is sharing common keys, the two octet LDP Cryptographic Protocol ID is
appended to the authentication key prior to use (refer to Section 8). appended to the authentication key prior to use (refer to Section 8).
Other protocols using the common key similarly append their own Other protocols using the common key similarly append their own
Cryptographic Protocol IDs to their keys prior to use thus ensuring Cryptographic Protocol IDs to their keys prior to use thus ensuring
that a different key value is used for each protocol. that a different key value is used for each protocol.
5. Cryptographic Aspects 5. Cryptographic Aspects
In the algorithm description below, the following nomenclature, which In the algorithm description below, the following nomenclature is
is consistent with [FIPS-198], is used: used:
H is the specific hashing algorithm (e.g. SHA-256). H is the specific hashing algorithm (e.g. SHA-256).
K is the Authentication Key from the LDP security association. K is the Authentication Key from the LDP security association.
Ks is a Protocol Specific Authentication Key obtained by appending Ks is a Protocol Specific Authentication Key obtained by appending
Authentication Key (K) with the two-octet LDP Cryptographic Protocol Authentication Key (K) with the two-octet LDP Cryptographic Protocol
ID appended. ID .
Ko is the cryptographic key used with the hash algorithm. Ko is the cryptographic key used with the hash algorithm.
B is the block size of H, measured in octets rather than bits.
Note that B is the internal block size, not the hash size.
For SHA-1 and SHA-256: B == 64
For SHA-384 and SHA-512: B == 128
L is the length of the hash, measured in octets rather than bits. L is the length of the hash, measured in octets rather than bits.
XOR is the exclusive-or operation. AuthTag is a value which is the same length as the hash output. In
case of IPv4, the first 4 octets contain the IPv4 source address
Opad is the hexadecimal value 0x5c repeated B times. followed by the hexadecimal value 0x878FE1F3 repeated (L-4)/4 times.
In case of IPv6, the first 16 octets contain the IPv6 source address
Ipad is the hexadecimal value 0x36 repeated B times. followed by the hexadecimal value 0x878FE1F3 repeated (L-16)/4 times.
This implies that hash output is always a length of at least 16
Apad is a value which is the same length as the hash output or octets.
message digest. In case of IPv4, the first 4 octets contain the IPv4
source address followed by the hexadecimal value 0x878FE1F3 repeated
(L-4)/4 times. In case of IPv6, the first 16 octets contain the IPv6
source address followed by the hexadecimal value 0x878FE1F3 repeated
(L-16)/4 times. This implies that hash output is always a length of
at least 16 octets.
5.1. Preparing the Cryptographic Key 5.1. Preparing the Cryptographic Key
The LDP Cryptographic Protocol ID is appended to the Authentication The LDP Cryptographic Protocol ID is appended to the Authentication
Key (K) yielding a Protocol Specific Authentication Key (Ks). In Key (K) yielding a Protocol Specific Authentication Key (Ks). In
this application, Ko is always L octets long. While [RFC2104] this application, Ko is always L octets long. Keys that are longer
supports a key that is up to B octets long, this application uses L than the bit length of the hash function are hashed to force them to
as the Ks length consistent with [RFC4822], [RFC5310], [RFC5709] and this length, as we describe below. Ks is computed as follows:
[RFC7166]. According to [FIPS-180-3], Section 3, keys greater than L
octets do not significantly increase the function strength. Ks is
computed as follows:
If the Protocol Specific Authentication Key (Ks) is L octets long, If the Protocol Specific Authentication Key (Ks) is L octets long,
then Ko is equal to Ks. If the Protocol Specific Authentication Key then Ko is equal to Ks. If the Protocol Specific Authentication Key
(Ks) is more than L octets long, then Ko is set to H(Ks). If the (Ks) is more than L octets long, then Ko is set to H(Ks). If the
Protocol Specific Authentication Key (Ks) is less than L octets long, Protocol Specific Authentication Key (Ks) is less than L octets long,
then Ko is set to the Protocol Specific Authentication Key (Ks) with then Ko is set to the Protocol Specific Authentication Key (Ks) with
zeros appended to the end of the Protocol Specific Authentication Key zeros appended to the end of the Protocol Specific Authentication Key
(Ks) such that Ko is L octets long. (Ks) such that Ko is L octets long.
For higher entropy it is RECOMMENDED that Key Ks should be at least L
octets long.
5.2. Computing the Hash 5.2. Computing the Hash
First, the Authentication Data field in the Cryptographic First, the Authentication Data field in the Cryptographic
Authentication TLV is filled with the value Apad. Then, to compute Authentication TLV is filled with the value AuthTag. Then, to
HMAC over the Hello message it performs: compute HMAC over the Hello message it performs:
H(Ko XOR Opad || H(Ko XOR Ipad || (Hello Message)))
Hello Message refers to the LDP Hello message excluding the IP
header.
When XORing Ko and Ipad, or XORing Ko and Opad, Ko must be padded AuthData = HMAC(Ko, Hello Message)
with zeros to the length of Ipad and the Opad. Hello Message refers to the LDP Hello message excluding the IP and
the UDP headers.
5.3. Result 5.3. Result
The resultant Hash becomes the Authentication Data that is sent in The resultant Hash becomes the Authentication Data that is sent in
the Authentication Data field of the Cryptographic Authentication the Authentication Data field of the Cryptographic Authentication
TLV. The length of the Authentication Data field is always identical TLV. The length of the Authentication Data field is always identical
to the message digest size of the specific hash function H that is to the message digest size of the specific hash function H that is
being used. being used.
This also means that the use of hash functions with larger output This also means that the use of hash functions with larger output
skipping to change at page 11, line 25 skipping to change at page 11, line 7
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 packet is less than If the cryptographic sequence number in the LDP packet is less than
or equal to the last sequence number received from the same neighbor, or equal to the last sequence number received from the same neighbor,
the LDP message MUST be discarded, and an error event SHOULD be the LDP message MUST be discarded, and an error event SHOULD be
logged. logged.
Before the receiving LSR performs any processing, it needs to save Before the receiving LSR performs any processing, it needs to save
the values of the Authentication Data field. The receiving LSR then the values of the Authentication Data field. The receiving LSR then
replaces the contents of the Authentication Data field with Apad, replaces the contents of the Authentication Data field with AuthTag,
computes the Hash, using the authentication key specified by the computes the Hash, using the authentication key specified by the
received Security Association ID field, as explained in Section 3. received Security Association ID field, as explained in Section 3.
If the locally computed Hash is equal to the received value of the If the locally computed Hash is equal to the received value of the
Authentication Data field, the received packet is accepted for other Authentication Data field, the received packet is accepted for other
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 packet MUST be discarded, the Authentication Data field, the received packet MUST be discarded,
and an error event SHOULD be logged. The foresaid logging need to be and an error event SHOULD be logged. The foresaid logging need to be
carefully rate limited, since while a LDP router is under attack of a carefully rate limited, since while a LDP router is under attack of a
storm of spoofed hellos, the resource taking for logging could be storm of spoofed hellos, the resource taking for logging could be
skipping to change at page 12, line 18 skipping to change at page 11, line 49
authentication type used. authentication type used.
It should be noted that the authentication method described in this It should be noted that the authentication method described in this
document is not being used to authenticate the specific originator of document is not being used to authenticate the specific originator of
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. Furthermore, it on the key are not feasible in their environments. In support of
is RECOMMENDED that Authentication Keys incorporate at least 128 these recommendations, management systems SHOULD support hexadecimal
pseudo-random bits to minimize the risk of such attacks. In support input of Authentication Keys.
of these recommendations, management systems SHOULD support
hexadecimal input of Authentication Keys.
The mechanism described herein is not perfect and does not need to be The mechanism described herein is not perfect . However, this
perfect. Instead, this mechanism represents a significant increase mechanism introduces a significant increase in the effort required
in the effort required for an adversary to successfully attack the for an adversary to successfully attack the LDP Hello protocol while
LDP Hello protocol while not causing undue implementation, not causing undue implementation, deployment, or operational
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 "Multiprotocol
Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Label Switching Architecture (MPLS) Label Switched Paths (LSPs)
Parameters - TLVs" registry, "TLVs and sub-TLVs" sub- registry. Parameters - TLVs" registry, "TLVs and sub-TLVs" sub- registry.
Value Meaning Reference Value Meaning Reference
----- -------------------------------- --------- ----- -------------------------------- ---------
TBD1 Cryptographic Authentication TLV this document (sect 2.3) TBD1 Cryptographic Authentication TLV this document (sect 2.3)
skipping to change at page 13, line 7 skipping to change at page 12, line 32
"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
The authors would like to thank Liu Xuehu for his work on background We are indebted to Yaron Sheffer who helped us enormously in
and motivation for LDP Hello authentication. The authors also would rewriting the draft to get rid of the redundant crypto mathematics
like to thank Adrian Farrel, Eric Rosen, Sam Hartman, Eric Gray, that we had added here.
Kamran Raza and Acee Lindem for their valuable comments.
We would also like to thank the authors of RFC 5709 and RFC 7166 from We would also like to thank Liu Xuehu for his work on background and
where we have taken most of the cryptographic computation procedures motivation for LDP Hello authentication. And last but not the least,
from. we would also thank Adrian Farrel, Eric Rosen, Sam Hartman, Stephen
Farrell, Eric Gray, Kamran Raza and Acee Lindem for their valuable
comments.
10. References 10. References
10.1. Normative References 10.1. Normative References
[FIPS-180-3] [FIPS-180-3]
"Secure Hash Standard (SHS), FIPS PUB 180-3", October "Secure Hash Standard (SHS), FIPS PUB 180-3", October
2008. 2008.
[FIPS-198] [FIPS-198]
"The Keyed-Hash Message Authentication Code (HMAC), FIPS "The Keyed-Hash Message Authentication Code (HMAC), FIPS
PUB 198", March 2002. PUB 198", March 2002.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic
Authentication", RFC 4822, February 2007. Authentication", RFC 4822, February 2007.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007. Specification", RFC 5036, October 2007.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
skipping to change at page 13, line 50 skipping to change at page 13, line 31
[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,
Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic
Authentication", RFC 5709, October 2009. Authentication", RFC 5709, October 2009.
[RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting
Authentication Trailer for OSPFv3", RFC 7166, March 2014. Authentication Trailer for OSPFv3", RFC 7166, March 2014.
10.2. Informative References 10.2. Informative References
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
Pignataro, "The Generalized TTL Security Mechanism Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, October 2007. (GTSM)", RFC 5082, October 2007.
[RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms
for the TCP Authentication Option (TCP-AO)", RFC 5926, for the TCP Authentication Option (TCP-AO)", RFC 5926,
June 2010. June 2010.
[RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security [RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security
Mechanism (GTSM) for the Label Distribution Protocol Mechanism (GTSM) for the Label Distribution Protocol
skipping to change at page 14, line 40 skipping to change at page 14, line 20
Mach(Guoyi) Chen Mach(Guoyi) Chen
Huawei Technologies Huawei Technologies
China China
Email: mach.chen@huawei.com Email: mach.chen@huawei.com
Manav Bhatia Manav Bhatia
Alcatel-Lucent Alcatel-Lucent
India India
Email: manav.bhatia@alcatel-lucent.com Email: manavbhatia@gmail.com
 End of changes. 27 change blocks. 
77 lines changed or deleted 59 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/