Re: [Ntp] NTP is unique (was Re: QUIC as a transport substrate (was:re-chartering: include DNS-over-QUIC?))

[Mikkel Fahnøe Jørgensen <[e-mail]>]

I think these observations on resource usage are correct, but changing
system time could be a significant attack vector. For NTP to make sense
over QUIC, the datagram extension would be needed to avoid much of the
state and retransmission overhead. A simplified implementation could even
forego a lot of the QUIC machinery such as streams and only rely on the
handshake and datagram. Of course you could also use DTLS but that is yet
another stack.

Kind Regards,
Mikkel Fahnøe Jørgensen


On 13 April 2020 at 11.23.06, Tal Mizrahi ([e-mail]) wrote:

Hi,

> > This came to mind because I had a silly idea. As I watched Christian's
presentation in dprive I thought (a) this DoQ doc really benefits from
Christian knowing what he's doing with QUIC, and (b) I wondered if I could
run NTP over QUIC. Like I said, this is probably silly and there might be
nothing to gain from the attempt, but it got me thinking about guidance for
anyone else with both (a) such an idea and (b) the time to write/implement
a proposal.

NTP-over-QUIC is an interesting idea.

The main benefits I can think of of running NTP over QUIC are enjoying
the inherent security of QUIC, and avoiding middlebox tampering.
I wonder if these benefits are worth the effort.

On the other side running NTP over QUIC may consume significantly
higher resources on NTP servers than are necessary today. NTP servers
try to minimize the per-client state (or keep it zero if possible),
while QUIC may require per-client state in order to allow 0-RTT. Also
the precision of NTP may be lower than existing implementations if
implemented in user space.

> You also don't want automatic retransmission in NTP, and the flow
> control is essentially nonexistent: it's driven by the synchronization
> loop.

One may consider using QUIC in datagram mode, and this would prevent
retransmissions. ACKs would still be sent in this case.

Cheers,
Tal.



On Mon, Apr 13, 2020 at 9:18 AM Watson Ladd <[e-mail]> wrote:
>
> On Sun, Apr 12, 2020 at 11:03 PM Erik Kline <[e-mail]> wrote:
> <chop>
> >
> > This came to mind because I had a silly idea. As I watched Christian's
presentation in dprive I thought (a) this DoQ doc really benefits from
Christian knowing what he's doing with QUIC, and (b) I wondered if I could
run NTP over QUIC. Like I said, this is probably silly and there might be
nothing to gain from the attempt, but it got me thinking about guidance for
anyone else with both (a) such an idea and (b) the time to write/implement
a proposal.
>
> NTP has a very unique property: one packet is sent every 1024 or 512
> seconds or so by the client. A single server can handle a high packet
> rate easily because of the statelessness. Adding state would start
> getting problematic at the high packet rates.
>
> You also don't want automatic retransmission in NTP, and the flow
> control is essentially nonexistent: it's driven by the synchronization
> loop.
>
> Getting through middleboxes isn't nothing! But that's more a new port,
> and ideally you want middleboxes to correct for packet queuing times.
>
> Sincerely,
> Watson Ladd
>