Subject: [Ntp] New draft - draft-dansarie-nts-00.txt

From: Ragnar Sundblad <[email-masked]>
Date: Mon, 2 Jul 2018 19:59:48 +0200

Dear All,

Thank you to the working group for your hard work on NTS.

We are running a time dissemination service that amongst other
interfaces have 8, soon 10, high bandwidth NTP servers spread over
Sweden. Each NTP server has 4 * 10 Gb/s ethernet ports, and each of
those ports can handle full wire speed NTP traffic, either
unauthenticated or signed using SHA1 or MD5, and over IPv4 or
IPv6. The idea with the high bandwidth is that we even during an
overload attack still should be able to respond to at least some of
the legitimate requests. To acheive this bandwidth and still have good
time stamping properties, the entire NTP server is implemented in
FPGA. Typical load on our system is around 300,000 NTP requests per
second, or about 300 Mb/s, most from abroad. We do not know how many
clients that use our system, but a rough and we believe not
exaggerated estimate is tens of millions.

Of course we would like to get authenticated NTP for everyone on this
system. We highly appreciate the work this group has done with a
proposal for a protocol that uses cookies to keep the per-session
state out of the server, which is an absolute need in our case.

We have today submitted a slightly revised version of the nts4ntp
draft. Our main concern with the earlier proposals is that the KE
service will be very easy to overload, so we have added some minor
changes that will let the NTP session be able to better survive a
network outage, and be reestablished after a client reboot, even if
the KE service is not reachable. We also believe some of our changes
can be of advantage in NTP pooling situations.

The draft can be found here:
<https://www.ietf.org/id/draft-dansarie-nts-00.txt>

The major differences between our draft and the working group draft are,
in no particular order:

* The separation of the NTS-KE and NTP servers. This enables the use of
NTS in advanced infrastructures such as ours as well as in pools. The
separation does not preclude combining the two servers in smaller
implementations.

* The addition of resilience as a design objective.

* Changing the requirement of TLS 1.2 to 1.3, as RFC 8446 is currently
in AUTH48 state and is expected to be published very shortly.

* Addition of an "NTS Server Negotiation" NTS record. Its primary use is
for the KE server to indicate which NTP server or servers the
generated cookies are valid for. It can also be used by the client to
request cookies for a specific server. The addition of this record is
what enables separation of the NTS-KE and NTP servers. Additionally,
it allows the NTS-KE server to perform additional tasks, such as load
balancing and geographic assignment of NTP servers to clients.

* Change of the "NTS Authenticator and Encrypted Extension Fields"
extension field format. This has been done to simplify implementations
of NTS in hardware and FPGAs.

* Addition of a requirement for servers that implement NTS to always
include the "Unique Identifier" extension field in replies to packets
that include it. Clients that have received authenticated packets from
an NTP server can therefore safely ignore any spoofed kiss-o'-death
packets sent by off-path attackers.

* Added a recommendation that clients should store cookies on persistent
storage when possible. This increases resilience in case of attacks on
the NTS-KE service.

* Addition of a section discussing usage in NTP server pools. Removal of
NTP pool discussion in "Security Considerations" section.

* Changes in "IANA Considerations" section to improve readability and
ensure compliance with RFC 8126.

* Added discussion on DDoS resilience.

We look forward to working on this protocol with you in this group,
and hope to soon be a part of the authenticated NTP community.

Our time dissemination system is funded by the Swedish Post and
Telecom Authority, PTS.
Some more information about this system can be found here:
<http://www.ntp.se>
A presentation of the system can be found here:
<https://www.netnod.se/sites/default/files/ntp/Network_Time_Protocol_from_a_distributed_timescale_traceable_to_UTC.pdf>.

Best regards,

Marcus Dansarie
Ragnar Sundblad
with review and ideas from
Patrik Fältström
Joachim Strömbergsson

---

From: [email-masked]
Date: Tue, 3 Jul 2018 18:28:20 +0200

Hello Ragnar,

first of all thank you for your input, and also for the format that you 
decided on (concrete text suggestions in the appropriate places in the 
draft).
The only thing I can think of that would make it even more convenient 
would be to get a hold of the XML source file (if there is one), for an 
easier and more meaningful way for us to create a diff and go through all 
the changes.

Some more specific comments can be found in-line below. 

Best regards, 
Kristof

> Von: "Ragnar Sundblad" <[email-masked]>
> An: [email-masked]
> Datum: 02.07.2018 20:01
> Betreff: [Ntp] New draft - draft-dansarie-nts-00.txt
> Gesendet von: "ntp" <[email-masked]>
> 
> [...]
> 

Thank you, this we believe is the most important feature for 
future-proofing.

> can be of advantage in NTP pooling situations.

I like what your additions bring to the table.
I would like to put some though into whether everyting is provably as 
secure as without these changes (I'm carefully optimistic).

> separation does not preclude combining the two servers in smaller

As mentioned: I like what it enables, but it does add a bit more 
complexity that I would like to think about so I can form a real opinion.
 
> in AUTH48 state and is expected to be published very shortly.

I don't know enough about TLS, but requiring 1.3 feels slightly rushed to 
me. 
Daniel, what is your opinion on this?
 
> of NTS in hardware and FPGAs.

Hadn't noticed these in my read-through.
Gotta give this a look later.
 
> packets sent by off-path attackers.

The goal makes sense to me. I'm unsure about the "costs" of this 
requirement.
Anyone have a scenario where this might be inconvenient?
 
> storage when possible. This increases resilience in case of attacks on

Makes sense to me.

> NTP pool discussion in "Security Considerations" section.

Yeah, this seems like an attractive side-effect of the splitting of KE and 
timing instances.
 
> ensure compliance with RFC 8126.

Hadn't noticed these in my read-through.
 
> and hope to soon be a part of the authenticated NTP community.

Do you intend to participate in future IETF meetings (including the 
upcoming one)?
Nice to have more people on board.

> <https://www.netnod.se/sites/default/files/ntp/
> 
Network_Time_Protocol_from_a_distributed_timescale_traceable_to_UTC.pdf>.
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Ragnar Sundblad <[email-masked]>
Date: Tue, 3 Jul 2018 22:21:46 +0200

Hello Kristof,

Thank you for your comments!

Indeed, I sent the wrong link. A better one is:
<https://datatracker.ietf.org/doc/draft-dansarie-nts/>
Sorry, I am new to this!

Regarding TLS 1.3, the RFC will be released very soon. A lot of legacy “features" will be deprecated in 1.3, increasing the security of the protocol. Additionally, TLS 1.3 handshake is faster, further reducing the time the KE server has to keep state.

We intend to participate in the work group going forward, and we hope to be able to make it to Montreal.

Best regards,
Marcus & Ragnar

> On 3 Jul 2018, at 18:28, [email-masked] wrote:
> 
> Hello Ragnar, 
> 
> first of all thank you for your input, and also for the format that you decided on (concrete text suggestions in the appropriate places in the draft). 
> The only thing I can think of that would make it even more convenient would be to get a hold of the XML source file (if there is one), for an easier and more meaningful way for us to create a diff and go through all the changes. 
> 
> Thank you, this we believe is the most important feature for future-proofing. 
> 
> I would like to put some though into whether everyting is provably as secure as without these changes (I'm carefully optimistic).
> 
> As mentioned: I like what it enables, but it does add a bit more complexity that I would like to think about so I can form a real opinion. 
>  
> I don't know enough about TLS, but requiring 1.3 feels slightly rushed to me. 
> The goal makes sense to me. I'm unsure about the "costs" of this requirement. 
> Yeah, this seems like an attractive side-effect of the splitting of KE and timing instances. 
>  
> Do you intend to participate in future IETF meetings (including the upcoming one)?

---

From: Martin Langer <[email-masked]>
Date: Wed, 04 Jul 2018 10:45:20 +0200

Hello Ragnar,

thanks for your work. It looks very interesting. I read the document and 
I have some questions about it.

- Where does the client get the IP address of the NTS-KE server when the 
NTS-KE server and NTP server are physically separate (and have different 
IP addresses)?
- About TLS 1.3: Technically I agree with you, but I'm not sure if we 
just allow TLS 1.3. Many TLS implementations are still in progress. 
Maybe we allow TLS 1.2 or higher and the NTP/NTS client implementation 
can choose the protocol version (e.g. by using a config file). ...but 
maybe we should use TLS 1.3 only....

best regards,
Martin

-- 
Martin Langer, M.Eng.
Labor Datentechnik
Labor Design Digitaler Systeme

Ostfalia Hochschule für angewandte Wissenschaften
- Hochschule Braunschweig/Wolfenbüttel -
Fakultät Elektrotechnik
Salzdahlumer Straße 46/48
38302 Wolfenbüttel
Tel. : +49 5331 939 43370
Fax  : +49 5331 939 43372
Mail : [email-masked]
Web  : http://www.ostfalia.de/cms/de/e

---

From: Ragnar Sundblad <[email-masked]>
Date: Wed, 4 Jul 2018 15:46:40 +0200

Hello Martin,

> On 4 Jul 2018, at 10:45, Martin Langer <[email-masked]> wrote:
> 
> Hello Ragnar,
> 
> thanks for your work. It looks very interesting. I read the document and I have some questions about it.
> 
> - Where does the client get the IP address of the NTS-KE server when the NTS-KE server and NTP server are physically separate (and have different IP addresses)? 

Our thought is to just give the DNS name of the KE server to clients, just as it works with NTP servers today. The client will then choose one of the NTP servers given in the KE server reply, which, depending on implementation, could be the KE server itself.

> - About TLS 1.3: Technically I agree with you, but I'm not sure if we just allow TLS 1.3. Many TLS implementations are still in progress. Maybe we allow TLS 1.2 or higher and the NTP/NTS client implementation can choose the protocol version (e.g. by using a config file). ...but maybe we should use TLS 1.3 only....

We believe we really should aim for 1.3 since the handshake is faster which further reduces the time the KE server has to keep state, and with 1.3 we get rid of all the old cruft which should make it more secure and easier to use/fit in small clients.
Indeed this would have been a much easier choice if 1.3 was already out there and was more proven. Hopefully it soon will be, and it should be an RFC any day now.

Best regards,

/ragge

---

From: Ask Bjørn Hansen <[email-masked]>
Date: Thu, 19 Jul 2018 20:15:13 -0700

> On Jul 4, 2018, at 6:46, Ragnar Sundblad <[email-masked]> wrote:
> 

As I said at the WG meeting a couple days ago, I think this is a very valuable addition / change.

For my hobby project this could make it possible, as I understand it, to support NTS for the NTP Pool. Many of the NTP Pool clients are terrible implementations (and will likely remain so), but it’d be a valuable service to the better maintained ones.

At my employer we have a large NTP service. Despite all the servers being under one “operationa domain”, separating the KE server from the NTP servers (again if I understand your changes right) will also vastly improve the operational experience of adding NTS if we were to do so.

Ask