KARP G. Lebovitz
Internet-Draft Juniper
Intended status: Informational February 28, 2010
Expires: September 1, 2010
The Threat Analysis and Requirements for Cryptographic Authentication of
Routing Protocols' Transports
draft-ietf-karp-threats-reqs-00
Abstract
In the March of 2006 the IAB held a workshop on the topic of
"Unwanted Internet Traffic". The report from that workshop is
documented in RFC 4948 [RFC4948]. Section 8.2 of RFC 4948 calls for
"[t]ightening the security of the core routing infrastructure." Four
main steps were identified for improving the security of the routing
infrastructure. One of those steps was "securing the routing
protocols' packets on the wire," also called the routing protocol
transport. One mechanism for securing routing protocol transports is
the use of per-packet cryptographic message authentication, providing
both peer authentication and message integrity. Many different
routing protocols exist and they employ a range of different
transport subsystems. Therefore there must necessarily be various
methods defined for applying cryptographic authentication to these
varying protocols. Many routing protocols already have some method
for accomplishing cryptographic message authentication. However, in
many cases the existing methods are dated, vulnerable to attack,
and/or employ cryptographic algorithms that have been deprecated.
The "Keying and Authentication for Routing Protocols" (KARP) effort
aims to overhaul and improve these mechanisms. This document has two
main parts. The first describes the threat analysis for attacks
against routing protocols' transports. The second enumerates the
requirements for addressing the described threats. This document,
along with the KARP Design Guide and KARP Framework documents, will
be used by KARP design teams for specific protocol review and
overhaul. This document reflects the input of both the IETF's
Security Area and Routing Area in order to form a jointly agreed upon
guidance.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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-
Lebovitz & Expires September 1, 2010 [Page 1]
Internet-Draft KARP Threats and Requirements February 2010
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 September 1, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Lebovitz & Expires September 1, 2010 [Page 2]
Internet-Draft KARP Threats and Requirements February 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 6
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 11
1.6. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 11
2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1. Threats In Scope . . . . . . . . . . . . . . . . . . . . . 12
2.2. Threats Out of Scope . . . . . . . . . . . . . . . . . . . 14
3. Requirements for Phase 1 of a Routing Protocol Transport's
Security Update . . . . . . . . . . . . . . . . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
7. Change History (RFC Editor: Delete Before Publishing) . . . . 19
8. Needs Work in Next Draft (RFC Editor: Delete Before
Publishing) . . . . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Lebovitz & Expires September 1, 2010 [Page 3]
Internet-Draft KARP Threats and Requirements February 2010
1. Introduction
In March 2006 the Internet Architecture Board (IAB) held a workshop
on the topic of "Unwanted Internet Traffic". The report from that
workshop is documented in RFC 4948 [RFC4948]. Section 8.1 of that
document states that "A simple risk analysis would suggest that an
ideal attack target of minimal cost but maximal disruption is the
core routing infrastructure." Section 8.2 calls for "[t]ightening
the security of the core routing infrastructure." Four main steps
were identified for that tightening:
o More secure mechanisms and practices for operating routers. This
work is being addressed in the OPSEC Working Group.
o Cleaning up the Internet Routing Registry repository [IRR], and
securing both the database and the access, so that it can be used
for routing verifications. This work should be addressed through
liaisons with those running the IRR's globally.
o Specifications for cryptographic validation of routing message
content. This work will likely be addressed in the SIDR Working
Group.
o Securing the routing protocols' packets on the wire
This document addresses the last bullet, securing the packets on the
wire of the routing protocol exchanges, i.e. the routing protocols'
transports. This effort is referred to as Keying and Authentication
for Routing Protocols, or "KARP". This document specifically
addresses the threat analysis for per packet routing protocol
transport authentication, and the requirements for protocols to
mitigate those threats.
This document is one of three that together form the guidance and
instructions for KARP design teams working to overhaul routing
protocol transport security. The other two are the KARP Design Guide
[I-D.ietf-karp-design-guide] and the KARP Framework
[I-D.ietf-karp-framework].
1.1. Terminology
Within the scope of this document, the following words, when
beginning with a capital letter, or spelled in all capitals, hold the
meanings described to the right of each term. If the same word is
used uncapitalized, then it is intended to have its common english
definition.
[Editor's note: At this point, I'm not sure exactly which of these
will end up being included in this document. They came for the
original "roadmap document". We can clean out any unused terms a few
revisions from now.]
Lebovitz & Expires September 1, 2010 [Page 4]
Internet-Draft KARP Threats and Requirements February 2010
PSK Pre-Shared Key. A key used by both peers in a secure
configuration. Usually exchanged out-of-band prior to
a first connection.
Routing Protocol When used with capital "R" and "P" in this document
the term refers the Routing Protocol for which work is
being done to provide or enhance its peer
authentication mechanisms.
PRF Pseudorandom number function, or sometimes called
pseudorandom number generator (PRNG). An algorithm
for generating a sequence of numbers that approximates
the properties of random numbers. The sequence is not
truly random, in that it is completely determined by a
relatively small set of initial values that are passed
into the function. An exmaple is SHA-256.
KDF Key derivation function. A particular specified use
of a PRF that takes a PSK, combines it with other
inputs to the PRF, and produces a result that is
suitable for use as a Traffic Key.
Identifier The type and value used by one peer of an
authenticated message exchange to signify to the other
peer who they are. The Identifier is used by the
receiver as a lookup index into a table containing
further information about the peer that is required to
continue processing the message, for example a
Security Association (SA) or keys.
Identity Proof A cryptographic proof for an asserted identity, that
the peer really is who they assert themselves to be.
Proof of identity can be arranged between the peers in
a few ways, for example PSK, raw assymetric keys, or a
more user-friendly representation of assymetric keys,
like a certificate.
Security Association or SA The parameters and keys that together
form the required information for processing secure
sessions between peers. Examples of items that may
exist in an SA include: Identifier, PSK, Traffic Key,
cryptographic algorithms, key lifetimes.
KMP Key Management Protocol. A protocol used between
peers to exchange SA parameters and Traffic Keys.
Examples of KMPs include IKE, TLS, and SSH.
Lebovitz & Expires September 1, 2010 [Page 5]
Internet-Draft KARP Threats and Requirements February 2010
KMP Function Any actual KMP used in the general KARP solution
framework
Peer Key Keys that are used between peers as the identity
proof. These keys may or may not be connection
specific, depending on who they were established, and
what form of identity and identity proof is being used
in the system.
Traffic Key The actual key used on each packet of a message.
Definitions of items specific to the general KARP framework are
described in more detail in the KARP Framework
[I-D.ietf-karp-framework] document.
1.2. 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 RFC2119 [RFC2119].
When used in lower case, these words convey their typical use in
common language, and are not to be interpreted as described in
RFC2119 [RFC2119].
1.3. Scope
Four basic tactics may be employed in order to secure any piece of
data as it is transmitted over the wire: privacy (or encryption),
authentication, message integrity, and non-repudiation. The focus
for this effort, and the scope for this roadmap document, will be
message authentication and packet integrity only. This work
explicitly excludes, at this point in time, the other two tactics:
privacy and non-repudiation. Since the objective of most routing
protocols is to broadly advertise the routing topology, routing
messages are commonly sent in the clear; confidentiality is not
normally required for routing protocols. However, ensuring that
routing peers truly are the trusted peers expected, and that no roque
peers or messages can compromise the stability of the routing
environment is critical, and thus our focus. The other two
explicitly excluded tactics, privacy and non-repudiation, may be
addressed in future work.
It is possible for routing protocol packets to be transmitted
employing all four security tactics mentioned above using existing
standards. For example, one could run unicast, layer 3 or above
routing protocol packets through IPsec ESP [RFC4303]. This would
Lebovitz & Expires September 1, 2010 [Page 6]
Internet-Draft KARP Threats and Requirements February 2010
provide the added benefit of privacy, and non-repudiation. However,
router platforms and systems have been fine tuned over the years for
the specific processing necessary for routing protocols' non-
encapsulated formats. Operators are, therefore, quite reluctant to
explore new packet encapsulations for these tried and true protocols.
In addition, at least in the case of OSPF, LDP, and RIP, these
protocols already have existing mechanisms for cryptographically
authenticating and integrity checking the packets on the wire.
Products with these mechanisms have already been produced, code has
already been written and both have been optimized for the existing
mechanisms. Rather than turn away from these mechanisms, we want to
enhance them, updating them to modern and secure levels.
Therefore, the scope of this roadmap of work includes:
o Making use of existing routing protocol security protocols, where
they exist, and enhancing or updating them as necessary for modern
cryptographic best practices,
o Developing a framework for using automatic key management in order
to ease deployment, lower cost of operation, and allow for rapid
responses to security breaches, and
o Specifying the automated key management protocol that may be
combined with the bits-on-the-wire mechanisms.
The work also serves as an agreement between the Routing Area and the
Security Area about the priorities and work plan for incrementally
delivering the above work. This point is important. There will be
times when the best-security-possible will give way to vastly-
improved-over-current-security-but-admittedly-not-yet-best-security-
possible, in order that incremental progress toward a more secure
Internet may be achieved. As such, this document will call out
places where agreement has been reached on such trade offs.
This document does not contain protocol specifications. Instead, it
defines the areas where protocol specification work is needed and
sets a direction, a set of requirements, and a relative priority for
addressing that specification work.
There are a set of threats to routing protocols that are considered
in-scope for this document/roadmap, and a set considered out-of-
scope. These are described in detail in the Threats (Section 2)
section below.
Lebovitz & Expires September 1, 2010 [Page 7]
Internet-Draft KARP Threats and Requirements February 2010
1.4. Goals
The goals and general guidance for the KARP work follow:
1. Provide authentication and integrity protection for packets on the
wire of existing routing protocols
2. Deliver a path to incrementally improve security of the routing
infrastructure. The principle of crawl, walk, run will be in
place. Routing protocol authentication mechanisms may not go
immediately from their current state to a state containing the
best possible, most modern security practices. Incremental steps
will need to be taken for a few very practical reasons. First,
there are a considerable number of deployed routing devices in
operating networks that will not be able to run the most modern
cryptographic mechanisms without significant and unacceptable
performance penalties. The roadmap for any one routing protocol
MUST allow for incremental improvements on existing operational
devices. Second, current routing protocol performance on deployed
devices has been achieved over the last 20 years through extensive
tuning of software and hardware elements, and is a constant focus
for improvement by vendors and operators alike. The introduction
of new security mechanisms affects this performance balance. The
performance impact of any incremental step of security improvement
will need to be weighed by the community, and introduced in such a
way that allows the vendor and operator community a path to
adoption that upholds reasonable performance metrics. Therefore,
certain specification elements may be introduced carrying the
"SHOULD" guidance, with the intention that the same mechanism will
carry a "MUST" in the next release of the specification. This
gives the vendors and implementors the guidance they need to tune
their software and hardware appropriately over time. Last, some
security mechanisms require the build out of other operational
support systems, and this will take time. An example where these
three reasons are at play in an incremental improvement roadmap is
seen in the improvement of BGP's [RFC4271] security via the update
of the TCP Authentication Option (TCP-AO)
[I-D.ietf-tcpm-tcp-auth-opt] effort. It would be ideal, and
reflect best common security practice, to have a fully specified
key management protocol for negotiating TCP-AO's authentication
material, using certificates for peer authentication in the
keying. However, in the spirit of incremental deployment, we will
first address issues like cryptographic algorithm agility, replay
attacks, TCP session resetting in the base TCP-AO protocol before
we layer key management on top of it.
Lebovitz & Expires September 1, 2010 [Page 8]
Internet-Draft KARP Threats and Requirements February 2010
3. The deploy-ability of the improved security solutions on currently
running routing infrastructure equipment. This begs the
consideration of the current state of processing power available
on routers in the network today.
4. Operational deploy-ability - A solutions acceptability will also
be measured by how deployable the solution is by common operator
teams using common deployment processes and infrastructures. I.e.
We will try to make these solutions fit as well as possible into
current operational practices or router deployment. This will be
heavily influenced by operator input, to ensure that what we
specify can -- and, more importantly, will -- be deployed once
specified and implemented by vendors. Deployment of incrementally
more secure routing infrastructure in the Internet is the final
measure of success. Measurably, we would like to see an increase
in the number of surveyed respondents who report deploying the
updated authentication mechanisms anywhere across their network,
as well as a sharp rise in usage for the total percentage of their
network's routers.
Interviews with operators show several points about routing
security. First, over 70% of operators have deployed transport
connection protection via TCP-MD5 on their EBGP [ISR2008] . Over
55% also deploy MD5 on their IBGP connections, and 50% deploy MD5
on some other IGP. The survey states that "a considerable
increase was observed over previous editions of the survey for use
of TCP MD5 with external peers (eBGP), internal peers (iBGP) and
MD5 extensions for IGPs." Though the data is not captured in the
report, the authors believe anecdotally that of those who have
deployed MD5 somewhere in their network, only about 25-30% of the
routers in their network are deployed with the authentication
enabled. None report using IPsec to protect the routing protocol,
and this was a decline from the few that reported doing so in the
previous year's report.
From my personal conversations with operators, of those using MD5,
almost all report deploying with one single manual key throughout
the entire network. These same operators report that the one
single key has not been changed since it was originally installed,
sometimes five or more years ago. When asked why, particularly
for the case of BGP using TCP MD5, the following reasons are often
given:
A. Changing the keys triggers a TCP reset, and thus bounces the
links/adjacencies, undermining Service Level Agreements
(SLAs).
Lebovitz & Expires September 1, 2010 [Page 9]
Internet-Draft KARP Threats and Requirements February 2010
B. For external peers, difficulty of coordination with the other
organization is an issue. Once they find the correct contact
at the other organization (not always so easy), the
coordination function is serialized and on a per peer/AS
basis. The coordination is very cumbersome and tedious to
execute in practice.
C. Keys must be changed at precisely the same time, or at least
within 60 seconds (as supported by two major vendors) in order
to limit connectivity outage duration. This is incredibly
difficult to do, operationally, especially between different
organizations.
D. Relatively low priority compared to other operatoinal issues.
E. Lack of staff to implement the changes device by device.
F. There are three use cases for operational peering at play
here: peers and interconnection with other operators, Internal
BGP and other routing sessions within a single operator, and
operator-to-customer-CPE devices. All three have very
different properties, and all are reported as cumbersome. One
operator reported that the same key is used for all customer
premise equipment. The same operator reported that if the
customer mandated, a unique key could be created, although the
last time this occurred it created such an operational
headache that the administrators now usually tell customers
that the option doesn't even exist, to avoid the difficulties.
These customer-uniqe keys are never changed, unless the
customer demands so.
The main threat at play here is that a terminated employee from
such an operator who had access to the one (or few) keys used for
authentication in these environments could easily wage an attack
-- or offer the keys to others who would wage the attack -- and
bring down many of the adjacencies, causing destabilization to the
routing system.
Whatever mechanisms we specify need to be easier than the current
methods to deploy, and should provide obvious operational
efficiency gains along with significantly better security and
threat protection. This combination of value may be enough to
drive much broader adoption.
5. Address the threats enumerated above in the "Threats" section
(Section 2) for each routing protocol, along a roadmap. Not all
threats may be able to be addressed in the first specification
update for any one protocol. Roadmaps will be defined so that
both the security area and the routing area agree on how the
threats will be addressed completely over time.
Lebovitz & Expires September 1, 2010 [Page 10]
Internet-Draft KARP Threats and Requirements February 2010
6. Create a re-usable architecture, framework, and guidelines for
various IETF working teams who will address these security
improvements for various Routing Protocols. The crux of the KARP
work is to re-use that framework as much as possible across
relevant Routing Protocols. For example, designers should aim to
re-use the key management protocol that will be defined for BGP's
TCP-AO key establishment for as many other routing protocols as
possible. This is but one example.
7. Bridge any gaps between IETF's Routing and Security Areas by
recording agreements on work items, roadmaps, and guidance from
the Area leads and Internet Architecture Board (IAB, www.iab.org).
1.5. Non-Goals
The following two goals are considered out-of-scope for this effort:
o Privacy of the packets on the wire, at this point in time. Once
this roadmap is realized, we may revisit work on privacy.
o Message content security. This work is being addressed in other
IETF efforts, like SIDR.
1.6. Audience
The audience for this roadmap includes:
o Routing Area working group chairs and participants - These
people are charged with updates to the Routing Protocol
specifications. Any and all cryptographic authentication work
on these specifications will occur in Routing Area working
groups, with close partnership with the Security Area. Co-
advisors from Security Area may often be named for these
partnership efforts.
o Security Area reviewers of routing area documents - These people
are delegated by the Security Area Directors to perform reviews
on routing protocol specifications as they pass through working
group last call or IESG review. They will pay particular
attention to the use of cryptographic authentication and
corresponding security mechanisms for the routing protocols.
They will ensure that incremental security improvements are
being made, in line with this roadmap.
Lebovitz & Expires September 1, 2010 [Page 11]
Internet-Draft KARP Threats and Requirements February 2010
o Security Area engineers - These people partner with routing area
authors/designers on the security mechanisms in routing protocol
specifications. Some of these security area engineers will be
assigned by the Security Area Directors, while others will be
interested parties in the relevant working groups.
o Operators - The operators are a key audience for this work, as
the work is considered to have succeeded if the operators deploy
the technology, presumably due to a perception of significantly
improved security value coupled with relative similarity to
deployment complexity and cost. Conversely, the work will be
considered a failure if the operators do not care to deploy it,
either due to lack of value or perceived (or real) over-
complexity of operations. And as such, the GROW and OPSEC WGs
should be kept squarely in the loop as well.
2. Threats
In RFC4949[RFC4949], a threat is defined as a potential for violation
of security, which exists when there is a circumstance, capability,
action, or event that could breach security and cause harm. This
section defines the threats that are in scope for this roadmap, and
those that are explicitly out of scope. This document leverages the
"Generic Threats to Routing Protocols" model, RFC 4593 [RFC4593] ,
capitalizes terms from that document, and offers a terse definition
of those terms. (More thorough description of routing protocol
threats sources, motivations, consequences and actions can be found
in RFC 4593 [RFC4593] itself). The threat listings below expand upon
these threat definitions.
2.1. Threats In Scope
The threats that will be addressed in this roadmap are those from
OUTSIDERS, attackers that may reside anywhere in the Internet, have
the ability to send IP traffic to the router, may be able to observe
the router's replies, and may even control the path for a legitimate
peer's traffic. These are not legitimate participants in the routing
protocol. Message authentication and integrity protection
specifically aims to identify messages originating from OUTSIDERS.
The concept of OUTSIDERS can be further refined to include attackers
who are terminated employees, and those sitting on-path.
Lebovitz & Expires September 1, 2010 [Page 12]
Internet-Draft KARP Threats and Requirements February 2010
o On-Path - attackers with control of a network resource or a tap
along the path of packets between two routers. An on-path
outsider can attempt a man-in-the-middle attack, in addition to
several other attack classes. A man-in-the-middle (MitM) attack
occurs when an attacker who has access to packets flowing between
two peers tampers with those packets in such a way that both peers
think they are talking to each other directly, when in fact they
are actually talking to the attacker only. Protocols conforming
to this roadmap will use cryptographic mechanisms to prevent a
man-in-the-middle attacker from situating himself undetected.
o Terminated Employees - in this context, those who had access
router configuration that included keys or keying material like
pre-shared keys used in securing the routing protocol. Using this
material, the attacker could send properly MAC'd spoofed packets
appearing to come from router A to router B, and thus impersonate
an authorized peer. The attacker could then send false traffic
that changes the network behavior from its operator's design. The
goal of addressing this source specifically is to call out the
case where new keys or keying material becomes necessary very
quickly, with little operational expense, upon the termination of
such an employee. This grouping could also refer to any attacker
who somehow managed to gain access to keying material, and said
access had been detected by the operators such that the operators
have an opportunity to move to new keys in order to prevent an
attack.
These ATTACK ACTIONS are in scope for this roadmap:
o SPOOFING - when an unauthorized device assumes the identity of an
authorized one. Spoofing can be used, for example, to inject
malicious routing information that causes the disruption of
network services. Spoofing can also be used to cause a neighbor
relationship to form that subsequently denies the formation of the
relationship with the legitimate router.
o FALSIFICATION - an action whereby an attacker sends false routing
information. To falsify the routing information, an attacker has
to be either the originator or a forwarder of the routing
information. Falsification may occur by an ORIGINATOR, or a
FORWARDER, and may involve OVERCLAIMING, MISCLAIMING, or
MISTATEMENT of network resource reachability. We must be careful
to remember that in this work we are only targeting falsification
from outsiders as may occur from tampering with packets in flight.
Falsification from BYZANTINES (see the Threats Out of Scope
section (Section 2.2) below) are not addressed by the KARP effort.
Lebovitz & Expires September 1, 2010 [Page 13]
Internet-Draft KARP Threats and Requirements February 2010
o INTERFERENCE - when an attacker inhibits the exchanges by
legitimate routers. The types of interference addressed by this
work include:
* ADDING NOISE
* REPLAYING OUT-DATED PACKETS
* INSERTING MESSAGES
* CORRUPTING MESSAGES
* BREAKING SYNCHRONIZATION
* Changing message content
o DoS attacks on transport sub-systems - This includes any other DoS
attacks specifically based on the above attack types. This is
when an attacker sends spoofed packets aimed at halting or
preventing the underlying protocol over which the routing protocol
runs, for example halting a BGP session by sending a TCP FIN or
RST packet. Since this attack depends on spoofing, operators are
encouraged to deploy
o DoS attacks using the authentication mechanism - This includes an
attacker sending packets which confuse or overwhelm a security
mechanism itself. An example is initiating an overwhelming load
of spoofed authenticated route messages so that the receiver needs
to process the MAC check, only to discard the packet, sending CPU
levels rising. Another example is when an attacker sends an
overwhelming load of keying protocol initiations from bogus
sources. All other possible DoS attacks are out of scope (see
next section).
o Brute Foce Attacks Against Password/Keys - This includes either
online or offline attacks where attempts are made repeatedly using
different keys/passwords until a match is found. While it is
impossible to make brute force attacks on keys completely
unsuccessful, proper design can make such attacks much harder to
succeed. For exmaple, the key length should be sufficiently long
so that covering the entire space of possible keys is improbable
using computational power expected to be available 10 years out or
more. Also, frequently changing the keys may render useless a
successful guess some time in the future, as those keys may no
longer be in use.
2.2. Threats Out of Scope
Threats from BYZANTINE sources -- faulty, misconfigured, or subverted
routers, i.e., legitimate participants in the routing protocol -- are
out of scope for this roadmap. Any of the attacks described in the
above section (Section 2.1) that may be levied by a BYZANTINE source
are therefore also out of scope.
Lebovitz & Expires September 1, 2010 [Page 14]
Internet-Draft KARP Threats and Requirements February 2010
In addition, these other attack actions are out of scope for this
work:
o SNIFFING - passive observation of route message contents in flight
o FALSIFICATION by BYZANTINE sources - unauthorized message content
by a legitimate authorized source.
o INTERFERENCE due to:
* NOT FORWARDING PACKETS - cannot be prevented with cryptographic
authentication
* DELAYING MESSAGES - cannot be prevented with cryptographic
authentication
* DENIAL OF RECEIPT - cannot be prevented with cryptographic
authentication
* UNAUTHORIZED MESSAGE CONTENT - the work of the IETF's SIDR
working group
(http://www.ietf.org/html.charters/sidr-charter.html).
* Any other type of DoS attack. For example, a flood of traffic
that fills the link ahead of the router, so that the router is
rendered unusable and unreachable by valid packets is NOT an
attack that this work will address. Many other such examples
could be contrived.
3. Requirements for Phase 1 of a Routing Protocol Transport's Security
Update
The following list of requirements SHOULD be addressed by a KARP Work
Phase 1 security update to any Routing Protocol (according to section
4.1 of the KARP Design Guide [I-D.ietf-karp-design-guide] document).
IT IS RECOMMENDED that any Phase 1 security update to a Rouing
Protocol contain a section of the specification document that
describes how each of these requirements are met. It is further
RECOMMENDED that textual justification be presented for any
requirements that are NOT addressed.
1. Clear definitions of which elements of the transmission (frame,
packet, segment, etc.) are protected by the authentication
mechanism
2. Strong algorithms, and defined and accepted by the security
community, MUST be specified. The option should use algorithms
considered accepted by the IETF's Security community, which are
considered appropriately safe. The use of non-standard or
unpublished algorithms SHOULD BE avoided.
3. Algorithm agility for the cryptograhpic algorithms used in the
authentication MUST be specified, i.e. more than one algorithm
MUST be specified and it MUST be clear how new algorithms MAY be
specified and used within the protocol. This requirement exists
in case one algorithm gets broken suddenly. Research to
Lebovitz & Expires September 1, 2010 [Page 15]
Internet-Draft KARP Threats and Requirements February 2010
identify weakness in algorithms is constant. Breaking a cipher
isn't a matter of if, but when it will occur. It's highly
unlikely that two different algorithms will be broken
simultaneously. So, if two are supported, and one gets broken,
we can use the other until we get a new one in place. Having
the ability within the protocol specification to support such an
event, having algorithm agility, is essential. Mandating two
algorithms provides both a redundancy, and a mechanism for
enacting that redundancy when needed. Further, the mechanism
MUST describe the generic interface for new cryptographic
algorithms to be used, so that implementers can use algorithms
other than those specified, and so that new algorithms may be
specifed and supported in the future.
4. Secure use of simple PSKs, offering both operational convenience
as well as building something of a fence around stupidity, MUST
be specified.
5. Inter-connection replay protection. Packets captured from one
connection MUST NOT be able to be re-sent and accepted during a
later connection.
6. Intra-connection replay protection. Packets captured during a
connection MUST NOT be able to be re-sent and accepted during
that same connection, to deal with long-lived connections.
Additionally, replay mechanisms MUST work correctly even in the
presence of Routing Protocol packet prioritization by the router
(see requirement 17 below).
7. A change of security parameters REQUIRES, and even forces, a
change of session traffic keys
8. Intra-connection re-keying which occurs without a break or
interruption to the current peering session, and, if possible,
without data loss, MUST be specified. Keys need to be changed
periodically, for operational privacey (e.g. when an
administrator who had access to the keys leaves an organization)
and for entropy purposes, and a re-keying mechanism enables the
deployers to execute the change without productivity loss.
9. Efficient re-keying SHOULD be provided. The specificaion SHOULD
support rekeying during a connection without the need to expend
undue computational resources. In particular, the specification
SHOULD avoid the need to try/compute multiple keys on a given
packet.
10. Prevent DoS attacks as those described as in-scope in the
threats section Section 2.1 above.
11. Default mechanisms and algorithms specified and defined are
REQUIRED for all implementations.
12. Manual keying MUST be supported.
13. Architecture of the specification MUST consider and allow for
future use of a KMP.
Lebovitz & Expires September 1, 2010 [Page 16]
Internet-Draft KARP Threats and Requirements February 2010
14. The authentication mechanism in the Routing Protocol MUST be
decoupled from the key management system used. It MUST be
obvious how the keying material was obtained, and the process
for obtaining the keying material MUST exist outside of the
Routing Protocol. This will allow for the various key
generation methods, like manual keys and KMPs, to be used with
the same Routing Protocol mechanism.
15. Convergence times of the Routing Protocols SHOULD NOT be
materially affected. Materially here is defined as anything
greater than a 5% convergence time increase. Note that
convergence is different than boot time. Also note that
convergence time has a lot to do with the speed of processors
used on individual routing peers, and this processing power
increases by Moore's law over time, meaning that the same route
calculations and table population routines will decrease in
duration over time. Therefore, this requirement should be
considered only in terms of total number of messages that must
be exchanged, and less for the computational intensity of
processing any one message.
16. The changes or addition of security mechanisms SHOULD NOT cause
a refresh of route updates or cause additional route updates to
be generated.
17. Router implementations provide prioritized treament to certain
protocol packets. For example, OSPF HELLO messages and ACKs are
prioritized for processing above other OSPF packets. The
authentication mechanism SHOULD NOT interfere with the ability
to observe and enforce such prioritizations. Any effect on such
priority mechanisms MUST be explicitly documented and justified.
18. The authentication mechanism does not provide message
confidentiality, but SHOULD NOT preclude the possibility of
confidentiality support being added in the future.
19. The KARP mechanism MUST provide a sufficiently large sequence
number space so that intra-connection replay protection will
succeed. [Editor note: This may be more of a design guide item
than a requirement? Also, it may be best to include it with
3.6?]
20. The new security and authentication mechanisms MUST support
incremental deployment. It will not be feasible to deploy a new
Routing Protocol authentication mechanism throughout the network
instantaneously. It also may not be possible to deploy such a
mechanism to all routers in a large autonomous system (AS) at
one time. Proposed solutions SHOULD support an incremental
deployment method that provides some benefit for those who
participate. Because of this, there are several requirements
that any proposed KARP mechanism should consider.
21.
Lebovitz & Expires September 1, 2010 [Page 17]
Internet-Draft KARP Threats and Requirements February 2010
1. The Routing Protocol security mechanism MUST enable each
router to configure use of the security mechanism on a per-
peer basis where the communication is one-on-one.
2. The new KARP mechanism MUST provide backward compatibility
in the message formatting, transmission, and processing of
routing information carried through a mixed security
environment. Message formatting in a fully secured
environment MAY be handled in a non-backward compatible
fashion though care must be taken to ensure that routing
protocol packets can traverse intermediate routers which
don't support the new format.
3. In an environment where both secured and non-secured
systems are interoperating a mechanism MUST exist for
secured systems to identify whether an originator intended
the information to be secured.
4. In an environment where secured service is in the process
of being deployed a mechanism MUST exist to support a
transition free of service interruption (caused by the
deployment per se).
22. The introduction of mechanisms to improve routing authentication
and security may increase the processing performed by a router.
Since most of the currently deployed routers do not have
hardware to accelerate cryptographic operations, these
operations could impose a significant processing burden under
some circumstances. Thus proposed solutions should be evaluated
carefully with regard to the processing burden they may impose,
since deployment may be impeded if network operators perceive
that a solution will impose a processing burden which either:
23.
* provokes substantial capital expense, or
* threatens to destabilize routers.
24. Given the high number of routers that would require the new
authentication mechanisms in a typical ISP deployment, solutions
can increase their appeal by minimizing the burden imposed on
all routers in favor of confining significant work loads to a
relatively small number of devices. Optional features or
increased assurance that provokes more pervasive processing load
MAY be made available for deployments where the additional
resources are economically justifiable.
25. The new authentication and security mechanisms should not rely
on systems external to the routing system (the equipment that is
performing forwarding). In order to ensure the rapid
initialization and/or return to service of failed nodes it is
important to reduce reliance on these external systems to the
greatest extent possible. Therefore, proposed solutions SHOULD
NOT require connections to external systems, beyond those
directly involved in peering relationships, in order to return
to full service. It is however acceptable for the proposed
Lebovitz & Expires September 1, 2010 [Page 18]
Internet-Draft KARP Threats and Requirements February 2010
solutions to require post initialization synchronization with
external systems in order to fully synchronize the security
information.
26.
4. Security Considerations
This document is mostly about security considerations for the KARP
efforts, both threats and requirements for solving those threats.
More detailed security considerations were placed in the Security
Considerations section of the KARP Design Guide
[I-D.ietf-karp-design-guide] document.
5. IANA Considerations
This document has no actions for IANA.
6. Acknowledgements
The majority of the text for version -00 of this document was taken
from draft-lebovitz-karp-roadmap, authored by Gregory Lebovitz.
Manav Bhatia provided a detailed review of the existing requirements,
and provided text for a few more.
7. Change History (RFC Editor: Delete Before Publishing)
[NOTE TO RFC EDITOR: this section for use during I-D stage only.
Please remove before publishing as RFC.]
kmart-00-00 original rough rough rough draft for review by routing
and security AD's
karp-threats-reqs-00-
o removed all the portions that will be covered in either
draft-ietf-karp-design-guide or draft-ietf-karp-framework
8. Needs Work in Next Draft (RFC Editor: Delete Before Publishing)
[NOTE TO RFC EDITOR: this section for use during I-D stage only.
Please remove before publishing as RFC.]
Lebovitz & Expires September 1, 2010 [Page 19]
Internet-Draft KARP Threats and Requirements February 2010
List of stuff that still needs work
o Clean up section 3 requirements, parsing for overlaps, and
ensuring that each are written in such a way as to be objectively
either filled or not filled by a KARP spec.
o Manav check sect 3 for inclusion of the various requirements you
sent to Gregory. Provide clear text for any omissions.
o check Brian Weis text on threats against what is in sect 2 already
to ensure it's covered.
o Review by a few other security area folks.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
Routing Protocols", RFC 4593, October 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.
9.2. Informative References
[I-D.ao-crypto]
Lebovitz, G., "Cryptographic Algorithms, Use and
Implementation Requirements for TCP Authentication
Option", March 2009, <http://tools.ietf.org/html/
draft-lebovitz-ietf-tcpm-tcp-ao-crypto-00>.
[I-D.ietf-karp-design-guide]
Lebovitz, G. and M. Bhatia, "Keying and Authentication for
Routing Protocols (KARP) Design Guidelines",
draft-ietf-karp-design-guide-00 (work in progress),
February 2010.
[I-D.ietf-karp-framework]
Atwood, W. and G. Lebovitz, "Framework for Cryptographic
Authentication of Routing Protocol Packets on the Wire",
draft-ietf-karp-framework-00 (work in progress),
February 2010.
[I-D.ietf-pim-sm-linklocal]
Atwood, W., Islam, S., and M. Siami, "Authentication and
Confidentiality in PIM-SM Link-local Messages",
Lebovitz & Expires September 1, 2010 [Page 20]
Internet-Draft KARP Threats and Requirements February 2010
draft-ietf-pim-sm-linklocal-10 (work in progress),
December 2009.
[I-D.ietf-tcpm-tcp-auth-opt]
Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", draft-ietf-tcpm-tcp-auth-opt-10
(work in progress), January 2010.
[ISR2008] McPherson, D. and C. Labovitz, "Worldwide Infrastructure
Security Report", October 2008,
<http://www.arbornetworks.com/dmdocuments/ISR2008_US.pdf>.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453,
November 1998.
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5
Signature Option", RFC 3562, July 2003.
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery
Protocol (MSDP)", RFC 3618, October 2003.
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol
Independent Multicast - Dense Mode (PIM-DM): Protocol
Specification (Revised)", RFC 3973, January 2005.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, June 2005.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
Lebovitz & Expires September 1, 2010 [Page 21]
Internet-Draft KARP Threats and Requirements February 2010
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The
Advanced Encryption Standard-Cipher-based Message
Authentication Code-Pseudo-Random Function-128 (AES-CMAC-
PRF-128) Algorithm for the Internet Key Exchange Protocol
(IKE)", RFC 4615, August 2006.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
RFC 4949, August 2007.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
Authors' Addresses
Gregory Lebovitz
Juniper Networks, Inc.
1194 North Mathilda Ave.
Sunnyvale, CA 94089-1206
US
Phone:
Email: gregory.ietf@gmail.com
Phone:
Email:
Lebovitz & Expires September 1, 2010 [Page 22]
