One document matched: draft-chroboczek-babel-security-considerations-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc tocdepth="2"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="no" ?>
<rfc category="info" docName="draft-chroboczek-babel-security-considerations-00"
     ipr="trust200902">
<front>
<title abbrev="Babel security considerations">Security considerations for the Babel routing protocol</title>
<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek">
<organization>PPS, University of Paris-Diderot</organization>
<address>
<postal>
<street>Case 7014</street>
<city>75205 Paris Cedex 13</city>
<region></region>
<code></code>
<country>France</country>
</postal>
<email>jch@pps.univ-paris-diderot.fr</email>
</address>
</author>

<date day="7" month="April" year="2015"/>

<abstract><t>Where we stress that the Babel routing protocol is completely
insecure.</t></abstract>

</front>

<middle>

<section title="Introduction">

<t>The Babel routing protocol <xref target="RFC6126"/> is a lightweight
and robust routing protocol that aims at being applicable in a wide range
of situations where familiar link-state routing protocols perform
suboptimally, ranging from lossy and unstable radio networks through
overlay networks and hybdrid networks (networks consisting of technologies
with widely different performance characteristics).</t>

<t>Because of the wide applicability of Babel, no single security
technology is likely to be acceptable to all the users of Babel.  In
particular, while symmetric cryptographic authentication technologies
(such as the one described in <xref target="RFC7298"/>) solve many of the
security issues of Babel in the vast majority of deployments, there may be
applications of Babel where they are not applicable, either because their
functionality is insufficient (e.g. no support for asymmetric
cryptography) or because of implementation cost (not only CPU cost).</t>

<t>For that reason, RFC 6126 does not specify any particular "must
implement" technology, and honestly mentions that "As defined in this
document, Babel is a completely insecure protocol" (Section 6 of <xref
target="RFC6126"/>).  We would be opposed to defining a single "must
implement" security mechanism, or including such a mechanism in the base
Babel specification, at least until there is enough implementation and
deployment experience to allow us to say "this is the right security
mechanism for Babel".</t>

<t>Our position is consistent with the letter and the spirit of <xref
target="BCP61"/>.  BCP 61 stresses that security is necessary, but it
does not specify how security is to be achieved.  It does not mandate that
a protocol should have a single "must implement" security mechanism, nor
does it require that it should be included in the base specification.</t>

<t>In this document, we describe some of the attacks that are easily
performed against an unsecured Babel router, and describe the mitigations
and solutions known to us.</t>

</section>

<section title="Active attacks">

<t>In this section, we describe some active attacks — attacks that
can be performed by an attacker that is able and willing to send Babel
control traffic to Babel nodes.</t>

<section title="Routing table poisoning">

<t>An attacker that is able to send packets containing Update TLVs can
insert hostile entries into the victim's routing table.  A routing table
that contains such hostile routes is said to be poisoned.</t>

<section title="Lower metric attack">

<t>An attacker that is in a sufficiently central position in a Babel
routing domain can announce hostile routes that carry a lower metric than
the authentic routes.  Babel's route selection mechanism will prefer these
routes to the legitimate but higher-metric routes, and therefore poison
its routing table.</t>

</section>

<section title="Higher seqno attack">

<t>An attacker that is unable to achieve a sufficiently low metric
(presumably because it cannot reach a sufficiently central position in
a Babel routing domain) can still poison routing tables by announcing
a seqno that is higher than the seqno of the legitimate routes.  While
Babel's route selection algorithm will normally ignore higher-metric
routes, a victim that is suffering temporary starvation (Section 2.5 of
<xref target="RFC6126"/>) will, under some circumstances, temporarily
switch to a higher-seqno route and therefore poison its routing table.</t>

</section>

<section title="Replay attack" anchor="replay">

<t>Even if Babel packets are authenticated, in the presence of static
keying an attacker may capture enough authentified low-metric updates to
perform routing table poisoning.  The seqno mechanism does not do anything
to protect against this attack, as Babel nodes do not ignore routes with
an unexpected seqno; in any case, the seqno space is circular, and seqnos
are reused after a few hours or at most days.</t>

</section>

<section title="Amplification through routing table poisoning">

<t>An attacker that is able to perform routing table poisoning may
announce a third party next hop (Section 4.4.8 of <xref
target="RFC6126"/>), and therefore redirect a node's data traffic to
a third party, which will potentially suffer a denial of service.</t>

</section>

</section>

<section title="Amplification due to requests">

<t>The Babel protocol includes the ability to request a full routing table
update by sending a "wildcard request".  Wildcard request may be sent over
multicast, and in a dense network a single request TLV may cause
a significant amount of traffic, thus potentially performing a denial of
service.</t>

</section>

<section title="Covert channel">

<t>Babel is an extensible protocol.  Babel's extension mechanism <xref
target="BABEL-EXT"/> allows attaching extension data to almost any TLV in
a Babel packet; this data will be silently ignored by an implementation
that doesn't understand the extension, and can therefore be used as
a covert channel that is propagated for just one hop.</t>

<t>Another approach consists in encoding covert information within one of
the currently defined extensions, for example in the radio interference
information carried by <xref target="BABEL-Z"/>.  The advantage of this
method is that the information will be propagated across the Babel routing
domain by non-collaborating routers.</t>

</section>

<section title="Mitigations and solutions">

<t>Some of the attacks in this section are avoided by using a cryptographic
authentication mechanism with replay protection, such as the one defined
in <xref target="RFC7298"/>.  However, in some deployments such mechanisms
may not be desirable, either due to implementation complexity or to the
difficulty of deploying symmetric keys.</t>

<t>If the Babel traffic is protected by some lower-layer mechanism, the
replay attack described in <xref target="replay"/> above can be avoided by
using a replay protection mechanism, such as the one described in
Section 5.1 of <xref target="RFC7298"/>, and which is independent of
the rest of the protocol described in that document.</t>

<t>If Babel traffic is carried over IPv6, which is normally the case,
Babel packets are sent from a link-local address.  Since Babel nodes
discard Babel packets that are not sent from a link-local address
(Section 4 of <xref target="RFC6126"/>), and since link-local packets
are unable to cross routers, this prevents all of the attacks in this
section unless an attacker is able to send traffic from a link directly
attached to a Babel node.</t>

<t>No such natural protection is available when Babel traffic is carried
over IPv4, which does not have an equivalent to IPv6 link-local addresses.
However, no implementation of Babel known to us carries its control
traffic over IPv4.</t>

<t>We are not aware of any solution or mitigation technique to the covert
channel problem.  As far as we can tell, there is nothing that can be done
to protect against a covert channel if untrusted routers are allowed to
join the routing domain.</t>

</section>

</section>

<section title="Passive attacks">

<t>In this section, we describe some attacks that can be performed by an
attacker that is unable or unwilling to send Babel protocol packets, but
that is able to eavesdrop on a link that carries Babel control traffic.</t>

<section title="Stable node identifiers">

<t>There are three ways in which Babel traffic can be used to identify
a node.  Babel Hello TLVs carry a unique (within the routing domain)
64 bit identifier, known as the "router-id"; Section 3 of <xref
target="RFC6126"/> recommends that router-ids be allocated in modified
EUI-64 format <xref target="RFC4291"/>, presumably from a hardware
address.  Router-ids can therefore serve as a stable node identifier.</t>

<t>In addition, when Babel control traffic is carried over IPv6, it is
sent from a link-local IPv6 address.  Such addresses are usually generated
from a hardware address, and can therefore be used as a stable node
identifier.</t>

<t>Finally, Babel Update TLVs carry the set of prefixes announced by
a node.  The prefixes announced with a metric of 0 are prefixes of
directly connected networks, which in some topologies can be used as
a stable node identifier.</t>

</section>

<section title="Mitigations and solutions">

<t>The stable identifier nature of a router-id can be mitigated by
choosing router-ids randomly, and changing them periodically.  However,
the protocol does not allow changing router-ids gracefully: a Babel node
that changes router-ids must tear down all of its neighbour associations.
Current implementations are only able to change router-id at startup.</t>

<t>The same approach, with the same caveats, can be taken to change
link-local interface addresses.</t>

<t>Whether the same approach can be used to rotate locally redistributed
prefixes depends on the topology and the way the network is managed.  At
any rate, the Babel protocol allows rotating announced addresses in
a graceful manner.</t>

</section>

</section>

<section title="Conclusion">

<t>The Babel routing protocol, as defined in <xref target="RFC6126"/>, is
a completely insecure protocol.  Due to the wide applicability of Babel,
no single security mechanism is likely to satisfy all the needs of Babel's
userbase, and hence no "must implement" security mechanism should be
defined for Babel.</t>

<t>Implementors and users must be aware of this fact, and use security
mechanisms or mitigation techniques that are adapted to the nature of
their deployment.  One such security mechanism can be readily integrated
to the protocol <xref target="RFC7298"/> (sample code is available);
alternatively, a lower-layer mechanism that is not vulnerable to replay
attacks may be used.</t>

</section>

</middle>

<back>

<references>

  <reference anchor="RFC6126"><front>
    <title>The Babel Routing Protocol</title>
    <author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek"/>
    <date month="February" year="2011"/>
  </front>
  <seriesInfo name="RFC" value="6126"/>
  </reference>

  <reference anchor="BABEL-EXT"><front>
    <title>Extension Mechanism for the Babel Routing Protocol</title>
    <author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek"/>
    <date month="March" year="2015"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-chroboczek-babel-extension-mechanism-04"/>
  </reference>

  <reference anchor='RFC7298'>
    <front>
      <title>Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication</title>
      <author initials='D.' surname='Ovsienko' fullname='D. Ovsienko'>
      <organization /></author>
      <date year='2014' month='July' />
    </front>
    <seriesInfo name='RFC' value='7298' />
    <format type='TXT' octets='128503' target='http://www.rfc-editor.org/rfc/rfc7298.txt' />
  </reference>

  <reference anchor='BCP61'>
    <front>
      <title>Strong Security Requirements for Internet Engineering Task Force Standard Protocols</title>
      <author initials='J.' surname='Schiller' fullname='J. Schiller'>
      <organization /></author>
    <date year='2002' month='August' /></front>
    <seriesInfo name='BCP' value='61' />
    <seriesInfo name='RFC' value='3365' />
    <format type='TXT' octets='16411' target='http://www.rfc-editor.org/rfc/rfc3365.txt' />
  </reference>

  <reference anchor="BABEL-Z"><front>
    <title abbrev="Babel Diversity Routing">Diversity Routing for the Babel
    Routing Protocol</title>
    <author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek"/>
    <date year="2014" month="July"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-chroboczek-babel-diversity-routing-00"/>
  </reference>

  <reference anchor='RFC4291'>
    <front>
      <title>IP Version 6 Addressing Architecture</title>
      <author initials='R.' surname='Hinden' fullname='R. Hinden'>
      <organization /></author>
      <author initials='S.' surname='Deering' fullname='S. Deering'>
      <organization /></author>
      <date year='2006' month='February' />
    </front>
    <seriesInfo name='RFC' value='4291' />
    <format type='TXT' octets='52897' target='http://www.rfc-editor.org/rfc/rfc4291.txt' />
  </reference>

</references>
</back>
</rfc>