Re: [babel] WG Last Call on draft-ietf-babel-rfc6126bis-04.txt (10/29 - 11/17)

[Juliusz Chroboczek <[e-mail]>]

> Now, seeing as the problem this creates is a security issue, I agree
> with David that the security considerations section is the place to add
> a note. So an way to fix this would be adding something like this to the
> first paragraph of section 6 (some wordsmithing probably needed):

I don't agree.

Babel is a completely insecure protocol.  It MUST therefore be used
together with a hop-to-hop security mechanism.  Depending on the
deployment model, this could be one of the following:

  * physical layer security (e.g. physically secured Ethernet);
  * link-layer security (e.g. WPA2, 802.1X, VPN);
  * network-layer security (e.g. IPsec);
  * transport-layer security (e.g. DTLS);
  * application-layer security (e.g. 7298bis).

If Babel is not properly secured, it is vulnerable to a wide range of
attacks (lower-metric, higher seqno, longer prefix, Hello-based DoS,
IHU-based DoS, etc.)  This is something that must be made perfectly clear
to the reader.

> "In particular, the bidirectional reachability detection in Babel is not
> a full handshake and does not offer any security guarantees (such as
> replay protection). Any security extensions to Babel need to take this
> into account."

Singling out this particular property is misleading for many reasons.  It
implies that this is the most serious vulnerability in unsecured Babel,
which is simply not true.  It also implies that a reliable three- or
four-way handshake does offer some sort of security guarantees, which it
does not.  In effect, the user will find himself wondering whether he
missed something.

In short, your suggestion makes the document less rather than more clear.
I would therefore be opposed to adding such a sentence.

-- Juliusz