[secdir] Secdir review of draft-ietf-babel-rfc6126bis-10

[Charlie Kaufman <[e-mail]>]

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