One document matched: draft-ietf-karp-threats-reqs-06.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "http://xml.resource.org/authoring/rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<rfc category="info" docName="draft-ietf-karp-threats-reqs-06"
ipr="trust200902">
<front>
<title abbrev="KARP Overview, Threats and Requirements">Keying and
Authentication for Routing Protocols (KARP) Overview, Threats, and
Requirements</title>
<author fullname="Gregory Lebovitz" initials="G.L." surname="Lebovitz">
<organization></organization>
<address>
<postal>
<street></street>
<city>Aptos</city>
<code>95003</code>
<region>California</region>
<country>USA</country>
</postal>
<email>gregory.ietf@gmail.com</email>
</address>
</author>
<author fullname="Manav Bhatia" initials="M.B." surname="Bhatia">
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street></street>
<city>Bangalore</city>
<code></code>
<region></region>
<country>India</country>
</postal>
<phone></phone>
<email>manav.bhatia@alcatel-lucent.com</email>
</address>
</author>
<date day="27" month="September" year="2012" />
<area>Routing Area</area>
<workgroup>KARP Working Group</workgroup>
<abstract>
<t>Different routing protocols employ different mechanisms for securing
protocol packets on the wire. While most already have some method for
accomplishing cryptographic message authentication, in many cases the
existing methods are dated, vulnerable to attack, and employ
cryptographic algorithms that have been deprecated. The "Keying and
Authentication for Routing Protocols" (KARP) effort aims to overhaul and
improve these mechanisms.</t>
<t>This document does not contain protocol specifications. Instead, it
defines the areas where protocol specification work is needed and a set
of requirements for KARP design teams to follow. RFC 6518, "Keying and
Authentication for Routing Protocols (KARP) Design Guidelines" is a
companion to this document; KARP design teams will use them together to
review and overhaul routing protocols. These two documents reflect the
input of both the IETF Security Area and IETF Routing Area in order to
form a mutually agreeable work plan.</t>
<t>This document has three main parts. The first part provides an
overview of the KARP effort. The second part lists the threats from RFC
4593 (Generic Threats To Routing Protocols) that are in scope for
attacks against routing protocol transport systems. This includes any
mechanisms built into the routing protocols themselves, to authenticate
packets. The third part enumerates the requirements that routing
protocol specifications must meet when addressing those threats for RFC
6518's "Work Phase 1", the update to a routing protocol's existing
transport security.</t>
</abstract>
</front>
<middle>
<section 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"></xref>. Section 8.1 of
that document states "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 style="symbols">
<t>Create secure mechanisms and practices for operating routers.</t>
<t>Clean up the Internet Routing Registry repository (IRR), and
securing both the database and the access, so that it can be used
for routing verification.</t>
<t>Create specifications for cryptographic validation of routing
message content.</t>
<t>Secure the routing protocols' packets on the wire</t>
</list></t>
<t>The first bullet is being addressed in the OPSEC working group. The
second bullet should be addressed through liaisons with those running
the IRR's globally. The third bullet is being addressed in other efforts
within the IETF. For example, BGP message content validity is being
addressed in the SIDR working group.</t>
<t>This document addresses the last item in the list above, securing the
transmission of routing protocol packets on the wire. More precisely, it
focuses on securing the transport systems employed by routing protocols,
including any mechanisms built into the protocols themselves to
authenticate packets. This effort is referred to as Keying and
Authentication for Routing Protocols, or "KARP". KARP is concerned with
issues and techniques for protecting the messages between directly
communicating peers. This may overlap with, but is strongly distinct
from, protection designed to ensure that routing information is properly
authorized relative to the source of the information. Such assurances
are provided by other mechanisms and are outside the scope of this
document.</t>
<t>This document is one of two that together form the guidance and
instructions for KARP design teams working to overhaul routing protocol
transport security. The other document is the KARP Design Guide <xref
target="RFC6518"> </xref>.</t>
<t>This document does not contain protocol specifications. Instead, its
goal is to define the areas where protocol specification work is needed
and to provide a set of requirements for KARP design teams to follow as
they update a routing protocol's existing transport security (see<xref
target="RFC6518"> </xref>, Section 4.1's "Work Phase 1").</t>
<t>This document has three main parts. The first part, found in Section
2, provides an overview of the KARP effort. Section 3 lists the threats
from <xref target="RFC4593"></xref>, (Generic Threats To Routing
Protocols), that are in scope for per-packet authentication for routing
protocol transport systems. Therefore, this document does not contain a
complete threat model; it simply points to the parts of the governing
threat model that KARP design teams must address, and explicitly states
which parts are out of scope for KARP design teams. Section 4 enumerates
the requirements that routing protocol specifications must meet when
addressing those threats related to KARP's "Work Phase 1", the update to
a routing protocol's existing transport security. ("Work Phase 2", a
framework and usage of a KMP, will be addressed in a future
document[s]).</t>
<t>This document uses the terminology "on the wire" to refer to the
information used by routing protocols' transport systems. This term is
widely used in IETF RFCs, but is used in several different ways. In this
document, it is used to refer both to information exchanged between
routing protocol instances, and to underlying protocols that may also
need to be protected in specific circumstances. Individual protocol
analysis documents will need to be more specific in their use of this
phrase.</t>
<section 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 immediately following each term. If the same word
is used uncapitalized, then it is intended to have its common English
definition.</t>
<t><list style="hanging">
<t>Identifier</t>
<t>The type and value used by a peer of an authenticated message
exchange to signify who it is to another peer. The Identifier is
used by the receiver as an 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>Identity Authentication</t>
<t>Once the identity is verified, then there must be a
cryptographic proof of that identity, that the peer really is who
it asserts to be. Proof of identity can be arranged among peers in
a few ways, for example symmetric and asymmetric pre-shared keys,
or an asymmetric key contained in a certificate. Certificates can
be used in ways that requires no additional supporting systems
external to the routers themselves. An example of this would be
using self signed certificates and a flat file list of "approved
thumbprints". The use of these different identity verification
mechanisms vary in ease of deployment, ease of ongoing management,
startup effort, 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 recover 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>KDF (Key derivation function)</t>
<t>A KDF is a function in which an input key and other input data
is used to generate keying material that can be employed by
cryptographic algorithms. The key that is input to a KDF is called
a key derivation key. KDFs can be used to generate one or more
keys from either (i) a random or pseudorandom seed value or (ii)
result of the Diffie-Hellman exchange or (iii) a non-uniform
random source (e.g., from a non-deterministic random bit
generator) or (iv) a pre-shared key which may or may not be
memorable by a human.</t>
<t>KMP (Key Management Protocol)</t>
<t>A protocol to establish a shared symmetric key between a pair
(or among a group) of users. It determines how secret keys are
made available to the users and in some cases also determines how
the secret keys are generated. In some routing protocols traffic
keys are derived by the routing protocol from a master key. In
this case, KMP is responsible for the master key generation and
for determining when it should be renewed. In
other cases, there are only traffic keys (and no master key), and
in such a case KMP is responsible for the traffic key generation
and renewal mechanism.</t>
<t>KMP Function</t>
<t>Any KMP used in the general KARP solution framework</t>
<t>Peer Key</t>
<t>Keys that are used among peers as a basis for identifying one
another. These keys may or may not be connection-specific,
depending on how they were established, and what forms of identity
and identity authentication mechanism are used in the system. A
peer key generally would be provided by a KMP and would later be
used to derive fresh traffic keys.</t>
<t>PSK (Pre-Shared Key)</t>
<t>A key used to communicate with one or more peers in a secure
configuration. Always distributed out-of-band prior to a first
connection.</t>
<t>Routing Protocol</t>
<t>When used with capital "R" and "P" in this document the term
refers the Routing Protocol for which work is being done to its
packets on the wire.</t>
<t>SA (Security Association)</t>
<t>A relationship established between two or more entities to
enable them to protect data they exchange. Examples of attributes
that may be associated with an SA include: Identifier, PSK,
Traffic Key, cryptographic algorithms, key lifetimes.</t>
<t>Threat Source</t>
<t>A threat source is a motivated, capable adversary.</t>
<t>Traffic Key</t>
<t>The key (or one of a set of keys) used for protecting the
routing protocol traffic. A traffic key should not be a fixed
value in a device configuration. A traffic key should be known
only to the participants in a connection, so that a compromise of
a stored key (possibly available to a terminated or turned
employee) does not result in disclosure of traffic keys. If a
server or other data store is stolen or compromised, the attackers
gain no access to current traffic keys. They may gain access to
key derivation material, like a PSK, but not current traffic keys
in use.</t>
</list></t>
<t>Additional terminology specific to threats are listed and defined
below in the Threats <xref target="Threats"></xref> section.</t>
</section>
<section 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 RFC2119 <xref
target="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 RFC2119
<xref target="RFC2119"></xref>.</t>
</section>
</section>
<section title="KARP Effort Overview">
<section title="KARP Scope">
<t>Three basic principles are possible to secure any piece of data as
it is transmitted over the wire: confidentiality, authenticity, and
integrity. The focus for the KARP working group will be message
authentication and message integrity only. This work explicitly
excludes, at this point in time, confidentiality. Non-repudiation is
also excluded as a goal at this time. Since the objective of most
routing protocols is to broadly advertise the routing topology,
routing protocol packets are commonly sent in the clear;
confidentiality is not normally required for routing protocols.
However, ensuring that routing peers are authentically identified, and
that no rogue peers or unauthenticated packets can compromise the
stability of the routing environment is critical, and thus in scope.
Confidentiality and non-repudiation may be addressed in future
work.</t>
<t>OSPF <xref target="RFC5709"> </xref>, IS-IS <xref target="RFC5310">
</xref>, LDP <xref target="RFC5036"> </xref>, and RIP <xref
target="RFC2453"> </xref> <xref target="RFC4822"> </xref> already
incorporate mechanisms for cryptographically authenticating and
integrity checking the messages on the wire. Products with these
mechanisms have been produced, code has been written, and have been
optimized for these existing security mechanisms. Rather than turn
away from these mechanisms, this document aims to enhance them,
updating them to modern and secure levels.</t>
<t>Therefore, the scope of KARP's roadmap of work includes:</t>
<t><list style="symbols">
<t>Making use of existing routing protocol transport security
mechanisms, where they have been specified, and enhancing or
updating them as necessary for modern cryptographic best
practices. <xref target="RFC6518"> </xref>, Section 4.1 labels
this KARP's "Work Phase 1."</t>
<t>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. <xref target="RFC6518">
</xref>, Section 4.1 labels this KARP's "Work Phase 2."</t>
<t>Specifying an automated key management protocol that may be
combined with Routing Protocol mechanisms. <xref target="RFC6518">
</xref>, Section 4.1 labels this KARP's "Work Phase 2."</t>
</list></t>
<t>Neither this document nor <xref target="RFC6518"> </xref> contain
protocol specifications. Instead, they define the areas where protocol
specification work is needed and set a direction, a set of
requirements, and priorities for addressing that specification
work.</t>
<t>There are a set of threats to routing protocols that are considered
in-scope for KARP, and a set considered out-of- scope. These are
described in detail in the Threats (Section 3) section below.</t>
</section>
<section anchor="IncrementalApproach" title="Incremental Approach">
<t>This document 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. The principle of "crawl,
walk, run" will be employed. Thus routing protocol authentication
mechanisms may not go immediately from their current state to a state
reflecting the best possible, most modern security practices. This
point is important as 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>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 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 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 a future release of the
specification. This approach 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.</t>
<t>An example where these three reasons were at play in an incremental
improvement roadmap was seen in the improvement of BGP's [RFC4271]
security via the TCP Authentication Option (TCP-AO) [RFC5925] effort.
It would have been ideal, and reflected best common security practice,
to have a fully specified key management protocol for negotiating
TCP-AO's keying material, e.g., using certificates for peer
authentication. However, in the spirit of incremental deployment, the
IETF first addressed issues like cryptographic algorithm agility,
replay attacks, and TCP session resetting in the base TCP-AO protocol,
and then later began work to layer key management on top of it.</t>
</section>
<section title="Goals">
<t>The goals and general guidance for the KARP work follow.</t>
<t><list style="numbers">
<t>Provide authentication and integrity protection for messages on
the wire for existing routing protocols.</t>
<t>Define a path to incrementally improve security of the routing
infrastructure as explained in <xref
target="IncrementalApproach"></xref>.</t>
<t>Ensure that the improved security solutions are deployable on
current routing infrastructure. This requires consideration of the
current state of processing power available on routers in the
network today.</t>
<t>Operational deployability - A solution's acceptability also
will be measured by how deployable the solution is by
operator teams, with consideration for their deployment processes
and infrastructures. Specifically, KARP design teams will try to
make these solutions fit as well as possible into current
operational practices and router deployment methodologies.
Doing so will depend heavily on operator input during KARP design
efforts. Hopefully, operator input will lead to a more deployable
solution, which will, in turn, lead to more production deployments.
Deployment of incrementally more secure routing infrastructure
in the Internet is the final measure of success. Measurably, in
reports like <xref target='ISR2008'></xref>,
we would like to see
an increase in the number of surveyed respondents who report
deploying the updated authentication and integrity mechanisms in
their networks, as well as a sharp rise in usage for the total
percentage of their network's routers. <vspace blankLines="1" />
Interviews with operators show several points about routing
security. First, according to <xref target='ISR2008'></xref>,
over 70% of operators have deployed transport
connection protection via TCP-MD5 <xref target="RFC3562"> </xref>
on their exterior Border Gateway Protocol (eBGP) sessions. Over
55% also deploy TCP-MD5 on
their interior Border Gateway Protocol (iBGP connections, and 50%
make use of TCP-MD5 offered on some other internal gateway
protocol (IGP). The same survey states
that "a considerable increase was observed over previous editions
of the survey for use of TCP MD5 with external peers (eBGP),
internal peers (iBGP) and MD5 extensions for IGPs." Though the
data is not captured in the report, the authors believe
anecdotally that of those who have deployed TCP-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 <xref target="RFC4301"> </xref> to protect the routing
protocol, and this was a decline from the few that reported doing
so in the previous year's report. Anecdotal evidence from
operators using MD5 shows that almost all report using one,
manually-distributed key throughout the entire network. These same
operators report that the 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 protecting BGP sessions
using TCP MD5, the following reasons are often given: <list
style="hanging">
<t hangText="A.">Changing the keys triggers a TCP reset, and
thus bounces the links/adjacencies, undermining Service Level
Agreements (SLAs).</t>
<t hangText="B.">For external peers, the 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 hangText="C.">Keys must be changed at precisely the same
time, or at least within 60 seconds (as supported by two major
vendors) in order to limit connectivity outage duration. This
is incredibly difficult to do, operationally, especially
between different organizations.</t>
<t hangText="D.">Key change is perceived as a relatively low
priority compared to other operational issues.</t>
<t hangText="E.">Lack of staff to implement the changes on a
device-by-device basis.</t>
<t hangText="F.">There are three use cases for operational
peering at play here: peers and interconnection with other
operators, iBGP and other routing sessions within a single
operator, and operator-to-customer devices. All three have
very different properties, and all are reported as cumbersome
to manage securely. One operator reported that the same key is
used for all customer premise equipment (CPE). The same
operator reported that if the customer mandated it, 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-unique keys are
never changed, unless the customer demands so. The main threat
here is that a terminated employee from such an operator who
had access to the one (or several) keys used for
authentication in these environments could wage an attack.
Alternatively, the operator could offer the keys to others who
would wage the attack. In either case, the attacker could then
bring down many of the adjacencies, causing destabilization to
the routing system.</t>
</list></t>
<t>Whatever mechanisms KARP specifies need to be easier to deploy
than the current methods, and should provide obvious operational
efficiency gains along with significantly better security. This
combination of value may be enough to drive much broader
adoption.</t>
<t>Address the threats enumerated below in the "Threats" section
(Section 3) for each routing protocol. 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>Create a re-usable architecture, framework, and guidelines for
various IETF working groups who will address these security
improvements for various Routing Protocols. The crux of the KARP
work is to re-use the architecture, guidelines and the 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, which will establish keys for TCP-AO, for as
many other routing protocols with similar characteristics and
properties as possible. </t>
<t>Bridge any gaps between IETF Routing and IETF Security Areas by
recording agreements on work items, roadmaps, and guidance from
the cognizant Area Directors and the Internet Architecture Board
(IAB).</t>
</list></t>
</section>
<section title="Non-Goals">
<t>The following two goals are considered out-of-scope for this
effort:</t>
<t><list style="symbols">
<t>Confidentiality of the packets on the wire. Once this roadmap
is realized, we may revisit work on confidentiality.</t>
<t>Message content validity (routing database validity). This work
is being addressed in other IETF efforts. For example, BGP message
content validity is being addressed in the SIDR working group.</t>
</list></t>
</section>
<section title="Audience">
<t>The audience for this document includes:</t>
<t><list style="symbols">
<t>Routing Area working group chairs and participants - These
people are charged with updated Routing Protocol specifications.
Any and all cryptographic authentication work on these
specifications will occur in Routing Area working groups, in close
partnership with the Security Area. Co-advisors from the Security
Area may often be named for these partnership efforts.</t>
<t>Security Area reviewers of routing area documents - These
people are tasked by the Security Area Directors to perform
reviews on routing protocol specifications as they pass through
working group last call or IESG review. Their particular
attention to the use of cryptographic authentication and newly
specified security mechanisms for the routing protocols is
appreciated. They also help to ensure that incremental security
improvements are being made, in line with this roadmap.</t>
<t>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>Operators - The operators are a key audience for this work, as
the work is considered to have succeeded only if operators deploy
the technology. It is anticipated that deployment will take place
only if operators perceive that the improved security offered by
the Routing Protocol updates warrant the complexity and cost of
deployment and operation. Conversely, the work will be considered
a failure if operators do not deploy it, either due to lack of
perceived value or due to perceived operational complexity. As a
result, the GROW and OPSEC WGs should be kept squarely in the loop
as well.</t>
</list></t>
</section>
</section>
<section anchor="Threats" title="Threats">
<t>This document uses the definition of "threat" from RFC4949 <xref
target="RFC4949"></xref>: "a potential for violation of security, which
exists when there is a circumstance, capability, action, or event that
could breach security and cause harm."</t>
<t>This section defines the threats that are in scope for the KARP
effort. It also lists those threats that are explicitly out of scope for
the KARP effort. Threats are discussed assuming that no protection
(i.e., message authentication and message integrity) has been applied to
routing protocol messages.</t>
<t>This document leverages the "Generic Threats to Routing Protocols"
model, <xref target="RFC4593"></xref>. Specifically, the threats below
were derived by reviewing <xref target="RFC4593"></xref>, analyzing the
KARP problem space relative to it, and listing the threats that are
applicable to the KARP design teams' work. This document categorizes
<xref target="RFC4593"></xref> threats into those in scope and those out
of scope for KARP. Each in-scope threat is discussed below, and its
applicability to the KARP problem space is described. As such, the
following text intentionally is not a comprehensive threat analysis.
Rather it describes the applicability of the existing threat analysis
<xref target="RFC4593"></xref> to KARP.</t>
<t>Note: terms from <xref target="RFC4593"></xref> appear capitalized
below -- e.g. OUTSIDERS -- so as to make explicit the term's origin, and
to enable rapid cross referencing to the source RFC.</t>
<t>For convenience, a terse definition of most <xref
target="RFC4593"></xref> terms is offered here. Those interested in a
more thorough description of routing protocol threat sources,
motivations, consequences and actions will want to read <xref
target="RFC4593"></xref> before continuing here.</t>
<section anchor="Threat_Sources" title="Threat Sources">
<section anchor="outsiders" title="OUTSIDERS">
<t>One of the threats that will be addressed in this roadmap are
those where the source is an OUTSIDER. An OUTSIDER attacker 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. OUTSIDERS are
not legitimate participants in the routing protocol. The use of
message authentication and integrity protection specifically aims to
identify packets originating from OUTSIDERS.</t>
<t>KARP design teams will consider two specific use cases of
OUTSIDERS: those on-path, and those off-path.</t>
<t><list style="symbols">
<t>On-Path - These attackers have control of a network resource
or a tap that sits along the path between two routing peers. A
"Man-in-the-Middle" (MitM) is an on-path attacker. From this
vantage point, the attacker can conduct either active or passive
attacks. An active attack occurs when the attacker places
packets on the network as part of the attack. One active MitM
attack relevant to KARP, an active wiretapping attack, occurs
when the attacker tampers with packets moving between two
legitimate router peers 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. Protocols conforming to this
roadmap will use cryptographic mechanisms to detect MitM attacks
and reject packets from such attacks (i.e. discard them as being
not authentic). Passive on-path attacks occur when the attacker
silently gathers data and analyses it to gain advantage. Passive
activity by an on-path attacker may lead to an active
attack.</t>
<t>Off-Path - These attackers sit on some network outside of
that over which runs the packets between two routing peers. The
source may be one or several hops away. Off-path attackers can
launch active attacks, such as SPOOFING or denial-of-service
(DoS) attacks, to name a few.</t>
</list></t>
</section>
<!-- end OUTSIDERS -->
<section anchor="Unauthorized_Key_Holder" title="Unauthorized Key Holder">
<t>This threat source exists when an unauthorized entity somehow
manages to gain access to keying material. Using this material, the
attacker could send packets that pass the authenticity checks based
on message authentication codes (MACs). The resulting traffic might
appear to come from router A, destined to router B, and thus the
attacker could impersonate an authorized peer. The attacker could
then adversely affect network behavior by sending bogus messages
that appear to be authentic. The attack source possessing the
unauthorized keys could be on-path, off-path, or both.</t>
<t>The obvious mitigation for an unauthorized key holder is to
change the keys
currently in use by the legitimate routing peers. This mitigation
can be either reactive or pro-active. Reactive mitigation occurs
when keys are changed only after one has discovered that the
previous keys fell into the possession of unauthorized users. The
reactive mitigation case is highlighted here in order to
explain a common operational situation where new keying material
will need to be put in place with little or no advanced warning. In
such a case new keys must be able to be installed and put into use
very quickly, and with little operational expense. Pro-active
mitigation occurs when an operator assumes that unauthorized
possession will occur from time to time without being discovered,
and the operator moves to new keying material in order to cut short
an attacker's window of opportunity to use the stolen keys
effectively.</t>
<t>KARP design teams can address this type of attack by creating
specifications that make it practical for the operator to quickly
change keys without disruption to the routing system, and with
minimal operational overhead. Operators can further mitigate
threats from unauthorized key holders by regularly changing keys.</t>
<section anchor="Terminated_Employee" title="Terminated Employee">
<t>A terminated employee is an important example of an
"unauthorized key holder". Staff attrition is a reality in
routing operations, and so regularly causes the potential for a
threat source. The threat source risk arises when a network
operator who had been granted access to keys ceases to be an
employee. If new keys are deployed immediately, the situation of a
terminated employee can become an "unauthorized key holder,
pro-active" case, as described above, rather than an
"unauthorized key holder, reactive mitigation" case. It behooves
the operator to change the keys, to enforce the revocation of
authorization of the old keys, in order to minimize the threat
source's window of opportunity.</t>
<t>A terminated employee is a valid unauthorized key holder threat
source for KARP, and designs should address the associated
threats. For example,new keys must be able to be
installed and made operational in the routing protocols very
quickly, with zero impact to the routing system, and with little
operational expense. The threat actions associated with a
terminated employee also motivate the need to roll the keys
quickly, also with little operational expense.</t>
</section>
<!-- end Terminated Employee -->
</section>
<!-- end Unauthorized Key Holder -->
<section anchor="byzantine" title="BYZANTINE">
<t>According to <xref target="RFC4593"></xref> , Section 3.1.1.2,
BYZANTINE "attackers are faulty, misconfigured, or
subverted routers, i.e., legitimate participants in the routing
protocol" whose messages cause routing to malfunction. </t>
<t><xref target="RFC4593"></xref> goes on to say that "[s]ome
adversaries can subvert routers, or the management
workstations used to control these routers. These Byzantine
failures represent the most serious form of attack capability in
that they result in emission of bogus traffic by legitimate
routers." </t>
<t><xref target="RFC4593"></xref> explains that "[d]eliberate
attacks are mimicked by failures that are random and
unintentional. In particular, a Byzantine failure in a router may
occur because the router is faulty in hardware or software or is
misconfigured," and thus routing malfunctions unintentionally. Though
not malicious, such occurrences still disrupt network operation.</t>
<t>Whether faulty, misconfigured, or subverted, Byzantine routers have
an empowered position from which to provide believable yet bogus
routing messages that are damaging to the network.</t>
</section>
<!-- end Byzantine -->
</section>
<!-- end Threat Sources -->
<section anchor="inscope" title="Threat Actions In Scope">
<t>These THREAT ACTIONS are in scope for KARP:</t>
<t><list style="symbols">
<t>SPOOFING - when an unauthorized device assumes the identity of
an authorized one. Spoofing is special in that it can be used to
carry out other threat actions causing other threat consequences.
SPOOFING can be used, for example, to inject malicious routing
information that causes the disruption of network services.
SPOOFING can also be used to cause a neighbor relationship to form
that subsequently denies the formation of the relationship with
the legitimate router.</t>
<t>DoS attacks <list style="numbers">
<t>At the transport layer - This occurs when an attacker sends
packets aimed at halting or preventing the underlying protocol
over which the routing protocol runs. The attacker could use
SPOOFING, FALSIFICATION and INTERFERENCE (see below) to
produce the DoS attack. For example, BGP running over TLS will
still not solve the problem of being able to send a spoofed
TCP FIN or TCP RST and causing the BGP session to go down.
Since this attack depends on spoofing, operators are
encouraged to deploy proper authentication mechanisms to
prevent such attacks. Specification work should ensure that
Routing Protocols can operate over transport sub-systems in a
fashion that is resilient to such DoS attacks.</t>
<t>Using the authentication mechanism - This includes an
attacker causing INTERFERENCE, which is inhibiting the
exchanges of legitimate routers. The attack is often
perpetrated by sending packets that confuse or overwhelm a
security mechanism itself. An example is initiating an
overwhelming load of spoofed routing protocol packets that
contain a MAC (i.e, INSERTING MESSAGES), so that the receiver
needs to spend the processing cycles to check the MAC, only to
discard the spoofed packet, consuming substantial CPU
resources. Other types of INTERFERENCE include: REPLAYING
OUT-DATED PACKETS, CORRUPTING MESSAGES, and BREAKING
SYNCHRONIZATION.</t>
</list></t>
<t>FALSIFICATION - an action whereby an attacker sends false
routing information. This document is only targeting FALSIFICATION
from OUTSIDERS as may occur from tampering with packets in flight,
or sending entirely false messages. FALSIFICATION from BYZANTINES
(see the Threats Out of Scope section below) are not addressed by
the KARP effort.</t>
<t>Brute Force Attacks Against Password/Keys - This includes
either online or offline attacks where attempts are made
repeatedly using different keys/passwords until a match is found.
While it is impossible to make brute force attacks on keys
completely unsuccessful, proper design can make such attacks much
harder to succeed. For example, current guidance for the security
strength of an algorithm with a particular key length should be
deemed acceptable for a period of 10 years. (Section 10 of <xref
target="SP.800-131A"> </xref> is one source for guidance). Using
per session keys is another widely used method for reducing the
number of brute force attacks as this would make it difficult to
guess the keys.</t>
</list></t>
</section>
<section title="Threat Actions Out of Scope">
<t>BYZANTINE sources -- be they faulty, misconfigured, or
subverted -- are out of scope for this roadmap. KARP works to
cryptographically ensure that received routing messages originated
from authorized peers, and that the message was not altered in
transit. Formation of a bogus message by a valid and authorized peer
falls outside the KARP scope. Any of the attacks
described in the above section (<xref target="inscope"></xref>) that
may be levied by a BYZANTINE source are therefore also out of scope,
e.g. FALSIFICATION from BYZANTINE sources, or unauthorized message
content by a legitimate authorized peer.</t>
<t>In addition, these other attack actions are out of scope for this
work:</t>
<t><list style="symbols">
<t>SNIFFING (passive wiretapping) - passive observation of route
message contents in flight. Data confidentiality, as achieved by
data encryption, is the common mechanism for preventing SNIFFING.
While useful, especially to prevent the gathering of data needed
to perform an off-path packet injection attack, data encryption is
out-of-scope for KARP.</t>
<t>INTERFERENCE due to: <list style="letters">
<t>NOT FORWARDING PACKETS - cannot be prevented with
cryptographic authentication. Note: If sequence numbers with
sliding windows are used in the solution (as is done, for
example, in BFD <xref target="RFC5880"> </xref>), a receiver
can at least detect the occurrence of this attack.</t>
<t>DELAYING MESSAGES - cannot be prevented with cryptographic
authentication. Note: Timestamps can be used to detect
delays.</t>
<t>DENIAL OF RECEIPT - cannot be prevented with cryptographic
authentication</t>
<t>UNAUTHORIZED MESSAGE CONTENT - the work of the IETF's SIDR
working group
(http://www.ietf.org/html.charters/sidr-charter.html).</t>
<t>DoS attacks not involving the routing protocol. For
example, a flood of traffic that fills the link ahead of the
router, so that the router is rendered unusable and
unreachable by valid packets is NOT an attack that KARP will
address. Many such examples could be contrived.</t>
</list></t>
</list></t>
</section>
</section>
<section title="Requirements for KARP Work Phase 1, the Update to a Routing Protocol's Existing Transport Security">
<t>The KARP Design Guide <xref target="RFC6518"> </xref>, Section 4.1
describes two distinct work phases for the KARP effort. This section
addresses requirements for the first work phase only, "Work Phase 1",
the update to a routing protocol's existing transport security. "Work
Phase 2", a framework and usage of a KMP, will be addressed in a future
document(s).</t>
<t>The following list of requirements SHOULD be addressed by a KARP Work
Phase 1 security update to any Routing Protocol (according to section
4.1 of the KARP Design Guide <xref target="RFC6518"> </xref>document).
IT IS RECOMMENDED that any Work Phase 1 security update to a Routing
Protocol contain a section of the specification document that describes
how each of the following requirements are met. It is further
RECOMMENDED that justification be presented for any requirements that
are NOT addressed.</t>
<t><list style="numbers">
<t>Clear definitions of which elements of the transmitted data
(frame, packet, segment, etc.) are protected by an
authentication/integrity mechanism</t>
<t>Strong cryptographic algorithms, as defined and accepted by the
IETF security community, MUST be specified. The use of non-standard
or unpublished algorithms MUST be avoided.</t>
<t>Algorithm agility for the cryptographic algorithms used in the
authentication MUST be specified, and protocol specifications MUST
be clear how new algorithms are specified and used within the
protocol. This requirement exists because research identifying
weaknesses in cryptographic algorithms can cause the security
community to reduce confidence in some algorithms. Breaking a cipher
isn't a matter of if, but when it will occur. Having the ability to
specify alternate algorithms (algorithm agility) within the protocol
specification to support such an event is essential. Additionally,
more than one algorithm MUST be specified. Mandating support for two
algorithms provides both redundancy, and a mechanism for enacting
that redundancy.</t>
<t>Secure use of PSKs, offering both operational convenience and a
baseline level of security, MUST be specified.</t>
<t>Routing Protocols (or the transport or network mechanism
protecting routing protocols) SHOULD be able to detect and reject
replayed messages. For non-TCP based protocols like OSPF <xref
target="RFC2328"></xref>, IS-IS <xref target="RFC1195"></xref> ,
etc., two routers are said to have a session up if they are able to
exchange protocol packets. Packets captured from one session MUST
not be able to be re-sent and accepted during a later session.
Additionally, replay mechanisms MUST work correctly even in the
presence of routing protocol packet prioritization by the
router.<vspace blankLines="1" />There is a specific case of replay
attack combined with spoofing that must be addressed. In several
routing protocols (e.g., OSPF <xref target="RFC2328"></xref>, IS-IS
<xref target="RFC1195"></xref>, BFD <xref target="RFC5880"></xref>,
RIP <xref target="RFC2453"></xref>, etc.), all speakers share the
same key (K) on a broadcast segment. The ability to run a MAC
operation with K is used for (group level) authentication and
message integrity, and (currently) no other identity validation
check is performed. It is important that an integrity check
associated with a message fail if an attacker has re-addressed it to
appear that it was originated by a different origin.</t>
<t>A change of security parameters MUST force a change of session
traffic keys. The specific security parameters for the various
routing protocols will differ, and will be defined by each protocols
design team. Some examples may include: master key, key lifetime,
cryptographic algorithm, etc. If one of these configured parameters
changes, then a new session traffic key MUST immediately be
established using the updated parameters. The routing protocol
security mechanisms MUST support this behavior.</t>
<t>Security mechanisms MUST specify a means to affect intra-session
re-keying without disrupting a routing session. This should be
accomplished without data loss, if possible. Keys may need to be
changed periodically based on policy, or when an administrator who
had access to the keys leaves an organization. A re-keying mechanism
enables the operators to execute the change without productivity
loss.</t>
<t>Re-keying SHOULD be supported in such a way that it can occur
during a session without the peer needing to use multiple keys to
validate a given packet. The rare exception will occur if a routing
protocol's design team can find no other way to re-key and still
adhere to the other requirements in this section. The specification
SHOULD include a key identifier, which allows receivers to choose
the correct key (or determine that they are not in possession of the
correct key).</t>
<t>New mechanisms MUST resist DoS attacks described as in-scope in
<xref target="inscope"></xref>. Routers protect the control plane by
implementing mechanisms to reject completely or rate limit traffic
not required at the control plane level (i.e., unwanted traffic).
Typically line rate packet filtering capabilities look at
information at the IP and transport (TCP or UDP) headers, but do not
include higher layer information. Therefore the new mechanisms
shouldn't hide nor encrypt the information carried in the IP and
transport layers in control plane packets.</t>
<t>Mandatory cryptographic algorithms and mechanisms MUST be
specified for each routing protocol security mechanism. Further, the
protocol specification MUST define default security mechanism
settings for all implementations to use when no explicit
configuration is provided. To understand the need for this
requirement, consider the case where a routing protocol mandates 3
different cryptographic algorithms for a MAC operation. If company A
implements algorithm 1 as the default for this protocol, while
company B implements algorithm 2 as the default, then two operators
who enable the security mechanism with no explicit configuration
other than a PSK will experience a connection failure. It is not
enough that each implementation implement the 3 mandatory
algorithms; one default must further be specified in order to gain
maximum out-of-the-box interoperability.</t>
<t>For backward compatibility reasons, manual keying MUST be
supported.</t>
<t>The specification MUST consider and allow for future use of a
KMP.</t>
<t>The authentication mechanism in a Routing Protocol MUST be
decoupled from the key management system used. The authentication
protocol MUST include a specification for agreeing on keying
material. This will accommodate both manual keying and the use of
KMPs.</t>
<t>Convergence times of the Routing Protocols SHOULD NOT be
materially affected. Changes in the
convergence time will be immediately verifiable by convergence
performance test beds already in use (e.g. those maintained by router vendors,
service providers, and researchers). An increase in convergence time
in excess of 5% is likely to be considered to have materially affected convergence
by network operators.
A number of other facts can also change convergence over
time (e.g., speed of processors used on individual routing peers, processing power
increases due to Moore's law, implementation specifics), and the effect of an
authentication mechanism on Routing Protocols will need to take these into account
by implementors. Protocol designers should consider the impact on convergence times
as a function of both the total number
of protocol packets that must be exchanged and the required computational processing of
individual messages in the specification, understanding that the operator community's
threshold for increase of convergence times is very low, as stated above. </t>
<t>The changes to or addition of security mechanisms SHOULD NOT
cause a refresh of route advertisements or cause additional route
advertisements to be generated.</t>
<t>Router implementations provide prioritized treatment for certain
protocol packets. For example, OSPF HELLO packets and ACKs are
prioritized for processing above other OSPF packets. The security
mechanism SHOULD NOT interfere with the ability to observe and
enforce such prioritization. Any effect on such priority mechanisms
MUST be explicitly documented and justified. Replay protection
mechanisms provided by the routing protocols MUST work even if
certain protocol packets are offered prioritized treatment.</t>
<t>The Routing Protocol MUST send minimal information regarding the
authentication mechanisms and associated parameters in its protocol
packets. This keeps the Routing Protocols as clean and focused as
possible, and loads security negotiations into the KMP as much as
possible. Another reason is to avoid exposing any security
negotiation information unnecessarily to possible attackers on the
path.</t>
<t>Routing Protocols that rely on the IP header (or information
separate from routing protocol payload) to identify the neighbor
that originated the packet, MUST either protect the IP header or
provide some other means to authenticate the neighbor. <xref
target="RFC6039"></xref> describes some attacks that motivate this
requirement.</t>
<t>Every new KARP-developed security mechanisms MUST support
incremental deployment. It will not be feasible to deploy a new
Routing Protocol authentication mechanism throughout a network
instantaneously. Indeed, it may not actually be feasible to deploy
such a mechanism to all routers in a large autonomous system (AS) in
a bounded timeframe. Proposed solutions MUST support an incremental
deployment method that provides some benefit for those who
participate. Because of this, there are several requirements that
any proposed KARP mechanism should consider. <list style="letters">
<t>The Routing Protocol security mechanism MUST enable each
router to configure use of the security mechanism on a per- peer
basis where the communication is peer-to-peer (unicast).</t>
<t>Every new KARP-developed security mechanism MUST provide
backward compatibility with respect to message formatting,
transmission, and processing of routing information carried
through a secure and non-secure security environment. Message
formatting in a fully secured environment MAY be handled in a
non-backward compatible fashion though care must be taken to
ensure that routing protocol packets can traverse intermediate
routers that don't support the new format.</t>
<t>In an environment where both secured and non-secured routers
are interoperating, a mechanism MUST exist for secured systems
to identify whether a peer intended the messages to be
secured.</t>
<t>In an environment where secured service is in the process of
being deployed, a mechanism MUST exist to support a transition
free of service interruption (caused by the deployment per
se).</t>
</list></t>
<t>The introduction of mechanisms to improve routing security may
increase the processing performed by a router. Since most of the
currently deployed routers do not have hardware to accelerate
cryptographic operations, these operations could impose a
significant processing burden under some circumstances. Thus
proposed solutions SHOULD be evaluated carefully with regard to the
processing burden they may impose, since deployment may be impeded
if network operators perceive that a solution will impose a
processing burden which either incurs substantial capital expense,
or threatens to degrade router performance.</t>
<t>New authentication and security mechanisms should not rely on
systems external to the routing system (the equipment that is
performing forwarding) in order for the routing system to be secure.
In order to ensure the rapid initialization and/or return to service
of failed nodes it is important to reduce reliance on these external
systems to the greatest extent possible. Proposed solutions SHOULD
NOT require connections to external systems, beyond those directly
involved in peering relationships, in order to return to full
service. It is however acceptable for the proposed solutions to
require post initialization synchronization with external systems in
order to fully synchronize security associations. <vspace
blankLines="1" />If authentication and security mechanisms rely on
systems external to the routing system, then there MUST be one or
more options available to avoid circular dependencies. It is not
acceptable to have a routing protocol (e.g., unicast routing) depend
upon correct operation of a security protocol that, in turn, depends
upon correct operation of the same instance of that routing protocol
(i.e., the unicast routing). However, it is acceptable to have
operation of a routing protocol (e.g., multicast routing) depend
upon operation of a security protocol, which depends upon an
independent routing protocol (e.g., unicast routing). Similarly it
would be okay to have the operation of a routing protocol depend
upon a security protocol, which in turn uses an out of band network
to exchange information with remote systems.</t>
</list></t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document is mostly about security considerations for the KARP
efforts, both threats and requirements for addressing those threats.
More detailed security considerations were placed in the Security
Considerations section of the KARP Design Guide <xref target="RFC6518">
</xref>document.</t>
<t>The use of a group key between a set of Routing Protocol peers has
special security considerations. Possession of the group key itself is
used for identity validation, and no other identity check is used. Under
these conditions an attack exists where one peer masquerades as a
neighbor by using the neighbor's source IP address. This type of attack
has been well documented in the group keying problem space, and it's
non-trivial to solve. Solutions exist within the group keying realm, but
they come with significant increases in complexity and computational
intensity.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document has no actions for IANA.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The majority of the text for version -00 of this document was taken
from "Roadmap for Cryptographic Authentication of Routing Protocol
Packets on the Wire", draft-lebovitz-karp-roadmap, authored by Gregory
M. Lebovitz.</t>
<t>Brian Weis provided significant assistance in handling the many
comments that came back during IESG review, including making textual
edits.</t>
<t>We would like to thank the following people for their thorough
reviews and comments: Brian Weis, Yoshifumi Nishida, Stephen Kent,
Vishwas Manral, Barry Leiba, Sean Turner, Uma Chunduri.</t>
<t>Author Gregory M. Lebovitz was employed at Juniper Networks, Inc. for
much of the time he worked on this document, though not at the
time of its publishing. Thus Juniper sponsored much of this effort.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc ?>
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.4593'?>
<?rfc include='reference.RFC.4948'?>
</references>
<references title="Informative References">
<?rfc ?>
<?rfc include='reference.RFC.1195'?>
<?rfc include='reference.RFC.2328'?>
<?rfc include='reference.RFC.2453'?>
<?rfc include='reference.RFC.3562'?>
<?rfc include='reference.RFC.4271'?>
<?rfc include='reference.RFC.4301'?>
<?rfc include='reference.RFC.4303'?>
<?rfc include='reference.RFC.4822'?>
<?rfc include='reference.RFC.4949'?>
<?rfc include='reference.RFC.5036'?>
<?rfc include='reference.RFC.5925'?>
<?rfc include='reference.RFC.6039'?>
<?rfc include='reference.RFC.5880'?>
<?rfc include='reference.RFC.5709'?>
<?rfc include='reference.RFC.5310'?>
<?rfc include='reference.RFC.6518'?>
<reference anchor="ISR2008"
target="http://www.arbornetworks.com/dmdocuments/ISR2008_US.pdf">
<front>
<title>Worldwide Infrastructure Security Report</title>
<author fullname="D McPherson" initials="D" surname="McPherson">
<organization></organization>
</author>
<author fullname="C Labovitz" initials="C" surname="Labovitz">
<organization></organization>
</author>
<date month="October" year="2008" />
</front>
</reference>
<reference anchor="SP.800-131A">
<front>
<title>Transitions: Recommendation for Transitioning the Use of
Cryptographic Algorithms and Key Lengths</title>
<author fullname="Elaine Barker" initials="E." surname="Barker">
<organization></organization>
</author>
<author fullname="Allen" initials="A." surname="Roginsky">
<organization></organization>
</author>
<date month="January" year="2011" />
</front>
<seriesInfo name="United States of America, National Institute of Science and Technology,"
value="NIST Special Publication 800&nbhy;131A" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:56:48 |