nanog mailing list archives

Re: constraining RPKI Trust Anchors


From: Job Snijders via NANOG <nanog () nanog org>
Date: Tue, 26 Sep 2023 21:24:54 +0200

Dear Matthew,

See below

On Tue, 26 Sep 2023 at 20:49, Matthew Petach <mpetach () 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



Current thread: