[Babel-users] RFC: Babel packet authentication

[Denis Ovsienko]

(Juliusz asked me to repost to babel-users. Please see the text below.)

24.05.2012, 00:10, "Juliusz Chroboczek" <jch at pps.jussieu.fr>:
> 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.

Hello, Juliusz.

Excuse me for the delay. This work was in its most part complete by today, but my initial intention was to have an IRC briefing with you before committing it as a part of QRE. Publishing it in a separate branch took finishing a few minor stylistic issues, which I have just done. Here is the code: https://github.com/Quagga-RE/quagga-RE/commits/babelauth

If you study the developments in RE-testing-0.99 of the last month, you will see a functional HMAC layer used from ripd code and a few fixes/refactorings in babeld, which make it possible to pack last two weeks of Babel authentication work into just two commits. These commits are currently based on RE-testing-0.99 branch, making it possible to merge in a fast-forward way (this is what I am looking for, TBH).

These two commits implement the draft specification posted to babel-users@ with a few fine, but important corrections. I have noted these corrections to include them in the next draft of the spec, but so far the implementation should be viewed as the right source, wherever it is different from the first draft of the spec.

Test-driving this implmentation should be quite simple. I have updated documentation, and the commands are very close to those you can find in ripd/ospfd. Upon enabling "debug babel auth" you will see a very detailed picture in the log file of what is happening. There is also a complete patch for tcpdump, which I used to see what is transmitted/received on the wire: https://github.com/infrastation/tcpdump/commits/master

When you look at the TLVs, you will notice there may be multiple HD TLVs. If you want, you can try rolling over authentication key and even hash algorithm, it just works. SHA-2 family of hash functions, RIPEMD-160 and Whirlpool are ready to go. MD5 and SHA-1 are not included due to the strong current tendency of migrating off these functions.

Looking forward to hear your opinion.

-- 
    Denis Ovsienko