Re: [babel] Minor clarification to HMAC

[Markus Stenberg <[e-mail]>]

> On 29 Jun 2019, at 12.41, Juliusz Chroboczek <[e-mail]> wrote:
>> In terms of security properties, notably resource exhaustion/contention,
>> I am bit leery of creating entry before validity of remote party is
>> actually verified (= challenge response received). I prefer the old
>> text.
> I initially thought like you, but Sawssen and Étienne convinced me that
> creating the entry late does not add any security.
> 
> Suppose that the packet passes HMAC.  Then one of the possible cases is
> possible:
> 
>  - the neighbour entry already exists;
>  - the neighbour entry doesn't exist, and we're going to send a challenge.
> 
> In the first case, the point is moot.  In the second case, we're going to
> create a neighbour entry anyway, so we might as well create it immediately.
> 
> (Note that the data structures of the protocol are conceptual, not
> prescriptive -- an implementation is allowed e.g. to use an "incomplete
> neighbour" data structure that is smaller than a full neighbour structure
> for holding uncompleted challenges, as long as the effect is identical to
> what is described in the protocol.

Is there some mechanism in place that prevents replay of historic packets? As the HMAC key itself does not change over time, storing (large amounts of) historic payloads with valid HMAC  is not hard.

Tthe value is bit questionable GIVEN router ID is stable, but if it is not, there is actually potential attack vector here.. RFC6126bis suggests even random router ids as valid strategy and does not mandate their storage.
(Also given large domain, it might be possible to gather more routers’ sent packets than there is space in neighbor table in limited implementations.)

Still -1.

Cheers,

-Markus