Re: [babel] Minor clarification to HMAC

[Mahesh Jethanandani <[e-mail]>]

To me this sounds much like a SYN flood attack in TCP, where TCP resources were allocated before the ACK came back. And TCP had to come back to clarify this, rather than leave it as a implementation level detail.

If we agree that a MAY should be allowed, I would like to see some guidance given on some implementation choices including the fact that a separate table of pending challenges should be kept to prevent an attack. 

Thanks.

Mahesh Jethanandani
[e-mail]

> On Jun 28, 2019, at 10:45 AM, David Schinazi <[e-mail]> wrote:
> 
> When a node detects a new neighbour (by receiving a multicast hello), it sends a challenge.
> I can imagine several ways to implement this:
> - create the neighbor entry at this point
> - have a separate table of pending challenges
> - come up with a clever stateless scheme involving cookies (maybe?)
> But how the node handles the challenge is an implementation matter.
> A rate-limiting and anti-DoS mechanism can be added to all of these.
> 
> Therefore, I support adding this MAY, because it gives implementors leeway.
> 
> David
> 
> 
>> On Fri, Jun 28, 2019 at 7:17 AM Markus Stenberg <[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 am not quite sure why the second 'may need to be created' is there..
>> 
>> I guess naive implementation would just remember specific nonces it has sent/freceived, but for new peers you can also just use e.g. nonce that contains timestamp (+ peer address (+- something))[1], which allows challenge sender to remain stateless until challenge responder proves they have the key.
>> 
>> So -1 from me. (Yes, I do wear my tinfoil hat even during summer.)
>> 
>> Cheers,
>> 
>> -Markus
>> 
>> [1] extra stuff is mostly for replay protection purposes, but I am not sure if it is a threat or not in this case. I have just cycled 140km, sue me.
>> 
>> > On 28.06.2019, at 16.21, Juliusz Chroboczek <[e-mail]> wrote:
>> > 
>> > Dear all,
>> > 
>> > Sawssen and Étienne (in copy of this mail) are currently working on
>> > cleaning up and completing the reference implementation of draft-...-hmac.
>> > We have just realised that the draft is not quite clear on two points.
>> > 
>> > The draft says that a neighbour entry MUST NOT be created before HMAC is
>> > verified (Section 4.3 first bullet).
>> > 
>> > It later says that a neighbour entry "might need to be created" when
>> > a challenge is sent, and "may need to be created" when a challenge is
>> > received.  However, it does not say whether it is legal to create an entry
>> > earlier.
>> > 
>> > I would therefore like to kindly request the permission of the group and
>> > the chairs to add the following between the first and second bullet points
>> > of Section 4.3:
>> > 
>> >  * A neighbour entry for the sender of the packet MAY be created at this
>> >    stage.  (Alternatively, an implementation MAY delay the creation of
>> >    a neighbour entry until a challenge request or reply is received.)
>> > 
>> > This clarification does not invalidate any implementations, it just makes
>> > the intent of the draft authors more explicit.
>> > 
>> > -- Juliusz
>> > 
>> > 
>> > _______________________________________________
>> > babel mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/babel
>> > 
>> 
>> _______________________________________________
>> babel mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/babel
> _______________________________________________
> babel mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/babel