Subject: [Ntp] Feedback on drafts from AusNOG conference

From: Paul Gear <[email-masked]>
Date: Thu, 14 Sep 2017 21:57:35 +1000

Hi all,

Thanks to sponsorship by NTF, I recently attended AusNOG 2017 to give a
presentation about NTP - slides are available at
http://www.ausnog.net/events/ausnog-2017/programme.  I hope I have
adequately represented the state of affairs with the RFC drafts.  There
were two interesting pieces of technical feedback which I wanted to pass on.

Firstly, during the time for questions at the end of my talk, Geoff
Huston from APNIC questioned the viability of DTLS.  He claimed that a)
one of the DNS working groups (DNS privacy, I think) had found that
there were no viable implementations of DTLS for their purposes when
they surveyed the field recently, and b) there are issues with packet
fragmentation in some switch/router chipsets which could cause problems
with the use of UDP for DTLS.  I asked him about this in more detail
later, and he indicated that the fragmentation problem was an IPv6-only
issue, whereby he found that a certain significant percentage of DNS
clients on the Internet cannot receive fragmented replies to requests
due to the fact that some routers and/or switches drop fragmented IPv6
packets.

I found both of Geoff's claims very unusual, so I went looking for DTLS
libraries and found that both OpenSSL and GnuTLS claim to support DTLS. 
I downloaded python DTLS (https://pypi.python.org/pypi/Dtls), which
claims to use OpenSSL internally, and started writing some code to
create a DTLS tunnel with it.  I haven't managed to get NTP to sync over
it, but I did manage to get it to complete a certificate exchange with a
931-byte self-signed certificate.  The certificate exchange took place
over several packets, due to the fact that either OpenSSL or python DTLS
split up the certificate into 256-byte chunks to send over the
connection.  So I think my fears about packet size under NTS
peer/control modes and Geoff's about fragmentation are probably
unfounded (although I didn't test IPv6 yet, so that is still up for grabs).

The second issue was raised by Steinthor Bjarnason of Arbor Networks, a
DDoS mitigation vendor.  He raised the point that if their DDoS
mitigation engine sees an NTP packet with NTS extensions in it without
seeing an NTS KE TCP connection prior to that, they could use that as a
heuristic for deciding that the UDP traffic was illegitimate.  During
our discussion I realised that this wouldn't be a valid heuristic,
because NTS is specifically built with client mobility in mind, and it's
completely plausible for a single client - say, a dual-SIM mobile
handset - to do its preliminary NTS key exhange via TCP over its wifi
interface, then send an NTP packet with NTS Extension Fields via UDP
over one cellular connection, and the next NTP packet with NTS Extension
Fields via UDP over its second cellular connection.  This would be
completely allowable (even natural) behaviour for an NTS client.  I
pointed out that even if the NTS standard mandated using the same IP
address for both the TCP and UDP exchanges, it wouldn't be practical to
enforce, since that would require the server holding additional state,
which is specifically not desired by NTS.

I don't think this is a problem for NTS, merely an observation that
whilst it aims not to contribute to DDoS attacks, it will also not
assist DDoS mitigation technologies in distinguishing legitimate from
illegitimate traffic.  Consensus at the conference seemed to be that
DDoS mitigation vendors are in for an increasingly difficult time over
the next few years as bandwidth at the edge increases much more quickly
than bandwidth at the core.

Regards,
Paul