Internet2 Network Security SIG

["Montgomery, Douglas (Fed)" <>]

It is no different for BGPSEC – all the certificates, which do have validity 
periods, are kept in the validating cache.  The SIGS on the BGP path etc do 
not have validity dates.  Note also that validity periods on CERTS in RPKI 
are expected to be long lived and rolled make-before-break when their 
expirations approaches. While you could do this poorly of course, if you are 
doing this reasonably, it would take a very large clock skew to begin to 
effect this.

Folks do this now with DNSSEC – creating validity periods that are “back 
dated” a bit to catch those resolvers with lagging clocks.

So, if you don’t plan to let your clocks skew by 10s of hours, or days, you 
should be OK.  Mind you I think the idea of doing that will present all kinds 
of other problems with normal operations / logs, not just security protocols.

--Doug Montgomery,  Mgr. Internet & Scalable Systems Research @ NIST
https://www.nist.gov/itl/antd/internet-scalable-systems-research
 

On 7/26/17, 9:48 AM, "Andrew Gallo" 
<
 on behalf of 
>
 wrote:

    I don't think that RPKI (origin validation) would be affected, since the 
    crypto processing is done by an external validator. What I *think* might 
    be a problem is full path validation, where each hop in an AS path has 
    to sign advertisements and do crypto processing, most likely on the 
    router.  At least that's my understanding of how secureBGP is supposed 
    to work.  I'll see if I can glean anything from the SIDR working group 
docs.
    
    
    
    
    On 7/26/2017 9:16 AM, gcbrowni wrote:
    > 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?
    >
    >
    >
    >
    >
    
    -- 
    ________________________________
    Andrew Gallo
    The George Washington University