On 2015-04-28 15:21, Iljitsch van Beijnum wrote:
On 28 Apr 2015, at 20:27, Roque Gagliano (rogaglia)
<[email protected]> wrote:
It is not an implementation choice, it is by design. If a signed
object does not validate (based on whatever reason not just
expiration), it is like if did not existed.
No...
Suppose:
ROA: 193.0.0.0/21 up to /21 -> AS 3333 not valid after 20150430
In your example, is this the only ROA with a prefix that covers
193.0.0.0/21 or is covered by 193.0.0.0/21? Based on the states below,
I'm assuming it is. Please correct me if I'm wrong.
BGP table 29 april:
193.0.0.0/21 3333 -> valid
193.0.0.0/21 4444 -> invalid
193.0.7.0/24 3333 -> invalid
192.0.0.0/16 5555 -> unknown
This part looks right to me.
But, two days later, after the ROA expires, do we have this:
193.0.0.0/21 3333 -> unknown
193.0.0.0/21 4444 -> unknown
193.0.7.0/24 3333 -> unknown
192.0.0.0/16 5555 -> unknown
or this:
193.0.0.0/21 3333 -> invalid
193.0.0.0/21 4444 -> invalid
193.0.7.0/24 3333 -> invalid
192.0.0.0/16 5555 -> unknown
?
[snip]
But the real issue is that this isn't written down anywhere as far as
I can tell, so we're dependent on implementers all independently
coming up with the preferred way to handle this. That's never good
business for a standards organization.
It's the first one (all unknowns). I don't think this is written down
explicitly, but if implementations follow RFC6483, I don't think there's
any way they can get the second result.
From RFC6483, Section 2:
It is assumed here that a relying party (RP) has access to a local
cache of the complete set of valid ROAs when performing validation
of
a route. (Valid ROAs are defined as ROAs that are determined to be
syntactically correct and are signed using a signature that can be
verified using the RPKI, as described in [RFC6482].) The RP needs
to
match a route to one or more valid candidate ROAs in order to
determine a validation outcome, which, in turn, can be used to
determine the appropriate local actions to perform on the route.
This means that only valid (non-expired) ROAs are used for origin
validation. Like Roque said, "if a signed object does not validate
(based on whatever reason not just expiration), it is like if did not
existed."
Then, in the next paragraph:
However, routes
for address prefixes that are not fully described by any single ROA
(i.e., those routes whose address prefixes may be an aggregate of
address prefixes described in a valid ROA, or have address prefixes
where there is no intersection with any valid ROA), and are not
matched by any valid ROA and do not have an address prefix that is a
more specific address prefix described in any valid ROA, cannot be
reliably classified as "invalid" in a partial deployment scenario.
Such routes have a validation outcome of "unknown".
Since the {AS 3333, 193.0.0.0/21-21} ROA expired, there's no *valid*
ROA that intersects any of {193.0.0.0/21, 193.0.0.0/21, 193.0.7.0/24,
192.0.0.0/16}. (See my assumption above about no other ROAs for these
prefixes.) Since none of these four prefixes intersect any prefix in any
valid ROA, all four routes you gave are unknown.
Based on the two snippets above, I do think it's clear enough for
implementations to get it right. However, you asked a good question that
other people will probably ask again. Do you think it would be helpful
to make this case more explicit somewhere?
--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
