Re: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11

[David Mandelberg <[e-mail]>]

On 2015-04-28 15:21, Iljitsch van Beijnum wrote:
> On 28 Apr 2015, at 20:27, Roque Gagliano (rogaglia)
> <[e-mail]> 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/