One document matched: draft-ietf-karp-framework-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629xslt\rfc2629.dtd" [
<!ENTITY RFC1195 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1195.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2328 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2328.xml">
<!ENTITY RFC2453 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2453.xml">
<!ENTITY RFC5036 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5036.xml">
<!ENTITY RFC3618 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3618.xml">
<!ENTITY RFC3562 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3562.xml">
<!ENTITY RFC3973 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3973.xml">
<!ENTITY I-D.ietf-tcpm-tcp-auth-opt SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tcpm-tcp-auth-opt.xml">
<!ENTITY I-D.ietf-pim-sm-linklocal SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pim-sm-linklocal.xml">
<!ENTITY I-D.polk-saag-rtg-auth-keytable SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.polk-saag-rtg-auth-keytable.xml">
<!ENTITY I-D.housley-saag-crypto-key-table SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.housley-saag-crypto-key-table.xml">
<!ENTITY I-D.ietf-tcpm-tcp-ao-crypto SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tcpm-tcp-ao-crypto.xml">
<!ENTITY RFC4086 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4086.xml">
<!ENTITY RFC4107 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4107.xml">
<!ENTITY RFC4593 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4593.xml">
<!ENTITY RFC4271 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY RFC4301 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml">
<!ENTITY RFC4303 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4303.xml">
<!ENTITY RFC4601 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4601.xml">
<!ENTITY RFC4615 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4615.xml">
<!ENTITY RFC4306 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4306.xml">
<!ENTITY RFC4948 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4948.xml">
<!ENTITY RFC4949 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4949.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no"?>
<?rfc compact="yes"?>
<rfc category="info" docName="draft-ietf-karp-framework-00"
ipr="trust200811">
<front>
<title abbrev="KARP Framework">Framework for Cryptographic Authentication of
Routing Protocol Packets on the Wire</title>
<author fullname="J. William Atwood" initials="W." surname="Atwood">
<organization>Concordia University/CSE</organization>
<address>
<postal>
<street>1455 de Maisonneuve Blvd, West</street>
<city>Montreal</city>
<region>QC</region>
<code>H3G 1M8</code>
<country>Canada</country>
</postal>
<phone>+1(514)848-2424 ext3046</phone>
<email>bill@cse.concordia.ca</email>
<uri>http://users.encs.concordia.ca/~bill</uri>
</address>
</author>
<author fullname="Gregory Lebovitz" initials="G.L." surname="Lebovitz">
<organization abbrev="Juniper">Juniper Networks, Inc.</organization>
<address>
<postal>
<street>1194 North Mathilda Ave.</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089-1206</code>
<country>US</country>
</postal>
<phone></phone>
<email>gregory.ietf@gmail.com</email>
</address>
</author>
<date day="27" month="February" year="2010" />
<area>Routing, Security</area>
<workgroup>KARP</workgroup>
<abstract>
<t>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 <xref target="RFC4948">RFC 4948</xref>. 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.</t>
</abstract>
</front>
<middle>
<section anchor="Introl" title="Introduction">
<t>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 <xref target="RFC4948">RFC 4948</xref>.
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:</t>
<t><list hangIndent="3" style="symbols">
<t anchor="o" hangText="3">More secure mechanisms and practices for
operating routers. This work is being addressed in the OPSEC Working
Group.</t>
<t>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.</t>
<t>Specifications for cryptographic validation of routing message
content. This work will likely be addressed in the SIDR Working
Group.</t>
<t>Securing the routing protocols' packets on the wire</t>
</list></t>
<t>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".</t>
<section anchor="TerminologyKmart" title="Terminology">
<t>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.</t>
<t><list hangIndent="15" style="hanging">
<t hangText="PSK">Pre-Shared Key. A key used by both peers in a
secure configuration. Usually exchanged out-of-band prior to a
first connection.</t>
<t></t>
<t hangText="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.</t>
<t></t>
<t hangText="PRF">Pseudorandom number function, or sometimes
called pseudorandom number generator (PRNG). An algorithm for
generating a sequence of numbers that approximates the properties
of random numbers. The sequence is not truly random, in that it is
completely determined by a relatively small set of initial values
that are passed into the function. An example is SHA-256.</t>
<t></t>
<t hangText="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.</t>
<t></t>
<t hangText="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.</t>
<t></t>
<t hangText="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.</t>
<t></t>
<t hangText="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.</t>
<t hangText=""></t>
<t hangText="KMP">Key Management Protocol. A protocol used between
peers to exchange SA parameters and Traffic Keys. Examples of KMPs
include IKE, TLS, and SSH.</t>
<t></t>
<t hangText="KMP Function">Any actual KMP used in the general KARP
solution framework</t>
<t></t>
<t hangText="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.</t>
<t></t>
<t hangText="Traffic Key">The actual key used on each packet of a
message.</t>
</list></t>
<t>Definitions of items specific to the general KARP framework are
described in more detail in the Framework section <xref
target="CommonFramework"></xref>.</t>
<t></t>
<t></t>
</section>
<section anchor="TerminologyReqs" title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC2119</xref>.</t>
<t>When used in lower case, these words convey their typical use in
common language, and are not to be interpreted as described in <xref
target="RFC2119">RFC2119</xref>.</t>
<t></t>
</section>
<section anchor="Scope" title="Scope">
<t></t>
<t>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.</t>
<t>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 <xref target="RFC4303">IPsec
ESP</xref>. 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.</t>
<t>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.</t>
<t>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 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.</t>
<t>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.</t>
<t>Therefore, the scope of this roadmap of work includes:</t>
<t></t>
<t><list hangIndent="3" style="hanging">
<t hangText="o">Making use of existing routing protocol security
protocols, where they exist, and enhancing or updating them as
necessary for modern cryptographic best practices,</t>
<t></t>
<t hangText="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</t>
<t></t>
<t hangText="o">Specifying the automated key management protocol
that may be combined with the bits-on-the-wire mechanisms.</t>
</list></t>
<t>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.</t>
<t>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.</t>
<t>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**].</t>
<t>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.</t>
</section>
<section anchor="Goals" title="Goals">
<t>The goals and general guidance for this work roadmap follow:</t>
<t></t>
<t><list hangIndent="3" style="hanging">
<t hangText="1.">Provide authentication and integrity protection
for packets on the wire of existing routing protocols</t>
<t></t>
<t hangText="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 <xref target="RFC4271">BGP's</xref>
security via the update of the TCP Authentication Option <xref
target="I-D.ietf-tcpm-tcp-auth-opt">(TCP-AO)</xref> 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, replay attacks, TCP session
resetting in the base TCP-AO protocol before we layer key
management on top of it.</t>
<t></t>
<t hangText="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.</t>
<t></t>
<t hangText="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.</t>
<t></t>
<t>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 <xref
target="ISR2008"></xref> . 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.</t>
<t>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:</t>
<t></t>
<t><list style="letters">
<t>Changing the keys triggers a TCP reset, and thus bounces
the links/adjacencies, undermining Service Level Agreements
(SLAs).</t>
<t>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.</t>
<t>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.</t>
<t>Relatively low priority compared to other operatoinal
issues.</t>
<t>Lack of staff to implement the changes device by
device.</t>
<t>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.</t>
</list></t>
<t>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.</t>
<t></t>
<t>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.</t>
<t></t>
<t hangText="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.</t>
<t></t>
<t hangText="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.</t>
<t></t>
<t hangText="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).</t>
<t></t>
</list></t>
<t></t>
</section>
<section anchor="NonGoals" title="Non-Goals">
<t>The following two goals are considered out-of-scope for this
effort:</t>
<t><list hangIndent="3" style="hanging">
<t hangText="o">Privacy of the packets on the wire, at this point
in time. Once this roadmap is realized, we may revisit work on
privacy.</t>
<t></t>
<t hangText="o">Message content security. This work is being
addressed in other IETF efforts, such as SIDR.</t>
</list></t>
<t></t>
</section>
<section anchor="Audience" title="Audience">
<t>The audience for this roadmap includes:<list hangIndent="5"
style="hanging">
<t hangText=""></t>
<t
hangText="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.</t>
<t></t>
<t
hangText="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.</t>
<t></t>
<t hangText="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.</t>
<t></t>
<t hangText="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.</t>
<t></t>
<t></t>
</list></t>
</section>
</section>
<section anchor="CommonFramework" title="Common Framework">
<t>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.</t>
<t>The components for the framework are listed here, and described
in the next section:</t>
<t></t>
<t><list style="symbols">
<t>Common Routing Protocol security mechanisms</t>
<t>Specific Routing Protocol security mechanisms</t>
<t>KeyStore</t>
<t>Peer Key</t>
<t>Traffic Key</t>
<t>KMP</t>
<t>Identifiers</t>
<t>Identity Proof</t>
<t>Profiles</t>
<t>RoutingProtocol-to-KMP API</t>
<t>RoutingProtocol-to-KeyStore API</t>
<t>KMP-to-KeyStore API</t>
</list></t>
<t>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.</t>
<t><figure anchor="figure1" title="Automatic Key Management Framework">
<artwork><![CDATA[
+------------+ +--------------------+ +-----------+
| | | | 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
+------------------------+---+---+---+---+
]]></artwork>
</figure></t>
<section title="Framework Elements" anchor="FrameworkElements" >
<t></t>
<t>Each element of the framework is described here:</t>
<t></t>
<t><list hangIndent="8" style="hanging">
<t hangText=""></t>
<t hangText="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.</t>
<t hangText=""></t>
<t hangText="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.</t>
<t hangText="">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.</t>
<t hangText=""></t>
<t hangText="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 <xref target="I-D.polk-saag-rtg-auth-keytable"></xref> and <xref target="I-D.housley-saag-crypto-key-table"></xref>. 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 <xref target="I-D.ietf-pim-sm-linklocal"></xref>.</t>
<t hangText=""></t>
<t hangText="o Peer Key -">A key used between peers from which a
traffic key is derived. An example is a Pre-Shared Key.</t>
<t hangText=""></t>
<t hangText="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.</t>
<t hangText=""></t>
<t hangText="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 (<xref target="RFC4301">RFC4301</xref>, <xref
target="RFC4303">RFC4303</xref> and <xref
target="RFC4306">RFC4306</xref>) 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.</t>
<t hangText=""></t>
<t hangText="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 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.</t>
<t hangText=""></t>
<t hangText="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.</t>
<t hangText=""></t>
<t hangText="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.</t>
<t hangText=""></t>
</list></t>
<t>[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.]</t>
<t>[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.]</t>
<t></t>
<t><list hangIndent="8" style="hanging">
<t hangText=""></t>
<t hangText="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.</t>
<t hangText=""></t>
<t hangText="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.</t>
<t hangText=""></t>
<t hangText="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**].</t>
</list></t>
<t></t>
<t>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
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.</t>
<t>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.</t>
<t></t>
</section>
</section>
<section title="Framework Components" anchor="FrameworkComponents">
<t>This section will contain additional information/commentary on the operation of the components.
</t>
<section title="Key Management Protocol" anchor="KMP">
<t>[[The following text needs a home.]]</t>
<t>[[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.
</t>
<t>[[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). </t>
</section>
<section title="KeyStore" anchor="KS">
<t>[[The following text needs a home.]]</t>
<t>[[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.</t>
</section>
<section title="Routing Protocol Mechanisms" anchor="RPmech">
<t>[[Issue to be resolved]]</t>
<t>[[Manav]] I am not sure I completely understand what would get into Common RtgProto auth mechanisms?</t>
<t>[[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?</t>
<t>[[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).</t>
<t>[[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.</t>
<t>[[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.</t>
<t>[[Manav]] On second thoughts, wouldnt KMP only interact with the KeyStore and RPs with Keystore - why would we want the RPs to speak to KMP?</t>
<t>[[Greg]] See explanation directly above.</t>
<t>[[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.</t>
<t>[[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.</t>
</section>
</section>
<section title="Framework APIs" anchor="FrameworkAPIs" >
<t>This will be new work.</t>
<section title="KMP-to_Keystore API" anchor="KMP-to-KeystoreAPI">
<t>To be written.</t>
</section>
<section title="KMP-to-Routing Protocol API" anchor="KMP-to-RPAPI">
<t>To be written.</t>
</section>
<section title="Keystore-to-Routing Protocl API" anchor="Keystore-to-RPAPI">
<t>To be written.</t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t></t>
</section>
<section title="IANA Considerations">
<t></t>
<t>This document has no actions for IANA.</t>
<t></t>
</section>
<section title="Acknowledgements">
<t></t>
<t>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.</t>
</section>
<section anchor="ChangeHistory"
title="Change History (RFC Editor: Delete Before Publishing)">
<t>[NOTE TO RFC EDITOR: this section for use during I-D stage only.
Please remove before publishing as RFC.]</t>
<t>kmart-framework-00- (original submission, based on draft-lebovitz-karp-roadmap-00)</t>
<t><list style="symbols">
<t>removed sections of the roadmap that are not part of the framework.</t>
<t>promoted subsection on "Common Framework" to section, and separated part of it into a subsection on "Framework Elements".</t>
<t>added section on Framework Components and three subsections for specific components. Inserted "notes" on points that need to be resolved.</t>
<t>added (empty) section on Framework APIs and three (empty) subsections for the specific APIs.</t>
<t>made arrows in Figure 1 bi-directional.</t>
<t>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.</t>
<t>made explicit the fact that the KeyStore contains various parameters for Security Associations (or Multicast Security Associations), not just keys.</t>
<t>broke the Routing Protocol security mechanisms into "common" and "specific" parts</t>
<t>re-ordered and augmented the "list of components" and the "list of framework elements" so that they contained the same components</t>
<t>marked internal references that need to become external references, pending creation of the external documents.</t>
<t>general grammatical corrections.</t>
</list></t>
<t></t>
</section>
<section anchor="ToDo"
title="Needs Work in Next Draft (RFC Editor: Delete Before Publishing)">
<t>[NOTE TO RFC EDITOR: this section for use during I-D stage only.
Please remove before publishing as RFC.]</t>
<t>List of stuff that still needs work<list style="symbols">
<t>text for section on Framework Components and its subsections</t>
<t>text for section on Framework APIs and its subsections</t>
<t>general removal of text that belongs in other companion documents</t>
<t></t>
<t></t>
</list></t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC4593;
&RFC4948;
</references>
<references title="Informative References">
<reference anchor="I-D.ao-crypto"
target="http://tools.ietf.org/html/draft-lebovitz-ietf-tcpm-tcp-ao-crypto-00">
<!-- bibxml3 wasn't happy, so entered this manually. Replace before publish as RFC -->
<front>
<title>Cryptographic Algorithms, Use and Implementation Requirements
for TCP Authentication Option</title>
<author initials="G. M." surname="Lebovitz">
<organization>Juniper Networks, Inc.</organization>
</author>
<date month="March" year="2009" />
</front>
</reference>
<reference anchor="ISR2008"
target="http://www.arbornetworks.com/dmdocuments/ISR2008_US.pdf">
<front>
<title>Worldwide Infrastructure Security Report</title>
<author initials="D." surname="McPherson">
<organization>Arbor Networks, Inc.</organization>
</author>
<author initials="C." surname="Labovitz">
<organization>Arbor Networks, Inc.</organization>
</author>
<date month="October" year="2008" />
</front>
</reference>
&I-D.ietf-tcpm-tcp-auth-opt;
&I-D.ietf-tcpm-tcp-ao-crypto;
&I-D.ietf-pim-sm-linklocal;
&I-D.polk-saag-rtg-auth-keytable;
&I-D.housley-saag-crypto-key-table;
&RFC4271;
&RFC2328;
&RFC3562;
&RFC4086;
&RFC4107;
&RFC4301;
&RFC4303;
&RFC4306;
&RFC4601;
&RFC4615;
&RFC3973;
&RFC2453;
&RFC5036;
&RFC3618;
&RFC4949;
&RFC1195;
&RFC5226;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 16:17:20 |