Re: [Sidrops] Talk: RPKI Deployment: Status, Challenges and the Learning-Validator

I am probably being simplistic, but my memory of this conversation
during happier more innocent days was that a covering prefix's use of
a ROA signalled that RPKI applied to all origin-as assertions made
below it, as more specific. Thats how I understood us to be discussing
it. For this mail, I discount a ROA which fails cryptographic checks:
its being spoofed or is otherwise mechanistically in error and cannot
apply.

The address holder is the sole signatory of a ROA. The address holder
of the covering prefix has a delegation authority over the more
specific. If they had transferred the resources, there would be an
overt 'hole' in their addresses and it would have a different RFC3779
representation, so there is no 'prefix' as such to announce: if they
continue to announce the aggregate covering prefix when there is an
explicit transfer out of the more specific, that wasn't engineered for
in the model. There can be no covering ROA which refers to it since
the 3779 state is not legal under the signing (even under modified
validation, the ROA which overclaims is going to be invalid)

So excluding explicit transfer, I believe the 'reductionist' sense of
a more specific is: either its authorized by an explicit ROA referring
to itself, or its implied as legal in the values specified in a
covering aggregate ROA, or its not actually permissable. I can't see
any other state implied. I do not see this as a tri-state situation:
if the aggregate over it is legal, then all more specifics of that
aggregate require a ROA or implied consent from the aggregate to be
true. (basically, the same AS and a length-permitting setting)

Now, as to intent: if somebody *wants* the more specific to exist,
there is a path out: make a ROA. If this is a timeliness situation,
they haven't published one, thats a transitional fault. if it
persists, its an operational failure. But its not in system to say
"oh, they probably meant this" -Thats not how validation is meant to
work.  Do we really want to move to a world where crypto intent and
declared validation semantics can be _interpreted_ ?

Why do a ROA, for the covering aggregate, if you didn't intend
applying ROA semantics to all addresses in the covering ROA? The
semantics should be concrete. Not inferential.

What am I missing here? What did I not understand? 'inferring' intent,
belief, which is not backed by the literal meaning of the ROAs which
exist, and their cryptographic checks, feels to me like a losing game.

On Thu, Jul 27, 2017 at 6:18 AM, Randy Bush <randy@psg.com> wrote:
>> Accepting more specific announcements leaves one vulnerable though to
>> more specific announcements done with a spoofed AS.
>
> one of the principle goals of the whole effort
>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops