On Thu, Sep 13, 2012 at 4:43 PM, Stephen Kent <[email protected]> wrote: > Brian,**** > > > If we allow a reasonable time for RPs to have fetched the not-yet-valid > objects, then when they "turn the crank" to process local caches after the > objects have become valid, the RPs would accept them. But, I've never hear > anyone suggest that one ought to try to impose a global, coordinated, RPKI > object processing time on all RPs. (That, in itself would be a security > concern.) So there may be limits here as to how much the overlap can be > reduced by this strategy. >
I'm not suggesting polling-based, synchronous processing of anything. Clearly, that would be foolish. While the implementation is up to the implementer(s), I'd expect event-driven scheduling of processing of changes of state. E.g. set up queues ordered by start or end date/time. Recall, this validation is on the RPKI cache validation side. It is outside of the scope of RPKI-RTR protocol, with the expectation that state changes on the validation would get pushed to routers. Pre-publishing means that local validation would merely need to occur in the overlap window. As long as the new and old objects have been pushed to the router with any amount of overlap, there is no risk of validation failure on received updates. > **** > > Also, are there any other examples you can cite where every network > operator is expected to perform some activity, at the same time (relative > to UTC), every day, around the world? > NETWORK operator? No. But there are plenty of other activities driven by certificate expirations, either passively or actively, which require overlapping (pre-published) objects in order to avoid validation failure. DNSSEC, TLS/SSL, pretty much any certificate-based protocol or security mechanism. > What is the accepted norm for clock sync among all ISPs today, and what > processes rely on the extant precision and accuracy of synchronized clocks > at all ISPs? > NTP, stratum 3 or better. BGP neighbors normally expect each others' clocks to be NTP synchronized, for reasons of trouble-shooting instances of accidental or malicious issues. Logs are useless if their time is not accurate to the millisecond. (Some peering contracts actually require this.) Transit relationships typically require accurate measurement of traffic, both volumetrically and with accurate time. Failure to implement measurement and billing using accurate (NTP) time, is a huge liability. Customers expect to be able to correlate their own measurements with their providers - again, without NTP, this is likely to incur L8/L9 problems. Additionally, virtually every network link requires accurate line-clock, either supplied by the network, or by the end devices. Nearly all network links and/or routers have line-clocking derived (directly or indirectly) from Stratum-1 sources. This can be achieved in a number of ways, either special NTP feeds, or BITS, or TTL, or via transmission gear with integrated cesium clocks and/or GPS receivers. Failure to have synchronized line-clocking is probably the #1 source of network problems during implementation of peering links. Drifting clocks will cause errors and/or outages, guaranteed. > Not being an operator, I really don't know the answers to these questions. > Maybe these are questions you should have asked and gotten the answers to, prior to designing the RPKI? (Sorry, cheap shot.) > **** > > Anyway, if we were to adopt your suggestion, the benefit might be that the > overlap interval need be determined primarily by the time needed to > accommodate skew in RPs posting, fetching, and processing RPKI objects. > Overlap times are only required when there is "live transfer" of INRs, correct? So, mostly (>>99.99999% of the INRs will never have this issue, as 99.999% won't transfer, and of the transfers, 99.99% won't be "live") moot. So, even supposing that such incidents occur, there are two limits to consider: (1) The minimum (actual) overlap interval between the old and new (2) The proscribed maximum overlap interval beyond which one or the other should be rejected So, the discussion would really need to focus on lower bounds and upper bounds for (2). Lower bounds impact mandatory actions by cache operators, or alternatively, risk to operators/RPs of RPKI-induced outages Upper bounds impact the security of the system, and/or window of opportunity for hijacking. > Rather the overlap interval would be a function of what folks consider to > be a comfortable interval to accommodate human processes (and errors) for > the INR transfers.**** > > ** ** > > I don’t know that this time scale as being one that requires carefully > coordinated clocks at all RPs, especially since we don't have a candidate > overlap interval value on the table. Moreover, since there is an overlap > interval in either case, it’s not immediately clear how hard we should work > to reduce it. What overlap interval did you envision? > To paraphrase Vin Diesel (in pretty much any movie he's been in): "Not my problem." What I envision is, the authors of SIDR I-Ds/RFCs proposing intervals, and then discussing/justifying them. Brian
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
