[routing-wg] RPKI ROA MaxLength - feature or misfeature? (UX/security)

Hello Job,


TL;DR: I disagree.


On Fri, 10 Dec 2021 at 19:10, Job Snijders via routing-wg
<routing-wg at ripe.net> wrote:
> I suspect that many people think that "xxx/48 maxlength 50" means "the
> /48, AND the four individual /50s" (mentally skipping over the
> intermediate /49s).

That may be the case. But how is this an actual real world problem
that needs to be solved with a hard change (as in actually restricting
the UI to be able to use maxlength, as opposed to a soft change that
would be: education and explanation or nothing at all)?

(I would have chosen a different example like /32 with maxlength /48
for example, because in this example we have to assume the unrealistic
scenario that prefixes longer than /48 are actually able to
propagate).

If the network operator knowingly allows 4 individual /50's, the
operator hopefully is aware that somebody with the ability to spoof
the origin AS can originate those. The fact that the attacker can also
originate /49s and the operator may not be aware of it is not a big
deal for me: I don't see how the attack scenario drastically changes
due to this misunderstanding.

Do you have a specific attack in mind that I don't see?



> Going back as far as 2011 [1] - the concept of
> "MaxLength" appeared less than straight-forward, the quest for a good
> 'default setting' seems a challenge.

The current default in the RIPE Lirportal is to not allow more
specifics; a network operator must actively specify a different value.
That seems like a pretty safe UI to me.

You are trying to solve a case where the user is actively overwriting
a default value in the UI, but at the same time does not know what it
actually does. But many lirportal users DO know what this is about.



> My experience at NTT taught me that encouraging customers to create IRR
> "route:" or "route6:" objects that *exactly* match what people intend to
> announce in the BGP plane, greatly simpifies things. Just register what
> you want to announce, nothing more, nothing less.

It's obvious a 1:1 relation is more easily understood; that doesn't
mean enforcing it globally is a good idea; and in this specific case:
maxlength is not an optional parameter but a principal one.



> A proposal for UX experiment: would it be beneficial to HIDE the
> 'maxlength' field (for some period of time) in the RPKI ROA management
> system hosted by RIPE NCC?
> If the option isn't there, it can't confuse people.

I would strongly oppose this change.

Maxlength is a basic parameter of VRP's and has been in use for a long
time. RPKI/ROA documentation, training and papers talk about it all
the time.

Removing it from the interface means we have an incomplete
implementation. Hide it to avoid confusing an extremely small number
of people, by taking away control from people who actually know what
they are doing after all this time and all this with questionable
benefit? That seems like a poor choice.



> Wouldn't it be better to encourage people to create ROAs that
> align one-to-one with BGP announcements?

Encouraging someone to do X is very different from forcing someone to
do X. You seem to suggest the latter here.



> (keep in mind: IRR route/route6 objects don't have the notion of maxlength).

IRR filtering also in many cases implies: maxlength /24 for v4 or /48
for v6, otherwise we wouldn't have "-R" in bgpq4. Would you remove
"-R" from bgpq4?



> Or an enhancement: a button "also create ROAs for all /24s and /48s, but
> not the intermediate prefix lengths". This saves people a lot of
> clicking if they want to prepare for maximum de-aggregation.

I don't mind adding those buttons, as long as maxlength itself stays.



> Is MaxLength used in the wild?
> ==============================
>
> Only 15% of Validated ROA Payloads (VRPs) under the RIPE NCC Trust
> Anchor have the MaxLength field set to something other than the
> aggregate Prefix Length.
>
> I'm not entirely convinced that accommodating the 15% is worth the
> hassle of explaining what the heck MaxLength is. Removing MaxLength from
> the UI does not in any way impact anyone's ability to create as many
> ROAs as they deem fit, it just forces people to be precise! :-)

I completely disagree with your conclusions. 15% is a lot, not a
minuscule amount as you seem to imply, but whatever the value I would
not argue for your proposal.

Maxlength is a basic VRP attribute that every VRP managing interface
should have. I agree that we need safe defaults everywhere. I strongly
disagree that this requires restricting existing functionality for
everyone.

Frankly I would kick out tools, solutions and services that
disenfranchise me by taking away control of basic operational
parameters like this. This is not only a technical question but also a
fundamental control question.



> Removing MaxLength from the UI does not in any way impact
> anyone's ability to create as many ROAs as they deem fit, it
> just forces people to be precise! :-)

Not necessarily. It may force or encourage people to remove ROAs
altogether or stop using the hosted CA.


This is an aviation safety anti-pattern: the pilot needs to be in
control and stay in control. Will the pilot make errors? Absolutely,
but the response can't be to take away control from the pilot. A lot
of aviation disasters are directly caused by such anti-patterns. It
also reminds me of the ROV implementation in Cisco IOS XE and
partially XR: it's geared towards the OS not caring about what the
operator wants - in this case making flawed assumptions but that's not
the point - the point is that the operator needs to be in control.


Now if you think maxlength shouldn't have been in ROV at all, or
propose alternatives to it, that's a very different discussion
altogether.



Regards,
Lukas