[RPKI] suggestion to remove as0 restriction in krill 0.8.0

[Tim Bruijnzeels]

Hi,

> On 2 Nov 2020, at 14:02, Lukas Tribus <lukas at ltri.eu> wrote:
> 
> Hello,
> 
> On Mon, 2 Nov 2020 at 12:28, Tim Bruijnzeels <tim at nlnetlabs.nl> wrote:
>>> Software tools are supposed to be just that: a tool. To achieve a goal
>>> through certain means. Doesn't need to save the world in the process.
>> 
>> So, just warnings, works for me.
>> 
>> But, I would prefer to have a comprehensive 0.8.1 release, where the
>> restrictions are removed *and* the warnings/suggestions make sense.
>> So if you have any feedback on the latter I would love to hear it.
> 
> Explain facts, without drawing conclusions.
> 
> Like:
> Warning: AS3320,80.128.0.0/13,13,ripe overlaps with
> AS3320,80.128.0.0/11,13,ripe ! Create anyway?
> 
> But not:
> Warning: [bad|insecure|invalid] ROA AS3320,80.128.0.0/13,13,ripe !
> Create Anyway?
> 
> 
> But the "Too Permissive ROAs" suggestion already draws a conclusion.
> In that case we are already past that, and therefor the drawbacks need
> to be explained as well, like:
> 
> "Keep in mind that if you do need to announce a more specific route at
> some point, updating the ROA (and waiting for global convergence) will
> be required. This could for example affect your ability to request
> DDoS mitigation or inbound traffic engineering, if a more specific
> announcement is required."
> 
> 
> That said, I believe by making those strong suggestions in the first
> place you have opened pandora's box. Now you need to cover everything,
> the pros and the cons. And people will blame you when you did not
> cover their specific use-case.
> 
> I would have stayed clear of this by a thousand miles, to be honest.
> 
> 
> The RIPE RPKI Dashboard only warns about problems causing invalids.
> And it makes suggestions for ROA's when you use that particular
> functionality only. That is, in my opinion, the only scalable way for
> CA Dashboards.
> 

Thank you. I think that different users will want different levels of advice/pedantry, let's say 'feedback', by Krill.

Note that one can also disable the BGP info and just deal with ROAs directly.

But for the 'Show BGP Info' enabled interface I am now thinking of having 3 configurable levels of feedback:
- extended advice (too permissive, redundant ROAs, redundant AS0)
- warn on invalid announcements only
- no feedback, just do it

The choice to go ahead with the submitted changes will always be there, even if feedback is shown.

Any other viewpoints on this one?

I will try to get a 0.8.1-rc1 out asap (most likely Fri/Mon).


Tim






> 
> Lukas