Re: Source address in response always the same as target address in request?

Brian,

You say "until recently"; NTP has been intimate with Unix since the early 1980s. Is this recent?

Second and more importantly, if the address is not used to bind a request to a reply, what else can replace it?

Why do you have 300 sockets bound to an interface with a stateless protocol? This appears to be a fundamental violation of the stateless paradigm.

Dave

Brian Utterback wrote:

Perhaps proper, but ill-advised. Look at the trouble we have
had trying to satisfy that requirement. I am sitting at a
system that currently has over 300 UDP ports in use. Exactly
one of those UDP ports is bound on each interface, namely 123.
Interestingly, it is also bound twice on the wildcard address
as well.

Until recently, it wasn't possible in a portable manner, for
a process to listen on a UDP port, receive a request and
then issue a reply with the reply's source address guaranteed
to be the same as the request's destination address. And
virtually all UDP protocols had a way to deal with it, except
NTP.


Danny Mayer wrote:

Brian,

UDP is stateless. There is absolutely no way that the UDP protocol
developers could require that that a reply go back to the same address
from which the packet was sent or that it be sent from the same IP
address. No reply is ever required of a datagram. It would be a protocol
layering violation to do so. The NTP protocol requirement is proper in
this context.

Danny

Brian Utterback wrote:

I beg to differ. Most UDP based protocols do not have this requirement.
If they did, it would not be the case that in the (mumble mumble) years
since the invention of the UDP protocol and the sockets interface,
that the interface even provided the ability for the application to
to do this within the interface within the last few years.

The UDP protocol itself has no such requirement. Although the
Hosts requirements RFC says that a host SHOULD provide a mechanism
to do it, until IPv6 came along, few systems actually did. The
only way to guarantee it was using the awful "bind every interface"
trick that the reference implementation uses.

The "RPC protocol" itself (RFC 1050) does not have this requirement.

I do not know why the original designers of UDP did not include this
requirement. I suspect they did not foresee the security requirements
we have today. Or perhaps they had a good reason. But in any case the
NTPv3 spec does not have the requirement in it. If I recall correctly,
the NTPv4 spec does have the requirement, but I also recall commenting
on this ages ago, comments that were ignored.

I don't disagree that UDP should have the requirement, but it does not,
and as such I do object to gratuitously adding the requirement to NTP,
which has complicated the code base to no end.

Of course, as I said above, it is now possible to implement this cleanly
on many OS's, which would allow us to simplify the code immensely. But
until such support is universal, that won't happen.

Brian


David L. Mills wrote:

Guys,

In both the NTPv4 specification and reference implementation the destination address used by the client when mobilizeing the association and sending the request must match the source address when receiving the response. This is a property of all RPC protocols known to me that use addresses to match requests with responses. This is so obvious a requirement that maybe the specification doesn't make it clear enough.

Dave

Brian Utterback wrote:

guuwwe@xxxxxxxxxxx wrote:


Are there any clear requirements in NTP/SNTP RFC docs about the UDP
source address in
all responses the same as the UDP target address in the original
requests?
I doubt it would be a UDP requirement because this is domain of upper
protocols.

Yes and no. The basic protocol does not require it. The reference
implementation does require it. The Autokey crypto authentication
scheme currently requires it, but there has been some discussion
recently about the nature of that requirement and whether it could
be relaxed, but I don't see that discussion going anywhere in this
regard.

Brian Utterback

_______________________________________________
questions mailing list
questions@xxxxxxxxxxxxx
https://lists.ntp.org/mailman/listinfo/questions



.

Relevant Pages