draft-ietf-karp-routing-tcp-analysis-01.txt   draft-ietf-karp-routing-tcp-analysis-02.txt 
Routing Working Group M. Jethanandani Routing Working Group M. Jethanandani
Internet-Draft Private Internet-Draft Ciena Corporation
Intended status: Informational K. Patel Intended status: Informational K. Patel
Expires: September 27, 2012 Cisco Systems, Inc Expires: December 25, 2012 Cisco Systems, Inc
L. Zheng L. Zheng
Huawei Huawei
March 26, 2012 June 23, 2012
Analysis of BGP, LDP, PCEP, and MSDP Security According to KARP Design Analysis of BGP, LDP, PCEP and MSDP Issues According to KARP Design
Guide Guide
draft-ietf-karp-routing-tcp-analysis-01.txt draft-ietf-karp-routing-tcp-analysis-02.txt
Abstract Abstract
This document analyzes BGP, LDP, PCEP and MSDP according to This document analyzes BGP, LDP, PCEP and MSDP according to
guidelines set forth in section 4.2 of Keying and Authentication for guidelines set forth in section 4.2 of Keying and Authentication for
Routing Protocols Design Guidelines [RFC6518]. Routing Protocols Design Guidelines [RFC6518].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].. document are to be interpreted as described in RFC 2119 [RFC2119]..
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 September 27, 2012. This Internet-Draft will expire on December 25, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 8 skipping to change at page 3, line 8
6. Security Requirements . . . . . . . . . . . . . . . . . . . . 13 6. Security Requirements . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
In March 2006 the Internet Architecture Board (IAB) in its "Unwanted In March 2006 the Internet Architecture Board (IAB) in its "Unwanted
Internet Traffic" workshop documented in Report from the IAB workship Internet Traffic" workshop documented in Report from the IAB workshop
on Unwanted Traffic March 9-10, 2006 [RFC4948] described an attack on on Unwanted Traffic March 9-10, 2006 [RFC4948] described an attack on
core routing infrastructure as an ideal attack with the most amount core routing infrastructure as an ideal attack with the most amount
of damage. Four main steps were identified for that tightening: of damage. Four main steps were identified for that tightening:
1. Create secure mechanisms and practices for operating routers. 1. Create secure mechanisms and practices for operating routers.
2. Clean up the Internet Routing Registry [IRR] repository, and 2. Clean up the Internet Routing Registry [IRR] repository, and
securing both the database and the access, so that it can be used securing both the database and the access, so that it can be used
for routing verifications. for routing verifications.
3. Create specifications for cryptographic validation of routing 3. Create specifications for cryptographic validation of routing
message content. message content.
4. Secure the routing protocols' packets on the wire. 4. Secure the routing protocols' packets on the wire.
This document looking at the last bullet performs the initial This document looking at the last bullet performs the initial
analysis of the current state of BGP, LDP, PCEP and MSDP according to analysis of the current state of BGP, LDP, PCEP and MSDP according to
the requirements of KARP Design Guidelines [RFC6518]. This draft the requirements of KARP Design Guidelines [RFC6518]. This draft
builds on several previous analysis efforts into routing security. builds on several previous analysis efforts into routing security.
The OPSEC working group put together Issues with existing The OPSEC working group put together Issues with existing
Cryptographic Protection Methods for Routing Protocols Cryptographic Protection Methods for Routing Protocols [RFC6039] an
[draft-ietf-opsec-routing-protocols-crypto-issues-07] an analysis of analysis of cryptographic issues with routing protocols and Analysis
cryptographic issues with routing protocols and Analysis of OSPF of OSPF Security According to KARP Design Guide
Security According to KARP Design Guide
[draft-ietf-karp-ospf-analysis-03]. [draft-ietf-karp-ospf-analysis-03].
Section 2 looks at the current state of the four routing protocols. Section 2 looks at the current state of the four routing protocols.
Section 3 goes into what the optimal state would be for the three Section 3 goes into what the optimal state would be for the three
routing protocols according to KARP Design Guidelines [RFC6518] and routing protocols according to KARP Design Guidelines [RFC6518] and
Section 4 does a analysis of the gap between the existing state and Section 4 does a analysis of the gap between the existing state and
the optimal state of the protocols and suggest some areas where we the optimal state of the protocols and suggest some areas where we
need to improve. need to improve.
1.1. Contributing Authors 1.1. Contributing Authors
skipping to change at page 5, line 20 skipping to change at page 5, line 20
2.1. Transport level 2.1. Transport level
At a transport level, routing protocols are subject to a variety of At a transport level, routing protocols are subject to a variety of
DoS attacks. Such attacks can cause the routing protocol to become DoS attacks. Such attacks can cause the routing protocol to become
congested with the result that routing updates are supplied too congested with the result that routing updates are supplied too
slowly to be useful or in extreme case prevent route convergence slowly to be useful or in extreme case prevent route convergence
after a change. after a change.
Routing protocols use several methods to protect themselves. Those Routing protocols use several methods to protect themselves. Those
that run on TCP use access list to permit packets only from know that run use TCP as a transport protocol use access list to permit
sources. These access lists also help edge routers from attacks packets from know sources only. These access lists also help edge
originating from outside the protected cloud. In addition for edge routers from attacks originating from outside the protected cloud.
routers running eBGP, TCP LISTEN is run only on interfaces on which In addition for edge routers running eBGP, TCP LISTEN is run only on
its peers have been discovered or that are configured to expect interfaces on which its peers have been discovered or that are
sessions on. configured to expect routing sessions on.
GTSM [RFC5082] describes a generalized Time to Live (TTL) security GTSM [RFC5082] describes a generalized Time to Live (TTL) security
mechanism to protect a protocol stack from CPU-utilization based mechanism to protect a protocol stack from CPU-utilization based
attacks.TCP Robustness [RFC5961] recommends some TCP level attacks.TCP Robustness [RFC5961] recommends some TCP level
mitigations against spoofing attacks targeted towards long lived mitigations against spoofing attacks targeted towards long lived
routing protocol sessions. routing protocol sessions.
Even when BGP, LDP, PCEP and MSDP sessions use access list they are Even when BGP, LDP, PCEP and MSDP sessions use access list they are
subject to spoofing and man in the middle attacks. Authentication subject to spoofing and man in the middle attacks. Authentication
and integrity checks allow the receiver of a routing protocol update and integrity checks allow the receiver of a routing protocol update
skipping to change at page 6, line 8 skipping to change at page 6, line 8
information known only to the connection end points. The MD5 key information known only to the connection end points. The MD5 key
used to compute the digest is stored locally on the router. This used to compute the digest is stored locally on the router. This
option is used by routing protocols to provide for session level option is used by routing protocols to provide for session level
protection against the introduction of spoofed TCP segments into any protection against the introduction of spoofed TCP segments into any
existing TCP streams, in particular TCP Reset segments. TCP MD5 does existing TCP streams, in particular TCP Reset segments. TCP MD5 does
not provide a generic mechanism to support key roll-over. not provide a generic mechanism to support key roll-over.
However, the Message Authentication Codes (MACs) used by MD5 to However, the Message Authentication Codes (MACs) used by MD5 to
compute the signature are considered to be too weak. TCP-AO compute the signature are considered to be too weak. TCP-AO
[RFC5925] and its companion document Crypto Algorithms for TCP-AO [RFC5925] and its companion document Crypto Algorithms for TCP-AO
[RFC5926] is a step towards correcting both the MAC weakness and KMP. [RFC5926] describe steps towards correcting both the MAC weakness and
For MAC it specifies two MAC algorithms that MUST be supported. They KMP. For MAC it specifies two MAC algorithms that MUST be supported.
are HMAC-SHA-1-96 as specified in HMAC [RFC2104] and AES-128-CMAC-96 They are HMAC-SHA-1-96 as specified in HMAC [RFC2104] and AES-128-
as specified in NIST-SP800-38B [NIST-SP800-38B]. Cryptographic CMAC-96 as specified in NIST-SP800-38B [NIST-SP800-38B].
research suggests that both these MAC algorithms defined are fairly Cryptographic research suggests that both these MAC algorithms
secure and are not known to be broken in any ways. It also provides defined are fairly secure and are not known to be broken in any ways.
for additional MACs to be added in the future. It also provides for additional MACs to be added in the future.
2.2. Keying mechanisms 2.2. Keying mechanisms
For TCP-AO [RFC5925] there is no Key Management Protocol (KMP) used For TCP-AO [RFC5925] there is no Key Management Protocol (KMP) used
to manage the keys that are used for generating the Message to manage the keys that are used for generating the Message
Authentication Code (MAC). It allows for a master key to be Authentication Code (MAC). It allows for a master key to be
configured manually or for it to be managed from a out of band configured manually or for it to be managed from a out of band
mechanism. Most routers are configured with a static key that does mechanism. Most routers are configured with a static key that does
not change over the life of the session. not change over the life of the session.
It should also be mentioned that those routers that have been It should also be mentioned that those routers that have been
configured with static keys have not seen the key changed. The configured with static keys have not seen the key changed. The
common reason given for not changing the key is because it triggers a common reason given for not changing the key is the difficulty in
TCP reset, and thus bounces links/adjacencies thus undermining coordinating the change, at least with TCP MD5. It is well known
Service Level Agreements (SLAs). It is well known that longer the that longer the same key is used, higher is the chance that it can be
same key is used, higher is the chance that it can be guessed, guessed, particularly if it is not a strong key.
particularly if it is not a strong key.
For point-to-point key management IKE [RFC2409] tries to solve the For point-to-point key management IKE [RFC2409] tries to solve the
issue of key exchange under a SA. issue of key exchange under a SA.
2.3. LDP 2.3. LDP
Section 5 of LDP [RFC5036] states that LDP is subject to three Section 5 of LDP [RFC5036] states that LDP is subject to three
different types of attacks. These are spoofing, protection of different types of attacks. These are spoofing, protection of
privacy of label distribution and denial of service attacks. privacy of label distribution and denial of service attacks.
skipping to change at page 7, line 34 skipping to change at page 7, line 33
2.3.1.2. Session communication using TCP 2.3.1.2. Session communication using TCP
LDP like other TCP based routing protocols specifies use of the TCP LDP like other TCP based routing protocols specifies use of the TCP
MD5 Signature Option to provide for the authenticity and integrity of MD5 Signature Option to provide for the authenticity and integrity of
session messages. As stated above, some assert that MD5 session messages. As stated above, some assert that MD5
authentication is now considered by some to be too weak for this authentication is now considered by some to be too weak for this
application. A stronger hashing algorithm e.g SHA1, could be application. A stronger hashing algorithm e.g SHA1, could be
deployed to take care of the weakness. deployed to take care of the weakness.
Alternatively, one could move to using TCP-AO which provides for
stronger MACs and protects against replays.
2.3.2. Privacy Issues 2.3.2. Privacy Issues
LDP provides no mechanism for protecting the privacy of label LDP provides no mechanism for protecting the privacy of label
distribution. The security requirements of label distribution are distribution. The security requirements of label distribution are
similar to other routing protocols that need to distribute routing similar to other routing protocols that need to distribute routing
information. information.
2.3.3. Denial of Service Attacks 2.3.3. Denial of Service Attacks
LDP is subject to Denial of Service (DoS) attacks both in its LDP is subject to Denial of Service (DoS) attacks both in its
skipping to change at page 8, line 46 skipping to change at page 8, line 46
Ensuring PCEP communication privacy is of key importance, especially Ensuring PCEP communication privacy is of key importance, especially
in an inter-AS context, where PCEP communication end-points do not in an inter-AS context, where PCEP communication end-points do not
reside in the same AS, as an attacker that intercepts a PCE message reside in the same AS, as an attacker that intercepts a PCE message
could obtain sensitive information related to computed paths and could obtain sensitive information related to computed paths and
resources. resources.
2.5. MSDP 2.5. MSDP
Similar to BGP and LDP, TCP MD5 [RFC2385] specifies a mechanism to Similar to BGP and LDP, TCP MD5 [RFC2385] specifies a mechanism to
protect TCP sessions via the TCP MD5 option. But with a weak MD5 protect TCP sessions via the TCP MD5 option. But with a weak MD5
authentication, TCP MD5 is considered too weak for this application. authentication, TCP MD5 is not considered strong enough for this
application.
MSDP also advocates imposing a limit on number of source address and MSDP also advocates imposing a limit on number of source address and
group addresses (S,G) that can be stored within the protocol and group addresses (S,G) that can be stored within the protocol and
thereby mitigate state explosion due to any denial of service and thereby mitigate state explosion due to any denial of service and
other attacks. other attacks.
3. Optimal State for BGP, LDP, PCEP, and MSDP 3. Optimal State for BGP, LDP, PCEP, and MSDP
The ideal state for BGP, LDP and MSDP protocols are when they can The ideal state for BGP, LDP and MSDP protocols are when they can
withstand any of the known types of attacks. withstand any of the known types of attacks.
Additionally, Key Management Protocol (KMP) for the routing sessions Additionally, Key Management Protocol (KMP) for the routing sessions
should help negotiate unique, pair wise random keys without should help negotiate unique, pair wise random keys without
administrator involvement. It should also negotiate Security administrator involvement. It should also negotiate Security
Association (SA) parameter required for the session connection, Association (SA) parameter required for the session connection,
including key life times. It should keep track of those lifetimes including key life times. It should keep track of those lifetimes
and negotiate new keys and parameters before they expire and do so and negotiate new keys and parameters before they expire and do so
without administrator involvement. In the event of a breach, the without administrator involvement. In the event of a breach,
keys should be changed immediately. including when an administrator with knowledge of the keys leaves the
company, the keys should be changed immediately.
The DoS attacks for BGP, LDP, PCEP and MSDP are attacks to the The DoS attacks for BGP, LDP, PCEP and MSDP are attacks to the
transport protocol, TCP in this case. TCP should be able to transport protocol, TCP in this case. TCP should be able to
withstand any of DoS scenarios by dropping packets that are attack withstand any of DoS scenarios by dropping packets that are attack
packets in a way that does not impact legitimate packets. packets in a way that does not impact legitimate packets.
The routing protocols should provide a mechanism to determine The routing protocols should provide a mechanism to determine
authenticate and validate the routing information carried within the authenticate and validate the routing information carried within the
payload. payload.
skipping to change at page 10, line 17 skipping to change at page 10, line 17
This section outlines the differences between the current state of This section outlines the differences between the current state of
the routing protocol and the desired state as outlined in section 4.2 the routing protocol and the desired state as outlined in section 4.2
of KARP Design Guidelines [RFC6518]. As that document states, these of KARP Design Guidelines [RFC6518]. As that document states, these
routing protocols fall into the category of the one-to-one peering routing protocols fall into the category of the one-to-one peering
messages and will use peer keying protocol. It covers issues that messages and will use peer keying protocol. It covers issues that
are common to the four protocols leaving protocol specific issues to are common to the four protocols leaving protocol specific issues to
sub-sections. sub-sections.
At a transport level the routing protocols are subject to some of the At a transport level the routing protocols are subject to some of the
same attacks that TCP applications are subject to. These include but same attacks that TCP applications are subject to. These include but
are not limited to DoS attacks. Recommendations to make the are not limited to DoS attacks. Defending TCP Against Spoofing
transport protocol should be followed and implemented. An example of Attacks [RFC4953] recommends ways to do just that. In addition
such a draft is Improving TCP's Robustness to Blind In-Window Improving TCP's Robustness to Blind In-Window Attacks. [RFC5961]
Attacks. [RFC5961] should also be followed and implemented.
From a security perspective there is a lack of comprehensive KMP. As From a security perspective there is a lack of comprehensive KMP. As
an example TCP-AO [RFC5925] talks about coordinating keys derived an example TCP-AO [RFC5925] talks about coordinating keys derived
from MKT between endpoints, but the MKT itself has to be configured from MKT between endpoints, but the MKT itself has to be configured
manually or through a out of band mechanism. Even when keys are manually or through a out of band mechanism. Even when keys are
configured manually, a method for their rollover has not been configured manually, a method for when to start using the new keys or
defined. This leads to keys not being updated regularly which in stop using old keys has not been defined. This leads to keys not
itself increases the security risk. Also TCP-AO does not address the being updated regularly which in itself increases the security risk.
issue of connectionless reset. Also TCP-AO does not address the issue of connectionless reset, as it
applies to routers that do not store MKT across reboots.
Authentication, tamper protection, and encryption all require the use Authentication, tamper protection, and encryption all require the use
of keys by sender and receiver. An automated KMP therefore has to of keys by sender and receiver. An automated KMP therefore has to
include a way to distribute MKT between two end points with little or include a way to distribute MKT between two end points with little or
no administration overhead. It has to cover automatic key rollover. no administration overhead. It has to cover automatic key rollover.
It is expected that authentication will cover the packet, i.e. the It is expected that authentication will cover the packet, i.e. the
payload and the TCP header and will not cover the frame i.e. the link payload and the TCP header and will not cover the frame i.e. the link
layer 2 header. layer 2 header.
There are two methods of automatic key rollover. Implicit key There are two methods of automatic key rollover. Implicit key
skipping to change at page 12, line 15 skipping to change at page 12, line 15
5. Transition and Deployment Considerations 5. Transition and Deployment Considerations
As stated in KARP Design Guidelines [RFC6518] it is imperative that As stated in KARP Design Guidelines [RFC6518] it is imperative that
the new authentication and security mechanisms defined support the new authentication and security mechanisms defined support
incremental deployment, as it is not feasible to deploy the new incremental deployment, as it is not feasible to deploy the new
routing protocol authentication mechansim overnight. routing protocol authentication mechansim overnight.
Typically authentication and security in a peer-to-peer protocol Typically authentication and security in a peer-to-peer protocol
requires that both parties agree to the mechanisms that will be used. requires that both parties agree to the mechanisms that will be used.
If an agreement is not reached the setup of the new mechanism will If an agreement is not reached the setup of the new mechanism will
fail. Upon failure, the routing protocols can fallback to the fail or will be deferred. Upon failure, the routing protocols can
mechanisms that were already in place e.g. use static keys if that fallback to the mechanisms that were already in place e.g. use static
was the mechanism in place. It is usually not possible for one end keys if that was the mechanism in place. It is usually not possible
to use the new mechanism while the other end uses the old. Policies for one end to use the new mechanism while the other end uses the
can be put in place to retry upgrading after a said period of time, old. Policies can be put in place to retry upgrading after a said
so a manual coordiantion is not required. period of time, so a manual coordiantion is not required.
If the automatic KMP requires use of public/private keys to exchange If the automatic KMP requires use of public/private keys to exchange
key material, the required CA root certificates may need to be key material, the required CA root certificates may need to be
installed to verify authenticity of requests initiated by a peer. installed to verify authenticity of requests initiated by a peer.
Such a step does not require coordination with the peer except to Such a step does not require coordination with the peer except to
agree on what CA authority will be used. decide what CA authority will be used.
6. Security Requirements 6. Security Requirements
This section describes requirements for BGP, LDP, PCEP and MSDP This section describes requirements for BGP, LDP, PCEP and MSDP
security that should be met within the routing protocol. security that should be met within the routing protocol.
As with all routing protocols, they need protection from both on-path As with all routing protocols, they need protection from both on-path
and off-path blind attacks. A better way to protect them would be and off-path blind attacks. A better way to protect them would be
with per-packet protection using a cryptographic MAC. In order to with per-packet protection using a cryptographic MAC. In order to
provide for the MAC, keys are needed. provide for the MAC, keys are needed.
skipping to change at page 15, line 50 skipping to change at page 15, line 50
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003. Group Domain of Interpretation", RFC 3547, July 2003.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the
IAB workshop on Unwanted Traffic March 9-10, 2006", IAB workshop on Unwanted Traffic March 9-10, 2006",
RFC 4948, August 2007. RFC 4948, August 2007.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks",
RFC 4953, July 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.
[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.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440, (PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009. March 2009.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010. Authentication Option", RFC 5925, June 2010.
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
Robustness to Blind In-Window Attacks", RFC 5961, Robustness to Blind In-Window Attacks", RFC 5961,
August 2010. August 2010.
[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues
with Existing Cryptographic Protection Methods for Routing
Protocols", RFC 6039, October 2010.
[draft-ietf-karp-ospf-analysis-03] [draft-ietf-karp-ospf-analysis-03]
Hartman, S., "Analysis of OSPF Security According to KARP Hartman, S., "Analysis of OSPF Security According to KARP
Design Guide", March 2012. Design Guide", March 2012.
[draft-ietf-opsec-routing-protocols-crypto-issues-07]
Bhatia, M., "Issues with Existing Cryptographic Protection
Methods for Routing Protocols", October 2010.
[draft-zheng-mpls-ldp-hello-crypto-auth-01] [draft-zheng-mpls-ldp-hello-crypto-auth-01]
Zheng, "LDP Hello Cryptographic Authentication", Zheng, "LDP Hello Cryptographic Authentication",
March 2011. March 2011.
Authors' Addresses Authors' Addresses
Mahesh Jethanandani Mahesh Jethanandani
Private Ciena Corporation
1741 Technology Drive
San Jose, CA 95110
USA USA
Phone: Phone: + (408) 436-3313
Email: mjethanandani@gmail.com Email: mjethanandani@gmail.com
Keyur Patel Keyur Patel
Cisco Systems, Inc Cisco Systems, Inc
170 Tasman Drive 170 Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 (408) 526-7183 Phone: +1 (408) 526-7183
Email: keyupate@cisco.com Email: keyupate@cisco.com
 End of changes. 23 change blocks. 
53 lines changed or deleted 62 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/