One document matched: draft-ietf-karp-threats-reqs-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!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.ietf-tcpm-tcp-ao-crypto SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tcpm-tcp-ao-cypto.xml"-->
<!ENTITY I-D.ietf-karp-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-karp-framework.xml">
<!ENTITY I-D.ietf-karp-design-guide SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-karp-design-guide.xml">
<!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 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-threats-reqs-00" ipr="pre5378Trust200902">
<front>
<title abbrev="KARP Threats and Requirements">The Threat Analysis and
Requirements for Cryptographic Authentication of Routing Protocols'
Transports</title>
<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>
<author fullname="" initials="" surname="">
<organization></organization>
<address>
<postal>
<street></street>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<email></email>
</address>
</author>
<date day="28" 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," also called the routing protocol transport. One
mechanism for securing routing protocol transports is the use of
per-packet cryptographic message authentication, providing both peer
authentication and message integrity. Many different routing protocols
exist and they employ a range of different transport subsystems.
Therefore there must necessarily be various methods defined for applying
cryptographic authentication to these varying protocols. Many routing
protocols already have some method for accomplishing cryptographic
message authentication. However, in many cases the existing methods are
dated, vulnerable to attack, and/or employ cryptographic algorithms that
have been deprecated. The "Keying and Authentication for Routing
Protocols" (KARP) effort aims to overhaul and improve these mechanisms.
This document has two main parts. The first describes the threat
analysis for attacks against routing protocols' transports. The second
enumerates the requirements for addressing the described threats. This
document, along with the KARP Design Guide and KARP Framework documents,
will be used by KARP design teams for specific protocol review and
overhaul. This document reflects the input of both the IETF's Security
Area and Routing Area in order to form a jointly agreed upon
guidance.</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, i.e. the routing protocols'
transports. This effort is referred to as Keying and Authentication for
Routing Protocols, or "KARP". This document specifically addresses the
threat analysis for per packet routing protocol transport
authentication, and the requirements for protocols to mitigate those
threats.</t>
<t>This document is one of three that together form the guidance and
instructions for KARP design teams working to overhaul routing protocol
transport security. The other two are the <xref
target="I-D.ietf-karp-design-guide">KARP Design Guide</xref> and the
<xref target="I-D.ietf-karp-framework">KARP Framework</xref>.</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>[Editor's note: At this point, I'm not sure exactly which of these
will end up being included in this document. They came for the
original "roadmap document". We can clean out any unused terms a few
revisions from now.]</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 exmaple 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, like 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 who 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 <xref
target="I-D.ietf-karp-framework">KARP Framework</xref> document.</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 roadmap document, will be message
authentication and packet integrity only. This work explicitly
excludes, at this point in time, the other two tactics: privacy and
non-repudiation. Since the objective of most routing protocols is to
broadly advertise the routing topology, routing messages are commonly
sent in the clear; confidentiality is not normally required for
routing protocols. However, ensuring that routing peers truly are the
trusted peers expected, and that no roque peers or messages can
compromise the stability of the routing environment is critical, and
thus our focus. The other two explicitly excluded tactics, privacy and
non-repudiation, may be addressed in future work.</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 OSPF, LDP, and RIP, these
protocols already have existing mechanisms for cryptographically
authenticating and integrity checking the packets on the wire.
Products with these mechanisms have already been produced, code has
already been written and both have been optimized for the existing
mechanisms. Rather than turn away from these mechanisms, we want to
enhance them, updating them to modern and secure levels.</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 <xref
target="Threats">Threats</xref> section below.</t>
<t></t>
</section>
<section anchor="Goals" title="Goals">
<t>The goals and general guidance for the KARP work 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 like
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 - A solutions
acceptability will also be measured by how deployable the solution
is by common operator teams using common deployment processes and
infrastructures. I.e. We will try to make these solutions fit as
well as possible into current operational practices or router
deployment. This will be heavily influenced by operator input, to
ensure that what we specify can -- and, more importantly, will --
be deployed once specified and implemented by vendors. Deployment
of incrementally more secure routing infrastructure in the
Internet is the final measure of success. Measurably, we would
like to see an increase in the number of surveyed respondents who
report deploying the updated authentication mechanisms anywhere
across their network, as well as a sharp rise in usage for the
total percentage of their network's routers.</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 is not captured in the report, the authors believe
anecdotally that of those who have deployed MD5 somewhere in their
network, only about 25-30% of the routers in their network are
deployed with the authentication enabled. None report using IPsec
to protect the routing protocol, and this was a decline from the
few that reported doing so in the previous year's report.</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 <xref
target="Threats">"Threats" section</xref> 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, like 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="Threats" title="Threats">
<t>In RFC4949<xref target="RFC4949" />, a threat is defined as a
potential for violation of security, which exists when there is a
circumstance, capability, action, or event that could breach security
and cause harm. This section defines the threats that are in scope for
this roadmap, and those that are explicitly out of scope. This document
leverages the "Generic Threats to Routing Protocols" model, <xref
target="RFC4593">RFC 4593</xref> , capitalizes terms from that document,
and offers a terse definition of those terms. (More thorough description
of routing protocol threats sources, motivations, consequences and
actions can be found in <xref target="RFC4593">RFC 4593</xref> itself).
The threat listings below expand upon these threat definitions.</t>
<section anchor="ThreatInScope" title="Threats In Scope">
<t />
<t>The threats that will be addressed in this roadmap are those from
OUTSIDERS, attackers that may reside anywhere in the Internet, have
the ability to send IP traffic to the router, may be able to observe
the router's replies, and may even control the path for a legitimate
peer's traffic. These are not legitimate participants in the routing
protocol. Message authentication and integrity protection specifically
aims to identify messages originating from OUTSIDERS.</t>
<t>The concept of OUTSIDERS can be further refined to include
attackers who are terminated employees, and those sitting
on-path.<list hangIndent="3" style="hanging">
<t hangText="" />
<t hangText="o">On-Path - attackers with control of a network
resource or a tap along the path of packets between two routers.
An on-path outsider can attempt a man-in-the-middle attack, in
addition to several other attack classes. A man-in-the-middle
(MitM) attack occurs when an attacker who has access to packets
flowing between two peers tampers with those packets in such a way
that both peers think they are talking to each other directly,
when in fact they are actually talking to the attacker only.
Protocols conforming to this roadmap will use cryptographic
mechanisms to prevent a man-in-the-middle attacker from situating
himself undetected.</t>
<t />
<t hangText="o">Terminated Employees - in this context, those who
had access router configuration that included keys or keying
material like pre-shared keys used in securing the routing
protocol. Using this material, the attacker could send properly
MAC'd spoofed packets appearing to come from router A to router B,
and thus impersonate an authorized peer. The attacker could then
send false traffic that changes the network behavior from its
operator's design. The goal of addressing this source specifically
is to call out the case where new keys or keying material becomes
necessary very quickly, with little operational expense, upon the
termination of such an employee. This grouping could also refer to
any attacker who somehow managed to gain access to keying
material, and said access had been detected by the operators such
that the operators have an opportunity to move to new keys in
order to prevent an attack.</t>
</list></t>
<t>These ATTACK ACTIONS are in scope for this roadmap:</t>
<t>
<list hangIndent="3" style="hanging">
<t hangText="o">SPOOFING - when an unauthorized device assumes the
identity of an authorized one. Spoofing can be used, for example,
to inject malicious routing information that causes the disruption
of network services. Spoofing can also be used to cause a neighbor
relationship to form that subsequently denies the formation of the
relationship with the legitimate router.</t>
<t />
<t hangText="o">FALSIFICATION - an action whereby an attacker
sends false routing information. To falsify the routing
information, an attacker has to be either the originator or a
forwarder of the routing information. Falsification may occur by
an ORIGINATOR, or a FORWARDER, and may involve OVERCLAIMING,
MISCLAIMING, or MISTATEMENT of network resource reachability. We
must be careful to remember that in this work we are only
targeting falsification from outsiders as may occur from tampering
with packets in flight. Falsification from BYZANTINES (see the
<xref target="ThreatsOutScope">Threats Out of Scope section</xref>
below) are not addressed by the KARP effort.</t>
<t />
<t hangText="o">INTERFERENCE - when an attacker inhibits the
exchanges by legitimate routers. The types of interference
addressed by this work include: <list style="symbols">
<t>ADDING NOISE</t>
<t>REPLAYING OUT-DATED PACKETS</t>
<t>INSERTING MESSAGES</t>
<t>CORRUPTING MESSAGES</t>
<t>BREAKING SYNCHRONIZATION</t>
<t>Changing message content</t>
</list></t>
<t hangText="" />
<t hangText="o">DoS attacks on transport sub-systems - This
includes any other DoS attacks specifically based on the above
attack types. This is when an attacker sends spoofed packets aimed
at halting or preventing the underlying protocol over which the
routing protocol runs, for example halting a BGP session by
sending a TCP FIN or RST packet. Since this attack depends on
spoofing, operators are encouraged to deploy</t>
<t />
<t hangText="o">DoS attacks using the authentication mechanism -
This includes an attacker sending packets which confuse or
overwhelm a security mechanism itself. An example is initiating an
overwhelming load of spoofed authenticated route messages so that
the receiver needs to process the MAC check, only to discard the
packet, sending CPU levels rising. Another example is when an
attacker sends an overwhelming load of keying protocol initiations
from bogus sources. All other possible DoS attacks are out of
scope (see next section).</t>
<t />
<t hangText="o">Brute Foce Attacks Against Password/Keys - This
includes either online or offline attacks where attempts are made
repeatedly using different keys/passwords until a match is found.
While it is impossible to make brute force attacks on keys
completely unsuccessful, proper design can make such attacks much
harder to succeed. For exmaple, the key length should be
sufficiently long so that covering the entire space of possible
keys is improbable using computational power expected to be
available 10 years out or more. Also, frequently changing the keys
may render useless a successful guess some time in the future, as
those keys may no longer be in use.</t>
</list>
</t>
<t />
</section>
<section anchor="ThreatsOutScope" title="Threats Out of Scope">
<t />
<t>Threats from BYZANTINE sources -- faulty, misconfigured, or
subverted routers, i.e., legitimate participants in the routing
protocol -- are out of scope for this roadmap. Any of the attacks
described in the above <xref target="ThreatInScope">section</xref>
that may be levied by a BYZANTINE source are therefore also out of
scope.</t>
<t>In addition, these other attack actions are out of scope for this
work:</t>
<t>
<list style="symbols">
<t>SNIFFING - passive observation of route message contents in
flight</t>
<t>FALSIFICATION by BYZANTINE sources - unauthorized message
content by a legitimate authorized source.</t>
<t>INTERFERENCE due to:<list style="symbols">
<t>NOT FORWARDING PACKETS - cannot be prevented with
cryptographic authentication</t>
<t>DELAYING MESSAGES - cannot be prevented with cryptographic
authentication</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>Any other type of DoS attack. For example, a flood of
traffic that fills the link ahead of the router, so that the
router is rendered unusable and unreachable by valid packets
is NOT an attack that this work will address. Many other such
examples could be contrived.</t>
</list></t>
</list>
</t>
</section>
<t />
</section>
<section anchor="Ph1Reqs"
title="Requirements for Phase 1 of a Routing Protocol Transport's Security Update">
<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 <xref target="I-D.ietf-karp-design-guide">KARP Design
Guide</xref> document). IT IS RECOMMENDED that any Phase 1 security
update to a Rouing Protocol contain a section of the specification
document that describes how each of these requirements are met. It is
further RECOMMENDED that textual justification be presented for any
requirements that are NOT addressed.</t>
<t></t>
<t><list hangIndent="5" style="numbers">
<t>Clear definitions of which elements of the transmission (frame,
packet, segment, etc.) are protected by the authentication
mechanism</t>
<t>Strong algorithms, and defined and accepted by the security
community, MUST be specified. The option should use algorithms
considered accepted by the IETF's Security community, which are
considered appropriately safe. The use of non-standard or
unpublished algorithms SHOULD BE avoided.</t>
<t>Algorithm agility for the cryptograhpic algorithms used in the
authentication MUST be specified, i.e. more than one algorithm MUST
be specified and it MUST be clear how new algorithms MAY be
specified and used within the protocol. This requirement exists in
case one algorithm gets broken suddenly. Research to identify
weakness in algorithms is constant. Breaking a cipher isn't a matter
of if, but when it will occur. It's highly unlikely that two
different algorithms will be broken simultaneously. So, if two are
supported, and one gets broken, we can use the other until we get a
new one in place. Having the ability within the protocol
specification to support such an event, having algorithm agility, is
essential. Mandating two algorithms provides both a redundancy, and
a mechanism for enacting that redundancy when needed. Further, the
mechanism MUST describe the generic interface for new cryptographic
algorithms to be used, so that implementers can use algorithms other
than those specified, and so that new algorithms may be specifed and
supported in the future.</t>
<t>Secure use of simple PSKs, offering both operational convenience
as well as building something of a fence around stupidity, MUST be
specified.</t>
<t>Inter-connection replay protection. Packets captured from one
connection MUST NOT be able to be re-sent and accepted during a
later connection.</t>
<t>Intra-connection replay protection. Packets captured during a
connection MUST NOT be able to be re-sent and accepted during that
same connection, to deal with long-lived connections. Additionally,
replay mechanisms MUST work correctly even in the presence of
Routing Protocol packet prioritization by the router (see
requirement 17 below).</t>
<t>A change of security parameters REQUIRES, and even forces, a
change of session traffic keys</t>
<t>Intra-connection re-keying which occurs without a break or
interruption to the current peering session, and, if possible,
without data loss, MUST be specified. Keys need to be changed
periodically, for operational privacey (e.g. when an administrator
who had access to the keys leaves an organization) and for entropy
purposes, and a re-keying mechanism enables the deployers to execute
the change without productivity loss.</t>
<t>Efficient re-keying SHOULD be provided. The specificaion SHOULD
support rekeying during a connection without the need to expend
undue computational resources. In particular, the specification
SHOULD avoid the need to try/compute multiple keys on a given
packet.</t>
<t>Prevent DoS attacks as those described as in-scope in the threats
section <xref target="ThreatInScope"></xref> above.</t>
<t>Default mechanisms and algorithms specified and defined are
REQUIRED for all implementations.</t>
<t>Manual keying MUST be supported.</t>
<t>Architecture of the specification MUST consider and allow for
future use of a KMP.</t>
<t>The authentication mechanism in the Routing Protocol MUST be
decoupled from the key management system used. It MUST be obvious
how the keying material was obtained, and the process for obtaining
the keying material MUST exist outside of the Routing Protocol. This
will allow for the various key generation methods, like manual keys
and KMPs, to be used with the same Routing Protocol mechanism.</t>
<t>Convergence times of the Routing Protocols SHOULD NOT be
materially affected. Materially here is defined as anything greater
than a 5% convergence time increase. Note that convergence is
different than boot time. Also note that convergence time has a lot
to do with the speed of processors used on individual routing peers,
and this processing power increases by Moore's law over time,
meaning that the same route calculations and table population
routines will decrease in duration over time. Therefore, this
requirement should be considered only in terms of total number of
messages that must be exchanged, and less for the computational
intensity of processing any one message.</t>
<t>The changes or addition of security mechanisms SHOULD NOT cause a
refresh of route updates or cause additional route updates to be
generated.</t>
<t>Router implementations provide prioritized treament to certain
protocol packets. For example, OSPF HELLO messages and ACKs are
prioritized for processing above other OSPF packets. The
authentication mechanism SHOULD NOT interfere with the ability to
observe and enforce such prioritizations. Any effect on such
priority mechanisms MUST be explicitly documented and justified.</t>
<t>The authentication mechanism does not provide message
confidentiality, but SHOULD NOT preclude the possibility of
confidentiality support being added in the future.</t>
<t>The KARP mechanism MUST provide a sufficiently large sequence
number space so that intra-connection replay protection will
succeed. [Editor note: This may be more of a design guide item than
a requirement? Also, it may be best to include it with 3.6?]</t>
<t>The new security and authentication mechanisms MUST support
incremental deployment. It will not be feasible to deploy a new
Routing Protocol authentication mechanism throughout the network
instantaneously. It also may not be possible to deploy such a
mechanism to all routers in a large autonomous system (AS) at one
time. Proposed solutions SHOULD support an incremental deployment
method that provides some benefit for those who participate. Because
of this, there are several requirements that any proposed KARP
mechanism should consider.</t>
<t><list hangIndent="5" style="numbers">
<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 one-on-one.</t>
<t>The new KARP mechanism MUST provide backward compatibility in
the message formatting, transmission, and processing of routing
information carried through a mixed security environment.
Message formatting in a fully secured environment MAY be handled
in a non-backward compatible fashion though care must be taken
to ensure that routing protocol packets can traverse
intermediate routers which don't support the new format.</t>
<t>In an environment where both secured and non-secured systems
are interoperating a mechanism MUST exist for secured systems to
identify whether an originator intended the information to be
secured.</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 authentication
and security may increase the processing performed by a router.
Since most of the currently deployed routers do not have hardware to
accelerate cryptographic operations, these operations could impose a
significant processing burden under some circumstances. Thus
proposed solutions should be evaluated carefully with regard to the
processing burden they may impose, since deployment may be impeded
if network operators perceive that a solution will impose a
processing burden which either:</t>
<t><list hangIndent="5" style="symbols">
<t>provokes substantial capital expense, or</t>
<t>threatens to destabilize routers.</t>
</list></t>
<t>Given the high number of routers that would require the new
authentication mechanisms in a typical ISP deployment, solutions can
increase their appeal by minimizing the burden imposed on all
routers in favor of confining significant work loads to a relatively
small number of devices. Optional features or increased assurance
that provokes more pervasive processing load MAY be made available
for deployments where the additional resources are economically
justifiable.</t>
<t>The new authentication and security mechanisms should not rely on
systems external to the routing system (the equipment that is
performing forwarding). In order to ensure the rapid initialization
and/or return to service of failed nodes it is important to reduce
reliance on these external systems to the greatest extent possible.
Therefore, proposed solutions SHOULD NOT require connections to
external systems, beyond those directly involved in peering
relationships, in order to return to full service. It is however
acceptable for the proposed solutions to require post initialization
synchronization with external systems in order to fully synchronize
the security information.</t>
<t></t>
</list></t>
<t></t>
<t></t>
</section>
<section anchor="Security" title="Security Considerations">
<t></t>
<t>This document is mostly about security considerations for the KARP
efforts, both threats and requirements for solving those threats. More
detailed security considerations were placed in the Security
Considerations section of the <xref
target="I-D.ietf-karp-design-guide">KARP Design Guide</xref>
document.</t>
</section>
<section title="IANA Considerations">
<t></t>
<t>This document has no actions for IANA.</t>
<t></t>
</section>
<section title="Acknowledgements">
<t>The majority of the text for version -00 of this document was taken
from draft-lebovitz-karp-roadmap, authored by Gregory Lebovitz.</t>
<t>Manav Bhatia provided a detailed review of the existing requirements,
and provided text for a few more.</t>
<t></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-00-00 original rough rough rough draft for review by routing
and security AD's</t>
<t>karp-threats-reqs-00-</t>
<t><list style="symbols">
<t>removed all the portions that will be covered in either
draft-ietf-karp-design-guide or draft-ietf-karp-framework</t>
</list></t>
<t></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>Clean up section 3 requirements, parsing for overlaps, and
ensuring that each are written in such a way as to be objectively
either filled or not filled by a KARP spec.</t>
<t>Manav check sect 3 for inclusion of the various requirements you
sent to Gregory. Provide clear text for any omissions.</t>
<t>check Brian Weis text on threats against what is in sect 2
already to ensure it's covered.</t>
<t>Review by a few other security area folks.</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.ietf-karp-design-guide;
&I-D.ietf-karp-framework;
&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 10:59:07 |