Re: [Ntp] Antw: [EXT] Re: I-D Action: draft-ietf-ntp-port-randomization-04.txt

I suggested off-list that the authors add such text in order to reduce the
number of pointless server-directed ICMP port unreachables when per-request
randomization is used.  Two cases come to mind:  responses that arrive
slightly after the client decides to stop waiting and when multiple
responses arrive at the client.

Debugging sessions can be confused by seeing these ICMPs messages.

NTP has some differences compared to other UDP protocols.  Many NTP clients
have historically used fixed client ports; moving to per-request
randomization would increase ICMP frequency.  NTP is subject to middlebox
meddling: network delays are sometimes artificially increased.

This is a minor point.  If it is objectionable, then omit the text.

Steve Sommars

On Fri, Jun 12, 2020 at 2:45 AM Ulrich Windl <
Ulrich.Windl@rz.uni-regensburg.de> wrote:

> >>> Tomoyuki Sahara <tsahara@iij.ad.jp> schrieb am 11.06.2020 um 08:51 in
> Nachricht
>
> <27326_1591858318_5EE1D48E_27326_38_1_20200611.155136.1977732866371143955.tsahar
> @iij.ad.jp>:
> > Thank you for updating the draft.
> >
> > One comment on a new text:
> >
> >>      If a client implementation performs port randomization on a per‑
> >>      request basis, it SHOULD close the corresponding socket/port after
> >>      each request/response exchange.  The client SHOULD wait for
> >>      response packets from the server for at least 3 seconds before
> >>      closing the UDP socket/port, even if a successful response is
> >>      received.  This will prevent duplicate or delayed server packets
> >>      from eliciting ICMP port unreachable error messages at the client.
> >
> > This concern is common to many UDP‑based request/response protocols
> > but most protocols (if not all) do not try to deal with it.  I do not
> > think it is necessary to mention and recommend (by "SHOULD" word) it
> > in this document.
>
> I think if not mentioned explicitly, it should be mentioned by reference
> to a
> document describing that.
> The assumption is that the reader of the RFC does _not_ know all existing
> recommendations...
>
> >
> >
> > Thanks,
> > Tomoyuki
> >
> > _______________________________________________
> > ntp mailing list
> > ntp@ietf.org
> > https://www.ietf.org/mailman/listinfo/ntp
>
>
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
>