Re: [tcpm] 793bis: TCP Quiet Time

[Fernando Gont <[e-mail]>]

On 23/1/20 03:59, Matt Mathis wrote:
> There are two other changes that have largely made this problem moot:
> a) ISS and ephemeral port randomization make it extremely unlikely that 
> segments delayed across a reboot will be in sequence for any connections 
> (at the time this was written, both ISS and ephemeral ports were 
> generated by counters starting from fixed integers).

FWIW, note in many of the randomization schemes (e.g. RFC6528) the 
resulting sequence still looks like a counter for each (src, dst). 
Still, I would expect the problem to be unlikely.



> b) Although not reflected in policy, the effective MSL of the internet 
> has been declining as it gets faster.   There are paths and devices that 
> can delay packets by more than 10 seconds but they don't normally cause 
> packets to be reordered by that much, so a new SYN can't pass an old 
> data segment, which is a requirement for triggering the hazard.

Agreed.



> I would suggest changing the text to say "a theoretical problem....  
> that could be fixed by...  but for the following reasons it is viewed as 
> being sufficiently unlikely to ignore.

I would agree with this. That aside, one might also consider than as 
encryption becomes more pervasive, even in the case the problem took 
place, the connection would be reset, and the application would recover. 
  -- so I guess it would be a hard case to make OSes implement this 
"quiet time".

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492