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
