>>> It doesn't seem to be a new problem to me. How is this time problem
>>> evaluated in the current off-line cache software?
>>
>> from draft-ietf-sidr-rpki-rtr
>>
>> As a cache server must evaluate certificates and ROAs which are time
>> dependent, servers' clocks MUST be correct to a tolerance of
>> approximately an hour.
>>
>>> Why think of another approach if the only difference is the device
>>> doing the validation of certs and ROA's?
>>
>> same approach. just trying to throw in a bit more detail for two
>> reasons
>
> If it is the same approach, why detail this more? It is a MUST time
> settings are correct, and let router vendors take care of the
> 'tolerance of approximately an hour' implementation.
>
> Beside this, I just read the draft-ymbk-bgpsec-ops draft and the
> detail you're now trying to get into the document seems a bit odd to
> me.
>
> I think the time-issues should be noted where validation is described
> and that operational considerations aren't the right place for this.
hi jac,
i am not sure i am really getting your point(s), so i may be way off
here. but let me give it a go.
we're talking two very different protocol/security/document sets here.
o draft-ietf-sidr-rpki-rtr is for origin validation, and goes with
draft-ietf-sidr-origin-ops, and the router never sees certs or
anything else which requires the router to know anything about time.
it's all in the cache servers which feed only highly digested data
to the routers.
o draft-ymbk-bgpsec-ops goes with draft-lepinski-bgpsec-overview and
draft-lepinski-bgpsec-protocol, where certs et alia go all the way
to the routers, and hence the routers need to know time. and brian
questioned if and how they might be trusted to know something about
what time it is.
while i could imagine a doc which covers operational considerations for
anything validating rpki data, this would not cover that bgpsec has
signatures with expiry times in the bgp messages, which are outside of
the rpki.
i guess we could ask matt to go into more detail about validation and
time in draft-lepinski-bgpsec-protocol. when we designed the bgpsec
docco set, i got the tasks of this level of dregs. and that would not
cover slack in validation of the rpki data.
if you have the stomach to read the idr list, i doubt you really want to
leave too much leeway for misinterpretation by bgp implementers. they
have the grand prize for twisty minded nit pickers. we are amateurs.
randy
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
