Re: Recent NTP pool traffic increase

[Yury Shefer <shefys () gmail com>]

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 () 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 () 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 () nanog org] On Behalf Of Tim Raphael
>
> > > > [raphael.timothy () gmail com]
>
> > > > Sent: Tuesday, December 20, 2016 5:34 PM
>
> > > > To: Gary E. Miller
>
> > > > Cc: nanog () 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 () rellim com> wrote:
>
> > > > >
>
> > > > > Yo Valdis.Kletnieks () vt edu!
>
> > > > >
>
> > > > > On Tue, 20 Dec 2016 20:20:48 -0500
>
> > > > > Valdis.Kletnieks () 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 () rellim com  Tel:+1 541 382 8588
>
> >