Recent NTP pool traffic increase

Wed Dec 21 05:04:35 UTC 2016

Google announced public NTP service some time ago:
https://developers.google.com/time/

On Tue, Dec 20, 2016 at 7:29 PM Laurent Dumont <admin at coldnorthadmin.com>
wrote:

> I do think that the point of the Pool network is to be used by both
>
> consumers and vendors. And as mentioned before, there is a process if
>
> you are a vendor and want to use the pool within a commercial product. I
>
> have 3 NTP servers running and I don't really care who is using it.
>
>
>
> That said, setting up your own infrastructure is also worth considering
>
> if it's a business critical feature. I assume that a Snapchat app that
>
> fails to have accurate time or correct itself could be abused.
>
>
>
> To be honest, the fact that NTP is still something managed by volunteers
>
> and not a regulated entity (a bit like DNS) is mind boggling.
>
>
>
> On 12/20/2016 09:41 PM, Keenan Tims wrote:
>
> > Better for whom? I'm sure all mobile operating systems provide some
>
> > access to time, with a least 'seconds' resolution. If an app deems
>
> > this time source untrustworthy for some reason, I don't think the
>
> > reasonable response is to make independent time requests from a
>
> > volunteer-operated pool for public servers designed for host
>
> > synchronization. Particularly on mobile, the compartmentalization of
>
> > applications means that this 'better' time will only be accessible to
>
> > one application, and many applications may have this 'better time'
>
> > requirement. These developers should be lobbying Apple and Google for
>
> > better time, if they need it, not making many millions of calls to the
>
> > NTP pool. To make things worse, I'm fairly sure that Apple's 'no
>
> > background tasks' policy means that an application can't *maintain*
>
> > its sense of time, so it would not surprise me if it fires off NTP
>
> > requests every time it is focused, further compounding the burden.
>
> >
>
> > Time is already available, and having every application query for its
>
> > own time against a public resource doesn't seem very friendly. It
>
> > certainly doesn't scale. If they are unsuccessful lobbying the OS, why
>
> > not trust the time provided by the API calls they are surely doing to
>
> > their own servers? Most HTTP responses include a timestamp; surely
>
> > this is good enough for expiring Snaps. Or at least operate their own
>
> > NTP infrastructure.
>
> >
>
> > I'm sure that Snap had no malicious intent and commend them for their
>
> > quick and appropriate response once the issue was identified, but I
>
> > don't think this behaviour is very defensible. I for one was not
>
> > harmed by the ~10x increase in load and traffic on my NTP pool node,
>
> > but the 100x increase if a handful of similar apps decided they 'need'
>
> > more accurate time than the OS provides would be cause for concern,
>
> > and I suspect a great many pool nodes would simply disappear,
>
> > compounding the problem. Please make use of these and similar services
>
> > as they are designed to be used, and as efficiently as possible,
>
> > especially if you are responsible for millions of users / machines.
>
> >
>
> > In a similar vein, I've always been curious what the ratio Google sees
>
> > of ICMP echo vs. DNS traffic to 8.8.8.8 is...
>
> >
>
> > Keenan
>
> >
>
> >
>
> > On 2016-12-20 18:16, Tim Raphael wrote:
>
> >> Exactly,
>
> >>
>
> >> Also they’re across Android and iOS and getting parity of operations
>
> >> across those two OSs isn’t easy.
>
> >> Better to just embed what they need inside the app if it is
>
> >> specialised enough.
>
> >>
>
> >> - Tim
>
> >>
>
> >>> On 21 Dec. 2016, at 10:13 am, Emille Blanc
>
> >>> <emille at abccommunications.com> wrote:
>
> >>>
>
> >>> Perhaps the host OS' to which snapchat caters, don't all have a
>
> >>> devent ntp subststem available?
>
> >>> I have vague recollections of some other software (I'm sure we all
>
> >>> know which) implemented it's own malloc layer for every system it
>
> >>> ran on, for less trivial reasons. ;)
>
> >>>
>
> >>> ________________________________________
>
> >>> From: NANOG [nanog-bounces at nanog.org] On Behalf Of Tim Raphael
>
> >>> [raphael.timothy at gmail.com]
>
> >>> Sent: Tuesday, December 20, 2016 5:34 PM
>
> >>> To: Gary E. Miller
>
> >>> Cc: nanog at nanog.org
>
> >>> Subject: Re: Recent NTP pool traffic increase
>
> >>>
>
> >>> This was my thought actually, Apple does offer some time services as
>
> >>> part of the OS but it’s becoming common with larger / more popular
>
> >>> apps to provide some of these services internally.
>
> >>> Look at the FB app for example, there are a lot of “system” things
>
> >>> they do themselves due to the ability to control specifics. Users
>
> >>> don’t want to have to install a second “specialised app” for this
>
> >>> either.
>
> >>>
>
> >>> With regard to an ephemeral chat app requiring time sync, I can
>
> >>> think of quite a few use cases and mechanisms in the app that might
>
> >>> require time services.
>
> >>>
>
> >>> - Tim
>
> >>>
>
> >>>
>
> >>>> On 21 Dec. 2016, at 9:26 am, Gary E. Miller <gem at rellim.com> wrote:
>
> >>>>
>
> >>>> Yo Valdis.Kletnieks at vt.edu!
>
> >>>>
>
> >>>> On Tue, 20 Dec 2016 20:20:48 -0500
>
> >>>> Valdis.Kletnieks at vt.edu wrote:
>
> >>>>
>
> >>>>> On Tue, 20 Dec 2016 18:11:11 -0500, Peter Beckman said:
>
> >>>>>> Mostly out of curiosity, what was the reason for the change in the
>
> >>>>>> Snapchat code, and what plans does Snap have for whatever reason
>
> >>>>>> the NTP change was put in place?
>
> >>>>>  From other comments in the thread, it sounds like the app was simply
>
> >>>>> linked against a broken version of a library....
>
> >>>> But why is a chat app doing NTP at all?  it should rely on the OS, or
>
> >>>> a specialized app, to keep local time accurate.
>
> >>>>
>
> >>>> RGDS
>
> >>>> GARY
>
> >>>>
> ---------------------------------------------------------------------------
>
> >>>>
>
> >>>> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
>
> >>>>       gem at rellim.com  Tel:+1 541 382 8588
>
> >
>
>
>
>