Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt

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
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr