Hello Job, TL;DR: I disagree. On Fri, 10 Dec 2021 at 19:10, Job Snijders via routing-wg <routing-wg@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