[RPKI] suggestion to remove as0 restriction in krill 0.8.0

Mon Nov 2 09:29:34 UTC 2020

Hi all,

Actually I had hoped to have this discussion after I asked about it explicitly in my message about 0.8.0-rc1:
https://lists.nlnetlabs.nl/pipermail/rpki/2020-October/000213.html

But, no worries :) better now than never.. I am quite happy to make changes and do a 0.8.1 release.

Before I do though, can I ask that we explore the ROA suggestions and restrictions a bit more? Your feedback is highly appreciated.

See below, in-line.

> On 1 Nov 2020, at 17:32, Jay Borkenhagen via RPKI <rpki at lists.nlnetlabs.nl> wrote:
> 
> Hi,
> 
> I agree with Job here, that Krill should impose no special
> restrictions with respect to AS0 ROAs.
> 
> Whatever their rationale, some people do publish ROAs authorizing AS0
> along with other ASes, e.g. these VRPs under 80.128.0.0/11:
> 
> AS0,80.128.0.0/11,11,ripe
> AS3320,80.128.0.0/11,11,ripe

That AS0 ROA is pointless, because it's exactly the same prefix and max length as the one for AS3320 above. Similarly it would be pointless to have an AS0 ROA for a more specific prefix already authorized for another ASN.

My main rationale for disallowing it was to keep the management and expectations simple.

> AS3320,80.128.0.0/12,12,ripe
> AS3320,80.144.0.0/13,13,ripe
> AS3320,80.152.0.0/14,14,ripe
> AS3320,80.156.0.0/16,16,ripe
> AS3320,80.157.0.0/16,16,ripe
> AS3320,80.157.8.0/21,21,ripe
> AS3320,80.157.16.0/20,20,ripe
> AS34086,80.158.0.0/17,24,ripe
> AS6878,80.158.0.0/21,24,ripe
> AS6878,80.158.0.0/23,23,ripe
> AS6878,80.158.16.0/20,24,ripe
> AS6878,80.158.31.0/24,24,ripe
> AS6878,80.158.32.0/19,24,ripe
> AS6878,80.158.72.0/21,24,ripe
> AS6878,80.158.80.0/20,24,ripe
> AS6878,80.158.96.0/19,24,ripe
> AS2792,80.159.224.0/19,24,ripe
> 
> I'd say, if these folks really feel there is value in doing this kind
> of thing, let them.
> 
> Thanks.
> 
> 						Jay B.
> 
> Job Snijders via RPKI writes:
>> Hi,
>> 
>> I saw in the release notes:
>> 
>>    """
>>    ROAs that use AS0 can be used in the RPKI to indicate that the
>>    holder of a prefix does NOT want the prefix to be routed on the
>>    global internet. In our understanding this precludes that ROAs for a
>>    real ASN for those resources should be made. Krill will therefore
>>    refuse to make AS0 ROAs for prefixes already covered by a real ASN
>>    ROA, and vice versa. Furthermore the presence of an AS0 ROA implies
>>    that announcements for covered prefixes are intentionally RPKI
>>    invalid. Therefore Krill will not suggest to authorize such
>>    announcements.
>>    """
>> 
>> I believe this to be a misunderstanding on the meaning of the value '0'
>> as the asID in RPKI ROAs. I suggest to remove this restriction.
>> 
>> A network operator may create a 'asID 0' ROA for its aggregate, as the
>> starting point of the use of the allocation, and then subsequently
>> create one or more covering ROAs with asID's referencing the customers
>> of such allocations. The co-existence of 'asID 0' and other ROAs can be
>> the result of thinking that as a baseline the space should not be
>> routable, unless specified otherwise.

You are quite right, I overlooked this case.

>> 
>> From a BGP routing perspective the presence of 'asID 0' ROAs is
>> effectively is moot if other ROAs exist too, making this phenomena
>> somewhat counter-intuitive. Combining 'asID 0' with partially or fully
>> covering ROAs with non-zero asIDs is a perfectly valid configuration,
>> which I believe krill should support.
>> 
>> The asID 0 restriction introduced in krill 0.8.0 is not supported by any
>> standards documentation as far as I know.

I understand, but we were trying to give people guidance. As said, I am happy to change it based on your feedback.

I believe that work on a BCOP would be very useful - I would definitely use it as guiding input.

Quoting Jay's example:

> AS0,80.128.0.0/11,11,ripe
> AS3320,80.128.0.0/11,11,ripe

That AS0 ROA is pointless, because it's exactly the same prefix and max length as the one for AS3320 above. Similarly it would be pointless to have an AS0 ROA for a more specific prefix already authorized for another ASN.

My main rationale for disallowing them was to keep the management and expectations simple.

That said, I can remove these restrictions and possibly make them warning offences only. We already support this for example for other cases.

While you are here, could you please let me know what you think of the following?

- ROA suggestions and AS0

AS0 ROAs are also treated differently wrt ROA suggestions. I.e. if we see an announcement in RIS that is invalid because of an AS0 ROA, Krill will *NOT* suggest that you authorize it. It assumes that you created the AS0 on purpose.

- Redundant ROAs

Currently Krill disallows the creation of 'redundant' ROAs. For example, if you have:
AS3320,80.128.0.0/11,13

It will not allow that you create:
AS3320,80.128.0.0/13,13,ripe

Because it's already covered by the max length of the first.

Having both doesn't break anything, but it is messy and makes it more difficult to reason about your setup. That said, I am also fine with removing this restriction, or changing it to a warning.

- Too permissive ROAs

Consider the case where you have:
AS3320,80.128.0.0/11,13

But we only see announcements for: 80.128.0.0/11 and 80.128.0.0/13, that leave three /13s which are not seen, and could be abused for hijacks with path prepending.

These are permitted, but Krill warns and suggests that you create ROAs for the seen announcements only.

Please let me know what you think. Again all this guidance is intended to make life better for operators, so I am very happy to get your feedback.. 

Kind regards,
Tim

>> 
>> Kind regards,
>> 
>> Job
>> -- 
>> RPKI mailing list
>> RPKI at lists.nlnetlabs.nl
>> https://lists.nlnetlabs.nl/mailman/listinfo/rpki
> -- 
> RPKI mailing list
> RPKI at lists.nlnetlabs.nl
> https://lists.nlnetlabs.nl/mailman/listinfo/rpki