Internet DRAFT - draft-manral-rp-existingcrypto
draft-manral-rp-existingcrypto
Routing Working Group V. Manral
Internet-Draft SiNett Corp
Expires: January 20, 2006 S. Hares
NextHop
R. White
Cisco Systems
July 19, 2005
Issues with existing Cryptographic Protection Methods for Routing
Protocols
draft-manral-rp-existingcrypto-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 20, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Routing protocols often use cryptographic mechanisms to authenticate
data being received from a neighboring router has not been modified
in transit, and actually originated from the nrighboring router
purporting to have originating the data. Most of the cryptographic
Manral, et al. Expires January 20, 2006 [Page 1]
Internet-Draft Routing Protocol Protection Issues July 2005
mechanisms rely on hash algorithms applied to the data in the routing
protocol packet, which means the data is transported, in the clear,
along with the has signature based on the data itself. These
mechanisms rely on the manual configuration of the keys used to seed,
or build, these hash based sigantures. This document outlines some
of the problems with manual keying of these cryptographic algorithms.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents
1. Problem Statement . . . . . . . . . . . . . . . . . . . . . 3
2. OSPF (OSPFv2) . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Management Issues with OSPF . . . . . . . . . . . . . . . 4
2.2 Technical Issues with OSPF . . . . . . . . . . . . . . . . 4
3. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Management Issues with OSPFv3 . . . . . . . . . . . . . . 5
3.2 Technical Issues with OSPFv3 . . . . . . . . . . . . . . . 5
4. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1 Management Issues with IS-IS . . . . . . . . . . . . . . . 7
4.2 Technical Issues with IS-IS . . . . . . . . . . . . . . . 7
5. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1 Management Issues with BGP . . . . . . . . . . . . . . . . 8
5.2 Technical Issues with BGP . . . . . . . . . . . . . . . . 8
6. The Routing Information Protocol (RIP) . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1 Normative References . . . . . . . . . . . . . . . . . . 13
10.2 Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . 15
Manral, et al. Expires January 20, 2006 [Page 2]
Internet-Draft Routing Protocol Protection Issues July 2005
1. Problem Statement
Routing protocols, such as OSPF [RFC2740] [RFC2328], IS-IS [RFC1995],
and [BGP], rely on various mechanisms to create a cryptographic
digest of each transmitted routing protocol. Generally, these
digests are the results of a hash algorithm, such as [MD5], across
the contents of the packet being transmitted, using a private key as
the hash base (or seed). These digests are recomputed by the
receiving router, using the same key as the originating router used
to create the hash, and compared with the transmited digest to
verify:
o That the router originating this piece of data is authorized to
peer with the local router, and to transmit routing data. This
generally protects against falsely generated routing data being
injected into a routing system by rogue systems.
o That the data has not been changed while transiting between the
two neighboring routers.
These sorts of authentication methods are not generally used to
protect the confidentiality of information being exchanged between
routers, since this information (entries in the routing table) is
generally freely available in many other context; if anyone has
access to the physical media between two routers exchanging routing
data, they will also probably have other ways to capture or otherwise
discover the contents of the routing tables in those routers.
The main problems with the authentication mechanisms in use today
revolve around:
o Manual configuration of shared secret keys, especially in large
scale networks, poses a major management problem, especially as
there is generally no way to gracefully move from one secret key
to another.
o In some cases, when manual keys are configured, some forms of
replay protection are disabled, allowing the routing protocol to
be attacked.
In fact, the MD5 digest algorithm was not designed to be used in the
way most routing protocols are using it, which leads to serious
security implications.
Manral, et al. Expires January 20, 2006 [Page 3]
Internet-Draft Routing Protocol Protection Issues July 2005
2. OSPF (OSPFv2)
OSPF [RFC2328] describes the use of an MD5 digest with OSPF packets.
MD5 keys are manually configured. The OSPF packet Header includes an
authentication type field as well as 64-bits of data for use by the
appropriate authentication scheme. [OSPF] also provides for a non-
decreasing sequence number to be included in each OSPF protocol
packet to protect against replay attacks.
2.1 Management Issues with OSPF
According to the OSPF specification, [RFC2328], digests are applied
to packets transmitted between adjacent neighbors, rather than being
applied to the routing information originated by a router (digests
are not applied at the LSA level, but rather at the packet level).
[RFC2328] states that any set of OSPF routers adjacent across a
single link may use a different key to build MD5 digests than the key
used to build MD5 digests on any other link. Thus, MD5 keys may be
configured, and changed, on a per-link basis in an OSPF network.
2.2 Technical Issues with OSPF
While [OSPF] provides relatively strong protection through the
inclusion of MD5 sigantures, with additional data and sequence
numbers, in transmitted packets, there are still two possible attacks
against OSPF:
o The sequence number is initialized to zero when forming an
adjacency with a newly discovered neighbor, and is also set to
zero whenever the neighbor is brought down. If the
cryptographically protected packets of a router that is brought
down(for administrative or other reasons) are stored by a
malicious router. The new router could replay the packets from
the previous session thus forcing traffic through the malicious
router. Dropping of such packets by the router could result in
blackholes. Also wrongly forwarding packets could result in
routing loops.
o [OSPF] allows multiple packets with the same sequence number.
This could mean the same packet can be replayed many times before
the next legitimate packet is sent. An attacker may resend the
same packet repeatedly until the next hello packet is transmitted
and received, which means the hello interval determines the attack
window.
Manral, et al. Expires January 20, 2006 [Page 4]
Internet-Draft Routing Protocol Protection Issues July 2005
3. OSPFv3
OSPFv3 [RFC2740] relies on the IP Authentication Header described in
[AH] and the IP Encapsulating Payload described in [ESP] to
cryptographically sign routing information passed between routers.
Generally, a null encryption algorithm is used, so the data carried
in the OSPFv3 packets is signed, but not encrypted. This provides
authentication or adjacent routers, and assurance data transmitted by
a router has not changed, but does not provide confidentiality of the
information transmitted. [OSPF-AUTH] does provide for protecting the
confidentiality of routing information transmitted, using [ESP]
encryption.
[OSPF-AUTH] describes OSPFv3's use of [AH] and [ESH], and specifies
that only manual keying of routing information may be used.
3.1 Management Issues with OSPFv3
[OSPF-AUTH] discusses, at length, the reasoning behind using manual
keys, rather than keys distributed through [IKE] or some other key
distribution mechanism. The primary problem is that all current key
distribution mechanisms are deisgned for one-to-one correlation of
keys, while OSPF adjacencies are formed on a one-to-many basis. This
forces the system administrator to use manual keys to provide
authentication and, if desired, confidentiality.
The primary administrative issue with manual keys in the OSPFv3 case
is the simple management issue of mantaining matching sets of keys on
all routers within a network. [OSPF-AUTH] does not require that all
OSPFv3 routers have the same key configured for every neighbor, so
each set of neighbors connected to a single link could have a
different key configured. While this makes it easier to change the
keys, by forcing the system administrator to only change the keys on
the routers a single link, the process of manual configuration for
all the routers in a network to change the keys used for OSPFv3
digests and confidentiality on a periodic basis can be difficult.
3.2 Technical Issues with OSPFv3
The primary technical concern with the current specifications for
OSPFv3 is that when manual keys are used, [AH] specifies, in section
3.3.2, Sequence Number Generation: "The sender assumes anti-replay is
enabled as a default, unless otherwise notified by the receiver (see
3.4.3) or if the SA was configured using manual key management."
Replayed OSPFv3 packets can cause several failures in a network,
including:
Manral, et al. Expires January 20, 2006 [Page 5]
Internet-Draft Routing Protocol Protection Issues July 2005
o Replaying hello packets with an empty neighbor list can cause all
the neighbor adajcencies with the sending router to be reset,
disrupting network communications.
o Replaying hello packets from early in the designated router
election process on broadcast links can cause all the neighbor
adjacencies with the sending router to be reset, disrupting
network communications.
o Replaying database description (DB-Description) packets can cause
all FULL neighbor adjacencies with the sending router to be reset,
disrupting network communications.
o Replaying link state request (LS-Request) packets can cause all
FULL neighbor adjacencies with the sending router to be reset,
disrupting network communications.
o Capturing a full adjacency process (from two-way all the way to
FULL state), and then replaying this process when the router is no
longer attached can cause a false adjacency to be formed, allowing
an attacker to attract and black hole traffic.
Manral, et al. Expires January 20, 2006 [Page 6]
Internet-Draft Routing Protocol Protection Issues July 2005
4. IS-IS
IS-IS [RFC1195] uses HMAC-MD5 authentication with manual keying, as
described in [RFC3567]. There is no provision within IS-IS to
encrypt the body of a routing protocol message.
4.1 Management Issues with IS-IS
[RFC3567] states that each LSP generated by an intermediate system is
signed with the HMAC-MD5 algorithm using a key manually defined by
the network administrator. Since authentication is performed on the
LSPs transmitted by an intermediate system, rather than on the
packets transmitted to a specific neighbor, it is implied that all
the intermediate systems within a single flooding domain must be
configured with the same key for authentication to work correctly.
The initial configuration of manual keys for authentication within an
IS-IS network is simplified by a state where LSPs containing HMAC-MD5
authentication TLVs are accepted, but the digest is not validated.
Once an initial set of keys are configured on all routers, however,
changing those keys becomes much more difficult.
4.2 Technical Issues with IS-IS
[RFC3567] states: "This mechanism does not prevent replay attacks,
however, in most cases, such attacks would trigger existing
mechanisms in the IS-IS protocol that would effectively reject old
information." The one case where existing mechanisms in the IS-IS
protocol would not effectively reject old information is the case of
the hello packets (IIHs) used to discover neighbors.
As described in IS-IS [RFC1195], a list of known neighbors is
included in each hello transmitted by an intermediate system, to
ensure two-way communications with any specific neighbor before
exchanging link state databases. A hello packet containing a digest
within a TLV, and an emtpy neighbor list, could be replayed, causing
all adjacencies with the original transmitting intermediate system to
be restarted.
Manral, et al. Expires January 20, 2006 [Page 7]
Internet-Draft Routing Protocol Protection Issues July 2005
5. BGP
[BGP] uses TCP [RFC793] for transporting routing information between
BGP speakers which have formed an adjacency, as described in
[RFC2385], with suggestions for choosing MD5 keys described in
[RFC3562].
5.1 Management Issues with BGP
Each pair of BGP speakers forming an adjacency may have a different
MD5 shared key, facilitating the configuration and changing of keys
across a large scale network. Manual configuration and maintenance
of manual keys on all routers is a challenge in any large scale
environment, however. Most BGP implementations will accept BGP
packets with a bad digest for the hold interval negotiated between
BGP peers at peering startup, allowing MD5 keys to be changed without
impacting the operation of the network. This technique does,
however, allow some short period of time during which an attacker may
inject BGP packets with false MD5 digests into the network, and can
expect those packets to be accepted, even though their MD5 digests
are not valid.
5.2 Technical Issues with BGP
Since BGP relies on TCP [RFC793] for transporting data between BGP
speakers, BGP can rely on TCP's protections against data corruption
and replay to prevent replay attacks against BGP sessions. A great
deal of research has gone into the difficulty or ease with which an
attacker can overcome these protections, including [TCP-WINDOW] and
[BGP-ATTACK]. Most implementations of BGP have modified their TCP
implementations to resolve the security vulnerabilities described in
these references, where possible.
Manral, et al. Expires January 20, 2006 [Page 8]
Internet-Draft Routing Protocol Protection Issues July 2005
6. The Routing Information Protocol (RIP)
RIP [RFC1058] does not provide for any authentication or
authorization of routing data, and thus is vulnerable to any of the
various attacks against routing protocols.
RIPv2 [RFC1388, RFC1723] provides for authenticating packets by
carrying a digest, but has no counter for replay protection. Packets
can be replayed at will, allowing the injection of false routing
information and various denial of service attacks, such as
continuously requesting a routing table download, causing devices
running RIP to become overloaded.
Manral, et al. Expires January 20, 2006 [Page 9]
Internet-Draft Routing Protocol Protection Issues July 2005
7. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
Manral, et al. Expires January 20, 2006 [Page 10]
Internet-Draft Routing Protocol Protection Issues July 2005
8. Security Considerations
This draft outlines security issues arising from the manual keying of
cryptographic keys for various routing protocols. No changes to any
protocols are proposed in this draft, and no new security
requirements result.
Manral, et al. Expires January 20, 2006 [Page 11]
Internet-Draft Routing Protocol Protection Issues July 2005
9. Acknowledgements
We would like to acknowledge Sam Hartman, Ran Atkinson, Steve Kent
and Brian Wies for their comments on this draft.
Manral, et al. Expires January 20, 2006 [Page 12]
Internet-Draft Routing Protocol Protection Issues July 2005
10. References
10.1 Normative References
[AH] Kent, S., "IP Authentication Header",
RFC draft-ietf-ipsec-rfc2402bis-11.txt, March 2005.
[BGP] Rekhter , Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC draft-ietf-idr-bgp4-26.txt,
October 2004.
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC draft-ietf-ipsec-esp-v3-10.txt, March 2005.
[OSPF-AUTH]
Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv3", RFC draft-ietf-ospf-ospfv3-auth-07.txt,
February 2005.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058,
June 1988.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[RFC1388] Malkin, G., "RIP Version 2 Carrying Additional
Information", RFC 1388, January 1993.
[RFC1723] Malkin, G., "RIP Version 2 - Carrying Additional
Information", STD 56, RFC 1723, November 1994.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
RFC 2740, December 1999.
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5
Signature Option", RFC 3562, July 2003.
Manral, et al. Expires January 20, 2006 [Page 13]
Internet-Draft Routing Protocol Protection Issues July 2005
[RFC3567] Li, T. and R. Atkinson, "Intermediate System to
Intermediate System (IS-IS) Cryptographic Authentication",
RFC 3567, July 2003.
10.2 Informative References
[BGP-ATTACK]
Convery, S. and M. Franz, "BGP Vulnerability Testing:
Separating Fact from FUD v1.00", June 2003.
[TCP-WINDOW]
Watson, T., "TCP Reset Spoofing", October 2003.
Authors' Addresses
Vishwas Manral
SiNett Corp
Bangalore
India
Phone:
Fax:
Email: vishwas@sinett.com
Sure Hares
NextHop
USA
Phone:
Fax:
Email: shares@nexthop.com
URI:
Russ White
Cisco Systems
RTP, NC
USA
Phone:
Fax:
Email: riw@cisco.com
URI:
Manral, et al. Expires January 20, 2006 [Page 14]
Internet-Draft Routing Protocol Protection Issues July 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Manral, et al. Expires January 20, 2006 [Page 15]
