Internet2 Network Security SIG

[John Kristoff <>]

On Wed, 26 Jul 2017 13:16:36 +0000
gcbrowni 
<>
 wrote:

> *) Being forced to run a server. I find this decision from Juniper
> puzzling. There’s lots of filter/acl options, but "just don’t listen
> on the port" doesn’t seem to one of them, beyond turning the entire
> NTP system off.

This is probably largely due to historical accident.  For year and
years the reference ntpd implementation did not have the capability to
listen on select interfaces or addresses, it was all or nothing.  That
began to change in 2009, but that is still relatively recent in ntpd
history.  I suspect Juniper could implement the interface/address
restriction in the CLI if they devote some development cycles to it.

> *) There’s some cost in man-hours to this, from getting the filters
> on the loop and edge and NTP correct, maintaining them, and dealing
> with anomalous message sin the syslog about xntpd … which STILL seem
> to occur. IE: you have to do everything you should do when running a
> server.

I believe you should really only need the loopback filter if your goal
is protect the individual router.  This shouldn't be too terribly
difficult to maintain if you're maintaining the router at all.  I
imagine most of you have seen this, but I wrote it up while at TC and I
think it is still more or less decent guidance:

  <http://www.team-cymru.org/secure-ntp-template.html>

Perhaps the one thing I left out is to remind people to also
apply the same logic to a v6 loopback as well.

> I don’t think I2 has the "personalized support person" maintenance
> option anymore; does anyone else? It might be worth it to see what
> Juniper response is to "why do have to have a server to have correct
> time?" … and then of course the associated coordinated feature
> request. :)

How about we as the I2 community write up a joint statement that each
interested person could sign their name to and one of us delivers it to
the appropriate Juniper rep?  I'm happy to be editor and messenger for
this if no one else wants the job.

> John & Andrew, could I get you to elaborate more on the potential
> drift implications in RPKI & route validation?

I am not an RPKI expert, but from IETF RFC 7115 - Origin Validation
Operation Based on the Resource Public Key Infrastructure (RPKI), near
the end of section 6 there is this statement:

   As a router must evaluate certificates and ROAs that are time
   dependent, routers' clocks MUST be correct to a tolerance of
   approximately an hour.

IETF RFC 6810 has similar wording.  Soon-to-be-published IETF RFC 8207
will have this as well.

There is some research-oriented reading here that covers various
NTP-related attacks here, including attacks on RPKI.

  <http://www.cs.bu.edu/~goldbe/NTPattack.html>

John