constraining RPKI Trust Anchors

Tue Sep 26 19:24:54 UTC 2023

Dear Matthew,

See below

On Tue, 26 Sep 2023 at 20:49, Matthew Petach <mpetach at netflight.com> wrote:

>
> Job,
>
> This looks fantastic, thank you!
>
> For my edification and clarification, the reason you don't need a
>
> deny 2000::/3
>
> or
>
> deny 0::/0
>
> at the bottom of the ARIN list of allows is that every file comes with an
> implicit "deny all", is that correct?
>
> Is there a drawback to adding the explicit "deny 0::/0" at the bottom of
> the file, to make it clear that everything else will return "invalid"?
> I tend to prefer being explicit in my configurations, rather than
> depending upon implicit behaviours which might change with future versions
> of software releases.
>

Sorry, the lede is a bit buried on how exactly the policy language works.
It’s in the appendix, and the example source code offers hints too
https://marc.info/?l=openbsd-tech&m=169574305230941&w=2

I’ll elaborate a bit here: the order of the entries in each constraints
file is not significant. All “deny” entries take precedence over all “allow
entries”. Individual “deny” entries may not overlap with any other “deny”
entries. Individual “allow” entries may not overlap with other “allow”
entries. Deny entries are available to punch holes in allow entries, as a
shortcut. If overlapping constraints are configured the program errors.

If a constraint is applied to a resource class (for example by specifying
just a single “allow 2000::/3” entry), all EE certificates with IPv6
resources in their respective RFC 3779 extensions under that TA must be
encompassed in that single allow entry. So the “implicit deny” comes into
effect the moment you’d configure at least one allow entry for a resource
class (IPv4, IPv6, or AS numbers). This is why no additional “deny the
rest” line is needed in the case of ARIN.

This approach was the best I could muster on short notice. My objective
wasn’t to invent a policy language everyone should adopt, but rather to
draw attention to the concept of constraining RPKI trust anchors and
provide some running code to advance the dialogue.

Thank you for reading the document and asking questions!

Kind regards,

Job

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230926/c9ad3b45/attachment.html>