On Sat, Sep 22, 2018 at 09:48:24PM +0000, Job Snijders wrote:
> Hi claudio,
>
> Seems we are getting very close. Some suggestions to simplify the
> experience for the end user.
>
> Let's start with supporting just one (unnamed) roa-set, so far I've
> really not come across a use case where multiple ROA tables are useful.
> I say this having implemented origin validation on both ISPs and IXPs.
>
> The semantics of the Origin Validation procedure that apply to
> "Validated ROA Payloads" are not compatible with how the ARIN WHOIS
> OriginAS semantics, so roa-set will never be used for ARIN WHOIS data.
Please explain further, because honestly both the ruleset that
arouteserver generates for ARIN WHOIS OriginAS and ROA are doing
the same. They connect a source-as with a prefix. This is what a
roa-set is giving you. It implements a way to quickly lookup a 2 key
element (AS + prefix). Depending on how this table is used it can be used
for both cases. This is the technical view based on looking at rulesets and
thinking on how to write them in a way that is fast and understandable.
I understand that from an administration point of view RPKI ROA is much
stronger and can therefor be used more strictly (e.g. with the simple rule
deny quick from ebgp roa-set RPKI invalid). The generic origin validatiation
as a supporting measure to IRR based prefixset filtering is only allowing
additional prefixes based on the roa-set (e.g. match from ebgp \
large-community $INTCOMM_ORIGIN_OK roa-set ARINDB valid \
set large-community $INTCOMM_PREF_OK). They are two different things but
can use the same filter building blocks.
Maybe naming it roa-set is wrong (since it is too much connected with
RPKI) but the lookup table is usable for more than just RPKI. This is why
I think supporting multiple tables is benefitial. I also agree that a
simplified user experience for RPKI is a good thing, it should be simple
to use.
> There currently is 1 RPKI, and therefor we should have just 1 roa-set.
I would fully agree here if ARIN would make their trust anchor freely
distributable. But yes in general only one RPKI table is needed.
My point is that roa-set is more generic than RPKI. It is not an RPKI only
thing. It can be used for more than that and we should support this as
well since it makes for much better and efficient configs.
> The advantage of having only one roa-set is that it does not need to be
> referenced in the policies.
>
> I propose the patch is amended to accomodate the following:
>
> roa-set {
> 165.254.255.0/24 source-as 15562
> 193.0.0.0/21 source-as 3333
> }
>
> deny from any ovs invalid
> match from any ovs valid set community local-as:42
> match from any ovs unknown set community local-as:43
>
> I suggest the filter keyword 'ovs' (origin validation state) is
> introduced to allow easy matching. I think this looks better. If the
> roa-set is not defined or empty, all route announcements are 'unknown'.
If we want to use ovs then the naming scheme should be the same as for the
extended community. At least if we reuse this keyword it should work the
same. Also the side-effect is that the two configs look fairly similar
which can be good or bad:
match from any ovs valid set community local-as:42
match from any ext-community ovs valid set community local-as:42
I'm not against this, just wanted to bring it up.
Also I think unknown should be renamed not-found. I will do that since
not-found is what the RFC is using.
I will rework the diff considering the input.
--
:wq Claudio
