On Tue, Sep 25, 2018 at 12:23:48PM +0200, Claudio Jeker wrote:
> On Sat, Sep 22, 2018 at 09:48:24PM +0000, Job Snijders wrote:
> > 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).
The big difference between IRR, ARIN WHOIS and RPKI is that the former
two carry no exclusivity, and the latter (RPKI) semantically means
someting different than IRR or WHOIS data can convey.
When an object from IRR or WHOIS indicates that something like
"192.0.2.0/24 source-as 65001", it does *not* mean that 192.0.2.0/24
can't be originated by other ASNs. There may be other sources (other
IRRs) that also have route objects covering the prefix, or not. It just
means that 65001 is one of the valid source ASNs, it is a rather weak
statement.
However, if the same information "192.0.2.0/24 source-as 65001" comes
from a RPKI ROA, it means that *ALL OTHER* announcements from different
source ASNs or with different prefix lengths are invalid.
You can't apply the origin validation procedure if the information fed
into the procedure has no proof of termination.
Phrased differently: this is why you can do RPKI Origin Validation on
all your EBGP sessions, including your transit providers. But with IRR
based filters you can't really apply them on you transit providers.
IRR/WHOIS are only an allowlist, where as RPKI ROAs is a combined allow
+ blocklist.
> 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.
At this point in time I do not thing we should support multiple tables.
Let's finish RPKI ROA origin validation and later, separately, look if
we can optimise for IRR/WHOIS data.
> > 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.
That is entirely unrelated, and being worked on outside of OpenBSD
scope.
> 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.
I disagree, roa-set is an RPKI only thing. There currently is nothing
else to support. No other type of published routing information has the
same semantics as a ROA and are thus suitable for the origin validation
procedure.
> > 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.
Ah, so instead of what I proposed 'unknown' we should use 'not-found'.
OK that makes sense.
> 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 think this is fine. 'ext-community ovs' is a non-transitive extended
community and is not that widely used.
> 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.
OK.
> I will rework the diff considering the input.
Kind regards,
Job
