Re: [babel] Mirja Kühlewind's Discuss on draft-ietf-babel-hmac-08: (with DISCUSS and COMMENT)

[Mirja Kuehlewind <[e-mail]>]

Hi Juliusz,

Okay, if I understand you correctly what you want is actually to limit “failed” challenge requests only (where no reply is received or the reply is not valid). Correct? I think then you should specify it this way. Further if the goal is to not run into the rate limit if a single packet is lost, then that is also possible with a token-bucket-like approach, e.g. allow 3 non-confirmed challenges per 10s (or even larger values depending in the expected loss rate). This would make more sense to me as that avoids the dependency on the hello interval.

Mirja



> On 7. Aug 2019, at 18:16, Juliusz Chroboczek <[e-mail]> wrote:
> 
>> Sorry I mean 300ms… (one important letter).
> 
> Ah, ok.  I think I undestand what you mean now.
> 
>> But this is usually send every 4 seconds or so…?
> 
> Not necessarily.  The timers are configurable, and there can be multiple
> packets sent over a single hello interval (e.g. when the routing table
> doesn't fit in a single packet).  The rate limiting here is going to limit
> how fast we can acquire new neighbours in the presence of packet loss.
> The value 300ms was chosen as being a compromise between the amount of
> traffic an attacker can cause with replayed packets, and the hard limit it
> imposes on neighbour acquisition in the presence of packet loss.
> 
> This has nothing to do with congestion control, Mirja, it's solely about
> resistance to DoS.  In normal operation (with no evil attacker replaying
> massive numbers of packets and in the absence of packet loss), there's
> going to be just two challenge/reply exchanges (one in each direction) for
> every neighbour acquisition.  This implies that there is no opportunity
> to establish RTT state, and no useful opportunity to reset timers when
> a reply is received.
> 
> -- Juliusz
> 
>