While I won't argue for hacking this, I do think there is a simpler realization.
If you flagged a ROA such that it would not be considered in the search for a covering ROA unless it exactly matched the length of the announced prefix (i.e., a "Not aggregate ROA"). That is a simple check on step one of the validation procedure of RFC6483. That would leave the more specifics UNKNOWN. If operative policy is IGNORE INVALID, the stature of the more specifics is no different than if we had not created the not-aggregate ROA for the /8. As ROAs for the more specifics of the /8 are created, they will move the relevant more specifics from UNKNOW to either VALID or INVALID as the case may be. Not sure any of that is worth pursuing, but I do think there is another realization what is less complex/damaging that what is imagined below. dougm On 2/16/12 8:08 PM, "Murphy, Sandra" <[email protected]> wrote: >Speaking as only a regular ol' member. > >btw: I agree with the "this is absolutely not for now" part. > >Your idea authorizes one prefix and says "more specifics are OK". > >Synopsis: It doesn't buy you much and it makes life much more complicated. > >First, saying "more specifics are OK" does not buy you much protection. > >Right now, a hijack of the /8 itself and any more specifics will succeed. > That's >2*24 possible hijacks. (Yes, I know the /25-/32 will be rejected many >places >with prefix length limits.) > >In a time and place where RPKI was being used in origin validation, if >the /8 >does not have a ROA, then a hijack of the /8 itself and any more >specifics >(not covered themselves by ROAs) will be judged UNKNOWN. That's >2*24 hijacks (max) looking UNKNOWN. > >In a time and place where RPKI was being used in origin validation, if >the /8 >does have a "more specifics are OK" ROA, then a hijack of the /8 itself >will >be INVALID and any more specifics (not covered themselves by ROAs) will >be judged UNKOWN. That's 1 attack that is INVALID and 2**24-1 attacks >that are UNKNOWN. > >That's a 1/(2**24) improvement in your security. Not that much help. > >Second, life gets a lot more complicated. > >NOTE: I am not suggesting opening a discussion of how this idea might be >improved. I am pointing to the necessary confusion that results when >there >are contradicting sorts of semantics ("more specifics ARE OK" vs "more >specifics ARE BAD"). > >As the /8 ISP starts (or its customers start) to issue ROAs for more >specifics, >it/they will want to issue the strong ROAs, the ones that protect against >more >specific hijacks as well. > >If there is a weak ROA for the /8 and a strong ROA for a /16, how do you >evaluate a route for a /24? > >If there is a strong ROA for the /16, and a weak ROA for a /20, how do >you >evaluate a route for a /24? > >Can you change a weak ROA into a strong ROA? When can you do that? >How will the change affect routing elsewhere? Etc. > >This complication of validation states was (imho) part of the >dissatisfaction >with the BOA suggestion (BOA is another case of contradicting sematics). >The wg tussled with that for several meetings in a row and eventually >gave >up the idea. Been there, done that, burned the t-shirt, etc. > >--Sandy, regular ol' member > > >________________________________________ >From: [email protected] [[email protected]] on behalf of Randy >Bush [[email protected]] >Sent: Thursday, February 16, 2012 5:23 PM >To: Jay Borkenhagen >Cc: sidr wg list >Subject: [sidr] a hack for the next generation of rpki-based origin >validation > >jay, i sent you this a couple of months back and you said to wait. but >i hear you have raised it again, so here it is, finally leaving my emacs >edit buffer > >randy > >--- > >this is absolutely not for now, but for the next generation of the >protocols once we have some experience under our belts. i.e. something >to think about to keep you from being bored. > >an ops friend said that they have 10.0.0.0/8 with a lot of bgp customers >below it. it will take a long time to get roas out for those customers. >in the meantime they would like to protect 10.0.0.0/8 and maybe the two >/9s below it. > >i am not sure i really support this idea as it defeats the basic >protections against hole punching which we want. and it really just >supports the lazy who are unable to simply run code against their >back-end db to gen the roas. and if they don't have the back-end db, >wuzza wuzza. but here is a hack which i think could do it. > >use max-len==0 to denote marking the exact prefix/len as valid, but not >invalidating covered prefixes from other asns. i.e. issuing roas for > > 10.0.0.0/8-0 42 > 10.0.0.0/9-0 42 > 10.128.0.0/9-0 42 > >would cause the marking of the following as valid > > 10.0.0.0/8 42 > 10.0.0.0/9 42 > 10.128.0.0/9 42 > >and the following as notfound > > 10.42.0.0/24 42 > 10.42.0.0/16 666 > 10.77.0.0/24 666 > >but would cause the marking of the following as invalid > > 10.0.0.0/8 666 > 10.0.0.0/9 666 > 10.128.0.0/9 666 > >the friend realizes that 10.x.0.0/10 could be hole-punched to death. if >he wants to stop that, he should not use max-len==0. > >randy >_______________________________________________ >sidr mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/sidr >_______________________________________________ >sidr mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
