On Sat, 22 Sep 2007, Jan Hoevers wrote:

> Eugene Smiley wrote on 22-9-2007 16:39:
>> Jan Hoevers wrote:
>> > [EMAIL PROTECTED] wrote on 22-9-2007 12:42:
>> >> An easy way to solve the TT problem and the like would be to configure the
>> >> pool DNS so when it gets a query from the 88.245.0.0 - 88.245.255.255 IP
>> >> range, the pool DNS would then return the IP of one of the numerous ntpd
>> >> servers that TT is running on their OWN network. Problem solved ! No more
>> >> TT traffic for pool members !
>> >
>> > That would not solve any problem, it would redirect it to TT customers.
>> > Come on! This would be a deliberate attack.
>>
>> Actually the server point to other servers in private IP space (192.168..) If
>> these were customers they'd likely point to different sources. These can't
>> possibly be customer resources.
>
> May well be colo customers, there's no way to tell. And how did you
> check those 192.168.. addresses are TT's own machines? Maybe they're
> colocated too.
>
No they are not colos, these machines are on their router subnet, colos 
would most likely be on another subnet like their customer subnet is on a 
different subnet than the router subnet.

These machines seem to be running FreeBSD and have no other ports open 
than the ntp port. I doubt a colo would pay to host a machine and then run only 
ntpd on it ;-)

As for the 192.168.. machines, it is TT decision where they get their time 
from, not ours.

> Anyway, bouncing a problem back to its supposed source would widely be
> seen as an attack. Also consider there's probably no malicious intent
> from TTs side.
> There were many examples in the past where this kind of warfare just
> caused more trouble.
>

Jumping to to words like warfare, malicious and attack. I don't view it as 
such. I view it as the logical thing to do from a network administrator 
perspective. Remember that it will save TT bandwidth (not to mention pool 
members and all others along the way) if they handle their ntp requests 
with their own servers.

> The pool DNS system could deny service to TT addresses, but I suppose
> that has been considered months ago.
>
Denying service is much more malicious in my humble opinion. Poor innocent 
people would see their devices going out of sync with no clues of what 
happened.

-ls

> Jan
> _______________________________________________
> timekeepers mailing list
> [email protected]
> https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
>

Louis
http://blogtech.oc9.com
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers

Reply via email to