Fwd: Re: Questions about the Babel protocol.
The Doctor
Hash: SHA1
With regard to the security of the Babel protocol and possible methods
of attack, I e-mailed Juliusz Chroboczek (the prime developer of the
Babel protocol) a link to the discussion thread in our archive and he
sent me the following response. I think we should investigate more
thoroughly.
- --
The Doctor [412/724/301/703]
PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1
WWW: https://drwho.virtadpt.net/
"Why, yes, I do speak fluent Aklo."
- -------- Original Message --------
Subject: Re: Questions about the Babel protocol.
Date: Sun, 15 Apr 2012 20:57:34 +0200
From: Juliusz Chroboczek <j...@pps.jussieu.fr>
To: dr...@virtadpt.net
Dear Doctor,
It's a very interesting issue. Here are a few pointers. I'd definitely
be interested in collaborating on the issue.
(Could you please forward this mail to the Google group?)
Attacks
=======
Like all seqno-based distance-vector protocols, Babel is vulnerable to
the following attacks.
## Smaller metric attack
A node can spoof a router and falsely advertise itself as a "better"
route to a given destination. Of course, in order to do that
effectively, it must be at a reasonably central place in the network.
## Higher seqno attack
A node can spoof a router and advertise a higher seqno, eventually
making the real routes unfeasible. The advantage is that the node can
be placed anywhere in the network -- seqnos don't depend on hop count.
Note that Babel is less vulnerable to this attack than say DSDV (I'm not
sure about BATMAN), since Babel nodes don't automatically prefer higher
seqnos. However, I'm pretty sure that with some effort it can be made
to work against Babel.
## Longer prefix attack
This attack is not applicable to Babel in its default configuration
(host routes only), but it can be used if you advertise prefixes.
A node can advertise a longer prefix route to a given destination, for
example announce two /25s instead of a single /24. In that case, all
the nodes in the network will prefer the longer prefixes.
Solutions
=========
## Hop-to-hop cryptography
Sign all messages, either symmetrically or asymmetrically. (Somebody in
the thread mentioned PGP, but raw RSA (or Curve25519?) is probably
a better choice.)
This needs to be done carefully, in order to prevent replay attacks.
There's a good discussion in
http://tools.ietf.org/html/draft-ietf-ospf-auth-trailer-ospfv3
## End-to-end cryptography
A different approach is end-to-end cryptography, where every node in the
chain signs a route; the advantage is that it protects against
misconfigured routers in addition to evil ones. See
for an example.
Mitigations
===========
In the absence of cryptographic solutions, people have been implementing
all sorts of mitigations.
## Filtering
Unlike link-state protocols, distance-vector protocols allow you to
ignore certain routes. Rejecting some routes and accepting others is
known as "filtering", and it is extensively used in BGP.
Babel has a rich filtering language, and you can say things like
in neigh fe80::1234:5678:9abc:def0 le 31 deny
which says that we'll only accept host routes from a given neighbour.
(Please see the babeld manual page for more information.)
Note that filtering could be used together with crypto -- for example,
you could have filtering policies that say that you only accept unsigned
routes to some destinations, but not others; this would allow an
attacker to mess with unauthenticated clients, but not with your
(authenticated) network infrastructure.
## Detection and retaliation
The attacks described above can be detected: the originating node can
notice that somebody else is announcing its routes, and warn a human
operator. (For example, a few years ago Pakistan hijacked the routes to
Youtube in order to perform censorship; this was noticed by the Youtube
people, who implemented a longer-prefix attack as a counter-measure.
Fun.)
## Lightweight crypto
There have been a number of papers published on crypto schemes that are
more lightweight than full-fledged PKIs. See for example the use of
one-way hash chains in SEAD, which are meant to prevent higher-seqno
attacks:
http://www.crhc.illinois.edu/~yihchun/pubs/ahnj0307.pdf
(No opinion about this paper, I last read it four years ago and I don't
remember whether it was any good.)
I hope this gives you enough pointers to go forward. I'm certainly
interested in hearing about any ideas you may have.
- -- Juliusz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk+LKNoACgkQO9j/K4B7F8HejwCcDoA778sw+B03tHKyd5K+najp
L2IAoOZ6qeTCcfmSk7SgB8JreBkanyvt
=gYvw
-----END PGP SIGNATURE-----