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

[Christian Huitema <[e-mail]>]

We also have timestamp frames. That may be related to NTP.

-- Christian Huitema 

> On Apr 14, 2020, at 12:03 PM, Roberto Peon <[e-mail]> wrote:
> 
> 
> I agree that Qv1 doesn’t have an ability to express this, since Qv1 doesn’t allow for partial reliability except in extensions.
> Regardless, if the requirement is to have no retransmission, then that is the requirement, and should be (at least in a spec) written that way.
> 
> I’ll disagree on whether that is similar to datagrams. Datagrams don’t have the same “address space” as does a stream, and there are certainly many things out there that would prefer to have a stream-with-holes (i.e. an address space that every party to the interaction agrees upon) than require the application to do reassembly of everything (and caching) on its own. This is really a separate conversation we can move somewhere else, though, assuming it is work having at all!
> -=R
>  
> From: Mikkel Fahnøe Jørgensen <[e-mail]>
> Date: Tuesday, April 14, 2020 at 11:54 AM
> To: Erik Kline <[e-mail]>, Watson Ladd <[e-mail]>, Roberto Peon <[e-mail]>, Tal Mizrahi <[e-mail]>
> Cc: IETF QUIC WG <[e-mail]>, "[e-mail]" <[e-mail]>, Lucas Pardue <[e-mail]>, Spencer Dawkins at IETF <[e-mail]>
> Subject: Re: NTP is unique (was Re: QUIC as a transport substrate (was:re-chartering: include DNS-over-QUIC?))
>  
> You don’t need the datagram extension, rather, you need a promise to not retransmit or a promise to communicate the time in any retransmission.
> I don’t understand this promise. In QUIC v1 you have streams, pings, bookkeeping frames, and extensions. You cannot promise not to retransmit something in as stream except by terminating the stream. Pings are not suitable for conveying time information unless perhaps its mere arrival acts a clock tick. You can of course create a new stream for each new time event but it still doesn’t prevent retransmission unless you cancel, and if you cancel, delivery of the payload is not guaranteed.
>  
> You could define a promise through a new extension with the desired semantics but that is close enough to datagrams that it doesn’t make much sense - but you might want a datagram that does not have ACKs - this affects flow control, but since transmission is infrequent, that could work.
>  
> Something else:
>  
> It is hard to prevent an attacker from dropping or delay packets even on an encrypted QUIC connection and a retransmission would not be a useful mitigation, so I am not sure how you can make NTP truly secure. A voting system from multiple sources could make such an attack more difficult.
>  
> Kind Regards,
> Mikkel Fahnøe Jørgensen
> 
>  
> On 14 April 2020 at 19.40.00, Roberto Peon ([e-mail]) wrote:
> 
> You don’t need the datagram extension, rather, you need a promise to not retransmit or a promise to communicate the time in any retransmission.
> While datagram provides, implicitly today, a promise to not retransmit, datagrams themselves aren’t the requirement.
> (Also, in the face of multipath, is it true that we won’t have duplicates even for datagrams. I’m not sure this is clear right now?)
> 
> If the first packet has higher measurable (latency) overhead in the processing stack, then you probably don’t want to use that one for NTP if you’re high time accuracy.
> In other words, you may find that you get better accuracy if you make a connection, and then do the NTP “stuff”. Similarly, you may find you get better accuracy if you *always* do a handshake on every packet (though that is more expensive)…
> 
> While QUIC is a wonderful hammer, I do wonder if it provides any significant benefit in this case.
> 
> -=R
> 
>  
> From: QUIC <[e-mail]> on behalf of Mikkel Fahnøe Jørgensen <[e-mail]>
> Date: Monday, April 13, 2020 at 2:31 AM
> To: Erik Kline <[e-mail]>, Tal Mizrahi <[e-mail]>, Watson Ladd <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, IETF QUIC WG <[e-mail]>, Spencer Dawkins at IETF <[e-mail]>, Lucas Pardue <[e-mail]>
> Subject: Re: NTP is unique (was Re: QUIC as a transport substrate (was:re-chartering: include DNS-over-QUIC?))
>  
> 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 
> >