Brian Utterback wrote: > 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.
You cannot violate an informational RFC which 2979 is. Furthermore it appears to only discuss TCP and it's layered protocols which NTP isn't. I happen to know Jeff Mogul who wrote screend who told me once that he wrote it in a weekend for TCP only, but that UDP was a much more difficult problem because it is stateless. The best a firewall can do is remember a request going out to a specific IP address and port and look for a response from that IP address and port. > 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. > See above. > 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? I don't believe so. That's a question for the NTP WG. > 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? > The NTP protocol won't fail if it doesn't match, but it may not be able to relate to any previous information that it had about that server. Don't forget that ntpd is collection information for statistical purposes so that it can examine the reliability of the server to provide time. Yes a unique refid would help there, but that is not currently working. > Of course, if there is such a requirement, then that would indeed > be a major layering violation, to my mind. > No, but there is loss of information. It is important to be able to match what went out with what got returned. DNS packets include a serial number so that the DNS server can match the request with where to send the response. NTP doesn't really need it as the NTP packet is consumed locally. Danny _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
