Hello all

I have take a look at ntp_request.h and I found that ntp doesn't put the the ip
address of the remote server being used in the request. That is, in the
ntp payload you can obtain the addresses of the peers and reference clocks of the
server but not the address of the server itself, and therefore the only way
to get the address of the server is looking at the IP header.

Am I wrong?

Thanks in advance

	Ulisses

                Debian GNU/Linux: a dream come true
-----------------------------------------------------------------------------
"Computers are useless. They can only give answers."            Pablo Picasso

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

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

Ulisses wrote:
> Hello all
> 
> I have take a look at ntp_request.h and I found that ntp doesn't put the the ip
> address of the remote server being used in the request. That is, in the
> ntp payload you can obtain the addresses of the peers and reference clocks of the
> server but not the address of the server itself, and therefore the only way
> to get the address of the server is looking at the IP header.
> 
> Am I wrong?

You are correct, that is a flaw in the protocol design. It has always
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. This has led to the super-kludge of binding to all IP addresses
on the system as being the best of a bad lot.

As one security guru recently said, "authentication based on IP address
is sooo 1980's"

-- 
blu

Remember when SOX compliant meant they were both the same color?
----------------------------------------------------------------------
Brian Utterback - OP/N1 RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom

Ulisses wrote:
> Hello all
> 
> I have take a look at ntp_request.h and I found that ntp doesn't put the the ip
> address of the remote server being used in the request. That is, in the
> ntp payload you can obtain the addresses of the peers and reference clocks of the
> server but not the address of the server itself, and therefore the only way
> to get the address of the server is looking at the IP header.
> 
> Am I wrong?
> 

No you are not wrong, but why would you want to? Are you asking about
the server sending the packet? We already know the IP address of the
sending server. The recvfrom() code returns that information so you need
not explicitly look at the header, recvfrom does that implicitly.

Danny

> Thanks in advance
> 
> 	Ulisses
> 
>                 Debian GNU/Linux: a dream come true
> -----------------------------------------------------------------------------
> "Computers are useless. They can only give answers."            Pablo Picasso
> 
> "Debugging is twice as hard as writing the code in the first place.
> Therefore, if you write the code as cleverly as possible, you are,
> by definition, not smart enough to debug it." - Brian W. Kernighan
> 
> _______________________________________________
> questions mailing list
> questions@lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions
> 

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

Brian Utterback wrote:
> Ulisses wrote:
> 
>> Hello all
>>
>> I have take a look at ntp_request.h and I found that ntp doesn't put
>> the the ip
>> address of the remote server being used in the request. That is, in the
>> ntp payload you can obtain the addresses of the peers and reference
>> clocks of the
>> server but not the address of the server itself, and therefore the
>> only way
>> to get the address of the server is looking at the IP header.
>>
>> Am I wrong?
> 
> 
> You are correct, that is a flaw in the protocol design.

No it is not a flaw in the protocol design. It would be if it were put
in. The address doesn't belong there, it belongs in the IP header which
the receiving server always gets.

 It has always
> 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.

> This has led to the super-kludge of binding to all IP addresses
> on the system as being the best of a bad lot.
> 

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. You MUST guarantee
that you return packets ONLY on the same address that the requestor
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.


> As one security guru recently said, "authentication based on IP address
> is sooo 1980's"
> 

It's not BASED on the IP address, it just doesn't allow authentication
between two nodes to change IP addresses once a node has been
authenticated. A packet from a different IP address is considered
unauthenticated until the authentication is done.

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

Hello Danny

On Thu, Nov 17, 2005 at 09:29:17PM -0500, Danny Mayer wrote:
> Ulisses wrote:
> > Hello all
[...]
> No you are not wrong, but why would you want to? 

The usefulness I wanted with it is to try getting the
loopback address of ntp servers running on routers

(for good purposes)

Also It would be useful if I could extract from ntp, any 
Globally Unique Identifier I could get from NTP protocol that
could identify the same ntpd process in a multi-homed router.

The only reliable way to achieve it I have figured out is 
(more or less) to extract the ntp stats and compare them when 
possible

> Are you asking about the server sending the packet? 

 Host A                         Host B (Router)

                     query
ntpdc/ntpq/ntpd --------------> ntpd
                <-------------
                     reply

I want to know from Host A, the address of Host B looking an ntp header

> We already know the IP address of the
> sending server. The recvfrom() code returns that information so you need
> not explicitly look at the header, recvfrom does that implicitly.

As you can see, that is not my question

Thanks so much for your comments

	Ulisses

                Debian GNU/Linux: a dream come true
-----------------------------------------------------------------------------
"Computers are useless. They can only give answers."            Pablo Picasso

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

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

Danny Mayer wrote:

 >
 > No it is not a flaw in the protocol design. It would be if it were put
 > in. The address doesn't belong there, it belongs in the IP header which
 > the receiving server always gets.


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


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

 >
 >
 >>This has led to the super-kludge of binding to all IP addresses
 >>on the system as being the best of a bad lot.
 >>
 >
 >
 > 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.

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


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

Ulisses wrote:
> Hello Danny
> 
> On Thu, Nov 17, 2005 at 09:29:17PM -0500, Danny Mayer wrote:
> 
>>Ulisses wrote:
>>
>>>Hello all
> 
> [...]
> 
>>No you are not wrong, but why would you want to? 
> 
> 
> The usefulness I wanted with it is to try getting the
> loopback address of ntp servers running on routers
> 

That's confusing me. Do you really mean the loopback addresss -
127.0.0.1 and ::1 or did you mean an address bound to the interface?

> (for good purposes)
> 
> Also It would be useful if I could extract from ntp, any 
> Globally Unique Identifier I could get from NTP protocol that
> could identify the same ntpd process in a multi-homed router.
> 

There nearest thing to an identifier is the refid. Unfortunately it's
flawed in the NTP reference implmentation since you can get different
refid's from different addresses on the machine.

> The only reliable way to achieve it I have figured out is 
> (more or less) to extract the ntp stats and compare them when 
> possible
> 
> 
>>Are you asking about the server sending the packet? 
> 
> 
>  Host A                         Host B (Router)
> 
>                      query
> ntpdc/ntpq/ntpd --------------> ntpd
>                 <-------------
>                      reply
> 
> I want to know from Host A, the address of Host B looking an ntp header
> 

I don't understand. Are you asking that, sitting at Host A, you send a
packet to host B and then you get in the response the address that Host
B sees as receiving the request from?

The answer is that it's the address of the interface receiving the
packet. There was a bug, long since fixed, which resulted in a packet
being returned to a different address.


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

Hi Danny

On Fri, Nov 18, 2005 at 09:24:34AM -0500, Danny Mayer wrote:
> Ulisses wrote:
[...]
> > The usefulness I wanted with it is to try getting the
> > loopback address of ntp servers running on routers
> > 
> 
> That's confusing me. Do you really mean the loopback addresss -
> 127.0.0.1 and ::1 or did you mean an address bound to the interface?

many (all?) routers wich run a routing protocol have an special address
that's called "loopback address" which is not 127.0.0.1

I wanted to check what address returned the ntp process on routers 
(if it was possible) in the ntp header, in hope to obtain the
loopback address I mention.

[...]

> There nearest thing to an identifier is the refid. Unfortunately it's
> flawed in the NTP reference implmentation since you can get different
> refid's from different addresses on the machine.

ok

Thanks for your comments

	Ulisses

PD: I did not reply the rest of the e-mail because I suposse it is clear now

                Debian GNU/Linux: a dream come true
-----------------------------------------------------------------------------
"Computers are useless. They can only give answers."            Pablo Picasso

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

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

Guys,

I have no idea what's going on here. The only reason the reference ID is 
in the NTP header in the first place is to detect and avoid timing 
loops. While it was found useful for traceback purposes in IPv4, it 
doesn't work for IPv6, as it is only a hash.

The reference ID is not different for different addresses. It reflects 
the source of timing only, and that is the same for all interfaces on 
the same machine.

The Autokey scheme is bound to the IP addresses only for the cookie 
calculation, which must be the same on the endpoint machines. The 
security flow does not depend on the addresses, only the certificate 
trail and group key. That this doesn't work with NAT is a valuable and 
carefully treasured feature.

Dave

Ulisses wrote:
> Hi Danny
> 
> On Fri, Nov 18, 2005 at 09:24:34AM -0500, Danny Mayer wrote:
> 
>>Ulisses wrote:
> 
> [...]
> 
>>>The usefulness I wanted with it is to try getting the
>>>loopback address of ntp servers running on routers
>>>
>>
>>That's confusing me. Do you really mean the loopback addresss -
>>127.0.0.1 and ::1 or did you mean an address bound to the interface?
> 
> 
> many (all?) routers wich run a routing protocol have an special address
> that's called "loopback address" which is not 127.0.0.1
> 
> I wanted to check what address returned the ntp process on routers 
> (if it was possible) in the ntp header, in hope to obtain the
> loopback address I mention.
> 
> [...]
> 
> 
>>There nearest thing to an identifier is the refid. Unfortunately it's
>>flawed in the NTP reference implmentation since you can get different
>>refid's from different addresses on the machine.
> 
> 
> ok
> 
> Thanks for your comments
> 
> 	Ulisses
> 
> PD: I did not reply the rest of the e-mail because I suposse it is clear now
> 
>                 Debian GNU/Linux: a dream come true
> -----------------------------------------------------------------------------
> "Computers are useless. They can only give answers."            Pablo Picasso
> 
> "Debugging is twice as hard as writing the code in the first place.
> Therefore, if you write the code as cleverly as possible, you are,
> by definition, not smart enough to debug it." - Brian W. Kernighan
> 
> _______________________________________________
> questions mailing list
> questions@lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions
> 

"Danny Mayer" <mayer@gis.net> wrote in message 
news:437D4371.2090004@gis.net...

> No it is not a flaw in the protocol design. It would be if it were put
> in. The address doesn't belong there, it belongs in the IP header which
> the receiving server always gets.

    It is a flaw. Its absence requires the receiver to assume that the 
origin address of the UDP packet received is the IP address of the sending 
server. This assumption may or may not be correct. But if the address were 
in there, the assumption would not be needed.

    DS

David,

I beg to differ. The session key is a hash of the endpoint addresses, 
key identifier (which changes with every packet) and server private 
seed. The terrorist cannot predict the hash and cannot fake any field or 
guess the server private seed, which changes on a daily basis. Session 
keys are unpredictable, can't be faked and used only once. Replays of 
old keys are detected and discarded. Session keys are cryptographical 
bound to a signed certificate trail and group key.

Dave

David Schwartz wrote:

> "Danny Mayer" <mayer@gis.net> wrote in message 
> news:437D4371.2090004@gis.net...
> 
> 
>>No it is not a flaw in the protocol design. It would be if it were put
>>in. The address doesn't belong there, it belongs in the IP header which
>>the receiving server always gets.
> 
> 
>     It is a flaw. Its absence requires the receiver to assume that the 
> origin address of the UDP packet received is the IP address of the sending 
> server. This assumption may or may not be correct. But if the address were 
> in there, the assumption would not be needed.
> 
>     DS
> 
> 

Brian Utterback wrote:
> Danny Mayer wrote:
> 
>>
>> No it is not a flaw in the protocol design. It would be if it were put
>> in. The address doesn't belong there, it belongs in the IP header which
>> the receiving server always gets.
> 
> 
> 
> 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.

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

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

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

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

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

Ulisses wrote:
> Hi Danny
> 
> On Fri, Nov 18, 2005 at 09:24:34AM -0500, Danny Mayer wrote:
> 
>>Ulisses wrote:
> 
> [...]
> 
>>>The usefulness I wanted with it is to try getting the
>>>loopback address of ntp servers running on routers
>>>
>>
>>That's confusing me. Do you really mean the loopback addresss -
>>127.0.0.1 and ::1 or did you mean an address bound to the interface?
> 
> 
> many (all?) routers wich run a routing protocol have an special address
> that's called "loopback address" which is not 127.0.0.1
> 
> I wanted to check what address returned the ntp process on routers 
> (if it was possible) in the ntp header, in hope to obtain the
> loopback address I mention.
> 

If you want this done in ntpd then it does everything it has to. If you
just want to do this on your own, read the UDP header.

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

David Schwartz wrote:
> "Danny Mayer" <mayer@gis.net> wrote in message 
> news:437D4371.2090004@gis.net...
> 
> 
>>No it is not a flaw in the protocol design. It would be if it were put
>>in. The address doesn't belong there, it belongs in the IP header which
>>the receiving server always gets.
> 
> 
>     It is a flaw. Its absence requires the receiver to assume that the 
> origin address of the UDP packet received is the IP address of the sending 
> server. This assumption may or may not be correct. But if the address were 
> in there, the assumption would not be needed.
> 

Absolutely not. That would be a layering violation. Verification is done
through key exchange and the MAC section in the NTP packet.

Danny
>     DS
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Danny Mayer wrote:
> David Schwartz wrote:
> 
>>"Danny Mayer" <mayer@gis.net> wrote in message 
>>news:437D4371.2090004@gis.net...
>>
>>
>>
>>>No it is not a flaw in the protocol design. It would be if it were put
>>>in. The address doesn't belong there, it belongs in the IP header which
>>>the receiving server always gets.
>>
>>
>>    It is a flaw. Its absence requires the receiver to assume that the 
>>origin address of the UDP packet received is the IP address of the sending 
>>server. This assumption may or may not be correct. But if the address were 
>>in there, the assumption would not be needed.
>>
> 
> 
> Absolutely not. That would be a layering violation. Verification is done
> through key exchange and the MAC section in the NTP packet.

If that is a layering violation, then why do you need to know both the
source and destination address of each NTP packet to authenticate it?


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

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

"Danny Mayer" <mayer@gis.net> wrote in message 
news:4380AF66.1080007@gis.net...

> David Schwartz wrote:

>> "Danny Mayer" <mayer@gis.net> wrote in message
>> news:437D4371.2090004@gis.net...

>>>No it is not a flaw in the protocol design. It would be if it were put
>>>in. The address doesn't belong there, it belongs in the IP header which
>>>the receiving server always gets.

>>     It is a flaw. Its absence requires the receiver to assume that the
>> origin address of the UDP packet received is the IP address of the 
>> sending
>> server. This assumption may or may not be correct. But if the address 
>> were
>> in there, the assumption would not be needed.

> Absolutely not. That would be a layering violation.

    What would be a layering violation? Assuming that the source address of 
a UDP packet is the address of the machine that sent it?

> Verification is done
> through key exchange and the MAC section in the NTP packet.

    That's nice but has nothing to do with how you tell whether two packets 
with different source UDP addresses came from the same server or not.

    Consider a simple case. We have a simple server that is not using 
authentication. It's on a LAN where a lot of machines have both public and 
private IP addresses. We recognize our local and internal LANs by their IP 
range and don't need to authenticate because spoof protection is done at the 
boundaries. We are talking to both 192.168.32.23 and 216.105.54.22, the 
question is, are they the same machine or not?

    DS

Brian Utterback wrote:
> Danny Mayer wrote:
> 
>> David Schwartz wrote:
>>
>>> "Danny Mayer" <mayer@gis.net> wrote in message
>>> news:437D4371.2090004@gis.net...
>>>
>>>
>>>
>>>> No it is not a flaw in the protocol design. It would be if it were put
>>>> in. The address doesn't belong there, it belongs in the IP header which
>>>> the receiving server always gets.
>>>
>>>
>>>
>>>    It is a flaw. Its absence requires the receiver to assume that the
>>> origin address of the UDP packet received is the IP address of the
>>> sending server. This assumption may or may not be correct. But if the
>>> address were in there, the assumption would not be needed.
>>>
>>
>>
>> Absolutely not. That would be a layering violation. Verification is done
>> through key exchange and the MAC section in the NTP packet.
> 
> 
> If that is a layering violation, then why do you need to know both the
> source and destination address of each NTP packet to authenticate it?
> 

I refer you to the autokey protocol.

Danny



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

Brian Utterback wrote:
> 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.
> 

I do. There are lots of things that I would like, but I don't get.
Frequently I find I can't do things the way I want because of the freeky
way some O/S has implemented something. I then end up having to kludge
up something just for that O/S. Windows isn't the only one with issues
like this.

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

In which case you can't authenticate and you don't need anything special.

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

We follow the rule: "Be liberal about what you receive, be strict about
what you return." The same goes for "how." The IP address is not an
authentication token at all. If you want a really in depth discussion of
the difference between identifiers and IP address, look at the
discussion currently raging in int-area@ietf.org. You may find it
illuminating.


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

Here you need to read the autokey protocol. The addresses are used to
create keys which change every exchange and prevents MIM attacks.

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

That's not true. Any application in the startup or that gains root
privilege can potentially bind to port 123 on any address. It's bad to
make assumptions on what happens to a system under attack or just
accidentally. I've lost count of the number of times that people end up
running two copies of ntpd on a system not realising that they are.

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

Because there is no way of knowing otherwise. If there is an identifier
in the protocol, there is no guarantee that it hasn't been spoofed by an
attacker. Normally configured systems will always send out on the same
address. If they are not normally configured you should authenticate on
the new address as well. Otherwise it may be a MIM attack.

Danny

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

David Schwartz wrote:
> "Danny Mayer" <mayer@gis.net> wrote in message 
> news:4380AF66.1080007@gis.net...
> 
> 
>>David Schwartz wrote:
> 
> 
>>>"Danny Mayer" <mayer@gis.net> wrote in message
>>>news:437D4371.2090004@gis.net...
> 
> 
>>>>No it is not a flaw in the protocol design. It would be if it were put
>>>>in. The address doesn't belong there, it belongs in the IP header which
>>>>the receiving server always gets.
> 
> 
>>>    It is a flaw. Its absence requires the receiver to assume that the
>>>origin address of the UDP packet received is the IP address of the 
>>>sending
>>>server. This assumption may or may not be correct. But if the address 
>>>were
>>>in there, the assumption would not be needed.
> 
> 
>>Absolutely not. That would be a layering violation.
> 
> 
>     What would be a layering violation? Assuming that the source address of 
> a UDP packet is the address of the machine that sent it?
> 

No, adding the source address to the NTP packet.
> 
>>Verification is done
>>through key exchange and the MAC section in the NTP packet.
> 
> 
>     That's nice but has nothing to do with how you tell whether two packets 
> with different source UDP addresses came from the same server or not.
> 
>     Consider a simple case. We have a simple server that is not using 
> authentication. It's on a LAN where a lot of machines have both public and 
> private IP addresses. We recognize our local and internal LANs by their IP 
> range and don't need to authenticate because spoof protection is done at the 
> boundaries. We are talking to both 192.168.32.23 and 216.105.54.22, the 
> question is, are they the same machine or not?
> 

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.

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

"Danny Mayer" <mayer@ntp.isc.org> wrote in message 
news:43837586.5000403@ntp.isc.org...

> David Schwartz wrote:

>>     That's nice but has nothing to do with how you tell whether two 
>> packets
>> with different source UDP addresses came from the same server or not.

>>     Consider a simple case. We have a simple server that is not using
>> authentication. It's on a LAN where a lot of machines have both public 
>> and
>> private IP addresses. We recognize our local and internal LANs by their 
>> IP
>> range and don't need to authenticate because spoof protection is done at 
>> the
>> boundaries. We are talking to both 192.168.32.23 and 216.105.54.22, the
>> question is, are they the same machine or not?

> You cannot tell from the outside, nor should you usually care.

    You should care. If you think they're two different servers, you may 
give the time data double the weight it really should get.

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

    That's not relevent to my example, wherein you have two addresses, 
queries to either of which elicit responses from that same address. The 
question is whether it's the same server twice, or not.

    I have seen NTP sync to the same server twice on two different IP 
addresses. So if there is a unique identifier that NTP could use to ignore 
duplicates, it doesn't use it as far as I've seen.

    DS

Danny Mayer wrote:
> Brian Utterback wrote:

>>If that is a layering violation, then why do you need to know both the
>>source and destination address of each NTP packet to authenticate it?
>>
> 
> 
> I refer you to the autokey protocol.
> 

Circular reasoning again. This is a "what is" argument. Couldn't the
autokey protocol be redesigned not to rely on the IP addresses?

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

Danny Mayer wrote:
> Brian Utterback wrote:

>>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.
>>
> 
> 
> That's not true. Any application in the startup or that gains root
> privilege can potentially bind to port 123 on any address. It's bad to
> make assumptions on what happens to a system under attack or just
> accidentally. I've lost count of the number of times that people end up
> running two copies of ntpd on a system not realising that they are.

That you can start up two NTP processes is a flaw in NTP not a need
to bind all the addresses. NTP could and should detect this even if
only the wildcard address is bound.

Sure, any application that is running as root could bind port 123.
What scenario do you envision where a root process accidentally
binds a specific interface address to port 123 and does not bind
the port to the wildcard address? If you are talking about a deliberate
such binding, then since the process is root, binding all the interfaces
is no protection.

I still see no scenario where binding all the addresses is useful on
UNIX, except to be able to determine the destination address. And of
course, I stil ldo not believe that even this should be necessary.

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

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

"Brian Utterback" <brian.utterback@sun.removeme.com> wrote in message 
news:4384A438.6050108@sun.removeme.com...

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

    I think if you can make the argument that the source address doesn't 
have to match the destination of the query, you can equally well argue that 
the destination address doesn't have to match the source of the query. ;)

    Or, to put it another way, as soon as you layer a request/reply protocol 
on top of UDP, the default presumption would be that the reply MUST have the 
same source as the query's destination and vice-versa.

    DS

Danny Mayer wrote:

> We follow the rule: "Be liberal about what you receive, be strict about
> what you return." The same goes for "how." The IP address is not an
> authentication token at all. If you want a really in depth discussion of
> the difference between identifiers and IP address, look at the
> discussion currently raging in int-area@ietf.org. You may find it
> illuminating.
> 

Okay, I have read the discussion, and it appears to me to argue even 
more for what I am talking about. The base NTP protocol has neither
identifiers nor locators, relying on the IP address for both. Even when
an identifier is added via the crypto functions, it is still tied up
with the IP locator.


> Because there is no way of knowing otherwise. If there is an identifier
> in the protocol, there is no guarantee that it hasn't been spoofed by an
> attacker. Normally configured systems will always send out on the same
> address. If they are not normally configured you should authenticate on
> the new address as well. Otherwise it may be a MIM attack.

I agree. If the response IP changes, then that is an indicator that the
system should be re-authenticated.


My point is that NTP should not require the binding of all addresses.
As I have elsewhere stated, it is not necessary from a security point
of view, i.e. to prevent other processes from stealing the port.
It is sometimes necessary in order to obtain the destination address
of a packet, but that in itself should not be necessary and wouldn't
be if NTP had transaction ID's and/or system ID's.

Let's say we were designing NTP protocol V5. I would include a 
transaction id. Mr. Schwartz would include a system ID. I would
include an "extensions included" flag and make each extension have
a "type" and "length" prefix to get away from the whole "if it this
size then it is a V3 MAC, if it is that size it must be a multiple of
this many bytes" nonsense that we have now.
-- 
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

David Schwartz wrote:

>     I think if you can make the argument that the source address doesn't 
> have to match the destination of the query, you can equally well argue that 
> the destination address doesn't have to match the source of the query. ;)
> 
>     Or, to put it another way, as soon as you layer a request/reply protocol 
> on top of UDP, the default presumption would be that the reply MUST have the 
> same source as the query's destination and vice-versa.

Completely false. Neither RFC 1123 "Requirements for Internet Hosts"
nor RFC 768 "User Datagram Protocol" make any such requirement. RFC 1123
does say that a UDP "SHOULD" be returned with the same source address
as the original destination address, but explicitly does not make that
a "MUST". Further, description of the API for use with UDP in RFC 768
lists the ability to determine the source address of a packet, but does
not list any such ability for the destination, which would be necessary
to accomplish this. The fact that this ability was not listed
and indeed not included in any UDP API until relatively recently should
tell you something about the requirement.

As I have said before, most UDP protocols are designed to handle this
problem. Only UDP protocols that deal with network control and topology
generally have cared about the destination address. The system I am
using has 356 listening UDP ports open right now, and exactly
3 of those have bound all the interfaces: bootps, snmp, and NTP.  Every 
one of the others either does not care or has another mechanism for
handling it, like XIDs. The bootps/DHCP and SNMP need to know the 
destination address in order  for them to respond with the proper 
answers, which is to say the answer is different depending on the 
destination address of the request. What is NTP's excuse?

I would further point out that none of these are bound to all addresses
in order to prevent port hijacking.
-- 
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

"Brian Utterback" <brian.utterback@sun.removeme.com> wrote in message 
news:4384C69A.7090003@sun.removeme.com...

> David Schwartz wrote:

>>     I think if you can make the argument that the source address doesn't 
>> have to match the destination of the query, you can equally well argue 
>> that the destination address doesn't have to match the source of the 
>> query. ;)
>>
>>     Or, to put it another way, as soon as you layer a request/reply 
>> protocol on top of UDP, the default presumption would be that the reply 
>> MUST have the same source as the query's destination and vice-versa.

> Completely false. Neither RFC 1123 "Requirements for Internet Hosts"
> nor RFC 768 "User Datagram Protocol" make any such requirement. RFC 1123
> does say that a UDP "SHOULD" be returned with the same source address
> as the original destination address, but explicitly does not make that
> a "MUST".

    The definition of "SHOULD" is "there may exist valid reasons in 
particular circumstances to ignore this item, but the full implications 
should be understood and the case carefully weighed before choosing a 
different course". Remember that RFC 1123 is not addressing any particular 
request/response protocol. If it said "MUST", it would be impossible for 
particular protocols to override it, which would make no sense at all.

    I am saying the default presumption is that it must be that way but that 
particular protocols can override it. That's effectively what SHOULD means 
in a general description -- done that way unless the specifics of some 
particular case justify doing otherwise.

> Further, description of the API for use with UDP in RFC 768
> lists the ability to determine the source address of a packet, but does
> not list any such ability for the destination, which would be necessary
> to accomplish this. The fact that this ability was not listed
> and indeed not included in any UDP API until relatively recently should
> tell you something about the requirement.

    The description of what API where? RFC 768 contains no API description.

> As I have said before, most UDP protocols are designed to handle this
> problem. Only UDP protocols that deal with network control and topology
> generally have cared about the destination address. The system I am
> using has 356 listening UDP ports open right now, and exactly
> 3 of those have bound all the interfaces: bootps, snmp, and NTP.  Every 
> one of the others either does not care or has another mechanism for
> handling it, like XIDs. The bootps/DHCP and SNMP need to know the 
> destination address in order  for them to respond with the proper answers, 
> which is to say the answer is different depending on the destination 
> address of the request. What is NTP's excuse?

    What is NTP's excuse for what?

> I would further point out that none of these are bound to all addresses
> in order to prevent port hijacking.

    I don't see the relevance.

    DS

David Schwartz wrote:
> "Brian Utterback" <brian.utterback@sun.removeme.com> wrote in message 
> news:4384C69A.7090003@sun.removeme.com...
> 
>> David Schwartz wrote:

>     I am saying the default presumption is that it must be that way but that 
> particular protocols can override it. That's effectively what SHOULD means 
> in a general description -- done that way unless the specifics of some 
> particular case justify doing otherwise.

Oh? Do you know of any OS that does this? Given a multi-homed system, 
the OS will respond with the same IP address in the source address that
was used as the destination address in the request, without application
support when using UDP, no matter which of the possibly many destination
addresses were used? I know Solaris doesn't, and truthfully, I don't
see how it could possibly be done.

The application can do it, if it can determine the destination address.
As I pointed out, only Bootps, SNMP and NTP are doing this, at least on
Solaris. Linux, Solaris and other OS's now have a way to get the
destination address via the socket, but that is a very new feature, and
not generally used. Of course, now that it is available, more might use
it, and it would have been unreasonable had the UDP standard demanded 
it, but it did not, and as such UDP protocols have traditionally 
included methods to work around it.

> 
>> Further, description of the API for use with UDP in RFC 768
>> lists the ability to determine the source address of a packet, but does
>> not list any such ability for the destination, which would be necessary
>> to accomplish this. The fact that this ability was not listed
>> and indeed not included in any UDP API until relatively recently should
>> tell you something about the requirement.
> 
>     The description of what API where? RFC 768 contains no API description.

Sure it does, on page 2, the section labeled "User Interface".

> 
>> As I have said before, most UDP protocols are designed to handle this
>> problem. Only UDP protocols that deal with network control and topology
>> generally have cared about the destination address. The system I am
>> using has 356 listening UDP ports open right now, and exactly
>> 3 of those have bound all the interfaces: bootps, snmp, and NTP.  Every 
>> one of the others either does not care or has another mechanism for
>> handling it, like XIDs. The bootps/DHCP and SNMP need to know the 
>> destination address in order  for them to respond with the proper answers, 
>> which is to say the answer is different depending on the destination 
>> address of the request. What is NTP's excuse?
> 
>     What is NTP's excuse for what?

For binding all the interfaces.

> 
>> I would further point out that none of these are bound to all addresses
>> in order to prevent port hijacking.
> 
>     I don't see the relevance.

This was just an aside to Danny Mayer. Pay no notice.
> 
>     DS
> 
> 


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

blu says:
> Let's say we were designing NTP protocol V5. I would include a transaction
> id. Mr. Schwartz would include a system ID. I would
> include an "extensions included" flag and make each extension have
> a "type" and "length" prefix to get away from the whole "if it this
> size then it is a V3 MAC, if it is that size it must be a multiple of
> this many bytes" nonsense that we have now.

Yay!

H

"Brian Utterback" <brian.utterback@sun.removeme.com> wrote in message 
news:4384D261.4080107@sun.removeme.com...

> David Schwartz wrote:

>> "Brian Utterback" <brian.utterback@sun.removeme.com> wrote in message 
>> news:4384C69A.7090003@sun.removeme.com...
>>
>>> David Schwartz wrote:

>>     I am saying the default presumption is that it must be that way but 
>> that particular protocols can override it. That's effectively what SHOULD 
>> means in a general description -- done that way unless the specifics of 
>> some particular case justify doing otherwise.

> Oh? Do you know of any OS that does this?

    Sure, I do. All of Linux's kernel request/response UDP protocols work 
this way, including NFS-over-UDP.

> Given a multi-homed system, the OS will respond with the same IP address 
> in the source address that
> was used as the destination address in the request, without application
> support when using UDP, no matter which of the possibly many destination
> addresses were used? I know Solaris doesn't, and truthfully, I don't
> see how it could possibly be done.

    If the OS implements a UDP request/response protocol, it should ensure 
the source address of the reply is the destination address of the request 
unless the protocol specifies otherwise. Most OS implementations of UDP 
request/reply protocols *DO* do this.

    You are asking about both OSes and applications in a confusing way that 
seems to be based on the misunderstanding that I'm saying the kernel should 
somehow make an application do the right thing. I'm saying whatever 
implements the request/response protocol over UDP should do the right thing, 
which in most cases is the application, not the kernel.

> The application can do it, if it can determine the destination address.

    Which it can, unless the OS is broken. Do we agree that an OS that makes 
it difficult or impossible for an application to determine the destination 
address of a received UDP datagram is broken?

> As I pointed out, only Bootps, SNMP and NTP are doing this, at least on
> Solaris.

    What do you think the OS has to do with what the applications that 
provide these services do?

> Linux, Solaris and other OS's now have a way to get the
> destination address via the socket, but that is a very new feature, and
> not generally used. Of course, now that it is available, more might use
> it, and it would have been unreasonable had the UDP standard demanded it, 
> but it did not, and as such UDP protocols have traditionally included 
> methods to work around it.

    I'm not sure I understand what you think the point of this is. Is it 
that bad design in the past somehow justifies bad design now? The source and 
destination IP addresses are not internal protocol details -- they're always 
already visible at the application level.

    DS

David Schwartz wrote:
> "Brian Utterback" <brian.utterback@sun.removeme.com> wrote in message
> news:4384D261.4080107@sun.removeme.com...
>
> > David Schwartz wrote:
>
> >> "Brian Utterback" <brian.utterback@sun.removeme.com> wrote in message
> >> news:4384C69A.7090003@sun.removeme.com...
> >>
> >>> David Schwartz wrote:
>
> >>     I am saying the default presumption is that it must be that way but
> >> that particular protocols can override it. That's effectively what SHOULD
> >> means in a general description -- done that way unless the specifics of
> >> some particular case justify doing otherwise.
>
> > Oh? Do you know of any OS that does this?
>
>     Sure, I do. All of Linux's kernel request/response UDP protocols work
> this way, including NFS-over-UDP.
>

[snip]

>     If the OS implements a UDP request/response protocol, it should ensure
> the source address of the reply is the destination address of the request
> unless the protocol specifies otherwise. Most OS implementations of UDP
> request/reply protocols *DO* do this.
>
>     You are asking about both OSes and applications in a confusing way that
> seems to be based on the misunderstanding that I'm saying the kernel should
> somehow make an application do the right thing. I'm saying whatever
> implements the request/response protocol over UDP should do the right thing,
> which in most cases is the application, not the kernel.
>


Right. That is my point. The kernel can easily do this because it has
all
of the necessary information. Protocols implemented in the user space
would have a much more difficult time because there is no standard way
to get this information. I say "would have", because historically they
do
not do it at all. That is to say, UDP was designed (I would guess
deliberately,
but I do not know for sure) not to need this information and the
protocols
implemented using all use another method to match up requests and
responses than by using the IP address.

This is why I say that no OS implements the "SHOULD" as you defined it
from
the host requirements RFC. No OS to my knowledge enforces or provides
this service for the applications automatically. The applications must
provide it
for themselves. Thus as a "host requirement", these OS's fail to
implement the
the requirement, at least for UDP.

[snip]

>     Which it can, unless the OS is broken. Do we agree that an OS that makes
> it difficult or impossible for an application to determine the destination
> address of a received UDP datagram is broken?

No, provisonally. As I noted, some applications do indeed need to have
this info,
so if it is impossible then those applications cannot run. But my point
is that UDP/IP
was not expected to need this information. I would therefore contend
that a protocol
that has this requirement gratuitiously is flawed. Which brings me back
to my question,
since IP does not have this requirement, and UDP does not have this
requirement, is
it the case that NTP explicitly has this requirement. I mean the base
protocol, not the
reference implementation, and even if it does, does it really need it?


[snip]

>     I'm not sure I understand what you think the point of this is. Is it
> that bad design in the past somehow justifies bad design now? The source and
> destination IP addresses are not internal protocol details -- they're always
> already visible at the application level.

My point is that the destination is not always readily visible from the
application
level.  And I do not think that this is a bad design, just not
necessarily intuitively
obvious.

I am reminded of an instance a year or so ago when someone (Harlan?)
suggested
that an error return be added to the ntp_adjtime call if the call
requested a frequency
adjustment greater than the maximum. As it was, requesting a frequency
adjustment
greater than the max is slilently capped at the max.  To anybody
experienced with
software design, this just screamed out for an error return. Except Dr.
Mills screamed
out first. He said that the behavior was/is by design and changing it
as proposed
would invalidate all of the correctness proofs.

It is the same here. It was clearly a design goal of UDP protocols not
to have the requirement. Since there was no such requirement, there was
no need for an API to get the destination address. People at various
times needed the desitnation address for other reasons, or because they
didn't understand this aspect of UDP, so the API was added, which just
means that new UDP protocols forego this aspect entirely and the people
designing them may not even realize that they are changing the way UDP
works.

blu

<brian.utterback@sun.com> wrote in message 
news:1132790855.492030.289600@g49g2000cwa.googlegroups.com...

> This is why I say that no OS implements the "SHOULD" as you defined it
> from
> the host requirements RFC. No OS to my knowledge enforces or provides
> this service for the applications automatically. The applications must
> provide it
> for themselves. Thus as a "host requirement", these OS's fail to
> implement the
> the requirement, at least for UDP.

    This is a nonsensical argument. Kernls *do* in fact do this when they 
provide the UDP based services. They *can't* enforce it for applications 
that provide a service because that is functionality that would have to be 
in the kernel.

>>     Which it can, unless the OS is broken. Do we agree that an OS that 
>> makes
>> it difficult or impossible for an application to determine the 
>> destination
>> address of a received UDP datagram is broken?

> No, provisonally.

    In other words, because kernels have historically been defective in this 
regard and we've been able to make things mostly work, they must not be 
defective.

> As I noted, some applications do indeed need to have
> this info,
> so if it is impossible then those applications cannot run.

    And that's not a kernel defect because ... ?

> But my point
> is that UDP/IP
> was not expected to need this information.

    Because it's always visible to the application. When I send you a UDP 
datagram, I know what address I'm sending it too, and if you need that for 
some reason (say, to reply from the same address), then I can put it in the 
payload. Which gets us back to the subject ... If you're right that it's 
okay for kernels not to provide this information, it's only because the 
sender has the information and can put it in the payload if it's needed.

> I would therefore contend
> that a protocol
> that has this requirement gratuitiously is flawed.

    Right, so NTP is flawed because it does not put the IP address in the 
payload, thus requiring you to get it from the kernel if you need it. (I 
don't agree with your premises, but they lead inexorably to this 
conclusion.)

>>     I'm not sure I understand what you think the point of this is. Is it
>> that bad design in the past somehow justifies bad design now? The source 
>> and
>> destination IP addresses are not internal protocol details -- they're 
>> always
>> already visible at the application level.

> My point is that the destination is not always readily visible from the
> application
> level.  And I do not think that this is a bad design, just not
> necessarily intuitively
> obvious.

    What? How can you send a UDP datagram without knowing what address 
you're sending it to? And when you receive it, you are always told the 
sender's address. So both the source and destination address of a UDP 
datagram are visible from application level. There are *no* layering 
violations here.

> It is the same here. It was clearly a design goal of UDP protocols not
> to have the requirement.

    Huh? It may be a design goal of UDP, but every request/response protocol 
layered over UDP has its own design requirements. UDP always makes both 
addresses visible at application level.

> Since there was no such requirement, there was
> no need for an API to get the destination address. People at various
> times needed the desitnation address for other reasons, or because they
> didn't understand this aspect of UDP, so the API was added, which just
> means that new UDP protocols forego this aspect entirely and the people
> designing them may not even realize that they are changing the way UDP
> works.

    They are not changing the way UDP works. That's absurd.

    DS

David Schwartz wrote:
> "Danny Mayer" <mayer@ntp.isc.org> wrote in message 
> news:43837586.5000403@ntp.isc.org...
> 
> 
>>David Schwartz wrote:
> 
> 
>>>    That's nice but has nothing to do with how you tell whether two 
>>>packets
>>>with different source UDP addresses came from the same server or not.
> 
> 
>>>    Consider a simple case. We have a simple server that is not using
>>>authentication. It's on a LAN where a lot of machines have both public 
>>>and
>>>private IP addresses. We recognize our local and internal LANs by their 
>>>IP
>>>range and don't need to authenticate because spoof protection is done at 
>>>the
>>>boundaries. We are talking to both 192.168.32.23 and 216.105.54.22, the
>>>question is, are they the same machine or not?
> 
> 
>>You cannot tell from the outside, nor should you usually care.
> 
> 
>     You should care. If you think they're two different servers, you may 
> give the time data double the weight it really should get.
> 

If you give more weight to one address over the other then you should
care that it gets sent from the right address and that's what we make
sure we do. So I don't understand your objections.

> 
>     I have seen NTP sync to the same server twice on two different IP 
> addresses. So if there is a unique identifier that NTP could use to ignore 
> duplicates, it doesn't use it as far as I've seen.
> 

That's because of a defect in the implementation of Refids in the
current code. Refids should be the same for all packets sent by the same
server no matter what IP address it uses. I intend to fix that in the
near future where the server will use one and only one refid and it
won't necessarily be based on an IPv4 address. That's a problem with the
specific implementation and not the protocol. One example of this is
that an IPv4 address and an IPv6 address on the same interface will give
you different refids.

Danny
>     DS
> 
> 
> _______________________________________________
> questions mailing list
> questions@lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions
> 


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

Brian Utterback wrote:
> Danny Mayer wrote:
> 
>> Brian Utterback wrote:
> 
> 
>>> If that is a layering violation, then why do you need to know both the
>>> source and destination address of each NTP packet to authenticate it?
>>>
>>
>>
>> I refer you to the autokey protocol.
>>
> 
> Circular reasoning again. This is a "what is" argument. Couldn't the
> autokey protocol be redesigned not to rely on the IP addresses?
> 

I didn't design the autokey protocol and have not reviewed it. However
from what I understand the IP addresses are used as seeds for the
authentication codes and ensure that it only work between two specific
endpoints so MIM attacks are virtually impossible.

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

Brian Utterback wrote:
> Danny Mayer wrote:
> 
>> Brian Utterback wrote:
> 
> 
>>> 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.
>>>
>>
>>
>> That's not true. Any application in the startup or that gains root
>> privilege can potentially bind to port 123 on any address. It's bad to
>> make assumptions on what happens to a system under attack or just
>> accidentally. I've lost count of the number of times that people end up
>> running two copies of ntpd on a system not realising that they are.
> 
> 
> That you can start up two NTP processes is a flaw in NTP not a need
> to bind all the addresses. NTP could and should detect this even if
> only the wildcard address is bound.
> 

No, NTP does not allow you to start two NTP processes as the second one
does not gain access to the ntp port for any address. However, who says
that they have to be the same application? Binding to just the wildcard
addresses does not being a different application cannot bind to a
specific address.

> Sure, any application that is running as root could bind port 123.
> What scenario do you envision where a root process accidentally
> binds a specific interface address to port 123 and does not bind
> the port to the wildcard address? If you are talking about a deliberate
> such binding, then since the process is root, binding all the interfaces
> is no protection.
> 

Actually it should be. If you are saying that more than one application
can share an address, then setting the socket option SO_REUSEADDR to
disallow that is of no value and I would ask why if it were ignored.
Does Solaris ignore this flag?

> I still see no scenario where binding all the addresses is useful on
> UNIX, except to be able to determine the destination address. And of
> course, I stil ldo not believe that even this should be necessary.
> 

I had consulted with someone who is much more of an Internet Security
expert than me and this decision was partly based on his input, but I
did agree with his reasons. I have blind copied him and he will reply if
he chooses to do so.

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

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
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

David Schwartz wrote:

>     This is a nonsensical argument. Kernls *do* in fact do this when they
> provide the UDP based services. They *can't* enforce it for applications
> that provide a service because that is functionality that would have to be
> in the kernel.
>

I never said that matching the addresses shouldn't be done. If the
kernel is
providing remote UDP services, by all means it should make every effort
to match the addresses.

The hosts requirements RFC could have said that the responses MUST
go back on the same address, but it did not. The UDP RFC could also
have made this requirement, but it didn't. The description of the user
interface in the UDP RFC could have specified a way to get the
destination
address, but it didn't. I prefer to think that the orginal designers of
these
protocols and API's gave these issues some thought and decided that
they were not needed, rather than to think that they all got it wrong.

That's just me, though. I would be happy to listen if one of people
came
forward and said that it was a big mistake and explain what they were
thinking and why it turned out to be wrong. I think it was Kernighan
that
said that if he had it to do over again, he would have left the "e" on
the
"creat" call.


>     And that's not a kernel defect because ... ?

Broken by design? Seriously, it clearly seems to be the case that
reading
the destination address was thought unnecessary. And it apppears that
this thought was largely correct.

>     Because it's always visible to the application. When I send you a UDP
> datagram, I know what address I'm sending it too, and if you need that for
> some reason (say, to reply from the same address), then I can put it in the
> payload. Which gets us back to the subject ... If you're right that it's
> okay for kernels not to provide this information, it's only because the
> sender has the information and can put it in the payload if it's needed.
>

Yes, the server application needs to know the source address in order
to
send a reply. That is why the ability to get the source address of a
UDP
packet was specified in the UDP RFC and has been in the API since it
was first implemented.


>     Right, so NTP is flawed because it does not put the IP address in the
> payload, thus requiring you to get it from the kernel if you need it. (I
> don't agree with your premises, but they lead inexorably to this
> conclusion.)

Perhaps. My point is that you might need the IP address, or maybe a
XID is better. Or a unique system ID. Or whatever. I think that your
original problem (identifying duplicate servers) is better served by a
unique system ID than an IP address.



> > My point is that the destination is not always readily visible from the
> > application
> > level.  And I do not think that this is a bad design, just not
> > necessarily intuitively
> > obvious.
>
>     What? How can you send a UDP datagram without knowing what address
> you're sending it to? And when you receive it, you are always told the
> sender's address. So both the source and destination address of a UDP
> datagram are visible from application level. There are *no* layering
> violations here.

The client knows what host it is sending it to, because it is
originating the packet.
The client process probably does not know what the source address of
that packet
is going to be, and probably doesn't care. The server that receives the
packet
knows what the source address is, because that info has always been
made
readily available, since you need it to send the reply, as you noted.
However,
the server process doesn't usually know or care what the destination
address
was. Likewise, when the reply packet is sent, it will set the
destination to match
the orginal source address, but will generally not know or care what
the reply
packet's source address will be. This is how most UDP protocols work.

I just question the need that NTP has to place the further restriction
that the
reply packet source address must match the request packet's destinaton
address.
Maybe it is legitimate, but be careful of chicken and egg reasoning
here. We know
that the crypto ID functions have this requirement, but is it a
legitimate requirement?
By that I mean, could it have been done another way, but used IP
addresses
because nobody thought about the possibility that the IP addresses
might
not match?


> > It is the same here. It was clearly a design goal of UDP protocols not
> > to have the requirement.
>
>     Huh? It may be a design goal of UDP, but every request/response protocol
> layered over UDP has its own design requirements. UDP always makes both
> addresses visible at application level.

Not to the same application. The ability to get the destination address
of a
received packet is a recent addition to the API and is not by any means

universal.  See
http://www.cs.helsinki.fi/linux/linux-kernel/2001-28/0744.html for
a discussion of the most portable way to get the destination address of
a
received UDP packet.


>
>     They are not changing the way UDP works. That's absurd.

Perhaps that isn't exactly the right phrase. Placing expectations on
the
UDP protocol that it is not designed to fulfill, and then designing a
protocol
based on those expectations, and then changing the API and otherwise
jumping through hoops so as to enforce those expectations, that is what

I am talking about.

This isn't really what I wanted to discuss. The bottom line is that UDP
does
not have the requirement that the addresses match. The application can
conform to that requirement if we want it to, but not without some pain
and
suffering. The real questions I have are:

1. Does the NTP protocol (modulo the crypto extensions) really require
that
the addresses match?
2. If it does, is that a flaw, or is it a fundemental result of the
design goals
of NTP?
3. If it is a flaw in the NTP protocol, how could it be repaired?
4. Can the crypto functions be made to work given the answer to
question 3?

Don't get me wrong. I love NTP. It is a master work, and I cannot say
enough
how much I respect the time, effort and innovations that went into its
design.
(Hi, Dave!) But as brilliant as Dr. Mills is, is it not outside the
realm of
possibiltiy that with hindsight, we might not see ways to improve the
protocol.

blu

Guys,

I'm answering Danny's message only because it is short. Bear in mind:

1. The protocol design originated over 25 years ago. There are estimates 
of over 25 million clients on the planet now. Changing the IPv4 refid 
compatibility is simply not in the cards. Certainly it is possible to 
accidently configure two associations with the same server and I have 
done that for test. It may be duplicative, but it is not fatal and does 
not impair good timekeeping.

2. I believe nobody has noticed that NTPv4 autokey extension fields 
contain the association ID of the client, which is returned by the 
server and of course is a transaction ID. If this isn't enough, define a 
new extension field for the purpose.

3. The transmit timestamp is in fact a very good transaction ID, as the 
unused low-order bits are filled with a random bitstring and the 
resulting timestamp is essentially unguessable. It is in fact used as 
the transaction ID to set up manycast client asssociations and has the 
advantage to be useful without autokey. It should include enough bits to 
defy cryptanalysis, yet not require a packet format change. When network 
delays approach 232 picoseconds, this should be reviewed.

4. By design the session key is a hash of some public and some private 
information. When it was designed over ten years ago the intent was to 
nab IP address hijackers, so I included the addresses in the hash. 
Doing without the addresses would be possible, but the resulting session 
key would be cryptographically weak.

5. I am very concerned about rogue broadcasters, which is why the 
broadcaster association ID is included in the extension field and is in 
fact used as a transaction ID. It is possible to do without the IP 
addresses, since the session key is bound by the reverse hash to a 
signature, but the reverse hash itself would be only 64 bits and that 
would ordinarily be considered cryptoanalyzeable.

6. My original and still viable plan was to provide an alternate mode 
where the cookie portion of the session key could be expanded and the IP 
addresses dropped. The cookie already is sliced from a 128-bit hash, so 
this may not be as hard as it looks. However, to avoid using the IP 
addresses, ports and version number for association matching is much 
harder to change.

Dave

Danny Mayer wrote:
> David Schwartz wrote:
> 
>>"Danny Mayer" <mayer@ntp.isc.org> wrote in message 
>>news:43837586.5000403@ntp.isc.org...
>>
>>
>>
>>>David Schwartz wrote:
>>
>>
>>>>   That's nice but has nothing to do with how you tell whether two 
>>>>packets
>>>>with different source UDP addresses came from the same server or not.
>>
>>
>>>>   Consider a simple case. We have a simple server that is not using
>>>>authentication. It's on a LAN where a lot of machines have both public 
>>>>and
>>>>private IP addresses. We recognize our local and internal LANs by their 
>>>>IP
>>>>range and don't need to authenticate because spoof protection is done at 
>>>>the
>>>>boundaries. We are talking to both 192.168.32.23 and 216.105.54.22, the
>>>>question is, are they the same machine or not?
>>
>>
>>>You cannot tell from the outside, nor should you usually care.
>>
>>
>>    You should care. If you think they're two different servers, you may 
>>give the time data double the weight it really should get.
>>
> 
> 
> If you give more weight to one address over the other then you should
> care that it gets sent from the right address and that's what we make
> sure we do. So I don't understand your objections.
> 
> 
>>    I have seen NTP sync to the same server twice on two different IP 
>>addresses. So if there is a unique identifier that NTP could use to ignore 
>>duplicates, it doesn't use it as far as I've seen.
>>
> 
> 
> That's because of a defect in the implementation of Refids in the
> current code. Refids should be the same for all packets sent by the same
> server no matter what IP address it uses. I intend to fix that in the
> near future where the server will use one and only one refid and it
> won't necessarily be based on an IPv4 address. That's a problem with the
> specific implementation and not the protocol. One example of this is
> that an IPv4 address and an IPv6 address on the same interface will give
> you different refids.
> 
> Danny
> 
>>    DS
>>
>>
>>_______________________________________________
>>questions mailing list
>>questions@lists.ntp.isc.org
>>https://lists.ntp.isc.org/mailman/listinfo/questions
>>
> 
> 
> 
> _______________________________________________
> questions mailing list
> questions@lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions
> 

Brian Utterback wrote:
> Danny Mayer wrote:
> 
>> We follow the rule: "Be liberal about what you receive, be strict
>> about what you return." The same goes for "how." The IP address is
>> not an authentication token at all. If you want a really in depth
>> discussion of the difference between identifiers and IP address,
>> look at the discussion currently raging in int-area@ietf.org. You
>> may find it illuminating.
>> 
> 
> Okay, I have read the discussion, and it appears to me to argue even 
> more for what I am talking about. The base NTP protocol has neither 
> identifiers nor locators, relying on the IP address for both. Even
> when an identifier is added via the crypto functions, it is still
> tied up with the IP locator.
> 

There is an identifier: the refid. Unfortunately it's not unique in that
it currently depends on the IP address being used to send the NTP
packet. I should be unique in order to accomplish its purpose of loop
prevention. The refid however can be trivially spoofed, at least without
the MAC section. I don't know what you mean by locator.

> 
>> Because there is no way of knowing otherwise. If there is an
>> identifier in the protocol, there is no guarantee that it hasn't
>> been spoofed by an attacker. Normally configured systems will
>> always send out on the same address. If they are not normally
>> configured you should authenticate on the new address as well.
>> Otherwise it may be a MIM attack.
> 
> 
> I agree. If the response IP changes, then that is an indicator that
> the system should be re-authenticated.
> 
> 
> My point is that NTP should not require the binding of all addresses.
>  As I have elsewhere stated, it is not necessary from a security
> point of view, i.e. to prevent other processes from stealing the
> port. It is sometimes necessary in order to obtain the destination
> address of a packet, but that in itself should not be necessary and
> wouldn't be if NTP had transaction ID's and/or system ID's.
> 

There are two totally separate issues here: 1) security and why it's
worthwhile binding all the addresses; and 2) whether or not binding all
addresses is a useful thing. I have stated that security requires it and
I won't repeat the arguments and also that binding all addresses are
useful for a variety of tasks involving the sockets and that it is
useful to send back on the same address as the one it was received on.

> Let's say we were designing NTP protocol V5. I would include a 
> transaction id. Mr. Schwartz would include a system ID. I would 
> include an "extensions included" flag and make each extension have a
> "type" and "length" prefix to get away from the whole "if it this 
> size then it is a V3 MAC, if it is that size it must be a multiple of
>  this many bytes" nonsense that we have now.

Transaction ID's are only useful to match responses to requests if you
don't otherwise know what the original request was. However, NTP doesn't
need it since the NTP packet already contains all of the information
required and it's not passing on the information to a third system.
System ID's are only useful for loop prevention and the refid fulfils
that role.

Danny


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

David Schwartz wrote:

> 
>>I would therefore contend
>>that a protocol
>>that has this requirement gratuitiously is flawed.
> 
> 
>     Right, so NTP is flawed because it does not put the IP address in the 
> payload, thus requiring you to get it from the kernel if you need it. (I 
> don't agree with your premises, but they lead inexorably to this 
> conclusion.)
> 

As long as you don't receive packets on the wildcard addresses your
response will go out using the same address as the packet was received
on. It's the wildcard addresses that cause the problem and you cannot
know which address the kernel may choose.

Danny


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

"Danny Mayer" <mayer@gis.net> wrote in message 
news:43852DAE.1070905@gis.net...

> I didn't design the autokey protocol and have not reviewed it. However
> from what I understand the IP addresses are used as seeds for the
> authentication codes and ensure that it only work between two specific
> endpoints so MIM attacks are virtually impossible.

> Danny

    Anyone who thinks you can use IP addresses to protect against MIM 
attacks doesn't understand what a MIM attack is. The MIM can certainly spoof 
each end's IP address to the other machine.

    DS

<brian.utterback@sun.com> wrote in message 
news:1132805341.941207.242150@f14g2000cwb.googlegroups.com...

> The hosts requirements RFC could have said that the responses MUST
> go back on the same address, but it did not.

    No, it could not have said that. That would have meant that *no* UDP 
query/response protocol could ever permit a reply to be sent from a 
different address, which would be nonsensical. So what it does, sensibly, is 
say that it SHOULD go back on the same address, which means that there has 
to be a damned good reason (such as the more detailed protocol saying so) 
for it to be different.

> The UDP RFC could also
> have made this requirement, but it didn't.

    Again, no it could not. It would be nonsensical for the UDP protocol to 
impose such a requirement on any protocol that might use it. There's no way 
you can do that. All it could do is say that matching the IP is what you 
should do, unless there's some good reason not to. There is no way it could 
enumerate what the criteria or reasons would be because it's too general an 
RFC to get into those kinds of specifics.

> The description of the user
> interface in the UDP RFC could have specified a way to get the
> destination
> address, but it didn't.

    What description? Where? I don't know what you're talking about.

> I prefer to think that the orginal designers of
> these
> protocols and API's gave these issues some thought and decided that
> they were not needed, rather than to think that they all got it wrong.

    I don't know why you think I have issues with protocols and API. I do 
not. I do, on the other hand, have issues with broken *implementations* of 
protocols and *users* of APIs.

>>     And that's not a kernel defect because ... ?

> Broken by design? Seriously, it clearly seems to be the case that
> reading
> the destination address was thought unnecessary. And it apppears that
> this thought was largely correct.

    Then how can you comply with the SHOULD in the UDP RFC? You understand 
that 'SHOULD' means that you can do otherwise only if you have a damned good 
reason. An API that makes it difficult for protocols to comply with a 
'SHOULD' in an RFC is defecient.

>>     Because it's always visible to the application. When I send you a UDP
>> datagram, I know what address I'm sending it too, and if you need that 
>> for
>> some reason (say, to reply from the same address), then I can put it in 
>> the
>> payload. Which gets us back to the subject ... If you're right that it's
>> okay for kernels not to provide this information, it's only because the
>> sender has the information and can put it in the payload if it's needed.

> Yes, the server application needs to know the source address in order
> to
> send a reply. That is why the ability to get the source address of a
> UDP
> packet was specified in the UDP RFC and has been in the API since it
> was first implemented.

    And the client application needs to know the destination address in 
order to send a query. Thus both IP addresses are already visible at 
application level. Thus, no layering violation.

>>     Right, so NTP is flawed because it does not put the IP address in the
>> payload, thus requiring you to get it from the kernel if you need it. (I
>> don't agree with your premises, but they lead inexorably to this
>> conclusion.)

> Perhaps. My point is that you might need the IP address, or maybe a
> XID is better. Or a unique system ID. Or whatever. I think that your
> original problem (identifying duplicate servers) is better served by a
> unique system ID than an IP address.

    I don't disagree. That's why the RFC says SHOULD rather than MUST.

>> > My point is that the destination is not always readily visible from the
>> > application
>> > level.  And I do not think that this is a bad design, just not
>> > necessarily intuitively
>> > obvious.
>>
>>     What? How can you send a UDP datagram without knowing what address
>> you're sending it to? And when you receive it, you are always told the
>> sender's address. So both the source and destination address of a UDP
>> datagram are visible from application level. There are *no* layering
>> violations here.

> The client knows what host it is sending it to, because it is
> originating the packet.
> The client process probably does not know what the source address of
> that packet
> is going to be, and probably doesn't care. The server that receives the
> packet
> knows what the source address is, because that info has always been
> made
> readily available, since you need it to send the reply, as you noted.
> However,
> the server process doesn't usually know or care what the destination
> address
> was. Likewise, when the reply packet is sent, it will set the
> destination to match
> the orginal source address, but will generally not know or care what
> the reply
> packet's source address will be. This is how most UDP protocols work.

    The point is that both IP addresses are always visible at application 
level.

> I just question the need that NTP has to place the further restriction
> that the
> reply packet source address must match the request packet's destinaton
> address.

    It doesn't have to, provided it gives you some other way to get the 
functionality you lose by not having this. That's why the RFC says 'SHOULD', 
not 'MUST'. But to ignore a SHOULD in an RFC without understanding the 
rationale behind the SHOULD and providing some other way to accomplish what 
the SHOULD is trying to do is reckless.

> Maybe it is legitimate, but be careful of chicken and egg reasoning
> here. We know
> that the crypto ID functions have this requirement, but is it a
> legitimate requirement?
> By that I mean, could it have been done another way, but used IP
> addresses
> because nobody thought about the possibility that the IP addresses
> might
> not match?

    I think using the IP addresses in the crypto code is pretty bone-headed 
anyway, assuming you rely on it in any way. You should use a public key 
identifier, not an IP address. Using it as quick 'which endpoint *might* I 
be talking to' or '*might* this be from the same host I was talking to 
before' is fine. But you should never rely on it.

>> > It is the same here. It was clearly a design goal of UDP protocols not
>> > to have the requirement.

>>     Huh? It may be a design goal of UDP, but every request/response 
>> protocol
>> layered over UDP has its own design requirements. UDP always makes both
>> addresses visible at application level.

> Not to the same application. The ability to get the destination address
> of a
> received packet is a recent addition to the API and is not by any means
> universal.  See
> http://www.cs.helsinki.fi/linux/linux-kernel/2001-28/0744.html for
> a discussion of the most portable way to get the destination address of
> a
> received UDP packet.

    Which application it makes it visible to is irrelevent, the applications 
are talking to each other. Anything visible to application A is visible to 
application B if they are exchanging datagrams.

>>     They are not changing the way UDP works. That's absurd.

> Perhaps that isn't exactly the right phrase. Placing expectations on
> the
> UDP protocol that it is not designed to fulfill, and then designing a
> protocol
> based on those expectations, and then changing the API and otherwise
> jumping through hoops so as to enforce those expectations, that is what
> I am talking about.

    Then why do you think the RFC sets out matching addresses as the default 
for query/response protocols layered on top of UDP? What is your explanation 
for the SHOULD in the RFC? (Which is the strongest possible way they could 
have said it without mandating it absolutely for all UDP query/response 
protocols.)

> This isn't really what I wanted to discuss. The bottom line is that UDP
> does
> not have the requirement that the addresses match. The application can
> conform to that requirement if we want it to, but not without some pain
> and
> suffering. The real questions I have are:

    But it does. That's what 'SHOULD' mean, you have to do it unless you 
have a damned good reason not to. Again, 'SHOULD' means:

   there may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

    Notice it says the full implications must be understood before choosing 
a different course?

    DS

"Danny Mayer" <mayer@ntp.isc.org> wrote in message 
news:43876FE3.1010309@ntp.isc.org...

> David Schwartz wrote:

>>>I would therefore contend
>>>that a protocol
>>>that has this requirement gratuitiously is flawed.

>>     Right, so NTP is flawed because it does not put the IP address in the
>> payload, thus requiring you to get it from the kernel if you need it. (I
>> don't agree with your premises, but they lead inexorably to this
>> conclusion.)

> As long as you don't receive packets on the wildcard addresses your
> response will go out using the same address as the packet was received
> on. It's the wildcard addresses that cause the problem and you cannot
> know which address the kernel may choose.

    Right. RFC1123 says:


         *    "SHOULD"

              This word or the adjective "RECOMMENDED" means that there
              may exist valid reasons in particular circumstances to
              ignore this item, but the full implications should be
              understood and the case carefully weighed before choosing
              a different course.

    and

     When the local host is multihomed, a UDP-based request/response
      application SHOULD send the response with an IP source address
      that is the same as the specific destination address of the UDP
      request datagram.

    What this means is that a UDP-based request/response application must 
send responses with the source address that was the destination in the reply 
unless the full implications of not doing so are understood and the case is 
carefully weighed. Failure to do this is failure to comply with RFC1123. 
RFC1123 states the host *requirements* for being part of the Intenet.

    DS

David,

Lets stop this. My previous message says it all. The issue about 
transaction ID is fully disclosed. There will be no further input from 
me on this issue. If you have substantive input, I am willing to 
participate. Otherwise, I intend to get along with more important issues.
Dave

David Schwartz wrote:
> "Danny Mayer" <mayer@ntp.isc.org> wrote in message 
> news:43876FE3.1010309@ntp.isc.org...
> 
> 
>>David Schwartz wrote:
> 
> 
>>>>I would therefore contend
>>>>that a protocol
>>>>that has this requirement gratuitiously is flawed.
> 
> 
>>>    Right, so NTP is flawed because it does not put the IP address in the
>>>payload, thus requiring you to get it from the kernel if you need it. (I
>>>don't agree with your premises, but they lead inexorably to this
>>>conclusion.)
> 
> 
>>As long as you don't receive packets on the wildcard addresses your
>>response will go out using the same address as the packet was received
>>on. It's the wildcard addresses that cause the problem and you cannot
>>know which address the kernel may choose.
> 
> 
>     Right. RFC1123 says:
> 
> 
>          *    "SHOULD"
> 
>               This word or the adjective "RECOMMENDED" means that there
>               may exist valid reasons in particular circumstances to
>               ignore this item, but the full implications should be
>               understood and the case carefully weighed before choosing
>               a different course.
> 
>     and
> 
>      When the local host is multihomed, a UDP-based request/response
>       application SHOULD send the response with an IP source address
>       that is the same as the specific destination address of the UDP
>       request datagram.
> 
>     What this means is that a UDP-based request/response application must 
> send responses with the source address that was the destination in the reply 
> unless the full implications of not doing so are understood and the case is 
> carefully weighed. Failure to do this is failure to comply with RFC1123. 
> RFC1123 states the host *requirements* for being part of the Intenet.
> 
>     DS
> 
> 

brian.utterback@sun.com wrote:
> The real questions I have are:
> 
> 1. Does the NTP protocol (modulo the crypto extensions) really require
> that
> the addresses match?

No, it's not a protocol requirement except with respect to autokey.

> 2. If it does, is that a flaw, or is it a fundemental result of the
> design goals
> of NTP?

No.

> 3. If it is a flaw in the NTP protocol, how could it be repaired?

No.

> 4. Can the crypto functions be made to work given the answer to
> question 3?
> 
No. The source and destination addresses are an integral part of the
autokey scheme. See the authopt.html page.

Danny

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

David L. Mills wrote:
> Guys,
> 
> I'm answering Danny's message only because it is short. Bear in mind:
> 
> 1. The protocol design originated over 25 years ago. There are estimates
> of over 25 million clients on the planet now. Changing the IPv4 refid
> compatibility is simply not in the cards. Certainly it is possible to
> accidently configure two associations with the same server and I have
> done that for test. It may be duplicative, but it is not fatal and does
> not impair good timekeeping.
> 

Dave, the reason to change the way it currently is defined is that you
frequently have multiple IP addresses and this is even more true with
IPv6 in addition to IPv4 becoming the norm. Choosing any 32-bit number
will do the same job including the first non-loopback IP address as long
as the same ID goes out on all interfaces. There is nothing sacred about
the refid as long as we just treat it as a 32-bit number. Such a number
will interoperate with all previous versions of NTP since it cannot
distinguish an IPv4 address from a hole-in-the-wall otherwise the MD5
hash of IPv6 addresses would never have worked. By making it unique
across all interfaces and addresses that a system services you have
better opportunities to ensure that you are preventing loops. It's the
only real use that I'm aware of.

Danny

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

Brian Utterback wrote:
> David Schwartz wrote:
> 
>>     I think if you can make the argument that the source address
>> doesn't have to match the destination of the query, you can equally
>> well argue that the destination address doesn't have to match the
>> source of the query. ;)
>>
>>     Or, to put it another way, as soon as you layer a request/reply
>> protocol on top of UDP, the default presumption would be that the
>> reply MUST have the same source as the query's destination and
>> vice-versa.
> 
> 
> Completely false. Neither RFC 1123 "Requirements for Internet Hosts"
> nor RFC 768 "User Datagram Protocol" make any such requirement. RFC 1123
> does say that a UDP "SHOULD" be returned with the same source address
> as the original destination address, but explicitly does not make that
> a "MUST". Further, description of the API for use with UDP in RFC 768
> lists the ability to determine the source address of a packet, but does
> not list any such ability for the destination, which would be necessary
> to accomplish this. The fact that this ability was not listed
> and indeed not included in any UDP API until relatively recently should
> tell you something about the requirement.
> 
> As I have said before, most UDP protocols are designed to handle this
> problem. Only UDP protocols that deal with network control and topology
> generally have cared about the destination address. The system I am
> using has 356 listening UDP ports open right now, and exactly
> 3 of those have bound all the interfaces: bootps, snmp, and NTP.  Every
> one of the others either does not care or has another mechanism for
> handling it, like XIDs. The bootps/DHCP and SNMP need to know the
> destination address in order  for them to respond with the proper
> answers, which is to say the answer is different depending on the
> destination address of the request. What is NTP's excuse?

NTP doesn't need an excuse. NTP needs to be careful to ensure that only
one process is modifying the system's clock. Not to do so would result
in clock instability.

I noticed that you didn't mention DNS. None of the mentioned protocols
have a need to worry about other processes doing something on the
system. It's not true of NTP.

> 
> I would further point out that none of these are bound to all addresses
> in order to prevent port hijacking.

None of them have to worry about more than one process taking actions
which could cause problems with the system.

Danny


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

David Schwartz wrote:
> 
>     Anyone who thinks you can use IP addresses to protect against MIM 
> attacks doesn't understand what a MIM attack is. The MIM can certainly spoof 
> each end's IP address to the other machine.
> 
>     DS

You need to understand it's usage within the autokey protocol to
understand that there's a lot more that goes into it than just the IP
addresses. IP addresses are easy to spoof, but the usage within autokey
is not. You are confusing the addresses for their usage within the protocol.

Danny

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

David Schwartz wrote:
> 
>     I think using the IP addresses in the crypto code is pretty bone-headed 
> anyway, assuming you rely on it in any way. You should use a public key 
> identifier, not an IP address. Using it as quick 'which endpoint *might* I 
> be talking to' or '*might* this be from the same host I was talking to 
> before' is fine. But you should never rely on it.
> 

I'm not going to respond to the rest of this as the two of you have
gotten way off topic. The newsgroup is about NTP and not UDP.

The above makes a basic erroneous assumption aout how autokey works. It
doesn't work the way you think. The IP Addresses are just two
ingredients in creating the protocol, not the only ones. You really need
to read how it works before you criticize what it uses.

Danny

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

David Schwartz wrote:
> "Danny Mayer" <mayer@ntp.isc.org> wrote in message 
> news:43876FE3.1010309@ntp.isc.org...
> 
>>As long as you don't receive packets on the wildcard addresses your
>>response will go out using the same address as the packet was received
>>on. It's the wildcard addresses that cause the problem and you cannot
>>know which address the kernel may choose.
> 
> 
>     Right. RFC1123 says:
> 
> 
>          *    "SHOULD"
> 
>               This word or the adjective "RECOMMENDED" means that there
>               may exist valid reasons in particular circumstances to
>               ignore this item, but the full implications should be
>               understood and the case carefully weighed before choosing
>               a different course.
> 
>     and
> 
>      When the local host is multihomed, a UDP-based request/response
>       application SHOULD send the response with an IP source address
>       that is the same as the specific destination address of the UDP
>       request datagram.
> 
>     What this means is that a UDP-based request/response application must 
> send responses with the source address that was the destination in the reply 
> unless the full implications of not doing so are understood and the case is 
> carefully weighed. Failure to do this is failure to comply with RFC1123. 
> RFC1123 states the host *requirements* for being part of the Intenet.


Then you don't understand the paragraph you just quoted. SHOULD is a
recommendation and not a requirement. You cannot violate a
recommendation. You used the word "must" which is not in the section you
quoted.

In any case we do do this.

Danny

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

Danny,

I've said very many times the reference ID is solely and exclusively 
intended to detect timing loops. A server can itself be synchronized to 
only one source and that source is revealed in the reference ID. There 
is no need nor no intent to interpret that field for any other purpose. 
The same reference ID goes out to all clients, regardless of the number 
of interfaces. A client of this server doesn't know whether this is an 
IPv4 or IPv6 address. The well-spoken client can check whether the field 
coincides with (any of) its IPv4 addresses or hashes to (any of) its 
IPv6 addresses, birthdays notwithstanding. There is no need to change 
any aspect of the reference ID as specified in rfc2030 and now implemented.

Dave

Danny Mayer wrote:
> David L. Mills wrote:
> 
>>Guys,
>>
>>I'm answering Danny's message only because it is short. Bear in mind:
>>
>>1. The protocol design originated over 25 years ago. There are estimates
>>of over 25 million clients on the planet now. Changing the IPv4 refid
>>compatibility is simply not in the cards. Certainly it is possible to
>>accidently configure two associations with the same server and I have
>>done that for test. It may be duplicative, but it is not fatal and does
>>not impair good timekeeping.
>>
> 
> 
> Dave, the reason to change the way it currently is defined is that you
> frequently have multiple IP addresses and this is even more true with
> IPv6 in addition to IPv4 becoming the norm. Choosing any 32-bit number
> will do the same job including the first non-loopback IP address as long
> as the same ID goes out on all interfaces. There is nothing sacred about
> the refid as long as we just treat it as a 32-bit number. Such a number
> will interoperate with all previous versions of NTP since it cannot
> distinguish an IPv4 address from a hole-in-the-wall otherwise the MD5
> hash of IPv6 addresses would never have worked. By making it unique
> across all interfaces and addresses that a system services you have
> better opportunities to ensure that you are preventing loops. It's the
> only real use that I'm aware of.
> 
> Danny
> 
> _______________________________________________
> questions mailing list
> questions@lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions
> 

"Danny Mayer" <mayer@ntp.isc.org> wrote in message 
news:4389126F.9030603@ntp.isc.org...

> David Schwartz wrote:

>>     Anyone who thinks you can use IP addresses to protect against MIM
>> attacks doesn't understand what a MIM attack is. The MIM can certainly 
>> spoof
>> each end's IP address to the other machine.

> You need to understand it's usage within the autokey protocol to
> understand that there's a lot more that goes into it than just the IP
> addresses.

    I do.

> IP addresses are easy to spoof, but the usage within autokey
> is not.

    That is a meaningless statement. If you mean that the autokey protocol 
has security that has nothing to do with IP addresses that prevent MIM 
attacks, you would be correct. However, the use of an IP address as a key 
for lookups has nothing to do with autokey's MIM protection.

> You are confusing the addresses for their usage within the protocol.

    No, I'm not. I'm simply saying that the IP address is of no use to 
protect against a MIM. The algorithm would work exactly the same and just as 
well without the IP address. A randomly chosen 32-bit number included in 
every packet would protect against MIM-attacks equally well.

    Part of the point of a MIM attack is to presume that attacker has full 
control over the IP addresses. A randomly-chosen 32-bit integer would do the 
same thing and equally well be under control of the MIM.

    DS

"Danny Mayer" <mayer@ntp.isc.org> wrote in message 
news:43891275.6060702@ntp.isc.org...

> David Schwartz wrote:

>>     I think using the IP addresses in the crypto code is pretty 
>> bone-headed
>> anyway, assuming you rely on it in any way.

    Note the "assuming you rely on it in any way"?

>> You should use a public key
>> identifier, not an IP address. Using it as quick 'which endpoint *might* 
>> I
>> be talking to' or '*might* this be from the same host I was talking to
>> before' is fine. But you should never rely on it.

> I'm not going to respond to the rest of this as the two of you have
> gotten way off topic. The newsgroup is about NTP and not UDP.

    Once an erroneous statement is made in public, it needs to be corrected. 
Especially one that people might rely upon to their serious harm.

> The above makes a basic erroneous assumption aout how autokey works.

    The above is not about how autokey works. That's why I said things like 
"assuming you rely on it any way".

> It
> doesn't work the way you think.

    It does work the way I think. I am not saying there is any defect in the 
autokey protocol.

> The IP Addresses are just two
> ingredients in creating the protocol, not the only ones. You really need
> to read how it works before you criticize what it uses.

    You could replace the IP address with a randomly-chosen 32-bit seed on 
each side and the defense against MIM-attacks would not get any weaker or 
stronger. The claim that you can use IP addresses to protect (or help 
protect) against MIM-attacks is a dangerous falsehood. This is true for 
autokey or any other protocol.

    It has nothing to do with how autokey works. It's this simple -- the MIM 
controls the IP addresses, so they are of no use to protect against the MIM.

    DS

"Danny Mayer" <mayer@ntp.isc.org> wrote in message 
news:4389127A.2030900@ntp.isc.org...

> Then you don't understand the paragraph you just quoted. SHOULD is a
> recommendation and not a requirement. You cannot violate a
> recommendation. You used the word "must" which is not in the section you
> quoted.

    If you simply ignore a SHOULD and don't do what it says by default 
without an evaluation of the consequences, you are ignoring the RFC. The 
definition of "compliance" prohibits ignoring SHOULDs, though it does not 
require you to do what the SHOULD says. Not complying with a SHOULD because 
it requires effort or the API requires an extra bind to do it or the like is 
not compliant.

    DS

David L. Mills wrote:
> Danny,
> 
> I've said very many times the reference ID is solely and exclusively
> intended to detect timing loops. A server can itself be synchronized to
> only one source and that source is revealed in the reference ID. There
> is no need nor no intent to interpret that field for any other purpose.
> The same reference ID goes out to all clients, regardless of the number
> of interfaces. A client of this server doesn't know whether this is an
> IPv4 or IPv6 address. The well-spoken client can check whether the field
> coincides with (any of) its IPv4 addresses or hashes to (any of) its
> IPv6 addresses, birthdays notwithstanding. There is no need to change
> any aspect of the reference ID as specified in rfc2030 and now implemented.
> 
> Dave

Dave,

I admit I haven't read all of the code relating to refids and I should
do so before I continue this debate, but I do want to make sure we get
away from the idea that this really is an IPv4 address rather than an
ID. They are very different concepts. I will be going through this very
carefully as soon as get a breather to review this.

Danny

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

David Schwartz wrote:
> "Danny Mayer" <mayer@ntp.isc.org> wrote in message 
> news:4389126F.9030603@ntp.isc.org...
> 
> 
>>David Schwartz wrote:
> 
> 
>>>    Anyone who thinks you can use IP addresses to protect against MIM
>>>attacks doesn't understand what a MIM attack is. The MIM can certainly 
>>>spoof
>>>each end's IP address to the other machine.
> 
> 
>>You need to understand it's usage within the autokey protocol to
>>understand that there's a lot more that goes into it than just the IP
>>addresses.
> 
> 
>     I do.
> 
I think you don't. In order to be a MIM you need to interfere in one of
three ways: 1) as a source point, 2) in the middle of the key dance, or
3) after the authentication is complete.

1) For the first case, you need the key, otherwise the client won't get
a match. If you have the key, your certificates won't since they are
also signed and the certification will fail.
2) If MIM attacks in the middle, then the authentication will fail since
the algorithm has passed beyond the starting point and you are unlikely
to get right the code in use at that point.
3) If you attack after authentication has been established then you will
fail because you need the right code to return to the sender and it
changes with each exchange.

> 
>>IP addresses are easy to spoof, but the usage within autokey
>>is not.
> 
> 
>     That is a meaningless statement. If you mean that the autokey protocol 
> has security that has nothing to do with IP addresses that prevent MIM 
> attacks, you would be correct. However, the use of an IP address as a key 
> for lookups has nothing to do with autokey's MIM protection.
> 
There's nothing to look up. It's just part of the ingredients.

> 
>>You are confusing the addresses for their usage within the protocol.
> 
> 
>     No, I'm not. I'm simply saying that the IP address is of no use to 
> protect against a MIM. The algorithm would work exactly the same and just as 
> well without the IP address. A randomly chosen 32-bit number included in 
> every packet would protect against MIM-attacks equally well.
> 

Possibly, but by including it, you are requiring that the source
addresss in the packet be agreed upon prior to the exchange requiring
that the MIM spoof the address as well. When MIM fails to send the
correct authentication code, the packet is dropped as it fails
authentication. If it sends it from a different address, it's considered
a new server and has to be authenticated and since it's a different
address it will be ignored as it was not listed as a server address.

>     Part of the point of a MIM attack is to presume that attacker has full 
> control over the IP addresses. A randomly-chosen 32-bit integer would do the 
> same thing and equally well be under control of the MIM.
> 
Which is why it's only used as an indicator and not an identifier of the
source.

Danny

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

David Schwartz wrote:
> "Danny Mayer" <mayer@ntp.isc.org> wrote in message 
> news:4389127A.2030900@ntp.isc.org...
> 
> 
>>Then you don't understand the paragraph you just quoted. SHOULD is a
>>recommendation and not a requirement. You cannot violate a
>>recommendation. You used the word "must" which is not in the section you
>>quoted.
> 
> 
>     If you simply ignore a SHOULD and don't do what it says by default 
> without an evaluation of the consequences, you are ignoring the RFC. The 
> definition of "compliance" prohibits ignoring SHOULDs, though it does not 
> require you to do what the SHOULD says. Not complying with a SHOULD because 
> it requires effort or the API requires an extra bind to do it or the like is 
> not compliant.
> 

You are making the assumption that the consequences were not evaluated.
As I said before, even if you do, it does not violate the RFC since a
SHOULD is not required in any implementation. The fact that we DO
implement it renders the question moot.

Danny

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

David Schwartz wrote:
> 
>     It does work the way I think. I am not saying there is any defect in the 
> autokey protocol.
> 

If it did, then there would be a defect in the autokey protocol.

Danny

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

David L. Mills wrote:
> Guys,
> 
> I'm answering Danny's message only because it is short. Bear in mind:
> 
> 1. The protocol design originated over 25 years ago. There are estimates 
> of over 25 million clients on the planet now. Changing the IPv4 refid 
> compatibility is simply not in the cards. Certainly it is possible to 
> accidently configure two associations with the same server and I have 
> done that for test. It may be duplicative, but it is not fatal and does 
> not impair good timekeeping.

I am not sure how refids got into this. I think Danny suggested them
as an existing server ID, which of course, they are not. At best they
are the server's server's ID.

> 
> 2. I believe nobody has noticed that NTPv4 autokey extension fields 
> contain the association ID of the client, which is returned by the 
> server and of course is a transaction ID. If this isn't enough, define a 
> new extension field for the purpose.

Well, a server ID. If it were a transaction ID it would have to change
on each transaction. However, this just shows the desirability of having
a server ID field. My claim is that it would be useful in the base
NTP header and should not require the use of the extension fields.

There are three types of ID that would be useful here. A transaction ID,
which is copied from request to reply. This is made a bit more difficult
by the existence of symmetric peers, since a transaction becomes half of
the full peer exchange. You need two transaction ID fields to implement
symmetric peers.

The next would be a server ID, which, like the transaction ID, is copied
from the reply to the request. And like the transaction ID, runs afoul
of the symmetric peers. It is really a special case of the transaction
ID, with an unchanging value.

And the last would be a server ID, where the value is filled in with a
unique identifier generated by the sender of the packet. This could be
used as a server ID in the sense of the previous paragraph, but only
after the first volley is done. The value of the response could be
recorded in the peer structure after the first response. It is therefore
useless in this first exchange. It does have the added benefit of
allowing the detection of duplicate servers, though.

The first two points are rendered moot by the existence of:
> 
> 3. The transmit timestamp is in fact a very good transaction ID, as the 
> unused low-order bits are filled with a random bitstring and the 
> resulting timestamp is essentially unguessable. It is in fact used as 
> the transaction ID to set up manycast client asssociations and has the 
> advantage to be useful without autokey. It should include enough bits to 
> defy cryptanalysis, yet not require a packet format change. When network 
> delays approach 232 picoseconds, this should be reviewed.

So, indeed. I mentioned the use of the transmit timestamp as a
transaction ID in one of my messages on the 23rd. At the time I stated
that it could be used, but might not be unique. Given the information
above, I withdraw that objection. I am a little leery of relying on
a implicit transaction ID; I would prefer to have an explicit field.
The reference implementation only tracks the timestamp to microsecond
resolution, so the number of bits available as a transaction ID is
implementation dependent, with a tradeoff between resolution and this
ID.
> 
> 4. By design the session key is a hash of some public and some private 
> information. When it was designed over ten years ago the intent was to 
> nab IP address hijackers, so I included the addresses in the hash. Doing 
> without the addresses would be possible, but the resulting session key 
> would be cryptographically weak.

Correction, "weaker", and perhaps able to be made stronger again.
I will have to look at the crypto stuff more closely.

And, just to be clear, I have no objection at all to using the IP
addresses in various places. The objection I have is for any thing
that requires the process to obtain the destination address of a
received packet. The source address is fine.

And to be even clearer still, my real objection is to binding all
of the addresses. It is my research into that problem led me to the
conclusion that the destination address should not be made a
requirement for any portable UDP protocol. I say portable,
because many OS's now have an API to easily get the destination
address, without binding all of the addresses. However, I would
still not make it a requirement gratuitously.

> 
> 5. I am very concerned about rogue broadcasters, which is why the 
> broadcaster association ID is included in the extension field and is in 
> fact used as a transaction ID. It is possible to do without the IP 
> addresses, since the session key is bound by the reverse hash to a 
> signature, but the reverse hash itself would be only 64 bits and that 
> would ordinarily be considered cryptoanalyzeable.
> 
> 6. My original and still viable plan was to provide an alternate mode 
> where the cookie portion of the session key could be expanded and the IP 
> addresses dropped. The cookie already is sliced from a 128-bit hash, so 
> this may not be as hard as it looks. However, to avoid using the IP 
> addresses, ports and version number for association matching is much 
> harder to change.

Right. This is what led to my discussion about NTPv5. What would you
change if you did not have to be backwards compatible. For instance,
I have made two or three attempts at adding a new extension field to
the existing code base. The treatment of extensions is somewhat
abstruse and inefficient, largely due to backwards compatibility
issues, or so I gather.

The only legitimate reason to bind all of the addresses that I have
heard is to be able to determine the destination IP address of a
packet. Indeed, there is no other way to do this portably. My
contention is that this is not and/or should not be a requirement
of the NTP protocol. You have confirmed this, that modulo the
crypto stuff, the base protocol does not need nor require it.
And the crypto stuff could probably be modified not to need it
as well.

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

Brian Utterback wrote:
> David L. Mills wrote:
> 
>> Guys,
>>
>> I'm answering Danny's message only because it is short. Bear in mind:
>>
>> 1. The protocol design originated over 25 years ago. There are
>> estimates of over 25 million clients on the planet now. Changing the
>> IPv4 refid compatibility is simply not in the cards. Certainly it is
>> possible to accidently configure two associations with the same server
>> and I have done that for test. It may be duplicative, but it is not
>> fatal and does not impair good timekeeping.
> 
> 
> I am not sure how refids got into this. I think Danny suggested them
> as an existing server ID, which of course, they are not. At best they
> are the server's server's ID.

I need to go back and look again.

> 
>>
>> 2. I believe nobody has noticed that NTPv4 autokey extension fields
>> contain the association ID of the client, which is returned by the
>> server and of course is a transaction ID. If this isn't enough, define
>> a new extension field for the purpose.
> 
> 
> Well, a server ID. If it were a transaction ID it would have to change
> on each transaction. However, this just shows the desirability of having
> a server ID field. My claim is that it would be useful in the base
> NTP header and should not require the use of the extension fields.
> 
> There are three types of ID that would be useful here. A transaction ID,
> which is copied from request to reply. This is made a bit more difficult
> by the existence of symmetric peers, since a transaction becomes half of
> the full peer exchange. You need two transaction ID fields to implement
> symmetric peers.
> 

Why do you need transaction ID's? You shouldn't be sending more than one
request NTP packet at a time so what you get back should be the request
and in any case the packet contains all of the information you need to
deal with the results.

> The next would be a server ID, which, like the transaction ID, is copied
> from the reply to the request. And like the transaction ID, runs afoul
> of the symmetric peers. It is really a special case of the transaction
> ID, with an unchanging value.
> 

What is the reason for having a server ID and what would you do with it.

> And the last would be a server ID, where the value is filled in with a
> unique identifier generated by the sender of the packet. This could be
> used as a server ID in the sense of the previous paragraph, but only
> after the first volley is done. The value of the response could be
> recorded in the peer structure after the first response. It is therefore
> useless in this first exchange. It does have the added benefit of
> allowing the detection of duplicate servers, though.
> 
> The first two points are rendered moot by the existence of:
> 
>>
>> 3. The transmit timestamp is in fact a very good transaction ID, as
>> the unused low-order bits are filled with a random bitstring and the
>> resulting timestamp is essentially unguessable. It is in fact used as
>> the transaction ID to set up manycast client asssociations and has the
>> advantage to be useful without autokey. It should include enough bits
>> to defy cryptanalysis, yet not require a packet format change. When
>> network delays approach 232 picoseconds, this should be reviewed.
> 
> 
> So, indeed. I mentioned the use of the transmit timestamp as a
> transaction ID in one of my messages on the 23rd. At the time I stated
> that it could be used, but might not be unique. Given the information
> above, I withdraw that objection. I am a little leery of relying on
> a implicit transaction ID; I would prefer to have an explicit field.
> The reference implementation only tracks the timestamp to microsecond
> resolution, so the number of bits available as a transaction ID is
> implementation dependent, with a tradeoff between resolution and this
> ID.
> 

Again what would you do with it?

>>
>> 4. By design the session key is a hash of some public and some private
>> information. When it was designed over ten years ago the intent was to
>> nab IP address hijackers, so I included the addresses in the hash.
>> Doing without the addresses would be possible, but the resulting
>> session key would be cryptographically weak.
> 
> 
> Correction, "weaker", and perhaps able to be made stronger again.
> I will have to look at the crypto stuff more closely.
> 
> And, just to be clear, I have no objection at all to using the IP
> addresses in various places. The objection I have is for any thing
> that requires the process to obtain the destination address of a
> received packet. The source address is fine.
> 

You have to have both. The source for one is the destination for the
other. You need both.

> And to be even clearer still, my real objection is to binding all
> of the addresses. It is my research into that problem led me to the
> conclusion that the destination address should not be made a
> requirement for any portable UDP protocol. I say portable,
> because many OS's now have an API to easily get the destination
> address, without binding all of the addresses. However, I would
> still not make it a requirement gratuitously.
> 

The binding of all interfaces has nothing to do with this. I was
originally not going to bind the wildcard addresses but changed my mind
on this after a discussion with a security expert.
>>
> 
> The only legitimate reason to bind all of the addresses that I have
> heard is to be able to determine the destination IP address of a
> packet. Indeed, there is no other way to do this portably. My
> contention is that this is not and/or should not be a requirement
> of the NTP protocol. You have confirmed this, that modulo the
> crypto stuff, the base protocol does not need nor require it.
> And the crypto stuff could probably be modified not to need it
> as well.
> 

It has nothing to do with the NTP protocol, it has to do with the
implementation. For autokey it is required.

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