Re: [Ntp] Details of the fragmentation attacks against NTP and port randomization

[Fernando Gont <[e-mail]>]

Hello, Gary,

On 13/6/19 22:29, Gary E. Miller wrote:
> 
> On Thu, 13 Jun 2019 22:14:12 +0300
> Fernando Gont <[e-mail]> wrote:
> 
>> On 13/6/19 20:00, Gary E. Miller wrote:
>>> Yo [e-mail]!
>>>
>>> On Thu, 13 Jun 2019 17:06:18 +0200
>>> [e-mail] wrote:
>>>   
>>>> As I see it, 1) puts the burden-of-proof on anyone arguing not to
>>>> opt for mandating port randomization.  
>>>
>>> One nit.  As discussed here previously.  Randomizing the NTP port on
>>> each server request degrades the quality of the time received.>
>>> Keeping the same random port, per server, for a while, works OK.  
>>
>> *May* degrade. (*) That said, the last revision we posted argued to
>> randomize the port on a per-association basis
> 
> PROVEN to degrade.  With a few known mechanisms for that understood.
> Many more suspected but as yet undocumented.

What I'm saying it: the port number may affect the path in scenarios
where forwarding is somewhat based on the port number. Unless you assume
that every router forwards packets with a hash-based algorithm that
includes the port, then randomization *may* affect the path.

That said, at least in the IPv4 world, you have to learned to live with
this, since the pervasive of NATs means that it may be impossible to
enforce src=PORT (whatever port is), unless e.g. you send requests every
t<30 secs which is a usual NAT timeout for and UDP "flow".



>> We are considering analyzing the trade-offs, and the document might
>> eventually argue one way or another. However, the version that has
>> been discussed so far doesn't suffer from this.
> 
> But your summary did not mention it.

Indeed the last rev didn't mentioned. In all fairness, I think it was
you that raised this (and we already starting working on this on our
working copy) -- those who objected to port randomization didn't raise
this, and even less considered per-association vs per-request
randomization in the objections they voiced.


> Just want to make sure the data point is not lost.

Point taken (and thanks for that!). The next revision will indeed
elaborate on this. We might need a couple of revs for everyone to be
happy -- but well... it's a draft, not an RFC ;-), so we do expect that
the draft evolves and improves overtime.

Based on the discussion above, there should certainly be a section about
whether to randomize on a per-association or a per-request basis. And I
wouldn't mind myself for the default to be "on a per-association basis"
(which an implementation could override "if they know better").

Thanks!

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