Internet2 Network Security SIG

[gcbrowni <>]

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?

Attachment: smime.p7s
Description: S/MIME cryptographic signature