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

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

Danny and Warner, in the interest of showing how diverging use models create controversies in the list based on people's emotional ownership of NTP let me posit this:

is there a chance we can build a hybrid client with the ability to answer a remote query which is fully authenticated as to "what my time is"? Clearly it would need aspects of the server's listener built into it, but to keep the code fingerprints reliable and secure, we can address remote code auditing through this same feature as well.

Additionally the ability to tell the client what port you want replies on is a variant of the NTP proxy I proposed several years ago before "getting slammed to the mmat" by this very group. 

If you want to see my SecureTP proposal I can send it and its three-way timesetting and time auditing practices all nicely merged into a single framework.

Amplification attacks go away, identity fraud goes away, and many of the proposals for extended authentication and their overhead become moot as well... All by creating a directed and port variable infrastructure using NTP. 

//Todd


Sent from my HTC, so please excuse any typos.

----- Reply message -----
From: "Warner Losh" <[e-mail]>
To: "Danny Mayer" <[e-mail]>
Cc: "Fernando Gont" <[e-mail]>, "NTP WG" <[e-mail]>
Subject: [Ntp] Details of the fragmentation attacks against NTP and port randomization
Date: Wed, Jun 12, 2019 05:26

Can we please keep it technical rather than launch into personal attacks?
You can make your points without the vitriol and nastiness.

Warner

On Tue, Jun 11, 2019, 4:34 PM Danny Mayer <[e-mail]> wrote:

>
> On 6/7/19 6:53 AM, Fernando Gont wrote:
> > On 5/6/19 05:41, Danny Mayer wrote:
> >> On 6/4/19 2:39 AM, Fernando Gont wrote:
> >>> On 4/6/19 06:09, Danny Mayer wrote:
> >>>> On 6/3/19 2:24 PM, Watson Ladd wrote:
> >>>>
> >>>>> Dear all,
> >>>>>
> >>>>> The debate over client port randomization is missing an important
> >>>>> fact: off-path attacks against NTP are not prevented by the origin
> >>>>> timestamp due to the OS handling of fragmentation. In
> >>>>> http://www.cs.bu.edu/~goldbe/papers/NTPattack.pdf we see that
> sending
> >>>>> a properly crafted IP fragment can selectively overwrite NTP packets,
> >>>>> thus allowing an attacker to modify received data without overwriting
> >>>>> the origin timestamp. I would recommend we adopt port randomization
> >>>>> to handle this problem.
> >>>>>
> >>>>> Sincerely,
> >>>>> Watson Ladd
> >>>> Actually if you read Section VI you will see that the last sentence of
> >>>> that section states that they do not consider it to be a sufficient
> defense.
> >>> Wasn't Your argument that the timestamp was enough to mitigate off-path
> >>> attacks?
> >>>
> >> Yes and no. The draft you wrote requires using random ports to avoid
> >> off-path attacks.
> > No.
> Actually that's exactly what it says. See the abstract of your own draft.
> >
> > The draft we wrote says employing predictable identifiers is a bad
> > practice that has been known for over 20 years. We have been on this
> > road so many times. You just don't use predictable IDs.
> You do this of off-path attackers.
> >
> > Using them leads to trouble, with no benefit. Using random port numbers
> > helps mitigate such trouble.
> No always which why your RFC is a BCP. What needs to be clarified is
> when it is wise to do so and when not to do so and what are the
> consequences if you do so. You cannot make proposals without including
> them.
> >
> >
> >
> >> The paper demonstrates that for at least some O/S's an
> >> off-path fragmentation attack succeeds regardless of the port number.
> >> This is at a layer below NTP. So randomizing the ports doesn't matter
> >> for this attack according to the paper. The proper way to deal with this
> >> fragmentation attack is to fix the underlying O/S behavior as has
> >> already been done for most of them. The NTP basic payload is only 48
> >> bytes so there is no reason to allow fragmentation in the first place.
> > The IPv4 minimum MTU is 68 bytes. Anything longer than that may need to