New Field: RPKI checkbox on ASN

[eloos]

Request from Andrew Alston:
Can a checkbox be added to a net object to indicate whether its prefixes are properly validated using RPKI.
Bonus question: could we derive this info from routing registries and make it auto-update?

[arnoldnipper]

On 08.09.2016 08:09, eloos wrote:

Request from Andrew Alston:
Can a checkbox be added to a net object to indicate whether its prefixes
are properly validated using RPKI.
Bonus question: could we derive this info from routing registries and
make it auto-update?

Imho yes, instead of a single 0|1 I would add a value between 0 and 1
which gives the percentage / 100 of prefixes properly validated using RPKI

Arnold

[job]

the semantics of what exactly is requested in this feature request are entirely unclear to me.

is the number something that should be acted upon? if yes, how? it cannot be a binary decision, might vary per region, per as-set, per interconnection.

even something simple as max_prefix already has complicated semantic interpretation, we should really think this one through

[benmaddison]

The intention of this was to signal that an ASN's originated prefixes should be fully covered by ROAs, and that filtering by ROA validity is therfore safe for that origin. The semantics are "my prefixes should be fully covered" = [true|false].

[job]

@benmaddison aha. But if your prefixes are fully covered, I can observe that myself in the RPKI. I don't see a point in replicating that information into PeeringDB - (where it can become stale or wrong, but above all its a cryptographically unverified statement.)

[benmaddison]

@job agreed - I'm not entirely convinced that this is a good idea (at least not in the longer term). It does however solve an issue that AA was discussing with me:
He wanted to maintain a list of origins for which he would accept prefixes only if they have valid ROA - bypassing other (e.g. IRR based) prefix filters. I pointed out that maintaining this list of origins would have scaling issues, as it relies on OOB communication between (possibly distant) parties. This field would signal a desire to be included in such a list, which can be automated around. Basing this inclusion on the actual existence of ROAs in the RPKI is circular. In this respect, it would function a bit like an automation layer on top of your peer-lock policies.
I don't think that the crypto concern is important, as the semantics of this are orthogonal to the semantics of a ROA. The two could never contradict one-another.
The main argument again this, from my POV, is that the use case is not obvious, and therefore the information provided by users may end up being misleading. I'd be interested to hear whether anyone else has a similar use case.

[job]

@benmaddison I suspect this discussion belongs either in IETF where a new ROA attribute is defined "Overrule-IRR: yes" (similar to MaxLength), or this becomes a boolean Attribute and is part if an autnum certificate of sorts. We should accept that any interpretation of ROA information is a matter of local policy. Even if you can signal to me "Ignore IRR entries, everything is in ROAs", implementing & honouring that request is a function of local policy. You are right that the use case is not obvious as can be seen from this thread, and such ambiguity has the potential to hurt rather then help network operators. I propose this issue is closed and we take the discussion to private mail.

[benmaddison]

@job, happy with that. Either mail, or the hotel bar in DC?