Internet2 Network Security SIG

[Michael Hare <>]

Something I don't think has come up: I'd be worried about adding operational 
steps, for example, when you do a routing engine swap, to do as something as 
simple as set the time.  While I understand (and have seen!) partial commits 
fail to apply loopback filters, disabling NTP won't save a network in that 
scenario.

In short, we haven't seen a need to try to optimize to this level (disable 
NTP).

We use the following stanzas that might be problematic without highly sync'd 
clocks.  I also put our NTP control and transit filters far below.  We have 
v6 equivs in place, I omitted them for space reasons.

-Michael

==/==

bfd-liveness-detection {
...
authentication {
 key-chain bfd-kc1;
 algorithm keyed-sha-1;
 }
}

security {
        ...
        ...
 authentication-key-chains {
   key-chain bfd-kc1 {
     key 1 {
     secret "$9"; ## SECRET-DATA
     start-time "201x-x-x.00:00:00 -0600";
   }
 }
}


set system ddos-protection protocols ntp aggregate bandwidth 50
set system ddos-protection protocols ntp aggregate burst 50
set system ddos-protection protocols ntp aggregate flow-level-bandwidth 
logical-interface 50
set system ddos-protection protocols ntp aggregate flow-level-detection 
subscriber off
set system ddos-protection protocols ntp aggregate flow-level-detection 
logical-interface on

set policy-options prefix-list NTP-Peers-v4 apply-path "system ntp server 
<*.*.*.*>"                   

for the control plane
set firewall family inet filter <*> term allow-ntp from source-prefix-list 
NTP-Peers-v4
set firewall family inet filter <*> term allow-ntp from source-prefix-list 
loopback-ips-v4
set firewall family inet filter <*> term allow-ntp from protocol udp
set firewall family inet filter <*> term allow-ntp from port ntp
set firewall family inet filter <*> term allow-ntp then count :accept:udp:ntp
set firewall family inet filter <*> term allow-ntp then accept
set firewall family inet filter <*> term block-ntp from protocol udp
set firewall family inet filter <*> term block-ntp from port ntp
set firewall family inet filter <*> term block-ntp then count :discard:udp:ntp
set firewall family inet filter <*> term block-ntp then discard

for transit traffic (optional on untrusted ingress)
set firewall family inet filter <*> term ntp-timesync from packet-length 76
set firewall family inet filter <*> term ntp-timesync from protocol udp
set firewall family inet filter <*> term ntp-timesync from port ntp
set firewall family inet filter <*> term ntp-timesync then count 
:accept:udp:ntp
set firewall family inet filter <*> term ntp-timesync then accept
set firewall family inet filter <*> term ntp-other from protocol udp
set firewall family inet filter <*> term ntp-other from port ntp
set firewall family inet filter <*> term ntp-other then policer 
udp-ntp-other-1M
set firewall family inet filter <*> term ntp-other then count 
:count:udp:ntp-other
set firewall family inet filter <*> term ntp-other then accept

set firewall policer udp-ntp-other-1M filter-specific
set firewall policer udp-ntp-other-1M if-exceeding bandwidth-limit 1m
set firewall policer udp-ntp-other-1M if-exceeding burst-size-limit 20k
set firewall policer udp-ntp-other-1M then discard

[FIN]

> -----Original Message-----
> From: 
> 
>  [
> ]
>  On Behalf Of gcbrowni
> Sent: Wednesday, July 26, 2017 8:17 AM
> To: 
> 
> Subject: Re: [Security-WG] I2 - Turning off NTP?
> 
> Great points in the discussion.
> 
> *) Accurate clock is convenient for looking at local logs
> *) More than Syslog timestamps, and third-party stamping can suffer from
> delays almost certainly resulting in out of order messages in some 
> situations.
> (Corner? Common? Corner but when you need it most?)
> *) A potential impact to RPKI & route validation
> *) A Juniper website that turns up EX switch docs more than real JunOS docs.
> :)
> 
> 
> And on the risk
> *) 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.
> *) 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.
> *) The … risk? of running a server that is a known vector if misconfigured, 
> as
> well as yet another server for a "if the packet reaches the loopback filter 
> it is
> too late" security advisory from Juniper.
> 
> 
> 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. :)
> 
> 
> 
> John & Andrew, could I get you to elaborate more on the potential drift
> implications in RPKI & route validation?
> 
> 
> 
>