[ntp:security] NOEPEER patch

Harlan Stenn stenn at nwtime.org
Mon Jul 30 10:22:39 UTC 2018


Martin,

Pearly and I have been chatting about this for the past hour.

Here's the thing:

We get an AM_NEWPASS situation.  This is one of several cases.

1) it's a broken Windows client.  We want to respond to these.

2) it's not a broken Windows client.  We want to drop these if NOEPEER
is set.  We want to spin up an ephemeral association otherwise.

The problem is that for the Windows case, we just call fast_xmit() to
send the response without spinning up an association.

For the non-windows case, we want to either drop the packet without
responding (if NOEPEER is set), or spin up an association.

We cannot first respond with a fast_xmit() and then decide if we want to
spin up an association or not.

We have to be able to know if the incoming request is from a broken
windows client or not.

Do you know how we can do that?

Similarly, it would be helpful to know if we can respond to these broken
windows clients with a mode 4 (Server) response instead of a mode 2
(Passive) response, just to try and let the client know what's going on.

I'd hate to be debugging why one side thinks it's doing a (passive)
symmetric association when the other (ntpd) side is just responding with
symmetric passive packets without actually bringing up an association.

Can't this problem also be solved with the ntp.keys file, where the
LANtime server would have a 4th argument of an IP address (possibly
localhost) so that you would not need to use NOEPEER on local networks?

Does the LANtime create ephemeral associations from Windows clients?

H
--
On 7/30/2018 2:05 AM, Harlan Stenn wrote:
> 
> 
> On 7/30/2018 1:56 AM, Martin Burnicki wrote:
>> Harlan Stenn wrote:
>> [...]
>>> I don't think I was involved in that discussion or coding.
>>
>> At least you haven't commented in those threads. ;-)
>>
>>> I'm assuming it's not that important that we find out who was involved,
>>> it's more important that we fix this ASAP.
>>
>> Yes.
>>
>>> Similarly, it's too bad that we didn't know about this before I released
>>> the proposed tarball.  But we're past that now.
>>
>> Yes.
>>
>>>> With the latest NOEPEER patch such "symmetric active" requests are
>>>> simply dropped, but IMO it would be good to get the behavior back that
>>>> was initially implemented by DLM, i.e. send a "symmetric passive" reply
>>>> back, but don't mobilize an association, unless authenticated.
>>>>
>>>> Do you think we can modify the patch so that we get this behavior back
>>>> in p12? It shouldn't be too hard to get it.
>>>
>>> Yes, I'm happy to find a solution to this and include it in p12.
>>
>> That would be really good.
>>
>>> Do you know if the Windows client will be upset if it gets back a mode 4
>>> (server) response instead of a mode 2 (passive symmetric) response?
>>
>> I haven't tried this, yet, but I'm going to investigate.
> 
> Thanks - while it probably doesn't matter to *us* if we reply with a
> mode 4 or a mode 2 packet, it might matter to the windows client, and
> that response is the key issue here.
> 
>> Would this be easier or more straightforward? With sending a passive
>> symmetric response it should work anyway ...
> 
> What we send back to the windows client is no problem either way.
> 
> The "hole" you found is from where we originally delayed the NOEPEER
> check, and when I looked at that code I saw how we could avoid the
> problem completely.  Unfortunately, I didn't realize that this was a
> code path for the broken windows clients as well.
> 
> It's after 0200 here, and I'll look at this for as long as I can tonight.
> 

-- 
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!


More information about the security mailing list