tlsport & ntpport

Richard Laager rlaager at wiktel.com
Sun Feb 3 02:39:04 UTC 2019


On 2/2/19 6:55 PM, Eric S. Raymond wrote:
> Richard Laager via devel <devel at ntpsec.org>:
>>>>> Can anyone explain to me a case in which these are not
>>>>> equivalent to expcit port prefixes on a server, ask, re require
>>>>> address?
>>>>
>>>> Because the Proposed RFC says you can ask for an ntpport without
>>>> asking for a ntpd address.
>>>
>>> Cite?  I want to be certain there'a a MUST there before I buy the
>>> complexity.  You have shown some tendency to overinterpret these
>>> things.
>>
>> 4.1.8.  NTPv4 Port Negotiation
>>
>>    The NTPv4 Port Negotiation record has a Record Type number of 7.  Its
>>    body consists of a 16-bit unsigned integer in network byte order,
>>    denoting a UDP port number.
> 
> Why does this imply an option, though?  What is the use case for that
> record?

In the server response, to tell the client which port to use.

In the client's request, to request a particular port.

Why would the client need to request a particular port? Maybe the server
supports multiple ports, but the client wants to use a particular one
for firewall rule reasons.

The way I read it, implication in the spec seems to be that the client
MUST use the returned values. That's actually not well specified, as it
says, "specifies the ... of the NTPv4 with which the client should
associate and which will accept the supplied cookies". First off, that
"should" isn't a "SHOULD", so it's unclear whether that is a real SHOULD
(and thus not a MUST) or just bad spec wording. But the spec makes a
point of saying that "honoring the client's preference is OPTIONAL". So
that explicitly means that the server can ignore the client's
preference. That suggests, but does not conclusively mean, that the
client is supposed to be following the server's decision.

If it is true that the client MUST (or really, even if it SHOULD) honor
the server's response, then to get the port it wants, the client needs
to first request it.

As discussed separately, this isn't needed for first ship, so you can
punt this option until later.

-- 
Richard

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20190202/25c56479/attachment.bin>


More information about the devel mailing list