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
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