draft-ietf-mpls-ldp-hello-crypto-auth-01.txt   draft-ietf-mpls-ldp-hello-crypto-auth-02.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: July 26, 2013 M. Bhatia Expires: March 2, 2014 M. Bhatia
Alcatel-Lucent Alcatel-Lucent
January 22, 2013 August 29, 2013
LDP Hello Cryptographic Authentication LDP Hello Cryptographic Authentication
draft-ietf-mpls-ldp-hello-crypto-auth-01.txt draft-ietf-mpls-ldp-hello-crypto-auth-02.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 2, line 26 skipping to change at page 2, line 26
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 July 26, 2013. This Internet-Draft will expire on March 2, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 3, line 12 skipping to change at page 3, line 12
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Cryptographic Authentication TLV . . . . . . . . . . . . . . . 6 2. Cryptographic Authentication TLV . . . . . . . . . . . . . . . 6
2.1. Optional Parameter for Hello Message . . . . . . . . . . . 6 2.1. Optional Parameter for Hello Message . . . . . . . . . . . 6
2.2. Cryptographic Authentication TLV Encoding . . . . . . . . 6 2.2. Cryptographic Authentication TLV Encoding . . . . . . . . 6
2.3. Sequence Number Wrap . . . . . . . . . . . . . . . . . . . 7
3. Cryptographic Aspects . . . . . . . . . . . . . . . . . . . . 8 3. Cryptographic Authentication Procedure . . . . . . . . . . . . 8
3.1. Cryptographic Key . . . . . . . . . . . . . . . . . . . . 8
3.2. Hash . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Processing Hello Message Using Cryptographic Authentication . 10 4. Cross Protocol Attack Mitigation . . . . . . . . . . . . . . . 9
4.1. Transmission Using Cryptographic Authentication . . . . . 10
4.2. Receipt Using Cryptographic Authentication . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Cryptographic Aspects . . . . . . . . . . . . . . . . . . . . 10
5.1. Preparing the Cryptographic Key . . . . . . . . . . . . . 10
5.2. Computing the Hash . . . . . . . . . . . . . . . . . . . . 11
5.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Processing Hello Message Using Cryptographic Authentication . 12
6.1. Transmission Using Cryptographic Authentication . . . . . 12
6.2. Receipt Using Cryptographic Authentication . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
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 runs between LDP peers. The peers could either be directly that runs 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 7, line 13 skipping to change at page 7, line 13
secret key used to create the message digest carried in LDP payload. secret key used to create the message digest carried in LDP payload.
- Cryptographic Sequence Number: 64-bit strictly increasing sequence - Cryptographic Sequence Number: 64-bit strictly increasing sequence
number that is used to guard against replay attacks. The 64-bit number that is used to guard against replay attacks. The 64-bit
sequence number MUST be incremented for every LDP Hello packet sent sequence number MUST be incremented for every LDP Hello packet sent
by the LDP router. Upon reception, the sequence number MUST be by the LDP router. Upon reception, the sequence number MUST be
greater than the sequence number in the last LDP Hello packet greater than the sequence number in the last LDP Hello packet
accepted from the sending LDP neighbor. Otherwise, the LDP packet is accepted from the sending LDP neighbor. Otherwise, the LDP packet is
considered a replayed packet and dropped. considered a replayed packet and dropped.
LDP routers implementing this specification SHOULD use available LDP routers implementing this specification MUST use available
mechanisms to preserve the sequence number's strictly increasing mechanisms to preserve the sequence number's strictly increasing
property for the deployed life of the LDP router (including cold property for the deployed life of the LDP router (including cold
restarts). One mechanism for accomplishing this could be to use the restarts). One mechanism for accomplishing this could be to use the
high-order 32 bits of the sequence number as a wrap/boot count that high-order 32 bits of the sequence number as a wrap/boot count that
is incremented anytime the LDP router loses its sequence number is incremented anytime the LDP router loses its sequence number
state. Techniques such as sequence number space partitioning state. Techniques such as sequence number space partitioning
described above or non-volatile storage preservation can be used but described above or non-volatile storage preservation can be used but
are really beyond the scope of this specification. are really beyond the scope of this specification. Sequence number
wrap is described in Section 2.3.
- Authentication Data: - Authentication Data:
This field carries the digest computed by the Cryptographic This field carries the digest computed by the Cryptographic
Authentication algorithm in use. The length of the Authentication Authentication algorithm in use. The length of the Authentication
Data varies based on the cryptographic algorithm in use, which is Data varies based on the cryptographic algorithm in use, which is
shown as below: shown as below:
Auth type Length Auth type Length
--------------- ---------- --------------- ----------
HMAC-SHA1 20 bytes HMAC-SHA1 20 bytes
HMAC-SHA-256 32 bytes HMAC-SHA-256 32 bytes
HMAC-SHA-384 48 bytes HMAC-SHA-384 48 bytes
HMAC-SHA-512 64 bytes HMAC-SHA-512 64 bytes
3. Cryptographic Aspects 2.3. Sequence Number Wrap
When incrementing the sequence number for each transmitted LDP
packet, the sequence number should be treated as an unsigned 64-bit
value. If the lower order 32-bit value wraps, the higher order 32-
bit value should be incremented and saved in non-volatile storage.
If by some chance the LDP router is deployed long enough that there
is a possibility that the 64-bit sequence number may wrap, all keys,
independent of key distribution mechanism, MUST be reset to avoid the
possibility of replay attacks. Once the keys have been changed, the
higher order sequence number can be reset to 0 and saved to non-
volatile storage.
3. Cryptographic Authentication Procedure
As noted earlier, the Auth Key ID maps to the authentication
algorithm and the secret key used to generate and verify the message
digest. This specification discusses the computation of LDP
Cryptographic Authentication data when any of the NIST SHS family of
algorithms is used in the Hashed Message Authentication Code (HMAC)
mode.
The currently valid algorithms (including mode) for LDP Cryptographic
Authentication include:
HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 and HMAC-SHA-512
Of the above, implementations of this specification MUST include
support for at least HMAC-SHA-256 and SHOULD include support for
HMAC-SHA-1 and MAY also include support for HMAC-SHA-384 and HMAC-
SHA-512.
Implementations of this standard MUST use HMAC-SHA-256 as the default
authentication algorithm.
4. Cross Protocol Attack Mitigation
In order to prevent cross protocol replay attacks for protocols
sharing common keys, the two octet LDP Cryptographic Protocol ID is
appended to the authentication key prior to use. Other protocols
using cryptographic authentication as specified herein MUST similarly
append their respective Cryptographic Protocol IDs to their keys in
this step. Refer to IANA Considerations (Section 8).
5. Cryptographic Aspects
In the algorithm description below, the following nomenclature, which In the algorithm description below, the following nomenclature, which
is consistent with [FIPS-198], is used: is consistent with [FIPS-198], is used:
- H is the specific hashing algorithm specified by Auth Type (e.g. H is the specific hashing algorithm (e.g. SHA-256).
SHA-256).
- K is the Authentication Key for the Hello packet. K is the Authentication Key from the LDP security association.
- Ko is the cryptographic key used with the hash algorithm. Ks is a Protocol Specific Authentication Key obtained by appending
Authentication Key (K) with the two-octet LDP Cryptographic Protocol
ID appended.
- B is the block size of H, in octets. Ko is the cryptographic key used with the hash algorithm.
For SHA-1 and SHA-256: B == 64 B is the block size of H, measured in octets rather than bits.
For SHA-384 and SHA-512: B == 128
- L is the length of the hash outputs, in octets. Note that B is the internal block size, not the hash size.
- XOR is the exclusive-or operation. For SHA-1 and SHA-256: B == 64
- Ipad is the byte 0x36 repeated B times. For SHA-384 and SHA-512: B == 128
- Opad is the byte 0x5c repeated B times. L is the length of the hash, measured in octets rather than bits.
- Apad is source IP address that the would be used when sending out XOR is the exclusive-or operation.
the LDP packet, repeated L/4 times, where L is the length of the
hash, measured in octets.
3.1. Cryptographic Key Opad is the hexadecimal value 0x5c repeated B times.
As described in [RFC2104], the authentication key K can be of any Ipad is the hexadecimal value 0x36 repeated B times.
length up to B. Applications that use keys longer than B bytes will
first hash the key using H and then use the resultant L byte string
as the actual key to HMAC.
In this application, Ko is always L octets long. If the Apad is a value which is the same length as the hash output or
Authentication Key (K) is L octets long, then Ko is equal to K. If message digest. In case of IPv4, the first 4 octets contain the IPv4
the Authentication Key (K) is more than L octets long, then Ko is set source address followed by the hexadecimal value 0x878FE1F3 repeated
to H(K). If the Authentication Key (K) is less than L octets long, (L-4)/4 times. In case of IPv6, the first 16 octets contain the IPv6
then Ko is set to the Authentication Key (K) with trailing zeros such source address followed by the hexadecimal value 0x878FE1F3 repeated
that Ko is L octets long. (L-16)/4 times. This implies that hash output is always a length of
at least 16 octets.
3.2. Hash 5.1. Preparing the Cryptographic Key
The LDP Cryptographic Protocol ID is appended to the Authentication
Key (K) yielding a Protocol Specific Authentication Key (Ks). In
this application, Ko is always L octets long. While [RFC2104]
supports a key that is up to B octets long, this application uses L
as the Ks length consistent with [RFC4822], [RFC5310], [RFC5709] and
[RFC6506]. 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,
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
Protocol Specific Authentication Key (Ks) is less than L octets long,
then Ko is set to the Protocol Specific Authentication Key (Ks) with
zeros appended to the end of the Protocol Specific Authentication Key
(Ks) such that Ko is L octets long.
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 Apad. Then, to compute
HMAC over the Hello packet it performs: HMAC over the Hello packet it performs:
H(Ko XOR Opad || H(Ko XOR Ipad || (Hello Packet))) H(Ko XOR Opad || H(Ko XOR Ipad || (Hello Packet)))
Hello Packet refers to the LDP Hello packet excluding the IP header. Hello Packet refers to the LDP Hello packet excluding the IP header.
3.3. Result When XORing Ko and Ipad, or XORing Ko and Opad, Ko must be padded
with zeros to the length of Ipad and the Opad.
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.
4. Processing Hello Message Using Cryptographic Authentication This also means that the use of hash functions with larger output
sizes will also increase the size of the LDP packet as transmitted on
the wire.
4.1. Transmission Using Cryptographic Authentication 6. Processing Hello Message Using Cryptographic Authentication
6.1. Transmission Using Cryptographic Authentication
Prior to transmitting Hello message, the Length in the Cryptographic Prior to transmitting Hello message, the Length in the Cryptographic
Authentication TLV header is set as per the authentication algorithm Authentication TLV header is set as per the authentication algorithm
that is being used. It is set to 24 for HMAC-SHA-1, 36 for HMAC-SHA- that is being used. It is set to 24 for HMAC-SHA-1, 36 for HMAC-SHA-
256, 52 for HMAC-SHA-384 and 68 for HMAC-SHA-512. 256, 52 for HMAC-SHA-384 and 68 for HMAC-SHA-512.
The Auth Key ID field is set to the ID of the current authentication The Auth Key ID field is set to the ID of the current authentication
key. The HMAC Hash is computed as explained in Section 3. The key. The HMAC Hash is computed as explained in Section 3. The
resulting Hash is stored in the Authentication Data field prior to resulting Hash is stored in the Authentication Data field prior to
transmission. The authentication key MUST NOT be carried in the transmission. The authentication key MUST NOT be carried in the
packet. packet.
4.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].
If the Auth Key ID field does not match the ID of a configured If the Auth Key ID field does not match the ID of a configured
authentication key, the received packet MUST be discarded. authentication key, the received packet MUST be discarded.
If the cryptographic sequence number in the LDP packet is less than If the cryptographic sequence number in the LDP packet is less than
skipping to change at page 11, line 5 skipping to change at page 13, line 5
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 Apad,
computes the Hash, using the authentication key specified by the computes the Hash, using the authentication key specified by the
received Auth Key ID field, as explained in Section 3. If the received Auth Key ID field, as explained in Section 3. If the
locally computed Hash is equal to the received value of 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.
5. Security Considerations 7. Security Considerations
Section 1 of this document describes the security issues arising from Section 1 of this document describes the security issues arising from
the use of unauthenticated LDP Hello messages. In order to address the use of unauthenticated LDP Hello messages. In order to address
those issues, it is RECOMMENDED that all deployments use the those issues, it is RECOMMENDED that all deployments use the
Cryptographic Authentication TLV to authenticate the Hello messages. Cryptographic Authentication TLV to authenticate the Hello messages.
The quality of the security provided by the Cryptographic The quality of the security provided by the Cryptographic
Authentication TLV depends completely on the strength of the Authentication TLV depends completely on the strength of the
cryptographic algorithm in use, the strength of the key being used, cryptographic algorithm in use, the strength of the key being used,
and the correct implementation of the security mechanism in and the correct implementation of the security mechanism in
skipping to change at page 12, line 5 skipping to change at page 14, line 5
pseudo-random bits to minimize the risk of such attacks. In support pseudo-random bits to minimize the risk of such attacks. In support
of these recommendations, management systems SHOULD support of these recommendations, management systems SHOULD support
hexadecimal input of Authentication Keys. 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 and does not need to be
perfect. Instead, this mechanism represents a significant increase perfect. Instead, this mechanism represents a significant increase
in the effort required for an adversary to successfully attack the in the effort required for an adversary to successfully attack the
LDP Hello protocol while not causing undue implementation, LDP Hello protocol while not causing undue implementation,
deployment, or operational complexity. deployment, or operational complexity.
6. 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
----- -------------------------------- --------- ----- -------------------------------- ---------
TBD Cryptographic Authentication TLV this document (sect 3.2) TBD Cryptographic Authentication TLV this document (sect 3.2)
7. Acknowledgements The IANA is also requested to as assign value from the
"Authentication Cryptographic Protocol ID", registry under the
"Keying and Authentication for Routing Protocols (KARP) Parameters"
category.
Value Meaning Reference
----- -------------------------------- ---------
TBD LDP Cryptographic Protocol ID this document (sect 4)
9. Acknowledgements
The authors would like to thank Liu Xuehu for his work on background The authors would like to thank Liu Xuehu for his work on background
and motivation for LDP Hello authentication. The authors also would and motivation for LDP Hello authentication. The authors also would
like to thank Adrian Farrel, Eric Rosen, Sam Hartman, Eric Gray, like to thank Adrian Farrel, Eric Rosen, Sam Hartman, Eric Gray,
Kamran Raza and Acee Lindem for their valuable comments. Kamran Raza and Acee Lindem for their valuable comments.
We would also like to thank the authors of RFC 5709 from where we We would also like to thank the authors of RFC 5709 and RFC 6506 from
have taken most of the cryptographic computation procedures from. where we have taken most of the cryptographic computation procedures
from.
8. References 10. References
8.1. Normative References 10.1. Normative References
[FIPS-180-3] [FIPS-180-3]
"Secure Hash Standard (SHS), FIPS PUB 180-3", "Secure Hash Standard (SHS), FIPS PUB 180-3",
October 2008. October 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- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
February 1997. 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
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.
8.2. Informative References [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, February 2009.
[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,
Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic
Authentication", RFC 5709, October 2009.
[RFC6506] Bhatia, M., Manral, V., and A. Lindem, "Supporting
Authentication Trailer for OSPFv3", RFC 6506,
February 2012.
10.2. Informative References
[I-D.ietf-karp-routing-tcp-analysis] [I-D.ietf-karp-routing-tcp-analysis]
Jethanandani, M., Patel, K., and L. Zheng, "Analysis of Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP and MSDP Issues According to KARP Design BGP, LDP, PCEP and MSDP Issues According to KARP Design
Guide", draft-ietf-karp-routing-tcp-analysis-06 (work in Guide", draft-ietf-karp-routing-tcp-analysis-07 (work in
progress), December 2012. progress), April 2013.
[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.
Authors' Addresses Authors' Addresses
Lianshu Zheng Lianshu Zheng
Huawei Technologies Huawei Technologies
China China
 End of changes. 42 change blocks. 
61 lines changed or deleted 158 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/