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

["Ulrich Windl" <[e-mail]>]

Hi!

Maybe the sentence "With changing port numbers there is a specific probability
that the packet run times (transmission / reception) may change, having an
effect on the accuracy of NTP that prefers fixed and symmetric packet run
times." can make it into the document, making both parties happy; those for
randomizing ports and those against ;-)

Note that in theory the effect on accuracy could be positive as well, but most
likely not in the general case.

Regards,
Ulrich Windl


>>> Fernando Gont <[e-mail]> schrieb am 02.07.2019 um 14:31 in
Nachricht <[e-mail]>:
> Hello, Gary,
> 
> On 14/6/19 19:25, Gary E. Miller wrote:
>> Yo Fernando!
>> 
>> On Fri, 14 Jun 2019 14:07:29 +0300
>> Fernando Gont <[e-mail]> wrote:
>> 
>>>> 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.
>> 
>> Yes.  That is one of a great many scenarios where randomizing the port
>> per connection degrades the time qulity of the connection.
> 
> Just for the record: all of the revs we have published so for advised to
> randomize the port on a per‑association basis, not on a "per
> transaction" basis.
> 
> 
>> 
>>> Unless you
>>> assume that every router forwards packets with a hash‑based algorithm
>>> that includes the port, then randomization *may* affect the path.
>> 
>> So you propose one, of many, ways the random port per connection is
>> bad.  Then sweep all the others under the rug because they are not that
>> one?  Sloppy thinking.
> 
> No. I noted that the I‑D has so far proposed to randomize the port on a
> per‑association basis, something that does not degrade the time quality.
> That's what I've said.
> 
> We can add a discussion of "randomizing per‑association vs.
> per‑transaction basis". In which case we should note the effect of
> randomization on time quality. SO far that's not what the document has
> been proposed. Hence I asked (and still ask) what are the alledged
> negative effects of the type of randomization the I‑D is actually
proposing.
> 
> 
> 
> 
>>> 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".
>> 
>> Yup.  The point of this discussion is finding the best of all the
>> imperfect options.
> 
> When you randomize on the per‑association basis (as opposed to
> per‑transaction basis), I still fail to see what are the problems it
brings.
> 
> 
>> 
>>>> 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.
>> 
>> I read the room differently. 
> 
> I'm all ears to hear/red your view.
> 
> Thanks!
> 
> Cheers,
> ‑‑ 
> Fernando Gont
> SI6 Networks
> e‑mail: [e-mail] 
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
> 
> 
> _______________________________________________
> ntp mailing list
> [e-mail] 
> https://www.ietf.org/mailman/listinfo/ntp