> 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 _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
