Re: [sidr] ROA management recommendations for users

[Randy Bush <[e-mail]>]

> I am working on a presentation giving some recommendations for RPKI
> early adopters. I want to provide some guidelines on how they should
> go about creating their ROAs, and I would love to receive some input
> from this list.
> 
> Broadly speaking, and looking at what people have created in the
> repositories so far, there seem to be two different views on the
> matter:
> 
> - ROAs that mirror BGP announcements and/or block de-aggregation within networks
> For example, an organization with as 100  holding 10.1/16 and having
> sub-allocated 10.1.128/18 to as 200 creates something like this:
> 
> ROA #1: 10.1.0/17-18, 10.1.192/18-18 origin-as 100
> ROA #2: 10.1.128/18-18 origin-as 200
> 
> - ROAs that protect all the way to /32 (in IPv4)
> 
> Using the same example as above, they would have:
> ROA #1: 10.1/16-32 origin-as 100
> ROA #2: 10.1.128/18-32 origin-as 200

from draft-ietf-sidr-origin-ops-10.txt 

   To aid translation of ROAs into efficient search algorithms in
   routers, ROAs SHOULD be as precise as possible, i.e. match prefixes
   as announced in BGP.  E.g. software and operators SHOULD avoid use of
   excessive max length values in ROAs unless operationally necessary.

   One advantage of minimal ROA length is that the forged origin attack
   does not work for sub-prefixes that are not covered by overly long
   max length.  E.g. if, instead of 10.0.0.0/16-24, one issues
   10.0.0.0/16 and 10.0.42.0/24, a forged origin attack can not succeed
   against 10.0.66.0/24.  They must attack the whole /16, which is more
   likely to be noticed.

   Therefore, ROA generation software MUST use the prefix length as the
   max length if the user does not specify a max length.

   Operators SHOULD be conservative in use of max length in ROAs.  E.g.,
   if a prefix will have only a few sub-prefixes announced, multiple
   ROAs for the specific announcements SHOULD be used as opposed to one
   ROA with a long max length.

randy