Subject: [Ntp] Call for Adoption: draft-mlichvar-ntp-alternative-port

From: Karen O'Donoghue <[email-masked]>
Date: Thu, 27 Aug 2020 02:31:11 +0000

Folks,

This email starts a two week Call for Adoption on: 
https://datatracker.ietf.org/doc/draft-mlichvar-ntp-alternative-port/

Please reply to the mailing list (keeping the subject line intact) regarding your position on adopting this document into the working group. Please provide any comments on the document itself as well. 

Regards,
Karen

---

From: [email-masked]
Date: Thu, 27 Aug 2020 12:18:15 +0200

I support the adoption of this document.
While I do imagine this approach might become controversial (people 
arguing that the restrictions on UDP 123 were necessary and circumventing 
them is suspicious), I still think the reasoning for it is sound and the 
approach needs to be taken into consideration.

There is one question I have, in light of the strawman opposition I see 
coming at some point:
is it worth it to treat mode 1 and 2 as allowed for this alternative port?
The argument for mode 5 packets not being harmful with regards to 
amplification is easy: they relate to one-way communication.
Mode 3 packets are similar: it is impossible to "trigger" another device 
into sending them, thus no amplification.
Mode 4 is much more complex - but definitely worth the effort (as I 
understand it, it is the main reason why this document exists).
Mode 1 and 2 seem more complicated, I don't understand all the rules that 
would be necessary to ensure no amplification.
I believe it might be more difficult to argue a cause-and-effect situation 
for mode 1 or 2 packets than for mode 4 packets in relation to mode 3 
ones.
Therefore the question: how important is it to offer a treatment for those 
modes, and how does that relate to possible delays in the publication of 
this document?

Best regards,
Kristof Teichel

"ntp" <[email-masked]> schrieb am 27.08.2020 04:31:11:

> Von: "Karen O'Donoghue" <[email-masked]>
> An: "NTP WG" <[email-masked]>
> Datum: 27.08.2020 04:31
> Betreff: [Ntp] Call for Adoption: draft-mlichvar-ntp-alternative-port
> Gesendet von: "ntp" <[email-masked]>
> 
> Folks,
> 
> Please reply to the mailing list (keeping the subject line intact) 
> regarding your position on adopting this document into the working 
> group. Please provide any comments on the document itself as well. 
> 
> Regards,
> Karen
> 
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Hal Murray <[email-masked]>
Date: Thu, 27 Aug 2020 04:25:33 -0700

What do the DNS folks to to avoid DDoS reflection amplification and/or what do 
the people who filter NTP packets do with DNS packets?

-- 
These are my opinions.  I hate spam.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 27 Aug 2020 15:30:29 -0400

I support adoption and am willing to review

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 31 Aug 2020 12:56:25 +0200

> modes, and how does that relate to possible delays in the publication of 

The idea (as originally suggested by Daniel?) is to not restrict the
alternative port to specific modes, but to specify general
requirements for a response to be allowed on the port. If a response
in the mode 1 or 2 would be larger than the request, it must not be
sent from the alternative port.

For the symmetric mode (where each response is also a new request)
that means packets in the opposite directions are required to have the
same length. It's mentioned in the draft. Different polling intervals
between peers are allowed, so technically an amplification is
possible, but the maximum rate of the packets is limited by the
minimum polling interval of the peer. As a special case, one of the
peers can be stateless, responding immediately to each request with a
mode 2 packet. In that case, it works exactly the same as in mode 3
and 4.

If that seems too complicated, or would be difficult to defend, I'd
probably not mind too much if the draft didn't allowed the symmetric
mode on the alternative port.

-- 
Miroslav Lichvar