Internet2 Network Security SIG

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

I should note that my statement “it would take a very large clock skew to 
begin to effect this” I meant in the validating cache.

dougm

--dougm @ NIST / ITL / ANTD

On 7/26/17, 10:05 AM, "Montgomery, Douglas (Fed)" 
<>
 wrote:

    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