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

Brian Utterback brian.utterback at sun.removeme.com
Mon Nov 21 13:24:39 UTC 2005


You need to keep "what is" and "what could be" straight. When you say 
that something works some particular way, that doesn't mean that is the 
best way of doing it.

Danny Mayer wrote:

 >Brian Utterback wrote:
 >
 >
 >>I agree that the IP address should not be in the NTP header. I do not
 >>know what should be there, just that something should be that acts as
 >>an authentication token of some sort. Almost all other UDP based
 >>protocols include either a token that identifies the system or the
 >>transaction.
 >>
 >>
 >
 >That's the MAC in the NTP packet.
 >
 >

Except that the MAC is not a required field. Nor does it generally 
include a transaction ID.

 >
 >
 >>The ability to send the UDP packet back with the required
 >>IP address on a multihomed host is not even guaranteed, since such
 >>an ability is only in the SHOULD category and is not in the MUST
 >>category in RFC 1123.
 >>
 >>
 >>
 >
 >That has nothing to do with it. If you get a packet arriving from a
 >different address you should assume it's a different server and will be
 >considered unauthenticated until the authentication is established.
 >
 >

That's a "is", not a "could be". Why should you assume that it is from a 
different host and not the same host on a different interface? You are 
assuming the that which is to be proved, namely that the IP address is a 
good authentication token.

 >
 >
 >>>>been the case that it is easy to get the address from whence a UDP
 >>>>was sent, but there is no portable way to determine to where it was
 >>>>bound.
 >>>>
 >>>>
 >>>
 >>>You can use sendmsg/recvmsg to do this but it's not implemented on all
 >>>platforms and I declined to work all the issues necessary to use it.
 >>>
 >>>
 >>Precisely. There is no portable way to get the IP destination. Why do
 >>you think that is? It's because no reasonable application that is not
 >>dealing in network control itself should need need to know it.
 >>
 >>
 >>
 >
 >It's done in BIND 9, but it would be a challenge in NTP and much more
 >difficult than rewriting the interface code.
 >
 >

I am not sure what the "It" is here. In all platforms, it is trivial to 
find the source address of an incoming UDP packet. Otherwise sending a 
reply would be impossible. However, it has only recently become easy on 
some platforms and remains difficult to impossible on others. This is 
because it is not necessary for most reasonably designed UDP protocols.
Even if you wanted to use the IP for authentication, which I still think 
is a bad thing, you only need to find the source address and not the 
destination. If the MAC is not in use, the IP address will not save you 
from a man-in-the-middle attack, and if the MAC is in use, then the IP 
addresses are irrelevant.

 >
 >
 >>>
 >>>
 >>>>This has led to the super-kludge of binding to all IP addresses
 >>>>on the system as being the best of a bad lot.
 >>>>
 >>>>
 >>>>
 >
 >No, that has nothing to do with it. The binding of all IP addresses is
 >deliberate and has to do with security and to prevent other applications
 >binding to the NTP port.
 >
 >
 >
 >>>Not at all. There are a number of reasons to bind all of the IP
 >>>addresses individually.  It's true in BIND too. In NTP it's even more
 >>>important to bind all addresses since that means another application
 >>>cannot be using the NTP port. You don't want another application setting
 >>>the clock or sending out its own spurious packets.
 >>>
 >>>
 >>I do not know why BIND does it, but my guess is that it  needs
 >>to know what interface a packet arrived on. The whole "grab it
 >>so nobody else can" thing is pretty bogus. It is a complete non-issue
 >>on any UNIX based system. I know you deal with the Windows port,
 >>and I couldn't say what the ramifications on that platform might
 >>be, even there, having an auth token in the NTP header would solve
 >>the problem without binding to all the interfaces.
 >>
 >>
 >>
 >
 >No it isn't bogus and is definitely not a non-issue on any Unix based
 >system. Windows is no different. You ignore the MAC header.
 >
 >

Explain to me why it is necessary to bind all the addresses on a system 
with a UNIX privilege model. I can not see any scenario where it stops 
any threat for port 123. For ports above 1024, I know of some issues, 
which is why Solaris added the EXCL_BIND socket option. But as I said, 
it is a non-issue on UNIX systems for port 123.

 >
 >
 >>>You MUST guarantee
 >>>that you return packets ONLY on the same address that the requester
 >>>packet was sent to, you must do authentication using only one address
 >>>and only accept packets between those two addresses that you can
 >>>validate once you have an agreed-upon authentication.
 >>>
 >>>
 >>That is my whole point. It is only because you rely on the IP address
 >>for authentication that you have all of these "MUST" requirements. That
 >>is the flaw.
 >>
 >>
 >>
 >
 >No, you must assume it's a different system sending the packet any other
 >address and must authenticate again.
 >
 >

Why must you assume it? This is an "Is" again and not a could be.

 >Danny
 >
 >


-- 
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