Last Call Review of draft-ietf-babel-rfc6126bis-10
review-ietf-babel-rfc6126bis-10-secdir-lc-kaufman-2019-06-28-00

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

This document defines the Babel Routing Protocol, a distance vector protocol
designed for use in networks with a high degree of mobility and fast-changing
connectivity such as an ad-hoc wireless network with no fixed connection points.

As a procedural matter, I don't know whether rfc6126bis is the right name for
this thing. RFC6126 specifies Babel as an experimental protocol, and I would
assume this I-D is an update to that document, probably still as an
experimental protocol. Or perhaps it is now going to be a proposed standard,
though without including a viable security mechanism (see below) that seems
problematic.

As noted in the Security Considerations, as specified Babel is a completely
insecure protocol. It appears that any hostile node within the network can
cause essentially all connectivity to fail. It even appears that when using
IPv4, if the network is connected to the Internet then any hostile node
anywhere on the Internet can cause essentially all connectivity to fail. That's
because security depends on the use of link-local IP addresses, a concept that
does not exist in IPv4. I would think that this protocol could specify that
that routers participating in this protocol maintain a list of IP addresses
associated with the subnet that are considered link local for purposes of
running this protocol.

There are two proposals (currently Internet Drafts) to improve security:
draft-ietf-babel-dtls-04 and draft-ietf-babel-hmac-04. I have not reviewed
those proposals, but would note that there recursion challenges using DTLS when
neither end is connected to services like DNS and OCSP. Babel users multicast,
so this protocol would probably be best secured using a single key shared by
all nodes participating in the subnet with some facility to periodically roll
it over.

Even with the proposed security enhancements, the protocol provides no
protection against a hostile "insider". It only protects against rogue nodes
that happen to share the same physical link (likely wireless, so that is
important). Adding protection against insider threats would be difficult and
perhaps impossible given the distance vector nature of the protocol. It could
not use the sort of layered digital signatures that is proposed for use with
BGP. That limits the scalability of the system.

The Security Considerations section notes that connectivity in a wireless space
can reveal physical location, and that for privacy reasons nodes might want to
use randomly chosen IP addresses and change them periodically. That is almost
certainly not realistic with IPv4 given the growing shortage of addresses.
There is no mention of whether this protocol could somehow interact with DHCP
in a useful way. It would certainly introduce new challenges.

 --Charlie