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

[Andrew Newton <[e-mail]>]

On Dec 12, 2008, at 10:52 AM, Stephen Kent wrote:

> Andy,
>
> Your characterization is good paraphrase of my comments at the mic.  
> In fairness to Geoff's BOA proposal, my ROA As 0 convention is not  
> as powerful, in that it has no provisions for making a negative  
> assertion about AS numbers.
>
> If I were a registry (or an ISP) making use of the AS 0 ROA  
> approach, I would issue one EE cert and one associated ROA )covering  
> all of the unallocated space that I hold). The EE cert would have a  
> lifetime consistent with the time I take to respond to allocation  
> requests, maybe on 1-day lifetime. That way I would not have to put  
> the EE cert on a CRL when a new AS 0 ROA was issued; I'd just be  
> issuing one new cert and one new ROA every day. Since it is probably  
> good practice to issue a CRL every day, the set of objects published  
> by the registry/ISP would have to change that frequently anyway, so  
> this is not much of a new burden, (e.g., the manifest has to change  
> whenever a new CRL is issued).
>
> I also note that even if we don't adopt AS 0 ROAs as a recognized  
> way to make this sort of assertion, any ROA issuer can use it  
> anyway, either explicitly or via analogous means :-).
>
> Steve

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.

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.

-andy

_______________________________________________
sidr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sidr