Subject: [Ntp] Last Call: <draft-ietf-ntp-using-nts-for-ntp-22.txt> (Network Time Security for the Network Time Protocol) to Proposed Standard

From: The IESG <[email-masked]>
Date: Fri, 14 Feb 2020 06:46:16 -0800

The IESG has received a request from the Network Time Protocol WG (ntp) to
consider the following document: - 'Network Time Security for the Network
Time Protocol'
  <draft-ietf-ntp-using-nts-for-ntp-22.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2020-02-28. Exceptionally, comments may
be sent to [email-masked] instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

   This memo specifies Network Time Security (NTS), a mechanism for
   using Transport Layer Security (TLS) and Authenticated Encryption
   with Associated Data (AEAD) to provide cryptographic security for the
   client-server mode of the Network Time Protocol (NTP).

   NTS is structured as a suite of two loosely coupled sub-protocols.
   The first (NTS-KE) handles initial authentication and key
   establishment over TLS.  The second handles encryption and
   authentication during NTP time synchronization via extension fields
   in the NTP packets, and holds all required state only on the client
   via opaque cookies.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/ballot/

No IPR declarations have been submitted directly on this I-D.

The document contains these normative downward references.
See RFC 3967 for additional information: 
    rfc5297: Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES) (Informational - IETF stream)

---

From: Russ Housley <[email-masked]>
Date: Mon, 17 Feb 2020 08:22:50 -0500

Section 3 says: "... NTS-KE server's private certificate."  Certificates are public.  I assume that you are talking about a private key here.

Section 4.1.5 says: "...  denoting Numeric Identifiers from the IANA AEAD registry [RFC5116]".  I think it would be more useful to provide a pointer to the registry instead of the RFC that created the registry.

Section 4.1.7 says: "...an IPv4 address in dotted decimal notation, an IPv6 address, or ...". This is followed by a sentence on the format of the IPv6 address and s sentence on IDNs.  I think a parallel structure would be more clear.  Please list the choices, and then discuss the format used for each of the choices.

Section 7.1: I believe the contact should be [email-masked] <mailto:[email-masked]> (not [email-masked] <mailto:[email-masked]>).

Russ

> On Feb 14, 2020, at 9:46 AM, The IESG <[email-masked]> wrote:
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Marcus Dansarie <[email-masked]>
Date: Tue, 18 Feb 2020 21:39:13 +0100

Russ,

Thank you for reviewing the draft and providing comments! I've discussed
the issues with the other authors. Please see our answers below.

Kind regards,
Marcus

On 2020-02-17 14:22, Russ Housley wrote:
> Section 3 says: "... NTS-KE server's private certificate."  Certificates
> are public.  I assume that you are talking about a private key here.

Indeed. This will be fixed.

> Section 4.1.5 says: "...  denoting Numeric Identifiers from the IANA
> AEAD registry [RFC5116]".  I think it would be more useful to provide a
> pointer to the registry instead of the RFC that created the registry.

This makes sense, although we are unsure about what the best practice
is. Do you (or anyone else) know if there's IETF guidance on how to
reference IANA registries?

> Section 4.1.7 says: "...an IPv4 address in dotted decimal notation, an
> IPv6 address, or ...". This is followed by a sentence on the format of
> the IPv6 address and s sentence on IDNs.  I think a parallel structure
> would be more clear.  Please list the choices, and then discuss the
> format used for each of the choices.

To fix this, we suggest changing the paragraph to:

"The contents of the string SHALL be either an IPv4 address, an IPv6
address, or a fully qualified domain name (FQDN). IPv4 address MUST be
in dotted decimal notation. IPv6 addresses MUST conform to the "Text
Representation of Addresses" as specified in [RFC4291] and MUST NOT
include zone identifiers [RFC6874]. If internationalized labels are
needed in the domain name, the A-LABEL syntax specified in [RFC5891]
MUST be used."

> Section 7.1: I believe the contact should be [email-masked]
> <mailto:[email-masked]> (not [email-masked] <mailto:[email-masked]>).

Section 8.1.1. of RFC 6335 says to use [email-masked].

---

From: "Patrik Fältström" <[email-masked]>
Date: Tue, 18 Feb 2020 21:58:29 +0100

On 18 Feb 2020, at 21:39, Marcus Dansarie wrote:

> If internationalized labels are needed in the domain name, the A-LABEL syntax specified in [RFC5891] MUST be used.

A different suggestion which I claim is more correct is:

If a label contains at least one non-ascii character, an A-LABEL MUST be used as defined in section 2.3.2.1 of RFC5890.

   Patrik

---

From: Daniel Lublin <[email-masked]>
Date: Wed, 19 Feb 2020 08:23:47 +0100

Good day,

I'm not entirely convinced of keeping a list of implementations in an RFC.
But since the information is there, let's at least have it corrected and
updated upon publishing.

Updated XML for the whole section 8.6. Implementation 6 follows.

  <section title="Implementation 6">
    <t>Organization: Hacklunch, independent</t>

    <t>Implementor: Michael Cardell Widerkrantz, Daniel Lublin, Martin Samuelsson et. al.</t>

    <t>Maturity: interoperable client, immature server</t>

    <section title="Coverage">
      <t>NTS-KE client and server.</t>
    </section>

    <section title="Licensing">
      <t>Licensing is ISC (details in LICENSE file).</t>

      <t>Source code is available at:
      https://gitlab.com/hacklunch/ntsclient</t>
    </section>

    <section title="Contact Information">
      <t>Contact Michael Cardell Widerkrantz: [email-masked]</t>
    </section>

    <section title="Last Update">
      <t>The implementation was updated 6. February 2020.</t>
    </section>
  </section>

---

From: Russ Housley <[email-masked]>
Date: Wed, 19 Feb 2020 03:21:25 -0500

Marcus:

See below ...

> reference IANA registries?

RFC 8708 says this for a specific registry:

   [IANA-LMS] IANA, "Leighton-Micali Signatures (LMS)",
              <https://www.iana.org/assignments/leighton-micali-
              signatures/>.

> needed in the domain name, the A-LABEL syntax specified in [RFC5891]

I liked the text proposed for the last sentence by Patrik.  Otherwise, this looks fine to me.

> Section 8.1.1. of RFC 6335 says to use [email-masked].

I stand corrected.

Russ

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 19 Feb 2020 00:26:41 -0800

I think a list of implementations is a bad idea.

Does the WG really want to deal with the ongoing updates, and the
liability that will likely exist if the list is incorrect, or it is
decided that updates will no longer be made?

H

On 2/18/2020 11:23 PM, Daniel Lublin wrote:
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
> 

-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: Hal Murray <[email-masked]>
Date: Wed, 19 Feb 2020 00:48:13 -0800

> But since the information is there, let's at least have it corrected and

I thought it was a temporary section and would be deleted by the final editing 
pass when the TBDs were filled in.

Traditionally, RFCs required running code, normally at least 2 independent 
implementations that can talk to each other.  That section is useful while 
debugging and collects the data for the reviewers.

-------

Speaking of TBDs...  How do we contact the czar who assigns numbers for NTP 
extensions?  We've all been testing with 4 values.  It will be a pain if they 
change and I don't know of any reason not to make the values we are using 
official.

-- 
These are my opinions.  I hate spam.

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 19 Feb 2020 00:52:35 -0800

> change and I don't know of any reason not to make the values we are using 

As long as we're talking about the original 0x0n04 values I agree with you.

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 19 Feb 2020 10:31:38 +0100

> pass when the TBDs were filled in.

That's my understanding too.

> change and I don't know of any reason not to make the values we are using 

Yes, that would help. However, the NTS-KE port is different between
the implementations, so there will still probably be a flag day.

-- 
Miroslav Lichvar

---

From: Hal Murray <[email-masked]>
Date: Wed, 19 Feb 2020 02:06:45 -0800

[email-masked] said:
> Yes, that would help. However, the NTS-KE port is different between the
> implementations, so there will still probably be a flag day. 

We can listen on both ports.  (4 if you count IPv6)  I think that avoids a 
flag day.

It might be possible to avoid a flag day on the extension numbers.  The idea 
is to accept either set, remember which arrived and use those for the reply.  
That's just complicated/ugly enough that I think I'd prefer a flag day.

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 19 Feb 2020 14:25:14 +0100

>>> Harlan Stenn <[email-masked]> schrieb am 19.02.2020 um 09:26 in
Nachricht
<10141_1582100906_5E4CF1AA_10141_2470_1_0edc8be5-3887-06a4-8821-041ad65bb027@nwt
> I think a list of implementations is a bad idea.

What about some informational statement like "At the time of writing there
exist <number> implementations having demonstrated use of the protocol in
practice." Any maybe "Those implementations are/were: ..."

>>       <t>NTS‑KE client and server.</t>
>>     </section>
>> 
> ‑‑ 
> http://networktimefoundation.org ‑ be a member!
>

---

From: Paul Wouters <[email-masked]>
Date: Wed, 19 Feb 2020 09:43:45 -0500

> On Feb 19, 2020, at 02:23, Daniel Lublin <[email-masked]> wrote:
> 
> Good day,
> 

There shouldn’t be. See https://tools.ietf.org/html/rfc7942

which clearly states:

Since this information is necessarily time dependent, it is inappropriate for inclusion in a published RFC. The authors should include a note to the RFC Editor requesting that the [implementation] section be removed before publication.

Paul

---

From: Watson Ladd <[email-masked]>
Date: Wed, 19 Feb 2020 07:03:04 -0800

On Wed, Feb 19, 2020 at 6:45 AM Paul Wouters <[email-masked]> wrote:
>
>
>
> On Feb 19, 2020, at 02:23, Daniel Lublin <daniel@lublin..se> wrote:
>
> Good day,
>
>    Since this information is necessarily time dependent, it is
>    inappropriate for inclusion in a published RFC.  The authors should
>    include a note to the RFC Editor requesting that the [implementation] section be
>    removed before publication.

I could have sworn that note appears in the draft in Section 8, and
looking at the file it indeed does.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 19 Feb 2020 15:31:25 +0000

>    I think a list of implementations is a bad idea.
    
I could not agree more!

---

From: Karen O'Donoghue <[email-masked]>
Date: Wed, 19 Feb 2020 15:38:00 +0000

Folks,

Suresh said this but let me reiterate... It was never the plan for the list of implementations to be in the final RFC. It will be removed in the publication phase. We should have indicated as such in the draft and that was my mistake for not catching it. 

Karen

        
    I could not agree more!

---

From: "Franke, Daniel" <[email-masked]>
Date: Wed, 19 Feb 2020 18:19:40 +0000

Suresh,

Hal may not have been clear. The four extension fields we're discussing are the four defined by the NTS draft. Due to the registry's unfortunate lack of any P&E range, Hal and other implementers have picked four codes that they've been squatting on for their draft implementations. Desiring to avoid a flag day when the draft becomes final, they'd like IANA to turn these four codes into official allocations rather than having IANA arbitrarily assign something else. Speaking as an author of the draft I have no objection to this.

________________________________
From: Suresh Krishnan <[email-masked]>
Sent: Wednesday, February 19, 2020 11:48
To: Hal Murray
Cc: Daniel Lublin; [email-masked]; [email-masked]; Karen O'Donoghue; [email-masked]; [email-masked]; IETF-Announce
Subject: NTP Extensions (was Re: [Ntp] Last Call: <draft-ietf-ntp-using-nts-for-ntp-22.txt> (Network Time Security for the Network Time Protocol) to Proposed Standard)

Hi Hal,
  (Changed subject to match your question below)

On Feb 19, 2020, at 3:48 AM, Hal Murray <[email-masked]<mailto:[email-masked]>> wrote:

[email-masked]<mailto:[email-masked]> said:
I'm not entirely convinced of keeping a list of implementations in an RFC.
But since the information is there, let's at least have it corrected and
updated upon publishing.

-------

If you are talking about NTP extension field types [0], they do require IETF review for allocation (i.e. no czar). Writing up a draft with your usage and sending it over to the ntp wg for consideration would be the best way forward.

[0] https://www.iana.org/assignments/ntp-parameters/ntp-parameters.xhtml#ntp-parameters-3<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_assignments_ntp-2Dparameters_ntp-2Dparameters.xhtml-23ntp-2Dparameters-2D3&d=DwMFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=NlX0r6ynsvJy6t1-UbBqZbYxmdFYzvmLMmHofVndJ5k&m=4kCauNy5drgPVUEUsh2dWTBaaNAbwXU3tn1IZ2PbYI8&s=Ilafc9XVtUXj0DZFzrrma2AVM9yP4qsJLTGybPb_FaE&e=>

Regards
Suresh

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 19 Feb 2020 10:29:47 -0800

> Hal may not have been clear. The four extension fields we're discussing are the four defined by the NTS draft. Due to the registry's unfortunate lack of any P&E range, Hal and other implementers ha…

It's pretty normal/supported to include requested values in the IANA
Considerations section.  Just be clear that they're suggestions and not
official allocations, lest you get a DISCUSS for codepoint squatting :)

-Ben

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 19 Feb 2020 13:33:39 -0800

Except that we did discuss this, years ago, and there was a meeting with
me and Karen and I forget who else where we specifically said that
0xnn04 was already allocated for NTS.  I've long been saying we need a
way to make progress with EF proposals that does not cause collisions
between inplementations and avoids flag days.  Furthermore, I told Karen
that the NTP Project was using 0xNN0[5-9] for other proposals and that
with no progress on changing the way the NTP Extension Field IANA
registry was being managed, that 1) the NTP Project has a chalkboard
that we're using for this purpose, and 2) if anybody wants to work on an
EF they should just let me know.

You knew this too, and picked different numbers for your own reasons.

H

On 2/19/2020 10:19 AM, Franke, Daniel wrote:
> Suresh,
> 
> 
> Hal may not have been clear. The four extension fields we're discussing
> are the four defined by the NTS draft. Due to the registry's unfortunate
> lack of any P&E range, Hal and other implementers have picked four codes
> that they've been squatting on for their draft implementations. Desiring
> to avoid a flag day when the draft becomes final, they'd like IANA to
> turn these four codes into official allocations rather than having IANA
> arbitrarily assign something else. Speaking as an author of the draft I
> have no objection to this.
> 
> ------------------------------------------------------------------------
> *From:* Suresh Krishnan <[email-masked]>
> *Sent:* Wednesday, February 19, 2020 11:48
> *To:* Hal Murray
> *Cc:* Daniel Lublin; [email-masked]; [email-masked]; Karen O'Donoghue;
> [email-masked]; [email-masked];
> IETF-Announce
> *Subject:* NTP Extensions (was Re: [Ntp] Last Call:
> <draft-ietf-ntp-using-nts-for-ntp-22.txt> (Network Time Security for the
> Network Time Protocol) to Proposed Standard)
>  
> Hi Hal,
>> [email-masked] <mailto:[email-masked]> said:
> If you are talking about NTP extension field types [0], they do require
> IETF review for allocation (i.e. no czar). Writing up a draft with your
> usage and sending it over to the ntp wg for consideration would be the
> best way forward.
> 
> [0] _https://www.iana.org/assignments/ntp-parameters/ntp-parameters.xhtml#ntp-parameters-3
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_assignments_ntp-2Dparameters_ntp-2Dparameters.xhtml-23ntp-2Dparameters-2D3&d=DwMFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=NlX0r6ynsvJy6t1-UbBqZbYxmdFYzvmLMmHofVndJ5k&m=4kCauNy5drgPVUEUsh2dWTBaaNAbwXU3tn1IZ2PbYI8&s=Ilafc9XVtUXj0DZFzrrma2AVM9yP4qsJLTGybPb_FaE&e=>_
> _
> _
> Regards
> Suresh
> 
>

---

From: Watson Ladd <[email-masked]>
Date: Wed, 19 Feb 2020 13:59:19 -0800

> EF they should just let me know.

The way to achieve this is to make an experimental/private use range
for the registry. The registry is currently IETF review, which is
annoying: it's big enough to be Specification Required unless
proposals take large chunks of the range. It's not impossible to
change this with WG consensus.

As for avoiding flag days, early drafts are going to evolve, breaking
backwards compatibility anyway. I've always emphasized that we are
going to have breaking changes in our NTP service until the draft
stabilizes, I don't see how we can get any sort of experimental
deployment unless we're willing to break the toys. (And no, they don't
get to keep the pieces). One solution, copying from the TLS WG, is to
have draft version numbers in the ordinary version negotiation
mechanism, but that's not as suitable for an extension field.

We discussed a potential early allocation request at the virtual
interim that would give us plenty of time to have implementations
ready before RFC. There is no reason we can't all have implementations
and deployments supporting the final RFC version and numbers when they
come out.

Sincerely,
Watson

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 19 Feb 2020 14:08:03 -0800

> change this with WG consensus.

Sorry, no.  There are 8 bits available for this.  If you would have
followed the design that was put in place 20 years ago you'd know this.

That so many folks want to ignore this and learn painful lessons all
over again is their choice.

H
--

---

From: Watson Ladd <[email-masked]>
Date: Wed, 19 Feb 2020 14:11:05 -0800

> followed the design that was put in place 20 years ago you'd know this.

RFC 7822 allocates 16 bits for extension types.

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 19 Feb 2020 14:15:31 -0800

> RFC 7822 allocates 16 bits for extension types.

RFC7822 was a terrible mistake in many ways, and I continue to regret
that I did not read it carefully when the vote was taken.  I spent a lot
of time and effort trying to clean that up and got no support for those
efforts.

So here we are.

---

From: Daniel Franke <[email-masked]>
Date: Wed, 19 Feb 2020 17:25:05 -0500

RFC 5905 likewise provides 16 bits.

---

From: Karen O'Donoghue <[email-masked]>
Date: Wed, 19 Feb 2020 22:28:40 +0000

We have had conversations about this in the past and a couple different plans to move forward, but we have struggled to get final consensus on any of them. As Harlan indicated we had an initial agreement based on early drafts of NTS; however, time moved on, the NTS draft went in a radically different direction that where it started, and those agreements never gained the full consensus of the working group. So, we are where we are now, and we need to figure out how to efficiently and effectively move forward.  

Specifically with regard to the NTS draft... 
We can do two things: 
1) Quickly come to consensus with the implementers, authors, and working group on an update to the IANA considerations text that we can add between IETF Last Call and the IESG vote. 
2) Do nothing and let the IANA folks do what they will... (do you really want this to happen?!?)

Longer term... we could still work on a consensus document that provides additional guidance for the whole EF registry assignment discussion. I welcome such submissions and a reasonable discussion around them... 

Please let's try to work together to resolve this quickly. I'm not responding any one individual here as much as the topic... 

Karen

On 2/19/20, 4:59 PM, "ntp on behalf of Watson Ladd" <[email-masked] on behalf of watson=[email-masked]> wrote:

    

    Sincerely,
    Watson

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 19 Feb 2020 14:29:08 -0800

> RFC 5905 likewise provides 16 bits.

But there was a STRUCTURE to those bits that is now being ignored.

H
--
> On Wed, Feb 19, 2020, 17:15 Harlan Stenn <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 
> 
>     > On Wed, Feb 19, 2020 at 2:08 PM Harlan Stenn <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >>
>     >>
>     >>
>     >>> On Wed, Feb 19, 2020 at 1:33 PM Harlan Stenn <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >>>>
>     Harlan Stenn <[email-masked] <mailto:[email-masked]>>
>     [email-masked] <mailto:[email-masked]>

---

From: Watson Ladd <[email-masked]>
Date: Wed, 19 Feb 2020 14:50:48 -0800

> 2) Do nothing and let the IANA folks do what they will... (do you really want this to happen?!?)

Looking at the source the numbers are
const EXT_TYPE_UNIQUE_IDENTIFIER: u16 = 0x0104;
const EXT_TYPE_NTS_COOKIE: u16 = 0x0204;
const EXT_TYPE_NTS_COOKIE_PLACEHOLDER: u16 = 0x0304;
const EXT_TYPE_NTS_AUTHENTICATOR: u16 = 0x0404;
which I think are the ones that came out of conversation with Harlan
according to his email above.

But I'm fine treating these as experimental points and having
different ones in the RFC, although it's slightly less work for me if
we don't do that. In the future I strongly feel we need an
experimental range and need to expect that points outside the range
will be allocated as drafts advance.

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 19 Feb 2020 14:52:06 -0800

I want the 0xNN04 numbers.

H

---

From: Daniel Franke <[email-masked]>
Date: Wed, 19 Feb 2020 23:50:56 -0500

> 2) Do nothing and let the IANA folks do what they will... (do you really want this to happen?!?)

It seems to me we already have consensus. Everyone who's spoken up
prefers that we ask IANA to register the numbers we've been squatting
on. Some have added that if the numbers get changed, then they can
live with that. I've already asked Hal Murray to submit a PR adding
the requested numbers to the draft, but I'll take it from whomever
submits one first.

This makes the argument over whether EF type codes have any structure
irrelevant because the codes we've been squatting already conform to
the structure that Harlan asserts exists. But the argument is also out
of order in general, because it's already been settled. Last year or
so Harlan sought adoption of a draft laying out this structure. That
draft is now a dead document because the response to the call for
adoption was overwhelming and unanimous in opposition to it.

---

From: Karen O'Donoghue <[email-masked]>
Date: Thu, 20 Feb 2020 08:55:53 +0000

On 2/19/20, 11:51 PM, "Daniel Franke" <[email-masked]> wrote:

<kfo> I have seen a lot of discussion and possibly consensus, but I haven't seen concrete text that articulates that consensus. The document is now a working group document, and given the amount of discussion around this topic, I would like to see the text agreed to before it is incorporated into the document. As you say it shouldn't be that hard, so someone please propose some text on the list, we'll discuss, determine consensus, and then you can incorporate it. 

<kfo> You are correct that the Extension Field draft did not get adopted last year. However, there was a great deal more in that draft than just instructions or possible structuring for the assignment of the code points for EFs. This is still a topic that we could potentially resolve with a much more narrowly scoped document - if we chose to do so. Or we could move it to the potential future ntpv5 effort.

---

From: Karen O'Donoghue <[email-masked]>
Date: Thu, 20 Feb 2020 09:12:42 +0000

And... just to close the loop... what is it they say ... one should trust but verify... 

I thought we had had the discussion, but I didn't double check the document, assuming that we must not have said anything because of the discussion on the mailing list... and as has been gently pointed out to me...
The header itself for the section actually says... 

"8. Implementation Status - RFC EDITOR: REMOVE BEFORE PUBLICATION"

So, like everyone else, I jumped on a conversation before verifying the underlying assumptions... A lesson for all... 

Karen

On 2/19/20, 10:37 AM, "Karen O'Donoghue" <[email-masked]> wrote:

    Folks,

    Karen

            
        I could not agree more!

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 19 Feb 2020 22:25:29 +0000

Hi Daniel,

On Feb 19, 2020, at 1:19 PM, Franke, Daniel <[email-masked]<mailto:[email-masked]>> wrote:

Suresh,

Ah. Thanks for clarifying. That makes sense. I don’t have any issues with this either. As Ben Kaduk said downthread, you can stuff in the currently used values as “requested values” into the draft after the last call completes. I will work with IANA to get these values assigned (I don’t foresee an issue)

Regards
Suresh

---

From: Steven Sommars <[email-masked]>
Date: Mon, 24 Feb 2020 08:51:46 -0600

There is substantial size-based blocking of UDP port 123 IPv4 packets by
ISPs/IXPs.  From one NTP monitoring point I saw about one third of the NTP
destinations unreachable (dropped en route) for  212-460 byte port 123
UDP.  Another monitoring point experienced blocking for all NTP
destinations when the size was greater than 428 bytes.  Size-based NTP
blocking is not a secret; it was discussed on the NANOG mailing list in
2014 (see for example
https://mailman.nanog.org/pipermail/nanog/2014-February/064634.html ).
NTP requests can be dropped, so  section 9.3 of draft 22 does not address
the problem.   While NTS will not be a DDoS amplification source, it will
be affected by existing DDoS countermeasures.

How will NTS work in today's UDP-unfriendly Internet?

On Fri, Feb 14, 2020 at 8:47 AM The IESG <[email-masked]> wrote:

>     rfc5297: Synthetic Initialization Vector (SIV) Authenticated
> Encryption Using the Advanced Encryption Standard (AES) (Informational -
> IETF stream)
>
>
>

---

From: Watson Ladd <[email-masked]>
Date: Mon, 24 Feb 2020 08:14:58 -0800

> How will NTS work in today's UDP-unfriendly Internet?

NTS-KE can advertise an alternate port for NTP.

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 24 Feb 2020 17:26:59 +0100

> NTS-KE can advertise an alternate port for NTP.

It would be good if all servers used the same alternative port to make
it easier to configure firewalls for NTS.

Considering the current state of the Internet, I think it would make
sense to specify one generally for NTP and not just for NTS. I have
prepared an initial draft that does that. If there is interest we can
work on that.
https://github.com/mlichvar/draft-ntp-alternative-port

-- 
Miroslav Lichvar

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 26 Feb 2020 09:39:15 +0100

>>> Steven Sommars <[email-masked]> schrieb am 24.02.2020 um 15:51 in
Nachricht
<13690_1582555938_5E53E31F_13690_19_1_CAD4huA6nNtJB5=E+dxBvmsLrozkgZ3f-3P=NydCsm
> How will NTS work in today's UDP-unfriendly Internet?

Maybe a candidate for the best practices: "How to block unwanted NTP packets correctly?", "Should NTP packets be blocked?". Here I can't use any external NTP server, BTW. I feel safe ;-)