Oops ... Sorry, that was Randy's first note/idea ... Somehow that got lost when I read Sandy's description.
Seems like we have been down this path. I should catch up from the bottom up of the thread, not top down. dougm On 2/18/12 10:05 AM, "Doug Montgomery" <[email protected]> wrote: >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
