Re: bgpd ROA validation
Claudio Jeker(cje...@diehard.n-r-g.com) on 2018.09.27 10:57:12 +0200:
> On Thu, Sep 27, 2018 at 09:39:36AM +0200, Claudio Jeker wrote:
> > On Wed, Sep 26, 2018 at 06:24:36PM +0200, Claudio Jeker wrote:
> > > On Tue, Sep 25, 2018 at 12:23:48PM +0200, Claudio Jeker wrote:
> > > > On Sat, Sep 22, 2018 at 09:48:24PM +, 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
> > > > > }
> > > > >
> > > > > 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.
> > >
> > > Here we go. This changes the diff so there is only one roa-set like
> > > mentioned above:
> > >
> > > roa-set {
> > > 165.254.255.0/24 source-as 15562
> > > 193.0.0.0/21 source-as
> > > }
> > >
> > > 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
> > >
> > > Additionally I left the old sets around but used
Re: bgpd ROA validation
On Thu, Sep 27, 2018 at 09:39:36AM +0200, Claudio Jeker wrote:
> On Wed, Sep 26, 2018 at 06:24:36PM +0200, Claudio Jeker wrote:
> > On Tue, Sep 25, 2018 at 12:23:48PM +0200, Claudio Jeker wrote:
> > > On Sat, Sep 22, 2018 at 09:48:24PM +, 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
> > > > }
> > > >
> > > > 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.
> >
> > Here we go. This changes the diff so there is only one roa-set like
> > mentioned above:
> >
> > roa-set {
> > 165.254.255.0/24 source-as 15562
> > 193.0.0.0/21 source-as
> > }
> >
> > 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
> >
> > Additionally I left the old sets around but used a bit different:
> >
> > origin-set FOO {
> > ...
> > }
> >
> > match from any community $ORIGIN_AS_OK origin-set FOO valid \
> > set community $ORIGIN_PREF_OK
> >
> > I may even consider to drop the 'valid' in the above rule since that is
> > the only check that kind of
Re: bgpd ROA validation
On Wed, Sep 26, 2018 at 06:24:36PM +0200, Claudio Jeker wrote:
> On Tue, Sep 25, 2018 at 12:23:48PM +0200, Claudio Jeker wrote:
> > On Sat, Sep 22, 2018 at 09:48:24PM +, 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
> > > }
> > >
> > > 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.
>
> Here we go. This changes the diff so there is only one roa-set like
> mentioned above:
>
> roa-set {
> 165.254.255.0/24 source-as 15562
> 193.0.0.0/21 source-as
> }
>
> 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
>
> Additionally I left the old sets around but used a bit different:
>
> origin-set FOO {
> ...
> }
>
> match from any community $ORIGIN_AS_OK origin-set FOO valid \
> set community $ORIGIN_PREF_OK
>
> I may even consider to drop the 'valid' in the above rule since that is
> the only check that kind of matters in this case.
>
New version removing the validity argument from origin-set FOO filter
rules as mentioned above. Apart from that it should be the same.
--
:wq Claudio
Index: bgpd.c
===
RCS file:
Re: bgpd ROA validation
On Tue, Sep 25, 2018 at 12:23:48PM +0200, Claudio Jeker wrote:
> On Sat, Sep 22, 2018 at 09:48:24PM +, 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
> > }
> >
> > 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.
Here we go. This changes the diff so there is only one roa-set like
mentioned above:
roa-set {
165.254.255.0/24 source-as 15562
193.0.0.0/21 source-as
}
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
Additionally I left the old sets around but used a bit different:
origin-set FOO {
...
}
match from any community $ORIGIN_AS_OK origin-set FOO valid \
set community $ORIGIN_PREF_OK
I may even consider to drop the 'valid' in the above rule since that is
the only check that kind of matters in this case.
--
:wq Claudio
Index: bgpd.c
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.c,v
retrieving revision 1.202
diff -u -p -r1.202 bgpd.c
--- bgpd.c 25 Sep 2018 07:58:11 - 1.202
+++ bgpd.c 26 Sep 2018 16:14:05 -
@@ -506,15 +506,15 @@ reconfigure(char *conffile, struct bgpd_
return (-1);
/* prefixsets for filters in the RDE */
- while ((ps = SIMPLEQ_FIRST(conf->prefixsets)) != NULL) {
Re: bgpd ROA validation
On Tue, Sep 25, 2018 at 12:23:48PM +0200, Claudio Jeker wrote:
> On Sat, Sep 22, 2018 at 09:48:24PM +, 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
> > }
> >
> > 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
Re: bgpd ROA validation
On Sat, Sep 22, 2018 at 09:48:24PM +, 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
> }
>
> 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
Re: bgpd ROA validation
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.
There currently is 1 RPKI, and therefor we should have just 1 roa-set.
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
}
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'.
I'm working on a patch to introduce the 'ovs' keyword to bgpctl too,
folks can do stuff like "bgpctl show rib ovs valid". I'll share that
with you privately.
Kind regards,
Job
Re: bgpd ROA validation
On Fri, Sep 21, 2018 at 05:29:24PM +0200, Claudio Jeker wrote: > I currently use the RIPE RPKI validator to grab a JSON file (e.g. > http://localcert.ripe.net:8088/export.json) and feed that to this perl > script to convert it into bgpd syntax: For now I recommend using https://rpki.gin.ntt.net/api/export.json - should be reliable. The localcert.ripe.net instance is not run as a production service, more as a sort of public facing demonstration of an old version of the validator. Of course best operational practise is to run your own RPKI validator. Currently there are two implementations available that can provide the 'export.json' file: https://github.com/RIPE-NCC/rpki-validator-3 (java, more mature) https://github.com/nlnetlabs/routinator (rust, beta) We'll have to use one of these until we have our own openbsd validator. Kind regards, Job
Re: bgpd ROA validation
Claudio Jeker(cje...@diehard.n-r-g.com) on 2018.09.21 22:30:17 +0200: > > In my setup I get these numbers: > > 5895 invalid prefixes > > 67478 valid prefixes > > 638299 unknown prefixes > > This is from a single IPv4 only full feed. > > > > Disclaimer: works for me but I did not test it thoroughly especially no > > comparison was done to other implementations. Still wanted to share it > > now so other people can help. fwiw, the numbers you are seeing and what i get seem to agree with the stats on https://rpki-monitor.antd.nist.gov/ (Of course more tests and reality checks/comparisions are still welcome)
Re: bgpd ROA validation
On Fri, Sep 21, 2018 at 05:29:24PM +0200, Claudio Jeker wrote:
> This diff adds the rest needed to do ROA validation.
>
> It does:
> - add the filter logic for roa validation check
>deny from any roa-set RPKI invalid
>match from any roa-set RPKI valid set community local-as:42
> - makes the RDE do the roa validation check whenever a prefix is added to
> the RIB (both via UPDATE or via network statement)
> - adds some magic for reloads (currently a big hammer that needs to be
> optimized but lets start easy)
> - various bug fixes
> - introduces a new funciton aspath_origin() to get the origin AS from an
> AS path. This info may later be used for source-as checks as well but
> they currently behave a bit different when it comes to pathes not ending
> with a AS SEQUENCE segement.
>
> I currently use the RIPE RPKI validator to grab a JSON file (e.g.
> http://localcert.ripe.net:8088/export.json) and feed that to this perl
> script to convert it into bgpd syntax:
>
> #!/usr/bin/perl
> use strict;
> use warnings;
> use JSON::PP;
> my $json = do { local $/; <> };
> my $roa = decode_json $json;
> print "roa-set RPKI {\n";
> foreach (@{$roa->{'roas'}}) {
> my $as = substr $_->{'asn'}, 2;
> print "\t$_->{'prefix'} maxlen $_->{'maxLength'} source-as $as\n";
> }
> print "}\n";
>
> With that configs like this work:
> include "/etc/bgpd/rpki.conf"
>
> deny from any roa-set RPKI invalid
> match from any roa-set RPKI valid set community local-as:42
> match from any roa-set RPKI unknown set community local-as:43
>
> In my setup I get these numbers:
> 5895 invalid prefixes
> 67478 valid prefixes
> 638299 unknown prefixes
> This is from a single IPv4 only full feed.
>
> Disclaimer: works for me but I did not test it thoroughly especially no
> comparison was done to other implementations. Still wanted to share it
> now so other people can help.
Updated diff, fixes an issue with IPv6 sessions which was found by benno@
--
:wq Claudio
Index: bgpd.c
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.c,v
retrieving revision 1.201
diff -u -p -r1.201 bgpd.c
--- bgpd.c 21 Sep 2018 04:55:27 - 1.201
+++ bgpd.c 21 Sep 2018 13:56:16 -
@@ -529,15 +529,15 @@ reconfigure(char *conffile, struct bgpd_
ps->name, sizeof(ps->name)) == -1)
return (-1);
RB_FOREACH_SAFE(psi, prefixset_tree, >psitems, npsi) {
- u_int32_t *as;
+ struct roa_set *rs;
size_t i, l, n;
RB_REMOVE(prefixset_tree, >psitems, psi);
- as = set_get(psi->set, );
+ rs = set_get(psi->set, );
for (i = 0; i < n; i += l) {
l = (n - i > 1024 ? 1024 : n - i);
if (imsg_compose(ibuf_rde,
IMSG_RECONF_ROA_AS_SET_ITEMS,
- 0, 0, -1, as + i, l) == -1)
+ 0, 0, -1, rs + i, l * sizeof(*rs)) == -1)
return -1;
}
if (imsg_compose(ibuf_rde, IMSG_RECONF_PREFIXSETITEM, 0,
@@ -569,7 +569,7 @@ reconfigure(char *conffile, struct bgpd_
for (i = 0; i < n; i += l) {
l = (n - i > 1024 ? 1024 : n - i);
if (imsg_compose(ibuf_rde, IMSG_RECONF_AS_SET_ITEMS,
- 0, 0, -1, as + i, l) == -1)
+ 0, 0, -1, as + i, l * sizeof(*as)) == -1)
return -1;
}
Index: bgpd.h
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.h,v
retrieving revision 1.344
diff -u -p -r1.344 bgpd.h
--- bgpd.h 21 Sep 2018 04:55:27 - 1.344
+++ bgpd.h 21 Sep 2018 12:20:16 -
@@ -695,6 +695,12 @@ struct filter_prefixset {
struct rde_prefixset*ps;
};
+struct filter_roaset {
+ u_int32_tvalidity;
+ char name[SET_NAME_LEN];
+ struct rde_prefixset*ps;
+};
+
struct filter_community {
int as;
int type;
@@ -886,6 +892,7 @@ struct filter_match {
struct filter_largecommunitylarge_community;
struct filter_extcommunity ext_community;
struct filter_prefixset prefixset;
+ struct filter_roasetroaset;
};
union filter_rule_ptr {
@@ -1015,6 +1022,8 @@ extern struct rib_names ribnames;
/* 4-byte magic AS number */
#define AS_TRANS 23456
+/* AS_NONE for origin validation */
+#define AS_NONE0
struct rde_memstats {
int64_t path_cnt;
Index: parse.y
===
RCS
