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

From: "[email-masked]" <[email-masked]>
Date: Tue, 04 Jun 2019 20:08:04 +0300

Absolutely

Sent from my HTC, so please excuse any typos.

----- Reply message -----
From: "Watson Ladd" <watson=[email-masked]>
To: "NTP WG" <[email-masked]>
Subject: [Ntp] Details of the fragmentation attacks against NTP and port randomization
Date: Mon, Jun 3, 2019 21:24

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

_______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 06 Jun 2019 06:51:34 +0300

Yes. PoC exists. It's run from intermediaries just like smtp spoofing is, and while arrogance wants to push this as very difficult it's not.

----- Reply message -----
From: "Majdi S. Abbas" <[email-masked]>
To: "AskBjørn Hansen" <[email-masked]>
Cc: <[email-masked]>, "Danny Mayer" <[email-masked]>
Subject: [Ntp] Details of the fragmentation attacks against NTP and port randomization
Date: Wed, Jun 5, 2019 19:09

On Wed, Jun 05, 2019 at 10:45:14AM +0800, Ask Bjørn Hansen wrote:
> This doesn’t seem right. There are much much less NTP servers in the 
> world than there are clients. Even an attacker wildly guessing will 
> have a limited scope of guessing (versus “every possible IP”).

You're still going to have to guess the entire set of servers
the client is using, get them to accept small fragmented packets, with
an invalid of zero checksum...and do this for a minimum of 8 poll 
intervals in order to fool the discipline filters.  So you have to 
correctly predict the timing, and try to send additional fragments...
while the host is still processing the UDP frame.

This does not appear to be anything but a very theoretical 
attack at this point -- does anyone have a proof of concept?

Additionally: Can anyone think of a reason an implementation
should accept an additional fragment if the MF bit was not set in the
first packet?  (Particularly an overlapping fragment, when we are not
expecting any fragments at all?)

And does that behavior exist in the wild?

Thanks,

--msa

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 13 Jun 2019 07:09:46 +0300

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

----- Reply message -----
From: "Warner Losh" <[email-masked]>
To: "Danny Mayer" <[email-masked]>
Cc: "Fernando Gont" <[email-masked]>, "NTP WG" <[email-masked]>
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 <[email-masked]> 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,
> >>>>>
> >>>> 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