Internet DRAFT - draft-chroboczek-babel-security-considerations

draft-chroboczek-babel-security-considerations







Network Working Group                                      J. Chroboczek
Internet-Draft                          PPS, University of Paris-Diderot
Intended status: Informational                             April 7, 2015
Expires: October 9, 2015


         Security considerations for the Babel routing protocol
           draft-chroboczek-babel-security-considerations-00

Abstract

   Where we stress that the Babel routing protocol is completely
   insecure.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 9, 2015.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.






Chroboczek               Expires October 9, 2015                [Page 1]

Internet-Draft        Babel security considerations           April 2015


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Active attacks  . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Routing table poisoning . . . . . . . . . . . . . . . . .   3
     2.2.  Amplification due to requests . . . . . . . . . . . . . .   4
     2.3.  Covert channel  . . . . . . . . . . . . . . . . . . . . .   4
     2.4.  Mitigations and solutions . . . . . . . . . . . . . . . .   4
   3.  Passive attacks . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Stable node identifiers . . . . . . . . . . . . . . . . .   5
     3.2.  Mitigations and solutions . . . . . . . . . . . . . . . .   5
   4.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   The Babel routing protocol [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).

   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 [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).

   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
   [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".

   Our position is consistent with the letter and the spirit of [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.




Chroboczek               Expires October 9, 2015                [Page 2]

Internet-Draft        Babel security considerations           April 2015


   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.

2.  Active attacks

   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.

2.1.  Routing table poisoning

   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.

2.1.1.  Lower metric attack

   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.

2.1.2.  Higher seqno attack

   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 [RFC6126]) will, under some circumstances,
   temporarily switch to a higher-seqno route and therefore poison its
   routing table.

2.1.3.  Replay attack

   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.







Chroboczek               Expires October 9, 2015                [Page 3]

Internet-Draft        Babel security considerations           April 2015


2.1.4.  Amplification through routing table poisoning

   An attacker that is able to perform routing table poisoning may
   announce a third party next hop (Section 4.4.8 of [RFC6126]), and
   therefore redirect a node's data traffic to a third party, which will
   potentially suffer a denial of service.

2.2.  Amplification due to requests

   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.

2.3.  Covert channel

   Babel is an extensible protocol.  Babel's extension mechanism
   [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.

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

2.4.  Mitigations and solutions

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

   If the Babel traffic is protected by some lower-layer mechanism, the
   replay attack described in Section 2.1.3 above can be avoided by
   using a replay protection mechanism, such as the one described in
   Section 5.1 of [RFC7298], and which is independent of the rest of the
   protocol described in that document.

   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 [RFC6126]), and since link-local packets are unable to
   cross routers, this prevents all of the attacks in this section



Chroboczek               Expires October 9, 2015                [Page 4]

Internet-Draft        Babel security considerations           April 2015


   unless an attacker is able to send traffic from a link directly
   attached to a Babel node.

   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.

   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.

3.  Passive attacks

   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.

3.1.  Stable node identifiers

   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 [RFC6126]
   recommends that router-ids be allocated in modified EUI-64 format
   [RFC4291], presumably from a hardware address.  Router-ids can
   therefore serve as a stable node identifier.

   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.

   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.

3.2.  Mitigations and solutions

   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.




Chroboczek               Expires October 9, 2015                [Page 5]

Internet-Draft        Babel security considerations           April 2015


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

   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.

4.  Conclusion

   The Babel routing protocol, as defined in [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.

   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 [RFC7298] (sample code is available);
   alternatively, a lower-layer mechanism that is not vulnerable to
   replay attacks may be used.

5.  References

   [BABEL-EXT]
              Chroboczek, J., "Extension Mechanism for the Babel Routing
              Protocol", draft-chroboczek-babel-extension-mechanism-04
              (work in progress), March 2015.

   [BABEL-Z]  Chroboczek, J., "Diversity Routing for the Babel Routing
              Protocol", draft-chroboczek-babel-diversity-routing-00
              (work in progress), July 2014.

   [BCP61]    Schiller, J., "Strong Security Requirements for Internet
              Engineering Task Force Standard Protocols", BCP 61, RFC
              3365, August 2002.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC6126]  Chroboczek, J., "The Babel Routing Protocol", RFC 6126,
              February 2011.

   [RFC7298]  Ovsienko, D., "Babel Hashed Message Authentication Code
              (HMAC) Cryptographic Authentication", RFC 7298, July 2014.





Chroboczek               Expires October 9, 2015                [Page 6]

Internet-Draft        Babel security considerations           April 2015


Author's Address

   Juliusz Chroboczek
   PPS, University of Paris-Diderot
   Case 7014
   75205 Paris Cedex 13
   France

   Email: jch@pps.univ-paris-diderot.fr










































Chroboczek               Expires October 9, 2015                [Page 7]