draft-ietf-karp-routing-tcp-analysis-00.txt   draft-ietf-karp-routing-tcp-analysis-01.txt 
Routing Working Group M. Jethanandani Routing Working Group M. Jethanandani
Internet-Draft K. Patel Internet-Draft Private
Intended status: Informational Cisco Systems, Inc Intended status: Informational K. Patel
Expires: December 29, 2011 L. Zheng Expires: September 27, 2012 Cisco Systems, Inc
L. Zheng
Huawei Huawei
June 27, 2011 March 26, 2012
Analysis of BGP, LDP, PCEP, and MSDP Security According to KARP Design Analysis of BGP, LDP, PCEP, and MSDP Security According to KARP Design
Guide Guide
draft-ietf-karp-routing-tcp-analysis-00.txt draft-ietf-karp-routing-tcp-analysis-01.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 guidelines set forth in section 4.2 of Keying and Authentication for
[draft-ietf-karp-design-guide]. 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]..
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 29, 2011. This Internet-Draft will expire on September 27, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 22 skipping to change at page 2, line 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Contributing Authors . . . . . . . . . . . . . . . . . . . 3 1.1. Contributing Authors . . . . . . . . . . . . . . . . . . . 3
1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
2. Current State of BGP, LDP, PCEP and MSDP . . . . . . . . . . . 5 2. Current State of BGP, LDP, PCEP and MSDP . . . . . . . . . . . 5
2.1. Transport level . . . . . . . . . . . . . . . . . . . . . 5 2.1. Transport level . . . . . . . . . . . . . . . . . . . . . 5
2.2. Keying mechanisms . . . . . . . . . . . . . . . . . . . . 6 2.2. Keying mechanisms . . . . . . . . . . . . . . . . . . . . 6
2.3. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1. Spoofing attacks . . . . . . . . . . . . . . . . . . . 6 2.3.1. Spoofing attacks . . . . . . . . . . . . . . . . . . . 6
2.3.2. Privacy Issues . . . . . . . . . . . . . . . . . . . . 7 2.3.2. Privacy Issues . . . . . . . . . . . . . . . . . . . . 7
2.3.3. Denial of Service Attacks . . . . . . . . . . . . . . 7 2.3.3. Denial of Service Attacks . . . . . . . . . . . . . . 7
2.4. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.5. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Optimal State for BGP, LDP, PCEP, and MSDP . . . . . . . . . . 9 3. Optimal State for BGP, LDP, PCEP, and MSDP . . . . . . . . . . 9
3.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Gap Analysis for BGP, LDP, PCEP and MSDP . . . . . . . . . . . 10 4. Gap Analysis for BGP, LDP, PCEP and MSDP . . . . . . . . . . . 10
4.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Security Requirements . . . . . . . . . . . . . . . . . . . . 12 5. Transition and Deployment Considerations . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 6. Security Requirements . . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . . 15
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 described an attack on core routing Internet Traffic" workshop documented in Report from the IAB workship
infrastructure as an ideal attack with the most amount of damage. It on Unwanted Traffic March 9-10, 2006 [RFC4948] described an attack on
called for the tightening the security of the core routing core routing infrastructure as an ideal attack with the most amount
infrastructure. of damage. Four main steps were identified for that tightening:
This document performs the initial analysis of the current state of 1. Create secure mechanisms and practices for operating routers.
BGP, LDP, PCEP and MSDP according to the requirements of
[draft-ietf-karp-design-guide]. This draft builds on several 2. Clean up the Internet Routing Registry [IRR] repository, and
previous analysis efforts into routing security. The OPSEC working securing both the database and the access, so that it can be used
group put together Issues with existing Cryptographic Protection for routing verifications.
Methods for Routing Protocols
[draft-ietf-opsec-routing-protocols-crypto-issues] an analysis of 3. Create specifications for cryptographic validation of routing
cryptographic issues with routing protocols and message content.
draft-hartman-ospf-analysis-01 which has a analysis for OSPF.
4. Secure the routing protocols' packets on the wire.
This document looking at the last bullet performs the initial
analysis of the current state of BGP, LDP, PCEP and MSDP according to
the requirements of KARP Design Guidelines [RFC6518]. This draft
builds on several previous analysis efforts into routing security.
The OPSEC working group put together Issues with existing
Cryptographic Protection Methods for Routing Protocols
[draft-ietf-opsec-routing-protocols-crypto-issues-07] an analysis of
cryptographic issues with routing protocols and Analysis of OSPF
Security According to KARP Design Guide
[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 routing protocols according to KARP Design Guidelines [RFC6518] and
[draft-ietf-karp-design-guide] and Section 4 does a analysis of the Section 4 does a analysis of the gap between the existing state and
gap between the existing state and the optimal state of the protocols the optimal state of the protocols and suggest some areas where we
and suggest some areas where we need to improve. need to improve.
1.1. Contributing Authors 1.1. Contributing Authors
Anantha Ramaiah, Mach Chen Anantha Ramaiah, Mach Chen
1.2. Abbreviations 1.2. Abbreviations
BGP - Border Gateway Protocol BGP - Border Gateway Protocol
DoS - Denial of Service DoS - Denial of Service
skipping to change at page 5, line 38 skipping to change at page 5, line 38
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
to know that the message genuinely comes from the node that purports to know that the message genuinely comes from the node that purports
to have sent it and to know whether the message has been modified. to have sent it and to know whether the message has been modified.
Sometimes routers can be subjected to a large number of
authentication and integrity checks which can result in genuine
requests failing.
TCP MD5 [RFC2385] specifies such a mechanism to protect BGP and other TCP MD5 [RFC2385] specifies a mechanism to protect BGP and other TCP
TCP based routing protocols via the TCP MD5 option. TCP MD5 option based routing protocols via the TCP MD5 option. TCP MD5 option
provides a way for carrying an MD5 digest in a TCP segment. This provides a way for carrying an MD5 digest in a TCP segment. This
digest acts like a signature for that segment, incorporating digest acts like a signature for that segment, incorporating
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 documentCrypto 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] is a step towards correcting both the MAC weakness and KMP.
For MAC it specifies two MAC algorithms that MUST be supported. They For MAC it specifies two MAC algorithms that MUST be supported. They
are HMAC-SHA-1-96 as specified in HMAC [RFC2104] and AES-128-CMAC-96 are HMAC-SHA-1-96 as specified in HMAC [RFC2104] and AES-128-CMAC-96
as specified in NIST-SP800-38B [NIST-SP800-38B]. Cryptographic as specified in NIST-SP800-38B [NIST-SP800-38B]. Cryptographic
research suggests that both these MAC algorithms defined are fairly research suggests that both these MAC algorithms defined are fairly
secure and are not known to be broken in any ways. It also provides secure and are not known to be broken in any ways. It also provides
for additional MACs to be added in the future. 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
configured with static keys have not seen the key changed. The
common reason given for not changing the key is because it triggers a
TCP reset, and thus bounces links/adjacencies thus undermining
Service Level Agreements (SLAs). It is well known that longer the
same key is used, higher is the chance that it can be guessed,
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. It talks about 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.
2.3.1. Spoofing attacks 2.3.1. Spoofing attacks
Spoofing attack for LDP occur both during the discovery phase and Spoofing attack for LDP occur both during the discovery phase and
during the session communication phase. during the session communication phase.
2.3.1.1. Discovery exchanges using UDP 2.3.1.1. Discovery exchanges using UDP
Label Switching Routers (LSRs) indicate their willingness to Label Switching Routers (LSRs) indicate their willingness to
skipping to change at page 10, line 9 skipping to change at page 10, line 9
the neighbors sending the Hello message. the neighbors sending the Hello message.
There is currently no requirement to protect the privacy of label There is currently no requirement to protect the privacy of label
distribution as labels are carried in the clear like other routing distribution as labels are carried in the clear like other routing
information. information.
4. Gap Analysis for BGP, LDP, PCEP and MSDP 4. Gap Analysis for BGP, LDP, PCEP and MSDP
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 [draft-ietf-karp-design-guide]. It covers of KARP Design Guidelines [RFC6518]. As that document states, these
issues that are common to the four protocols leaving protocol routing protocols fall into the category of the one-to-one peering
specific issues to sub-sections. messages and will use peer keying protocol. It covers issues that
are common to the four protocols leaving protocol specific issues to
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. Recommendations to make the
transport protocol should be followed and implemented. An example of transport protocol should be followed and implemented. An example of
such a draft is Improving TCP's Robustness to Blind In-Window such a draft is Improving TCP's Robustness to Blind In-Window
Attacks. [RFC5961] Attacks. [RFC5961]
From a security perspective we lack comprehensive KMP. As an example From a security perspective there is a lack of comprehensive KMP. As
TCP-AO [RFC5925] talks about coordinating keys derived from MKT an example TCP-AO [RFC5925] talks about coordinating keys derived
between endpoints, but the MKT itself has to be configured manually from MKT between endpoints, but the MKT itself has to be configured
or through a out of band mechanism. Even when keys are configured manually or through a out of band mechanism. Even when keys are
manually, a method for their rollover has not been defined. This configured manually, a method for their rollover has not been
leads to keys not being updated regularly which in itself increases defined. This leads to keys not being updated regularly which in
the security risk. Also TCP-AO does not address the issue of itself increases the security risk. Also TCP-AO does not address the
connectionless reset. issue of connectionless reset.
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
payload and the TCP header and will not cover the frame i.e. the link
layer 2 header.
There are two methods of automatic key rollover. Implicit key There are two methods of automatic key rollover. Implicit key
rollover can be initiated after certain volume of data gets exchanged rollover can be initiated after certain volume of data gets exchanged
or when a certain time has elapsed. This does not require explicit or when a certain time has elapsed. This does not require explicit
signaling. On the other hand, explicit key rollover requires a out signaling nor should it result in a reset of the TCP connection in a
of band key signaling mechanism. An example of this is IKE [RFC2409] way that the links/adjacencies are affected. On the other hand,
but it could be any other new mechanisms also. explicit key rollover requires a out of band key signaling mechanism.
It can be triggered by either side and can be done anytime a security
parameter changes e.g. an attack has happened, or a system
administrator with access to the keys has left the company. An
example of this is IKE [RFC2409] but it could be any other new
mechanisms also.
As stated earlier TCP-AO [RFC5925] and its accompanying document
Crypto Algorithms for TCP-AO [RFC5926] suggest that two MAC
algorithms that MUST be supported are HMAC-SHA-1-96 as specified in
HMAC [RFC2104] and AES-128-CMAC-96 as specified in NIST-SP800-38B
[NIST-SP800-38B].
There is a need to protect authenticity and validity of the routing/ There is a need to protect authenticity and validity of the routing/
label information that is carried in the payload of the sessions. label information that is carried in the payload of the sessions.
However, we believe that is outside the scope of this document at However, we believe that is outside the scope of this document at
this time and is being addressed by SIDR WG. Similar mechanisms this time and is being addressed by SIDR WG. Similar mechanisms
could be used for intra-domain protocols. could be used for intra-domain protocols.
4.1. LDP 4.1. LDP
As described in LDP [RFC5036], the threat of spoofed Basic Hellos can As described in LDP [RFC5036], the threat of spoofed Basic Hellos can
skipping to change at page 12, line 5 skipping to change at page 12, line 5
PCE discovery according to its RFC is a significant feature for the PCE discovery according to its RFC is a significant feature for the
successful deployment of PCEP in large networks. This mechanism successful deployment of PCEP in large networks. This mechanism
allows a PCC to discover the existence of suitable PCEs within the allows a PCC to discover the existence of suitable PCEs within the
network without the necessity of configuration. It should be obvious network without the necessity of configuration. It should be obvious
that, where PCEs are discovered and not configured, the PCC cannot that, where PCEs are discovered and not configured, the PCC cannot
know the correct key to use. There are different approaches to know the correct key to use. There are different approaches to
retain some aspect of security, but all of them require use of a keys retain some aspect of security, but all of them require use of a keys
and a keying mechanism, the need for which has been discussed above. and a keying mechanism, the need for which has been discussed above.
5. Security Requirements 5. Transition and Deployment Considerations
As stated in KARP Design Guidelines [RFC6518] it is imperative that
the new authentication and security mechanisms defined support
incremental deployment, as it is not feasible to deploy the new
routing protocol authentication mechansim overnight.
Typically authentication and security in a peer-to-peer protocol
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
fail. Upon failure, the routing protocols can fallback to the
mechanisms that were already in place e.g. use static keys if that
was the mechanism in place. It is usually not possible for one end
to use the new mechanism while the other end uses the old. Policies
can be put in place to retry upgrading after a said period of time,
so a manual coordiantion is not required.
If the automatic KMP requires use of public/private keys to exchange
key material, the required CA root certificates may need to be
installed to verify authenticity of requests initiated by a peer.
Such a step does not require coordination with the peer except to
agree on what CA authority will be used.
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.
Once keys are used, mechanisms are required to support key rollover. Once keys are used, mechanisms are required to support key rollover.
skipping to change at page 13, line 5 skipping to change at page 14, line 5
mechanisms to introduce and retire new keys, focusing on the existing mechanisms to introduce and retire new keys, focusing on the existing
mechanism as a starting point is prudent. mechanism as a starting point is prudent.
Finally, replay protection is required. The replay mechanism needs Finally, replay protection is required. The replay mechanism needs
to be sufficient to prevent an attacker from creating a denial of to be sufficient to prevent an attacker from creating a denial of
service or disrupting the integrity of the routing protocol by service or disrupting the integrity of the routing protocol by
replaying packets. It is important that an attacker not be able to replaying packets. It is important that an attacker not be able to
disrupt service by capturing packets and waiting for replay state to disrupt service by capturing packets and waiting for replay state to
be lost. be lost.
6. Acknowledgements 7. Acknowledgements
We would like to thank Brian Weis for encouraging us to write this We would like to thank Brian Weis for encouraging us to write this
draft and providing comments on it. draft and providing comments on it.
7. References 8. References
7.1. Normative References 8.1. Normative References
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998. Signature Option", RFC 2385, August 1998.
[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.
[draft-ietf-karp-design-guide] [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for
Lebovitz, G., "KARP Design Guidelines", September 2010. Routing Protocols (KARP) Design Guidelines", RFC 6518,
February 2012.
7.2. Informative References [draft-ietf-karp-threats-reqs]
Lebovitz, G. and M. Bhatia, "KARP Threats and
Requirements", March 2012.
8.2. Informative References
[NIST-SP800-38B] [NIST-SP800-38B]
Dworking, "Recommendation for Block Cipher Modes of Dworking, "Recommendation for Block Cipher Modes of
Operation: The CMAC Mode for Authentication", May 2005. Operation: The CMAC Mode for Authentication", May 2005.
[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
skipping to change at page 14, line 41 skipping to change at page 15, line 46
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998. (IKE)", RFC 2409, November 1998.
[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
IAB workshop on Unwanted Traffic March 9-10, 2006",
RFC 4948, August 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.
[draft-ietf-opsec-routing-protocols-crypto-issues] [draft-ietf-karp-ospf-analysis-03]
Manral, "Issues with existing Cryptographic Protection Hartman, S., "Analysis of OSPF Security According to KARP
Methods for Routing Protocols", September 2010. 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
Cisco Systems, Inc Private
170 Tasman Drive
San Jose, CA 95134
USA USA
Phone: +1 (408) 527-8230 Phone:
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. 31 change blocks. 
67 lines changed or deleted 141 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/