Re: [babel] Some open HMAC issues

[Juliusz Chroboczek <[e-mail]>]

>> 2. Should the HMAC cover the packet header?

> Yes, I see now reason not to hash the whole thing.

Fully agreed.  That's what draft-do-...-00 says, and what we've
implemented (not very well, by the way).

>> 5. Use of the packet trailer

> I agree that sticking the signatures in the packet trailer is the right
> thing to do. The zero out / hash self / rewrite hash dance is way too
> annoying. Also, when the signature is in the packet trailer the hash
> check can move straight to that and ignore the rest of the packet; and
> the regular parser can ignore the packet trailer and just parse the
> regular TLVs.

That's what I think too, but David disagreed last time I asked him.
Since you agree with me, I think I'm going to insist on this one.

(I assume your implementation correctly drops all non-HMAC TLVs from the
packet trailer, including PAD1.)

>> 8. Index and Nonce size

> Letting the nonce be of arbitrary size is fine, but doing the same thing
> for the index is incredibly annoying. Since the index needs to be stored
> with the same lifetime as the neighbour, making it arbitrary size means
> there's another blob of dynamically assigned memory to keep track of.
> Which may have to be resized later if the peer changes its index size.

I think we have some time to decide, but here's a few arguments both ways.

1. We really want nonces to be of arbitrary size, so implementations have
   the space to encode a cookie if they're concerned about DoS.

2. Having nonces of arbitrary size implies dynamic allocation.  At any
   rate, you need dynamic allocation for nonces, since they're short-lived
   and per-neighbour.

3. You do want to allow tiny indices (unless we adopt Markus' proposal),
   since some implementations will want to save bytes on the wire by using
   a real-time clock.

4. I don't see any good reason right now for long indices (more than 16
   bytes, say).

So right now (likely to change in the future), I'd argue for:

  - variable size nonces with no size limit;
  - variable size indices.

I haven't made an opinion yet on whether we want a limit to the size of
indices.
   
> If we want to allow really small indexes, that is fine, but then limit
> the max size to (say) 10 bytes; that way, a buffer of the maximum size
> can be statically assigned in the neighbour struct (251 or even 192
> bytes is way too much for static allocation).

Agreed.

> Or maybe just forgo the complexity entirely and make the index a fixed
> size; you just know that someone is going to pick a way too small value
> and make themselves susceptible to replay attacks at some point...

Disagreed.

-- Juliusz