[Babel-users] RFC: Babel packet authentication

[Juliusz Chroboczek]

Hi Denis,

> An implementor of an authenticated Babel network is left with the
> following options:

> * Authenticate all packetes in the network (e.g. WPA).

Yes.

> * Selectively authenticate Babel packets with IPSec policy.

I don't think that can be made to work, at least not without some
protocol changes.  IKE doesn't work for multicast, while
statically-keyed IPSec is vulnerable to replay attacks.

> * Implement Babel packet-level authentication using trailing data.
> * Implement Babel packet-level authentication using TLVs.

Yes and yes.

> The TLV option, to my opinion, makes the most sense.

I personally prefer an authentication trailer approach.

Note first that the authentication trailer is variable size -- it can be
anywhere between one octet and (MTU - 60) octets.  So the TLV approach
is no more flexible than the trailer approach.

Second, note that the digest in the Hash-Digest (HD) TLV ranges over the
HD TLV itself.  I find that confusing, and it is difficult to
implement -- you need to make an initial HD-TLV, append it to the
packet, compute the digest, then walk back over the packet and fill-in
all the HD TLVs.  Similarly, on reception you need to walk the TLVs of
a packet before you authentify it -- and then you need to walk the
packet a second time in order to parse it (you don't want to be parsing
an unauthenticated packet).

None of these are issues with an authentication trailer (AT).  You
generate your packet as usual, just making sure you have enough space
left for the AT.  You then compute a hash of a pseudo-header and the
packet, and append the AT to the packet.  Similarly, on reception, you
jump directly to the AT, extract the data, compute the hash, and accept
or drop the packet before you ever walk the packet data itself.

Third, AT code can be shared by multiple protocols, even if the have
different packet structure.  In particular, at first glance it would
appear that RFC 6506 can be adapted to Babel with little trouble.  That
means that we can use a mature spec (11 IDs!) without having to develop
one ourselves, or even share code between OSPFv3 and Babel.

For all of these reasons, I would like to encourage you to work on
adapting RFC 6506 to Babel rather than on an approach based on TLVs.
No problem with having TLVs 11 and 12 for your purposes, however.

-- Juliusz

P.S. I might be away from the Internet from 25 May until 4 June.