[Babel-users] RFC: Babel packet authentication

[Denis Ovsienko]

12.06.2012, 23:37, "Juliusz Chroboczek" <jch at pps.jussieu.fr>:
> We've just had a long discussion with Denis on IRC.  Here's a summary.
>
> Short summary: this is very impressive work, and I'm very grateful to be
> able to accept that as an experimental extension to the Babel protocol
> (which is itself experimental).  TLV types 11 and 12 are hereby assigned
> to this extension.
>
> Long version.  I still prefer a trailer-based approach, which allows
> validating a packet with no knowledge of the packet's structure.
> However, Denis' has taken care to mitigate the flaws of a TLV-based
> approach (notably by having an "obviously correct" packet validation
> function run before any parsing is attempted), he is strongly in favour
> of a TLV-based approach, and has a lot of experience with security
> features in routing protocols.  I yield to his superior experience.

Thank you! This work would not be possible without larger works of other people, including yours. My role boils down to picking the best in one problem space and delivering into another.

>
> The design of TLV 11 (cryptographic timestamp) is excellent.  I am fully
> confident that it can be reused by a trailer-based extension.

It definitely could (technically), PC/TS is a direct development of its RFC6506 counterpart (4.1.1. Sequence Number Wrap). But for now this is left for a different solution.

> I am slightly less confident about TLV 12 (digest); in particular, I am
> not sure that it is necessary to have an explicit field for the
> key-id -- I'd simply make the whole body opaque.  However, I don't see
> anything actually wrong with the current definition.

This is the best current practice. An explicit Key-ID helps the receiver spend less time authenticating a packet (RFC5709 3.5. Changing OSPFv2 Security Associations, paragraph 3) and can be used to couple with a key management protocol in future. As soon as the field is always present, having it parked inside the HD TLV is convenient.

> I very much like the way of avoiding a pseudo-header in digest
> computation (by overwriting the digest with the packet's source
> address).

This is also borrowed from RFC6506 (2.3. IPv6 Source Address Protection).

> The writeup needs some editing, but nothing serious.  In particular,
> it's not clear how to deal with IPv4 source addresses (not an issue for
> the current implementation, which only runs over v6).

Now I will work on updating the spec. There are things I need to state in plain text to make some important things implemented in the source code visible. There are points, which really matter for mesh networks.

> Commit f2fdcb0 ("babeld: focus Rx packet structure/sizing checks") is
> great, I intend to pull it into standalone babeld (with Denis'
> permission).  babel_packet_examin I'll rename -- suggestions?  (I
> suggest babel_packet_validate.)

No objections from my side.

> Commit 797213b ("babeld: improve Rx check for fixed-size TLVs") is
> wrong.  See RFC 6126 Section 4.3, which allows sub-TLVs to be included
> into any TLV.  Please revert.

Done.

> Nothing to say about commit b256107.
>
> Commit c9d6a7f is the big one.  I haven't fully reviewed it yet, but
> here's a few things I notice.
>
> We're going to break if the interface has multiple link-local addresses.
> Not a big deal -- I don't think we're dealing with that edge-case in the
> first place.  Fixing that would require a bunch of system calls for each
> packet, probably not worth it.

There is now a comment in the code stating that this problem exists.

> babel_auth_got_source_address should probably fail if there's no
> link-local address rather than returning a non-local one.

Done.

> Unless I'm missing something, in babel_auth_make_packet there's an
> obsolete comment (FIXME: write source address).

Done.

>
> That's all for now.  Denis, please feel free to merge your code into the
> trunk and document it, any further nits can be corrected there.
>
> -- Juliusz

Two main commits have been pushed into RE-testing-0.99. There are minor last-time fixes incorporated, including one addressing timer thread setup. The old "babelauth" branch is deleted. This is the list of all relevant commits made so far: https://github.com/Quagga-RE/quagga-RE/wiki/hashes

And this is an updated HTML documentation including description of new babeld commands: http://quagga-re.github.com/quagga-RE/

-- 
    Denis Ovsienko