[ntp:questions] Re: server's address in ntp payload?

Brian Utterback brian.utterback at sun.removeme.com
Wed Nov 23 17:17:44 UTC 2005


Danny Mayer wrote:

> You cannot tell from the outside, nor should you usually care. However,
> with all the stateful firewalls now in place if the response to a packet
> request gets sent from a different address than the address to which the
> packet was originally sent, the firewall will drop it as unmatched to
> the address and the requestor will never receive a response.

Which is a flaw in such a firewall and a violation of RFC 2979. However,
in the case NTP, the protocol is such that a stateful firewall *cannot*
implement a stateful set of rules that would securely allow response
packets from all standard-compliant hosts, since there is no standard 
requirement that UDP packets respond with a source IP the same as the
request's destination IP. There is no transaction ID, so the firewall
has no information that it can use to do this. The XMIT timestamp comes
close and might be used in practice, but is not guaranteed to be unique.
Luckily the reference implementation always responds with that address,
so the question is moot.

This brings up a an interesting question. Is there anywhere in any of
the published or proposed RFC's related to NTP that explicitly states
that NTP requires that the response packet have the same IP source
address as that of the original request packet's destination address?
Or is that merely an artifact of the reference implementation? I
know that the protocol will fail if the addresses do not match, so
there is an implicit requirement, but it ever explicitly stated?

Of course, if there is such a requirement, then that would indeed
be a major layering violation, to my mind.

-- 
blu

"Having them stolen may become our distribution model..."
Nicolas Negroponte on the Hundred Dollar Laptop.
----------------------------------------------------------------------
Brian Utterback - OP/N1 RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom




More information about the questions mailing list