Sent from my iPhone
> On Oct 11, 2023, at 15:29, Randy Bush wrote:
>
>
>>
>> So while each RP should be able to make policy decisions based on its
>> own local criteria, managing a default set of constraints is something
>> that is best done centralized. Who do you envision should manage
> So while each RP should be able to make policy decisions based on its
> own local criteria, managing a default set of constraints is something
> that is best done centralized. Who do you envision should manage these
> lists? RP software maintainers? RIRs? Others?
and how will this
.
Kind regards,
Job
[0]:
https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml
[1]:
https://www.ietf.org/archive/id/draft-snijders-constraining-rpki-trust-anchors-00.html
[2]: https://packages.debian.org/stable/rpki-trust-anchors
Isn’t this sort of related to the AS-0 ROA effort a while back (except some of
the RIRs rejected it, unfortunately)?
I suspect that the same reasons behind rejection of AS-0 will also apply to RIR
implementation of something like this, so plans to address that (and revive
AS-0 perhaps) might
Hi Job,
I think this is important work.
As you indicated in your mail you have spent quite some time compiling
the constraints files in the appendix. Keeping them up to date requires
tracking allocations and policy developments in all RIRs. It reminds me
of bogon filters for unallocated IP
nt a maintainable
> constraints mechanism for rpki-client(8), and publicly document the
> concept of applying operator-defined policy to derived trust arcs.
>
> Please take a moment to read
> https://www.ietf.org/archive/id/draft-snijders-constraining-rpki-trust-anchors-00.html
>
> Your feedback is appreciated.
>
> Kind regards,
>
> Job
v6, 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
p
ainable
> constraints mechanism for rpki-client(8), and publicly document the
> concept of applying operator-defined policy to derived trust arcs.
>
> Please take a moment to read
>
> https://www.ietf.org/archive/id/draft-snijders-constraining-rpki-trust-anchors-00.html
>
> Your feedback is appreciated.
>
> Kind regards,
>
> Job
>
cation spaghetti, design & implement a maintainable
constraints mechanism for rpki-client(8), and publicly document the
concept of applying operator-defined policy to derived trust arcs.
Please take a moment to read
https://www.ietf.org/archive/id/draft-snijders-constraining-rpki-trust-anchors-00.
9 matches
Mail list logo
