One document matched: draft-lebovitz-kmart-roadmap-00.txt
saag G. Lebovitz
Internet-Draft Juniper
Intended status: Informational January 23, 2009
Expires: July 24, 2009
Roadmap for Cryptographic Authentication of Routing Protocol Packets on
the Wire
draft-lebovitz-kmart-roadmap-00
Status of this Memo
Distribution of this memo is unlimited.
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.
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 July 24, 2009.
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
Lebovitz & Expires July 24, 2009 [Page 1]
Internet-Draft KMART Roadmap January 2009
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 depricated. This document
creates a roadmap of protocol specification work for the use of
modern cryptogrpahic mechanisms and algorithms for message
authentication in routing protocols. It also defines the framework
for a key management protocol that may be used to create and manage
session keys for message authentication and integrity. This 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1. Threats In Scope . . . . . . . . . . . . . . . . . . . 5
1.4.2. Threats Out of Scope . . . . . . . . . . . . . . . . . 6
1.5. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 9
1.7. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 9
2. The Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1. Categorizing Routing Protocols . . . . . . . . . . . . . . 9
2.2. Security Characterization Vectors . . . . . . . . . . . . 11
2.2.1. Internal vs. External Operation . . . . . . . . . . . 11
2.2.2. Unique versus Shared Keys . . . . . . . . . . . . . . 11
2.2.3. Out of Band vs. In-band Key Management . . . . . . . . 13
2.3. Common Framework . . . . . . . . . . . . . . . . . . . . . 13
2.4. Work Items Per Routing Protocol . . . . . . . . . . . . . 18
2.5. Protocols, Categories, and Priorities . . . . . . . . . . 19
3. Change History . . . . . . . . . . . . . . . . . . . . . . . . 21
4. Needs Work in Next Draft (RFC Editor: Delete Before
Publishing) . . . . . . . . . . . . . . . . . . . . . . . . . 21
5. Security Considerations . . . . . . . . . . . . . . . . . . . 22
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 25
Lebovitz & Expires July 24, 2009 [Page 2]
Internet-Draft KMART Roadmap January 2009
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 is being conducted through
liaisons with the RIR's globally.
o Specifications for cryptographic validation of routing message
content. This work is being done 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.
1.1. Terminology
[to be filled out later]
Base RP
key_store
KMP
session keys
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 RFC 2119 [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, non-repudiation. The focus for
this effort, and the scope for this roadmap document, will be message
Lebovitz & Expires July 24, 2009 [Page 3]
Internet-Draft KMART Roadmap January 2009
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, the two explicitly excluded tactics may
be addressed in future work.
This work will also include the definition of a key management
protocol for creating and managing session keys for the message
authentication and data integrity functions.
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,
routing products have been fine tuned over the years for the specific
processing necessary for these routing protocols non-encapsulated
formats. Operators are, therefore, quite unwilling 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. Implemented products
have already been produced and code has already been written and,
both have been optimized for the existing mechanisms.
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, the document will call out places
where agreement has been reached on such trade offs.
Lebovitz & Expires July 24, 2009 [Page 4]
Internet-Draft KMART Roadmap January 2009
The document does not contain protocol specifications. Instead, it
defines the areas where protocol specification work is needed and
sets both a direction and a relative priority for addressing that
specification work.
1.4. Threats
In RFC2828[RFC2828], 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.
1.4.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.
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 actions. 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 attempt to impersonate a legitimate
router. 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
Lebovitz & Expires July 24, 2009 [Page 5]
Internet-Draft KMART Roadmap January 2009
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 attack.
These ATTACK ACTIONS are in scope for this roadmap:
o SPOOFING - when an illegitimate device assumes the identity of a
legitimate one. Spoofing can be used, for example, to inject
unrealistic 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 1.4.2) below) are not addressed by this roadmap,
but by other work in the IETF.
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 - when an attacker sends
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 packet. Another example is sending
packets which confuse or overwhelm a security mechanism itself,
for example initiating an overwhelming load of keying protocol
initiations from bogus sources.
1.4.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 1.4.1) that may be levied by a BYZANTINE
Lebovitz & Expires July 24, 2009 [Page 6]
Internet-Draft KMART Roadmap January 2009
source are therefore also out of scope.
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 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
grouphttp://www.ietf.org/html.charters/sidr-charter.html).
1.5. Goals
The goals and general guidance for this work roadmap follow:
o Provide authentication and integrity protection for packets on the
wire of existing routing protocols
o 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 is a great deal 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
Lebovitz & Expires July 24, 2009 [Page 7]
Internet-Draft KMART Roadmap January 2009
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.
o 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.
o 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.
o Address the threats enumerated above in the "Threats" section
(Section 1.4) 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.
o Reuse common mechanisms across routing protocols whenever possible
- 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.
o Bridge any gaps between routing and security engineers by
recording agreements on work items, roadmaps, and guidance from
the Area leads and Internet Architecture Board (IAB, www.iab.org).
o Create a re-usable architecture and guidelines for various IETF
working teams who will address these security improvements for
various protocols
Lebovitz & Expires July 24, 2009 [Page 8]
Internet-Draft KMART Roadmap January 2009
1.6. 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 deal with in other
areas, like SIDR.
1.7. Audience
The audience for this roadmap includes:
o Routing Area working group chairs and members - 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.
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.
o Security Area engineers partnering 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.
2. The Roadmap
2.1. Categorizing Routing Protocols
For the purpose of this security roadmap definition, we will
categorize the routing protocols into groups and have design teams
focus on the specification work within those groupings. It is
believed that the groupings will have like requirements for their
authentication mechanisms, and that reuse of authentication
mechanisms will be greatest within these grouping. The first
categorization defines three types of messaging transactions used on
the wire by the base routing protocol, the Base RP. They are:
Lebovitz & Expires July 24, 2009 [Page 9]
Internet-Draft KMART Roadmap January 2009
One-to-One
One peer router directly and intentionally delivers a route update
specifically to one other peer router. Examples are BGP and LDP.
[question to reviewers: Should we list all protocols into these
categories right here, or just give a few examples?]
One-to-Many
A router peers with multiple other routers on a single network
segment such that it creates and sends one route update message
which is intended for consumption by multiple peers. Examples
would be OSPF and IS-IS.
Client-Server
A client-server routing protocol is one where one router initiates
a request for route information from another router, who then
formulates a response to that request, and replies with the
requested data. Examples are ???? and ????.
Multicast
Multicast protocols have unique security properties because of the
fact that they are inherently group-based protocols and thus have
group keying requirements. In addition, they are called out here
separately because much work has already been done by the
Multicast Security working group (MSEC,
http://www.ietf.org/html.charters/msec-charter.html), with much of
the specification work already completed.
[author's note: I think the above definitions need clean up. Routing
area folks, especially ADs, PLEASE suggest new text.]
The second axis of categorization groups protocols by the keying
mechanism that will be necessary for distributing session keys to the
actual routing protocol transports. They are:
Peer keying
One router sends the keying messages directly and only to one
other router, such that a one-to-one, unique keying security
association (SA) is established between the two routers
Group Keying
One router creates and distributes a single keying message to
multiple peers. In this case an group SA will be established and
used between multiple peers simultaneously. Group keying exists
for protocols like OSPF [RFC2328] , and also for multicast
protocols like PIM-SM [RFC4601].
Lebovitz & Expires July 24, 2009 [Page 10]
Internet-Draft KMART Roadmap January 2009
There must also be given consideration
The work items placed on the roadmap will be defined and assigned
based on these categorizations.
2.2. Security Characterization Vectors
A few more considerations must be made about the protocol and its use
when initially categorizing the protocol and scoping the
authentication work.
2.2.1. Internal vs. External Operation
The designers must consider whether the protocol is an internal
routing protocol or an external one, i.e. Does it primarily run
between peers within a single domain of control or between two
different domains of control? Some protocols may be used in both
cases, internally and externally, and as such various modes of
authentication operation may be required for the same protocol.
While it is preferred that all routing exchanges run with the utmost
security mechanisms enabled in all deployments, the exhortation is
greater for those protocols running at a peering point between two
domains of control, and greatest for those on public exchange point
links, because the volume of attackers are greater from the outside.
Note however that the consequences of internal attacks maybe no less
severe -- in fact they may be quite a bit more sever -- than an
external attack. An example of this internal versus external
consideration is BGP which has both EBGP and IBGP modes. Another
example is a multicast protocol where the neighbors are sometimes
within a domain of control and sometimes external, like at an
exchange link. It would be more acceptable to give up some security
to get some convenience by using a group key on large broadcast
networks within your domain, whereas operators may favor security
over convenience and use unique keying on peering links. In this
case again, designers must consider both modes of operation and
ensure the authentication mechanisms fit both.
Operators are encouraged to run cryptographic authentication on all
their adjacencies, but to work from the outside in, i.e. The EBGP
links are a higher priority than the IBGP links because they are
externally facing.
2.2.2. Unique versus Shared Keys
This section discusses security considerations of when it is
appropriate to use the same authentication key inputs for multiple
peers and when it is not. This is largely a debate of convenience
Lebovitz & Expires July 24, 2009 [Page 11]
Internet-Draft KMART Roadmap January 2009
versus security. It is often the case that the best secured
mechanism is also the least convenient mechanism. For example, an
air gap between a host and the network absolutely prevents remote
attacks on the host, but having to copy and carry files using the
"sneaker net" is quite inconvenient and unscalable.
Operators have erred on the side of convenience when it comes to
securing routing protocols with cryptographic authentication. Many
do not use it at all. Some use it only on external links, but not on
internal links. Those that do use it often use the same key for all
peers across their entire network. It is common to see the same key
in use for years, and that being the same key that was entered when
authentication was originally configured.
The goal for designers is to create authentication mechanisms that
are easy for the operators to deploy, and still use unique keys.
Operators have the impression that they NEED shared keys, when in
fact they do not. What they need is the relative convenience they
experience from deploying cryptographic authentication with shared
keys, compared to the inconvenience they would experience if they
deployed the same authentication mechanism using unique keys per
pair. An example is BGP Route Reflectors. Here operators often use
the same authentication key between each client and the route
reflector. The roadmaps defined from this guidance document will
allow for unique keys to be used between each client and the peer,
without sacrificing much convenience. Designers should strive to
deliver unique keying mechanisms with similar ease-of-deployment
properties as today's shared keys.
Operators must understand the consequences of using shared keys
across many peers. Unique keys are more secure than shared keys
because the reduce both the attack target size and the attack
consequence size. In this context, the attack target size represents
the number of unique routing exchanges across a network that an
attacker may be able to observe in order to gain security association
credentials, i.e. Crack the keys. If a shared key is used across
the entire internal domain of control, then the attack target size is
very large. The larger the attack target, the easier it is for the
attacker to gain access to analysis data, and greater the volume of
analysis data he can access, both of which make his job easier. In
this context, the attack consequence size represents the amount of
routing adjacencies that can be negatively affected once a breach has
occurred, i.e. Once the keys have been acquired by the attacker.
Again, if a shared key is used across the internal domain, then the
consequence size is the whole network. Ideally, unique key pairs
would be used for each adjacency.
In some cases designers may need to use shared keys in order to solve
Lebovitz & Expires July 24, 2009 [Page 12]
Internet-Draft KMART Roadmap January 2009
the given problem space. For example, a multicast packet is sent
once but then observed and consumed by several routing neighbors. If
unique keys were used per neighbor, the benefit of multicast would be
erased because the casting peer would have to create a different
announcement packet/stream for each listening peer. Though this may
be desired and acceptable in some small amount of use cases, it is
not the norm. Shared group keys are an acceptable solution here, and
much work has been done already in this area (see MSEC working
group).
2.2.3. Out of Band vs. In-band Key Management
[need to fill this out in next rev (ran out of time), outline points
below]
This section discussed the security and use case considerations for
keys placed on devices through out-of-band configurations versus
through in-band key management protocol exchanges with peers.
Define in-band key management exchange as using crypto protected ID
verification and session key negotiation.
Drawbacks of oob - scale-ability, complexity and speed of changing if
breech is suspected, i.e. terminated employee or compromised machine.
Pros, set in OSS system and pushed to all devices. Operators have
mechanisms in place for this already.
Pros of in-line KMP - results in key that is not recorded anywhere
and thus not steal-able if a server or other data store is stolen or
compromised, fresh keys, regular rekeys w/o operator involvement or
oversight, can leverage properties of assymetric keys vs shared keys.
Cons - more crypto overhead, though only at start up and re-key, for
the router device.
The desired end goal is in-band KMPs.
2.3. 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 Base RP needed to define
it's own key management protocol this would balloon the total amount
of different sockets that needed to be opened and processes that
needed to be simultaneously running on an implementation. It would
also significantly increase the run-time complexity and memory
Lebovitz & Expires July 24, 2009 [Page 13]
Internet-Draft KMART Roadmap January 2009
requirements of such systems running multiple Base RPs, 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 Base RP's 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 Base RPs that will provide better threat protection.
The components for the framework are listed here, and described
below:
o BaseRP security mechanism
o KMP
o key_store
o Base RP-to-KMP API
o Base RP-to-key_store API
o KMP-to-key_store API
o Common Base RP mechanisms
o Identifiers
o Proof of identity
o Profiles
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.
Lebovitz & Expires July 24, 2009 [Page 14]
Internet-Draft KMART Roadmap January 2009
+-------------------+
| |
| KMP Function |
| |
+---------+---------+
|
|
API
|
|
+--------------------+
| |
| Session |
| Key Store |
| |
+---------+----------+
|
|
API
|
|
+---------+----------+
| |
| Transport Keys |
| |
+--------------------+
Figure 1: Automatic Key Management Framework
Each element of the framework is described here.
Base RP
Base RP security mechanism - In each case, the Base RP will
contain a mechanism for using session keys in their security
option.
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 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 [RFC 4301, 4303 and 4306] 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 Base RP, say
BGP and LDP are analogous to ESP and AH, while the KMP is
analogous to IKEv2 itself.
Lebovitz & Expires July 24, 2009 [Page 15]
Internet-Draft KMART Roadmap January 2009
Key_store
Each implementation will also contain a protocol independent
mechanism for storing keys, called key_store. The key_store will
have multiple different logical containers, one container for each
session key that any given Base RP will need.
RP-KMP API
There will be an API for the Base RP 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 Base
RP 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
Base RPs and each of their unique parameters that need to be
negotiated and returned.
RP-key_store API
There will be an API for Base RP to retrieve the keys from the
key_store. This will enable implementers to reuse the same API
calls for all their Base RPs. The API will necessarily include
facility to retrieve other parameters it may need to construct
it's packets, like key IDs or key lifetimes, etc.
KMP-key_store API
There will be an API for the KMP to place keys and parameters into
the key_store 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 RPs as described in Section [Categorizing..link this
later.].
[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 RP to any KMP, then there can be a generic hand-down
function from the KMP to the RP 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 RP teams to use
them. Need to get this team going asap.]
Lebovitz & Expires July 24, 2009 [Page 16]
Internet-Draft KMART Roadmap January 2009
ldentitifiers
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, 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 only
matters that the type of string must be agreed upon by the two
endpoints. Further, the string can be used as an identifier in
this context, even if the string is not actually provisioned in
it's source domain. For example, the email address
"rtr0210@sf.ca.us.company.com" may not actually exist, but that
string may still be used as an identifier 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.
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, like a certificate. Certificates can used in a
way requiring very little supporting systems, as is the case with
self-signed certificates. 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, i.e. Resistance to
a security breach, and the effort required to remediate the whole
system in the event of such a breach.
Lebovitz & Expires July 24, 2009 [Page 17]
Internet-Draft KMART Roadmap January 2009
Profiles
Once the KMP, Identifiers and Proofs mechanisms are converged
upon, they must be clearly profiled for each Base RP, 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.
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 Base RP and Base RP to KMP, but also between
Base RP 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.
2.4. Work Items Per Routing Protocol
Each Base RP will have a team (the [RP]-KMART team) working on
incrementally improving their Base RP's security, These teams will
have the following main work items:
Characterize the RP
Assess the Base RP to see what authentication mechanisms it has
today. Does it needs significant improvement to its existing
mechanisms or not? This will include determining if modern,
strong security algorithms and parameters are present.
Define Optimal State
List the requirements for the Base RP's session key usage and
format to contain to modern, strong security algorithms and
mechanisms [RFC?????]. This includes things like cipher agility,
keyID, overlapping keys, rolling keys, IV, etc. The goal here is
to determine what is needed for they Base RP alone to be used
securely with at least manual keys.
KMP Analysis
Review requirements for KMPs [RFC????]. Identify any nuances for
this particular protocol's needs and its use cases for KMP. List
the requirements that this RP has for being able to be use in
conjunctions with a KMP.
Lebovitz & Expires July 24, 2009 [Page 18]
Internet-Draft KMART Roadmap January 2009
Gap Analysis
Enumerate the requirements for this protocol to move from its
current security state, the first bullet, to its optimal state,
bullet two above.
Define the Roadmap
Create a roadmap of the design work and release a document(s)
Design
Do the design and document work for a KMP to be able to generate
the Base RP's session keys for the packets on the wire. These
will be the arguments passed in the API to the KMP in order to
bootstrap the session keys to the Base RP.
There will also be a team formed to work on the base framework
mechanisms for each of the main categories, i.e. the blocks and API's
represented in figure 1 (Figure 1).
2.5. Protocols, Categories, and Priorities
This section groups the Base RPs into like categories, according to
attributes set forth in Categories Section (Section 2.1). Each group
will have a design team tasked with improving the security of the
Base RP mechanisms and defining the KMP requirements for their group,
then rolling both into a roadmap document upon which they will
execute.
BGP, LDP and MSDP
The Base RP's that fall into the category of the one-to-one
peering messages, and will use peer keying protocols, AND are all
transmitted over TCP include BGP RFC 4271 [RFC4271], LDP [RFC3036]
and MSDP [RFC3618]. A team will work on one mechanism to cover
these three protocols. The exception is the mode where LDP is
used directly on the LAN [RFC????]. The work for this may go into
the Group keying category (w/ OSPF) mentioned below
PCE over TCP
[my notes were unclear about what to do with this]
OSPF, ISIS, and RIP
The Base RPs that fall into the category Group keying with one-to-
many peering messages includes OSPF [RFC2328], ISIS [RFC1195] and
RIP [RFC2453]. Not surprisingly, all these routing protocols have
two other things in common. First, they are run on a combination
of the OSI datalink layer 2, and the OSI network layer 3. Second,
they are all internal gateway protocols, or IGPs. The keying
mechanisms and use will be much more complicated to define for
these.
Lebovitz & Expires July 24, 2009 [Page 19]
Internet-Draft KMART Roadmap January 2009
BFD
Because it is less of a routing protocol, per se, and more of a
peer aliveness detection mechanism, Bidirectional Forwarding
Detection (BFD) [RFC????] will have its own team.
RSVP [RFC????], RSVP-TE [RFC????], and PCE
These three protocols will be handled together. [what more
characterisation should we give here? Routing AD's, provide text
pls?]
PIM-SM and PIM-DM
Finally, the multicast protocols of PIM-SM [RFC4601] and PIM-DM
[RFC3973] will be handled together. However, much work has been
done in the MSEC working group on these, so it is highly likely
that no additional work will need to be done for these.
These protocols are deemed out-of-scope for this current iteration of
the work roadmap. Once all of the protocols listed above have had
their work completed, or are clearly within site of completion, then
the community will revisit the need and interest for working on
these:
o MANET
o FORCES
[need text from routing ADs on why these are out of scope]
Resources from both the routing area and the security area will be
applied to work on these problem spaces as quickly as possible.
Realizing that such resources are far from unlimited, a rank order
priority for addressing the work of incrementally securing these
groups of routing protocols is provided:
o Priority 1 - BGP / LDP / MSDP
o Priority 2 - BFD
o Priority 3 - OSPF / ISIS / RIP
o Priority 4 - RSVP and RSVP-TE
By far the most important group is the Priority 1 group as these are
the protocols used on the most public and exposed segments of the
networks, at the peering points between operators and between
operators and their customers. BFD, as a detection mechanism
underlying the Priority 1 protocols is therefore second.
Lebovitz & Expires July 24, 2009 [Page 20]
Internet-Draft KMART Roadmap January 2009
3. Change History
[NOTE TO RFC EDITOR: this section for use during I-D stage only.
Please remove before publishing as RFC.]
-00-00 original rough rough rough draft for review by routing and
security AD's
-00- original submission
o adds new category = multicast protocols in category section and
mentions mcast in group keying category description.
o add a lot of references where they did not exist before, or where
there were only place holders. Still more work needed on this.
o abstract filled in
o changed from standards track to informational (this was an
oversight in last draft).
o filled out threats section with detailed descriptions, and linked
to RPsec threats RFC
o made ascii art for the basic KMP framework
o added section on internal versus external peering and the
requirements decisions for them
o added security characterization section in sect 2, added sections
discussing internal vs external protocols, shared vs unique keys,
oob vs in-band keying
o incorporates all D Ward's feedback from his initial skim of the
document.
4. 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 expand the framework figure to include all the framework elements
o move standard terminology section next to other terminology
section
o clean up the three definitions of route message type categories
o a: ref each of the sections for internal hopping
o More clarity on the work items for those defining and specifying
the framework elements and API's themselves.
o What category is PCEP over TCP? It's own, or grouped with BGP?
o text justifying RSVP and RSVP-TE and what we thing solving that
problem may look like
o more justification for why MANET and FORCES are out of scope.
Need ref for those RFCs.
Lebovitz & Expires July 24, 2009 [Page 21]
Internet-Draft KMART Roadmap January 2009
o Get RFC references and insert
o security section?
o
5. Security Considerations
This entire document focuses on improving the security of routing
protocols by improving or implementing cryptographic authentication
for each routing protocol. Security considerations are largely
contained within the body text of the document.
[we can pull pieces out of body and place here, if people think it
more appropriate].
6. IANA Considerations
This document has no actions for IANA.
7. Acknowledgements
The outline for this draft was created from discussions and
agreements with Routing AD's Ross Callon and Dave Ward, Security AD's
Tim Polk and Pasi Eronen, and IAB members Danny McPherson and Gregory
Lebovitz.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828,
May 2000.
[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.
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
Routing Protocols", RFC 4593, October 2006.
Lebovitz & Expires July 24, 2009 [Page 22]
Internet-Draft KMART Roadmap January 2009
[RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the
IAB workshop on Unwanted Traffic March 9-10, 2006",
RFC 4948, August 2007.
8.2. Informative References
[I-D.ietf-tcpm-tcp-auth-opt]
Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", draft-ietf-tcpm-tcp-auth-opt-02
(work in progress), November 2008.
[I-D.narten-iana-considerations-rfc2434bis]
Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs",
draft-narten-iana-considerations-rfc2434bis-09 (work in
progress), March 2008.
[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.
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
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.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
Lebovitz & Expires July 24, 2009 [Page 23]
Internet-Draft KMART Roadmap January 2009
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 July 24, 2009 [Page 24]
Internet-Draft KMART Roadmap January 2009
Copyright and License Notice
Copyright (c) 2008 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.
Intellectual Property
All IETF Documents and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Copies of Intellectual Property disclosures made to the IETF
Secretariat and any assurances of licenses to be made available, or
the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are
Lebovitz & Expires July 24, 2009 [Page 25]
Internet-Draft KMART Roadmap January 2009
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices, of the IETF. Versions
of these Legal Provisions that are published by third parties,
including those that are translated into other languages, should not
be considered to be definitive versions of these Legal Provisions.
For the avoidance of doubt, each Contributor to the IETF Standards
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
Lebovitz & Expires July 24, 2009 [Page 26]
| PAFTECH AB 2003-2026 | 2026-04-22 06:07:09 |