KARP W. Atwood
Internet-Draft Concordia University/CSE
Intended status: Informational G. Lebovitz
Expires: August 31, 2010 Juniper
February 27, 2010
Framework for Cryptographic Authentication of Routing Protocol Packets
on the Wire
draft-ietf-karp-framework-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." One mechanism for securing routing
protocol packets on the wire 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. This document is
one of a series concerned with defining a roadmap of protocol
specification work for the use of modern cryptogrpahic mechanisms and
algorithms for message authentication in routing protocols. In
particular, it defines the framework for a key management protocol
that may be used to create and manage session keys for message
authentication and integrity. The overall roadmap reflects the input
of both the security area and routing area in order to form a jointly
agreed upon and prioritized work list for the effort.
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-
Drafts.
Atwood & Lebovitz Expires August 31, 2010 [Page 1]
Internet-Draft KARP Framework February 2010
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 August 31, 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.
Atwood & Lebovitz Expires August 31, 2010 [Page 2]
Internet-Draft KARP Framework 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. Common Framework . . . . . . . . . . . . . . . . . . . . . . . 12
2.1. Framework Elements . . . . . . . . . . . . . . . . . . . . 15
3. Framework Components . . . . . . . . . . . . . . . . . . . . . 19
3.1. Key Management Protocol . . . . . . . . . . . . . . . . . 19
3.2. KeyStore . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3. Routing Protocol Mechanisms . . . . . . . . . . . . . . . 20
4. Framework APIs . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. KMP-to_Keystore API . . . . . . . . . . . . . . . . . . . 21
4.2. KMP-to-Routing Protocol API . . . . . . . . . . . . . . . 21
4.3. Keystore-to-Routing Protocl API . . . . . . . . . . . . . 21
5. Security Considerations . . . . . . . . . . . . . . . . . . . 21
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
8. Change History (RFC Editor: Delete Before Publishing) . . . . 22
9. Needs Work in Next Draft (RFC Editor: Delete Before
Publishing) . . . . . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Atwood & Lebovitz Expires August 31, 2010 [Page 3]
Internet-Draft KARP Framework 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. The document addresses
Keying and Authentication for Routing Protocols, aka "KARP".
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.
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
Atwood & Lebovitz Expires August 31, 2010 [Page 4]
Internet-Draft KARP Framework February 2010
relatively small set of initial values that are passed
into the function. An example 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,
such as 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.
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 how 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 Framework section Section 2.
Atwood & Lebovitz Expires August 31, 2010 [Page 5]
Internet-Draft KARP Framework February 2010
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 framework 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 rogue
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
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 BGP and LDP, 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.
There are two main work phases for the roadmap, and for any Routing
Protocol work undertaken as part of the roadmap. The first is to
Atwood & Lebovitz Expires August 31, 2010 [Page 6]
Internet-Draft KARP Framework February 2010
enhance the Routing Protocol's current authentication mechanism,
ensuring it employs modern cryptographic algorithms and methods for
its basic operational model, fulfilling the requirements defined in
the Requirements section of the Design Guidelines document [**need
reference**], and protecting against as many of the threats as
possible as defined in the Threats section of the same dcoument.
Many of the Routing Protocols' current mechanisms use manual keys, so
the first phase updates will focus on shoring up the manual key
mechanisms that exist.
The second work phase is to define the use of a key management
protocol (KMP) for creating and managing session keys used in the
Routing Protocols' message authentication and data integrity
functions. It is intended that a general KMP framework -- or a small
number of frameworks -- can be defined and leveraged for many Routing
Protocols.
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 of
[**somewhere**].
Atwood & Lebovitz Expires August 31, 2010 [Page 7]
Internet-Draft KARP Framework February 2010
NOTE: Cross-references now indicated by [** some text *]] were valid
in the original draft by Greg. They will be properly indicated in
the next version, once all three companion documents are published
and available in the repository.
1.4. Goals
The goals and general guidance for this work roadmap 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 such as cryptographic algorithm agility,
Atwood & Lebovitz Expires August 31, 2010 [Page 8]
Internet-Draft KARP Framework February 2010
replay attacks, TCP session resetting in the base TCP-AO protocol
before we layer key management on top of it.
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 - The acceptability of a solution 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 are 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:
Atwood & Lebovitz Expires August 31, 2010 [Page 9]
Internet-Draft KARP Framework February 2010
A. Changing the keys triggers a TCP reset, and thus bounces the
links/adjacencies, undermining Service Level Agreements
(SLAs).
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.
Atwood & Lebovitz Expires August 31, 2010 [Page 10]
Internet-Draft KARP Framework February 2010
5. Address the threats enumerated above in the "Threats" section
[**somewhere**] 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.
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, such as 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
Atwood & Lebovitz Expires August 31, 2010 [Page 11]
Internet-Draft KARP Framework February 2010
corresponding security mechanisms for the routing protocols.
They will ensure that incremental security improvements are
being made, in line with this roadmap.
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. Common Framework
Each of the categories of routing protocols above will require unique
designs for authenticating and integrity checking their protocols.
However, a single underlying framework for delivering automatic
keying to those solutions will be pursued. Providing such a single
framework will significantly reduce the complexity of each step of
the overall roadmap. For example, if each Routing Protocol needed to
define its own key management protocol this would balloon the total
number of different sockets that need to be opened and processes that
need to be simultaneously running on an implementation. It would
also significantly increase the run-time complexity and memory
requirements of such systems running multiple Routing Protocols,
causing perhaps slower performance of such systems. However, if we
can land on a very small set (perhaps one or two) of automatic key
management protocols, KMPs, that the various Routing Protocols can
use, then we can reduce this implementation and run-time complexity.
We can also decrease the total amount of time implementers need to
deliver the KMPs for the Routing Protocols that will provide better
threat protection.
The components for the framework are listed here, and described in
the next section:
Atwood & Lebovitz Expires August 31, 2010 [Page 12]
Internet-Draft KARP Framework February 2010
o Common Routing Protocol security mechanisms
o Specific Routing Protocol security mechanisms
o KeyStore
o Peer Key
o Traffic Key
o KMP
o Identifiers
o Identity Proof
o Profiles
o RoutingProtocol-to-KMP API
o RoutingProtocol-to-KeyStore API
o KMP-to-KeyStore API
The framework is modularized for how keys and security association
(SA) parameters generally get passed from a KMP to a transport
protocol. It contains three main blocks and APIs.
Atwood & Lebovitz Expires August 31, 2010 [Page 13]
Internet-Draft KARP Framework February 2010
+------------+ +--------------------+ +-----------+
| | | | Check | |
| Identifier +-->| +---------->| Identity |
| | | KMP Function | | Proof |
+----------- + | |<----------+ |
| | Approve +-----------+
+---------------+ +-------+--------+---+
| | /|\ /|\
| Manual | | |
| Configuration | | |
| | | |
+-------------+-+ | |
/|\ KMP-to- | |
| Keystore | |
| API | |
\|/ \|/ |
+-+-------------+-+ |
| | | KMP-to-
| | | RoutingProtocol
| KeyStore | | API
| | |
+---------+-------+ |
/|\ |
| |
KeyStore-to- | |
RoutingProtocol API | |
| \|/
+--------------------------+-------------+
| | |
| | Common Routing |
| \|/ Protocol |
| +-------+-------+ Security |
| | | Mechanisms |
+---| Traffic |----+---+---+---+---+
| | Key(s) | | | | | |
| | | | | | | | A, B, C, D ->
| +---------------+ | A | B | C | D | Specific
| | | | | | Routing Protocol
| | | | | | Security
| | | | | | Mechanisms
+------------------------+---+---+---+---+
Figure 1: Automatic Key Management Framework
Atwood & Lebovitz Expires August 31, 2010 [Page 14]
Internet-Draft KARP Framework February 2010
2.1. Framework Elements
Each element of the framework is described here:
o Common Routing Protocol security mechanisms - In each case, the
Routing Protocol will contain one or more mechanism(s) for
using session keys in their security option. The common
mechanisms part will allow a routing protocol to receive
updates from the KeyStore and to poll for updates from the
KeyStore, including the passing of all possible required
attributes relevant to that Routing Protocol.
o Specific Routing Protocol security mechanisms - These parts will
be specific to a particular Routing Protocol. When the
Routing Protocol uses a transport substrate, e.g., the way
BGP, LDP and MSDP use TCP, then this applies to the security
mechanism the includes that substrate.
NOTE: the point of this two-layer approach is that there will
be one generic abstraction layer that can sit on top of any/
all Routing Protocols. The hope is that the Routing Protocol
Demon development teams can write this part once, and use it
for any routing Protocol. There may be evolution over time
of the abstraction layer so as to contain capabilities and
attribute definitions as needed by routing Protocols yet-to-
be-addressed in this architecture. However, the new Routing
Protocol would still leverage all that had gone into the
abstraction layer before.
o KeyStore - Each implementation will also contain a protocol
independent mechanism for storing keys, called the KeyStore.
The KeyStore will have multiple different logical containers,
one container for each Session Association or Multicast
Session Association that any given Routing Protocol will
need. The container will store the parameters needed for the
SA or the MSA, for example, detalis of the authentication/
encryption algorithms employed, the valid lifetime of the
keys, the direction in which the key needs to be applied
(inward/outward/both), the group SPI, a KeyID, etc. A key
stored here may be a Peer Key or a Traffic Key. Further
details may be found in [I-D.polk-saag-rtg-auth-keytable] and
[I-D.housley-saag-crypto-key-table]. Note that a specific
Routing Protocol may utilize both communication between two
peers and communication among groups of peers. As an
example, PIM-SM sends distant messages (Register and
Register-Stop) using unicast, and "link-local" messages
(Hello, Assert, Join/Prune) using multicast
[I-D.ietf-pim-sm-linklocal].
Atwood & Lebovitz Expires August 31, 2010 [Page 15]
Internet-Draft KARP Framework February 2010
o Peer Key - A key used between peers from which a traffic key is
derived. An example is a Pre-Shared Key.
o Traffic Key - The actual key used on each packet of a message.
This key may be derived from the key existing in the
KeyStore. This will depend on whether the key in KeyStore
was a manual PSK for the peers, or whether a connection-aware
KMP created the key. Further, it will be connection
specific, so as to provide inter- and intra-connection replay
protection.
o KMP - There will be an automated key management protocol, KMP.
This KMP will run between the peers. The KMP serves as a
protected channel between the peers, through which they can
negotiate and pass important data required to exchange proof
of key identifiers, derive session keys, determine re-keying,
synchronize their keying state, signal various keying events,
notify with error messages, etc. As an analogy, in the IPsec
protocol (RFC4301 [RFC4301], RFC4303 [RFC4303] and RFC4306
[RFC4306]) IKEv2 is the KMP that runs between the two peers,
while AH and ESP are two different base protocols that take
session keys from IKEv2 and use them in their transmissions.
In the analogy, the Routing Protocol, say BGP and LDP, are
analogous to ESP and AH, while the KMP is analogous to IKEv2
itself.
o Identifiers - A KMP is fed by identities. The identities are
text strings used by the peers to indicate to each other that
each are known to the other, and authorized to establish
connections. Those identities must be represented in some
standard string format, e.g. an IP address -- either v4 or
v6, an FQDN, an RFC 822 email address, a Common Name [RFC
PKI], etc. Note that even though routers do not normally
have email addresses, one could use an RFC 822 email address
string as a formatted identifier for a router. They would do
so simply by putting the router's reference number or name-
code as the "NAME" part of the address, left of the "@"
symbol. They would then place some locational context in the
"DOMAIN" part of the string, to the right of the "@" symbol.
An example would be "rtr0210@sf.ca.us.company.com". This
document does not suggest this string value at all. Instead,
the concept is used only to clarify that the type of string
employed does not matter. It also does not matter what
specific text you chose to place in that string type. It
only matters that the type of string -- and its format --
must be agreed upon by the two endpoints. Further, the
string can be used as an identifier in this context, even if
Atwood & Lebovitz Expires August 31, 2010 [Page 16]
Internet-Draft KARP Framework February 2010
the string is not actually provisioned in its source domain.
For example, the email address "rtr0210@sf.ca.us.company.com"
may not actually exist as an email address in that domain,
but that string of characters may still be used as an
identifier type(s) in the routing protocol security context.
What is important is that the community decide on a small but
flexible set of Identifiers they will all support, and that
they decide on the exact format of those string. The formats
that will be used must be standardized and must be sensible
for the routing infrastructure.
o Identity Proof - Once the form of identity is decided, then
there must be a cryptographic proof of that 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 pre-shared keys, raw assymetric keys, or a more
user-friendly representation of assymetric keys, such as a
certificate. Certificates can be used in a way requiring no
additional supporting systems -- e.g. public keys for each
peer can be maintained locally for verification upon contact.
Certificate management can be made more simple and scalable
with the use of minor additional supporting systems, as is
the case with self-signed certificates and a flat file list
of "approved thumbprints". Self-signed certificates will
have somewhat lower security properties than Certificate
Authority signed certificates [RFC Certs]. The use of these
different identity proofs vary in ease of deployment, ease of
ongoing management, startup effort, ongoing effort and
management, security strength, and consequences from loss of
secrets from one part of the system to the rest of the
system. For example, they differ in resistance to a security
breach, and the effort required to remediate the whole system
in the event of such a breach. The point here is that there
are options, many of which are quite simple to employ and
deploy.
o Profiles - Once the KMP, Identifiers and Proofs mechanisms are
converged upon, they must be clearly profiled for each
Routing Protocol, so that implementors and deployers alike
understand the different pieces of the solution, and can have
similar configurations and interoperability across multiple
vendors' devices, so as to reduce management difficulty. The
profiles SHOULD also provide guidance on when to use which
various combinations of options. This will, again, simplify
use and interoperability.
Atwood & Lebovitz Expires August 31, 2010 [Page 17]
Internet-Draft KARP Framework February 2010
[after writing this all up, I'm not sure we really need the key_store
in the middle. As long as we standardize fully all the calls needed
from any Routing Protocol to any KMP, then there can be a generic
hand-down function from the KMP to the Routing Protocol when the key
and parameters are ready. Let's sleep on it.]
[will need state machines and function calls for these APIs, as one
of the work items. In essence, there is a need for a core team to
develop the APIs out completely in order for the Routing Protocol
teams to use them. Need to get this team going asap.]
o KMP-to-RoutingProtocol API - There will be an API for the
Routing Protocol to request a session key of the KMP, and be
notified when the keys are available for it. The API will
also contain a mechanism for the KMP to notify the Routing
Protocol that there are new keys that it must now use, even
if it didn't request those keys. The API will also include a
mechanism for the KMP to receive requests for session keys
and other parameters from the routing protocol. The KMP will
also be aware of the various Routing Protocols and each of
their unique parameters that need to be negotiated and
returned.
o KeyStore-to-RoutingProtocol API - There will be an API for
Routing Protocol to retrieve (or receive; it could be a push
or a pull) the keys from the KeyStore. This will enable
implementers to reuse the same API calls for all their
Routing Protocols. The API will necessarily include facility
to retrieve other SA parameters required for the construction
of the Routing Protocol's packets, such as key IDs or key
lifetimes, etc.
o KMP-to-KeyStore API - There will be an API for the KMP to place
keys and parameters into the KeyStore after their negotiation
and derivation with the other peer. This will enable the
implementers to reuse the same calls for multiple KMPs that
may be needed to address the various categories of Routing
Protocols as described in the section defining categories in
the Design Guidelines document [**need reference**].
In addition to other business, administrative, and operational terms
they must already exchange prior to forming first adjacencies, it is
assumed that two parties deploying message authentication on their
routing protocol will also need to decide upon acceptable security
parameters for the connection. This will include the form and
Atwood & Lebovitz Expires August 31, 2010 [Page 18]
Internet-Draft KARP Framework February 2010
content of the identity each use to represent the other. It will
also include the type of keys to be used, e.g. PSK, raw assymetric
keys, certificate. Also, it will include the acceptable
cryptographic algorithms, or algorithm suite. This agreement is
necessary in order for each to properly configure the connection on
their respective devices. The manner in which they agree upon and
exchange this policy information is normally via phone call or
written exchange, and is outside the scope of the KARP effort, but
assumed to have occured. We take as a given that each party knows
the identity types and values, key types and values, and acceptable
cryptographic algorithms for both their own device and the peer that
form the security policy for configuration on their device.
Common Mechanisms - In as much as they exist, the framework will
capture mechanisms that can be used commonly not only within a
particular category of Routing Protocol and Routing Protocol to KMP,
but also between Routing Protocol categories. Again, the goal here
is simplifying the implementations and runtime code and resource
requirements. There is also a goal here of favoring well vetted,
reviewed, operationally proven security mechanisms over newly brewed
mechanisms that are less well tried in the wild.
3. Framework Components
This section will contain additional information/commentary on the
operation of the components.
3.1. Key Management Protocol
[[The following text needs a home.]]
[[Manav]] Should there be some text on key rollover or keys expiring?
Who takes care of these events, the KMP or the Routing Protocol? I
believe that it should be the former.
[[Greg]] If there is a kmp, then the kmp can put the new SA
parameters (including keys) into the KeyStore. However, based on our
experience with TCP-AO, there are several things that the base
RoutingProtocol needs to do to handle key rollover so that no routing
messages are dropped. Allowing for overlapping or multiple,
simulatneously valid KeyIDs is one requirements. polling for updates,
or receiving updates from, KeyStore is another requirement. For now,
however, it would be better to capture these in the threats-
requirements document, and then let each routing protocol category
design team figure out the details as apporpriate for their
protocol(s).
Atwood & Lebovitz Expires August 31, 2010 [Page 19]
Internet-Draft KARP Framework February 2010
3.2. KeyStore
[[The following text needs a home.]]
[[Greg]] If one continues down this thought exercise, one could
imagine an IANA registry filled with attributes as would be required
for any SA parameters that any KARP-following protocol would want /
need to use, such that both the KMP-to-KeyStore API and the KeyStore-
to-RtgProto API would reference that registry, and it would grow over
time as new categories of RoutingProtocols find need for this or that
attribute to make their specific SA's complete.
3.3. Routing Protocol Mechanisms
[[Issue to be resolved]]
[[Manav]] I am not sure I completely understand what would get into
Common RtgProto auth mechanisms?
[[Manav]] Is it some infrastructure that protocols like OSPF and ISIS
can use, or all RPs (PIM, OSPFv3, etc) using IPSec may want to use?
[[Greg]] Probably only those protocols taking keys from IKE directly
(assuming IKEv2 would be the KMP, whic is still up for discussion),
and not relevant to keys created from IKE for IPsec (IKE already
knows how to pass keys SA parameters to IPsec).
[[Manav]] If so, then some protocols (BGP?) may want KMP to directly
speak to them, in which case KMP-to-RoutingProtocol API should also
have a direct connection to Specific routing protocol auth security
mechanism.
[[Greg]] We discussed this on the planning call for the first draft.
We decided that there are times when, as the routing protocol kicks-
off, it sees that the protocol config calls for authentication. In
this case, the routing protocol needs to tell the KMP that it needs
keys and SA parameters. Also, though this isn't the exchange I agree
with, we might decide that it is the RoutingProtocol's responsibility
to tell the KMP when active keys are approaching expiry, and ask for
new keys. (On this point, I favor the KMP keeping track of this, and
negotiating new Keys for the RoutingProtocol when needed.) But we
aren't done with that discussion yet. As we get into the detailed
work on RoutingProtocol(s) categories, we may find other uses for the
direct KMP-to-RoutingProtocol-Auth-Mechanism abstraction layer, so we
decided to keep it.
[[Manav]] On second thoughts, wouldnt KMP only interact with the
KeyStore and RPs with Keystore - why would we want the RPs to speak
Atwood & Lebovitz Expires August 31, 2010 [Page 20]
Internet-Draft KARP Framework February 2010
to KMP?
[[Greg]] See explanation directly above.
[[Manav, later]] Would be extremely helpful if we can have a section
with the pros and cons of having IKEv2 as the KMP as against defining
a new KMP for RPs.
[[Bill]] Unicast relationships may well use something such as IKEv2;
multicast relationships will need to use a group key management
protocol, such as GDOI some variant of GDOI.
4. Framework APIs
This will be new work.
4.1. KMP-to_Keystore API
To be written.
4.2. KMP-to-Routing Protocol API
To be written.
4.3. Keystore-to-Routing Protocl API
To be written.
5. Security Considerations
6. IANA Considerations
This document has no actions for IANA.
7. Acknowledgements
Almost all the text for draft-00 of this document was pasted in from
draft-lebovitz-karp-roadmap, which was written by Gregory Lebovitz.
Bill Atwood took the role as editor for the first version of this
framework document.
Atwood & Lebovitz Expires August 31, 2010 [Page 21]
Internet-Draft KARP Framework February 2010
8. 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-framework-00- (original submission, based on
draft-lebovitz-karp-roadmap-00)
o removed sections of the roadmap that are not part of the
framework.
o promoted subsection on "Common Framework" to section, and
separated part of it into a subsection on "Framework Elements".
o added section on Framework Components and three subsections for
specific components. Inserted "notes" on points that need to be
resolved.
o added (empty) section on Framework APIs and three (empty)
subsections for the specific APIs.
o made arrows in Figure 1 bi-directional.
o added "Manual Configuration" in Figure 1, so that the routing
protocol's use of keys is decoupled from the mechanism used to
derive and place those keys.
o made explicit the fact that the KeyStore contains various
parameters for Security Associations (or Multicast Security
Associations), not just keys.
o broke the Routing Protocol security mechanisms into "common" and
"specific" parts
o re-ordered and augmented the "list of components" and the "list of
framework elements" so that they contained the same components
o marked internal references that need to become external
references, pending creation of the external documents.
o general grammatical corrections.
9. 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.]
List of stuff that still needs work
o text for section on Framework Components and its subsections
o text for section on Framework APIs and its subsections
o general removal of text that belongs in other companion documents
o
o
10. References
Atwood & Lebovitz Expires August 31, 2010 [Page 22]
Internet-Draft KARP Framework February 2010
10.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.
10.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.housley-saag-crypto-key-table]
Housley, R. and T. Polk, "Database of Long-Lived Symmetric
Cryptographic Keys",
draft-housley-saag-crypto-key-table-01 (work in progress),
November 2009.
[I-D.ietf-pim-sm-linklocal]
Atwood, W., Islam, S., and M. Siami, "Authentication and
Confidentiality in PIM-SM Link-local Messages",
draft-ietf-pim-sm-linklocal-10 (work in progress),
December 2009.
[I-D.ietf-tcpm-tcp-ao-crypto]
Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms
for TCP's Authentication Option, TCP-AO",
draft-ietf-tcpm-tcp-ao-crypto-02 (work in progress),
February 2010.
[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.
[I-D.polk-saag-rtg-auth-keytable]
Polk, T. and R. Housley, "Routing Authentication Using A
Database of Long-Lived Cryptographic Keys",
draft-polk-saag-rtg-auth-keytable-02 (work in progress),
December 2009.
Atwood & Lebovitz Expires August 31, 2010 [Page 23]
Internet-Draft KARP Framework February 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.
[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
Atwood & Lebovitz Expires August 31, 2010 [Page 24]
Internet-Draft KARP Framework February 2010
(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
J. William Atwood
Concordia University/CSE
1455 de Maisonneuve Blvd, West
Montreal, QC H3G 1M8
Canada
Phone: +1(514)848-2424 ext3046
Email: bill@cse.concordia.ca
URI: http://users.encs.concordia.ca/~bill
Gregory Lebovitz
Juniper Networks, Inc.
1194 North Mathilda Ave.
Sunnyvale, CA 94089-1206
US
Phone:
Email: gregory.ietf@gmail.com
Atwood & Lebovitz Expires August 31, 2010 [Page 25]