At 2:31 PM -0500 12/12/08, Andrew Newton wrote:
On Dec 12, 2008, at 10:52 AM, Stephen Kent wrote:
...
Steve,
Thanks for the information. That was very helpful.
As to the use of a negative attestation (be it BOA or AS 0 ROA) by a
registry, that will most likely be decided by policy in my opinion.
But I do believe there are operational differences between the two approaches.
A 1 day lifetime is reasonable during the working week, but weekends
and holidays are a different story. And often times those weekends
are used for maintenance windows. Additionally, there are exception
cases were allocations need to be updated urgently and then there
are trouble shooting events... in both these situations an AS 0 ROA
acts like an another moving part that needs to be double checked
whereas a BOA requires less care and maintenance. From my
perspective, a BOA seems less error prone should negative
attestations be desired.
First, recall that each CRL says when the next CRL will be issued, so
if one decides to not issue CRLs on weekend and holidays, that
distinction is easy to express in the CRL NextUpdate field.
Similarly, if the intent is to not make new allocations and enable
then during such periods, the AS 0 ROA can be given a longer lifetime
for those days.
Separately, I don't think I understand the operational difference. A
BOA, as a signed object, would need to be revoked just as an AS 0 ROA
would, and it would have the same lifetime management requirements.
Which aspect of BOAs vs. AA 0 ROAs, do you believe make the former
easier to deal with in these contexts?
I think there is also another angle to the adoption issue that needs
consideration. As I stated, I do not know if negative attestations
will be immediately adopted and at what level. But let's
hypothesize about a community that adopts RPKI and does not use
them. And then, 5 years after adoption they determine that such a
thing is needed. To get them, there would be a need to cycle back
through the standards track and software adoption curve. It seems
better to have BOAs in the standard now and have them ignored then
to have to iterate through another standards & software adoption
process.
I think there are several, separable issues here. One issue is
whether we need to make provisions for negative assertions. If so,
then I agree that making provisions for such assertions sooner is
better. A second issue is the scope of such assertions (just address
space or address space and AS numbers). Then we can ask what form
such assertions should take, e.g., BOAs vs. ROAs, vs. ?
I observe that if the scope of such assertions is just address space,
and not AS numbers I believe we can do this via ROAs, and thus we
already have the necessary mechanism available. It then becomes a
matter of policy whether to make such assertions ort not.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
