[ntp:hackers] Samba's MS-NTP implementation

Danny Mayer mayer at ntp.org
Mon Jul 13 11:54:48 UTC 2009


Harlan Stenn wrote:
>> I have been reviewing the code that the Samba team introduced into the
>> NTP dev code base and I am seeing a lot of problems that disturb me
>> about this contribution. So let me enumerate the problems with the
>> implementation:
>>
>> 1) The code uses a TCP socket to call another server. This is even
>> though NTP only uses UDP
> 
> So what?  This is the code the Samba team says makes for the easiest
> integration with samba.
> 
> That is the entire point of this whack of code.
> 

So what you are saying is that this is for Samba only and that is a very
restricted list of servers.

>> 2) The code only seems to try to contact a Samba server but it should
>> equally be able to connect to an Active Directory Domain Controller or a
>> Kerberos server.
> 
> Why do you say this?  The samba folks know what they need, and sent us
> code to do what they need.
> 
> What problem are you trying to solve?

So only Samba can use this.

> 
>> 3) The code blocks on the connect, the send (write) and the recv (read)
>> calls all of which violate the basic requirements of NTP.
> 
> Yes, Dave Mills and I both know this and discussed this.
> 
> Until we get event-loop code into ntp, the samba interaction *can*
> block.

The event-loop is not a cure-all and will take a great deal of time and
effort to get into the NTP source and working. Don't put too much
expectation on it.

> 
> Therefore we default the samba code to "off" and we warn people (at
> least we *should* be warning them) about the problems they *may* have if
> they use this code.
> 
> And as I understand it, the new MSSNTP 'restrict' code can limit the
> networks that ntpd will even talk to about this.
> 
>> I am unsure of the affect of using this on a Windows system.
> 
> Why would you want to run Samba on a Windows box?
> 

"Why wouldn't I want to run NTP on an active directory domain
controller" is the correct question. We are ending up with a solution
that only works for Samba.

>> 4) The code uses AF_UNIX instead of AF_INET or AF_INET6 as appropriate
> 
> What problem are yo trying to solve?  This stuff is all on the local
> machine.  What is the problem with using an AF_UNIX socket to talk
> between ntpd and samba running on a Unix box?
> 

If you only want to run it on a Unix box running Samba, that's fine,
it's just very limiting.

>> 5) The time for another server to respond is indeterminate and cannot be
>> relied upon.
> 
> Yes, so what?  This is also going on (near as I can recall) in between
> T2 and T3, so the amount of time it takes doesn't really matter.
> 

Actually it's worse than that since you are now holding up the
processing of other incoming packets and delaying timestamping them.

>> 6) The requirement that it waits for another server makes it easy to
>> mount a DOS attack on such an NTP server.
> 
> Yes, and since this service should only be set up to support local
> users, there is less risk.  And we document this.
>

The documentation that I have seen so far has not said a word about this.

>> 7) The reliance on another server increases the likelihood that the
>> jitter and delay will increase enormously in unexpected and unreliable
>> ways and that is something that NTP cannot afford.
> 
> Says who?  And if indeed this interaction is between T2 and T3, where is
> this problem you speak of?  And if this really does turn out to be ab ig
> deal, we'll hear about it, see if we can fix it, and either way folks
> can decide to use it or not.

The delay in processing other incoming packets affects the timestamps.
That's why we insist on non-blocking for the DNS lookups.

> 
>> 8) There maybe some issues over the copyright of the protocol which is
>> covered under Microsoft's Open Specifications copyright but I am not a
>> lawyer and cannot say if there are any legal issues involved with this
>> code.
> 
> I'm not a laywer either so neither can I.  We got the code in good
> faith.

I'm not talking about Samba's code, I'm talking about Microsoft's
licensing of the protocol.

> 
>> This is so at variance with the NTP design requirements that I am
>> recommending that we completely remove the Samba contribution from the
>> 4.2.5 code at this time. If at some point in the future this can be done
>> without involving a third system then it can be reconsidered. Even if
>> this is released we should explicitly be turning off this capability and
>> require that anyone who wants to use it turn it on.
> 
> It is *already* off by default.
> 
> It *already* requires specific action to turn it on.  
> 
> And I hear your recommendation.  We (me, Dave Mills, a bunch of other
> folks) have been discussing this proposal for quite a long time now
> (since May 2008, and before that, Novermber of 2006), and I suspect you
> knew about this.

I don't recall a discussion of the blocking issue but maybe I missed it.

> 
> Even if it wasn't so late in the game, the dangers of enabling this
> capability are well understood and documented, and there are significant
> complications if we do *not* have this capability.

Where is it documented?

> 
> Furthermore, I believe most of the "danger" in this capability will go
> away as soon as we have a useful event-loop in the mainline code.
> 

Again don't expect too much of the event-loop processing and this code
would have to be decomposed to be non-blocking to be any use to the
event-loop processing.

> So far I've heard only good things about this code, and no reports of
> problems.
> 
> That's good enough for me, given the current default behavior and the
> warnings and caveats to those who intend to use it.
> 
> I am again reminded of my favorite between-the-lines Bible Quote:
> 
>  Blessed are those who get what they deserve.

I'm more concerned about the Principle of Least Astonishment.

Danny

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



More information about the hackers mailing list