Re: Theorical question about cyclic dependency in IRR filtering

[Ben Maddison via NANOG]

Hi Chris,

On 11/29, Christopher Morrow wrote:
> On Mon, Nov 29, 2021 at 8:14 AM Job Snijders via NANOG 
> wrote:
> 
> > Hi Anurag,
> >
> > Circular dependencies definitely are a thing to keep in mind when
> > designing IRR and RPKI pipelines!
> >
> > In the case of IRR: It is quite rare to query the RIR IRR services
> > directly. Instead, the common practise is that utilities such as bgpq3,
> > peval, and bgpq4 query “IRRd” (https://IRRd.net) instances at for example
> > whois.radb.net and rr.ntt.net. You can verify this with tcpdump. These
> > IRRd instances serve as intermediate caches, and will continue to serve old
> > cached data in case the origin is down. This phenomenon in the global IRR
> > deployment avoids a lot of potential for circular dependencies.
> >
> > Also, some organisations use threshold checks before deploying new
> > IRR-based filters to reduce risk of “misfiring”.
> >
> >
> beyond just 'did the filter deployed change by +/- X%'
> you probably don't want to deploy content if you can't actually talk to the
> source... which was anurag's proposed problem.
> 
The point that Job was (I think?) trying to make was that by querying a
mirror for IRR data at filter generation time, as opposed to the source
DB directly, the issue that Anurag envisioned can be avoided.

I would recommend that anyone (esp. transit operators) using IRR data
for filter generation run a local mirror whose reachability is not
subject to IRR-based filters.

Of course, disruption of the NRTM connection between the mirror and the
source DB can still result in local data becoming stale/incomplete.

You can imagine a situation where an NRTM update to an object covering
the source DB address space is missed during a connectivity outage, and
that missed change causes the outage to become persistent.
However, I think that is fairly contrived. I have certainly never seen
it in practise.

Cheers,

Ben


signature.asc
Description: PGP signature

Re: What are best practices for RPKI ROV in transit networks....

[Ben Maddison via NANOG]

Hi Steve,

On 10/28, s...@iu.edu wrote:
> Greetings,
> 
> We seek input on best practices for implementing RPKI ROV in a transit
> (partial transit) network. The Internet2 network provides partial
> transit for many of the K-12 and higher education institutions in the
> US. Our customer routes number just over 6,000. We work with our
> customers to assist with the adoption of MANRS, including creating
> RPKI ROAs for their resources.
> 
>  At some point in the future, we'd like to implement RPKI route origin
>  validation (e.g., dropping invalids). Given that some routes may have
>  mistaken ROAs that resolve to an invalid state, is there a
>  standard/best practice for processing exceptions?

Yes, SLURM, defined in RFC8416, provides a means of expressing local
policy exceptions. All the RP implementations in common use (that I am
aware of) support it.

However...

>  Or, do transit providers that implement ROAs drop all routes that are
>  invalid?

We have had discard-invalid policy in production on every eBGP adjacency
since April 2019.

In that time, we have had *zero* incidents that could not be resolved
without the creation of local exceptions. My understanding from
colleagues at other operators is that their experience has been similar.

As always, your experience may be different, so it is wise to be
prepared.

Cheers,

Ben


signature.asc
Description: PGP signature

Re: ROA mirror to IRR?

[Ben Maddison via NANOG]

Hi Shawn,

On 10/26, Shawn wrote:
> 
> 
> IRR questions:
> How do most large networks maintain (automate) their IRR records?
> Is it standard practice to accept more specifics (append IPv4 "le /24" and
> IPv6 "le /48")?
>  Or is it expected to have one IRR route per BGP announcement?
> 
We (37271) use different policies depending on our relationship to the
neighbor.
From customers, we require an exactly matching route(6) object.
From peers, we accept more specifics up to /24 or /48.

The rationale for this is:
1.  We consider that we have a higher "duty of care" with respect to
routes that we intend to announce to the wider Internet; and
2.  Having a customer facing policy that is at least as strict as our
strictest neighbor helps eliminate hard to troubleshoot propagation
issues.

We've been doing things this way for several years now, and it seems to
be a good middle ground.

Cheers,

Ben


signature.asc
Description: PGP signature

Re: IRR for IX peers

[Ben Maddison via NANOG]

Hi Randy,

On 10/04, Randy Bush wrote:
> hi ben,
> 
> a SIX peer's customer could be the feed to RIS
> 
Sure, but how do you describe the policy between your peer and their
customer in your aut-num?! That's not a thing.

Cheers,

Ben


signature.asc
Description: PGP signature

Re: IRR for IX peers

[Ben Maddison via NANOG]

Hi Randy,

On 10/04, Randy Bush wrote:
> so i have an AS (3130) which peers at the SIX (RSs and some direct).
> 
> in the hope that leak detectors such as artemis would stop false
> positives when they see my prefixes announced customer cones of SIX
> peers, i want to add the SIX peers to my aut-num: policy.
> 
I would be astonished if artemis was parsing your import/export
expressions, but as an academic exercise...

> export:  toAS-SEATTLEIX-RS-CLIENTS  announce AS-RG-SEA
> 
> seems clear and obvious.  but
> 
> import:  from  AS-SEATTLEIX-RS-CLIENTS  accept AS-SEATTLEIX-RS-CLIENTS
> 
> would seem to allow bill's bait and sushi to announce microsoft to me.
> and i am not sure that expansive `from` clause is actually allowed.
> 
The having an as-set in the peering-expr part is fine, but that
particular set appears to contain all of the peers' customer cones,
which is not what you want there.

Additionally it evaluates down to "any route originated by any customer
of any peer, from any customer of any (other) peer". That's not a good
filter, as you pointed out ;-)

In order to express what you want, the SIX needs to create:
- an as-set containing the ASNs of the RS peers (not their customers),
  e.g. AS33108:AS-PEERS;
  and
- for each peer, a set containing that peer's customer cone, each with
  name that contains the peer's ASN, e.g. AS33108:AS-PEERS:AS65000.

Then you can say something like:

import: from AS33108:AS-PEERS accept AS33108:AS-PEERS:PeerAS

The fact that the IX operator needs to maintain these sets is a symptom
of the same issue that makes it near impossible to construct sane
filters for route-server sessions: you have no idea when someone joins,
or what they *should* be announcing.

One of the many reasons you don't see us on route-servers.

> what are others in this space doing?
> 
Mostly, asking people fill-in peeringdb records, and ignoring
import/export attributes entirely.

However we use roughly the above scheme, just in case someone is
reading.

Cheers,

Ben


signature.asc
Description: PGP signature

Re: "Tactical" /24 announcements

[Ben Maddison via NANOG]

Hi David,

On 08/19, David Bass wrote:
> Ben,
> 
> Yes, sorry.
> 
> Pulling/pushing the config data to a server, and then managing it there in
> addition to on the box.  Like, if I want to run some reports to see how
> many PL are defined on each box, it’s easier to do that with the data
> centralized and managed.
> 
Thanks for clarifying.

A bit of additional context:

We build and push whole device configs, doing a full replace on every
change.
The configs are built from centralized, version controlled data which
describes devices connectivity, customer services, etc, etc, etc.
On every change, we retrieve a diff from the device (e.g. show arch
config diff ... on IOS).

Having the *contents* of IRR derived prefix-lists in the configs has two
major downsides:
- it makes the config dependent on data that we don't own (i.e. a box
  gets a new config even though we didn't change any of our internal
  data), which in turn makes the diffs large and noisy; and
- the size of the generated configs is huge, which slows down deployment
  and makes the whole process fragile.

The tool I mentioned allows us to put a single line (syntactically
equivalent to an empty prefix list) in the generated config. The agent
"sees" that line, and fills in the details, keeping it up to date.
The contents of the list never show up in a "show run", keeping noise
levels down.

There are ultimately three sources of policy data that contribute to the
runtime operation of a device:
- config pushed from our deployment tools
- rpki-rtr data
- prefix-list contents, from our mirrors on the various IRR DBs

If I need to know what prefix lists are on a given box, and what they
contain, I can simply look at those data sources directly.

The key to reliability here is to share as much logic between
operational tools as possible, so that you can be confident that the
"ad-hoc troubleshooting tool" gives an answer that is consistent with
the "config generation tool".

Hope that kinda answers the question?

Cheers,

Ben


signature.asc
Description: PGP signature

Re: "Tactical" /24 announcements

[Ben Maddison via NANOG]

Hi Randy,

On 08/17, Randy Bush wrote:
> for junos, i build the prefix list externally and push config.  sad to
> say, the code is so old ('90s) that it's pearl and uses `peval`.  i
> should fix but (copious spare time) == 0.
> 
Spare time must be > 0 if you're willing to wait for peval to finish ;-)

> originally i tried to also build and push for cisco ios classic, but it
> died in the push.  breathe on the router and it reset bgp sessions.  i
> gather from heas that things are better these years.
> 
Better, but not good (or even tolerable). There is a reason I didn't
provide an example of doing this kind of thing on IOS classic/XE.

> i guess i really should have a go at doing it for arcos, but ...
> 
The thing that EOS and JUNOS have in common that allows this to work is
a mechanism to store config state outside the main "running config".

In JUNOS that's the ephemeral DBs, in EOS they call it "URL based
import" for as-path and prefix lists.

If ArcOS doesn't already have something similar, I'd get it on the list.

Cheers,

Ben


signature.asc
Description: PGP signature

Re: "Tactical" /24 announcements

[Ben Maddison via NANOG]

Hi David,

On 08/18, David Bass wrote:
> I'm also in the externally managed space...very cool tool though.  I love
> the idea of distributing some of this functionality.
> 
> Are you also exporting and managing this data outside?
> 
[assuming that was directed to me...]

I'm not sure what you mean by "exporting and managing this data
outside".
Would you elaborate?

Cheers,

Ben


signature.asc
Description: PGP signature

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

[Ben Maddison via NANOG]

Hi Patrick,

On 08/18, Patrick W. Gilmore wrote:
> > Of course! Including headers to show authenticity. I was very amused by the 
> > explanation of the "chicken and egg" problem. Who's creating that? The 
> > networks
> > who refuse to peer with non-peeringdb registered ASNs, or peeringdb who 
> > won't 
> > recognize ASNs that are not peering with anyone because nobody wants to 
> > peer 
> > with them because they are not registered in peeringdb because nobody wants 
> > to
> > peer with them? You get the idea.
> 
> First, most networks do not require a PDB record to peer. (Silly of
> them, I know, but still true.)
> 
> Second, you do not need to have a PDB record to get a link to an IXP.
> Even membership in a free IXP is sufficient for an account in PDB, as
> Grizz points out below.
> 
> Third, if you have an agreement, even just an email, saying a network
> will peer with you once you have a record, that may well suffice. Have
> you asked any network to peer? Private peering (because you are not on
> an IXP) is usually reserved for networks with more than a modicum of
> traffic. If your network is large enough to qualify for private
> peering, I have trouble believing you cannot get another network to
> agree to peer so you can get a record.
> 
> I guess you are right, the _Peering_DB does not register “certain”
> networks. Those networks would be ones that do not peer. Which seems
> pretty obvious to me - it is literally in the name.
> 
A PDB record for an Internet-connected ASN, listing no IXPs or
facilities, but with a note saying approximately "We only use transit,
and don't peer" has some utility: it saves prospective peers from
finding contacts to ask and sending emails, etc.

I'd argue this is in scope for PDB. But perhaps there was additional
context to the original decision that I'm missing?

Cheers,

Ben


signature.asc
Description: PGP signature

Re: "Tactical" /24 announcements

[Ben Maddison via NANOG]

Hi Saku,

On 08/17, Saku Ytti wrote:
> I share your confusion Randy. It seems like perhaps Jakob answered a
> slightly different question and his answer is roughly.
> 
> a) Use this as-set feature to ensure valid set of ASNs from given peer
> b) Validate prefix using RPKI (I'm assuming with rejecting unknowns
> and invalids)
> c) Don't punch in prefix-lists anywhere
> 
> Which in theory works, but in practice it does not, as RPKI validity
> cover is incomplete.
> 
This, and (more fundamentally) RPKI-breakage gets translated into a dataplane
outage.

> Somewhat related, when JNPR implemented RTR the architecture was
> planned so that the RTR implementation itself isn't tightly coupled to
> RPKI validity. It was planned day1 that customers could have multiple
> RTR setups feeding prefixes and the NOS side could use these for other
> purposes too. So technically JNPR is mostly missing CLI work to allow
> you to feed prefix-lists dynamically over RTR, instead of punching
> them in vendor-specific way in config.
> 
We already do essentially this on arista EOS using a custom agent.

It runs under the EOS process supervisor and calls home to a REST-API
wrapper around bgpq3. It looks for specific config lines to work out
which prefix lists to build, and then fetches them on a configurable
interval.

This has been in production for a year or two, without major incident.
It's all open source, available at 
https://github.com/wolcomm/eos-prefix-list-agent.
Pull-requests welcomed ;-)

I'm in the middle of writing the equivalent tool for junos at the
moment. Assuming that it works, we'll open source that too.

HTH,

Ben


signature.asc
Description: PGP signature

Re: NTT/AS2914 enabled RPKI OV 'invalid = reject' EBGP policies

[Ben Maddison via NANOG]

On Tue, 2020-03-31 at 13:18 +0200, Mark Tinka wrote:
> 
> On 26/Mar/20 02:50, Job Snijders wrote:
> > Dear group,
> > 
> > Exciting news! Today NTT's Global IP Network (AS 2914) enabled RPKI
> > based BGP Origin Validation on virtually all EBGP sessions, both
> > customer and peering edge. This change positively impacts the
> > Internet
> > routing system.
> 
> Good man. The club is growing :-).
> 
> Quick one - do you have ROV on any IOS or IOS XE-based boxes? We've
> had
> to walk back the few we did in recent weeks; the thing is just
> totally
> broken there.
> 
> The good news is Cisco are listening to fix suggestions, and I'm
> waiting
> for test code to verify.
> 
Tomorrow is our first ROV invalid = reject anniversary, and for most of
that time I have been in communications at various levels with Cisco
regarding the shocking brokenness in classic and XE.

Aside from some well meaning sounding email, crickets.

I very much hope, for the sake of the interwebs at large, that you have
more luck than me. We're are falling back to plan B, aka truck-roll.

Cheers,

Ben

Re: CloudFlare issues?

[Ben Maddison via NANOG]

Welcome to the club!

Get Outlook for Android


From: Francois Lecavalier 
Sent: Thursday, July 4, 2019 8:46:46 PM
To: Ben Maddison; j...@ntt.net
Cc: nanog@nanog.org
Subject: RE: CloudFlare issues?

>> At this point in time I think the ideal deployment model is to perform
>> the validation within your administrative domain and run your own
>> validators.

>+1

We'll definitely look into this shortly.  I definitely don't want to leave a 
security measure in the end of a third party but with my team being so busy it 
was a quick temp fix.

> The larger challenge has been related to vendor implementation choices and 
> bugs, particularly on ios-xe. Happy to go into more detail if anyone is 
> interested.

We are on Juniper MX204's at the edge and they have been solid for the last 60 
weeks - we ran into a long list of bugs on other platforms but not on these.

So I had about 4200 routes marked as invalid.  After looking at a sample of 
them it looks like most of them have a valid ROA with an improper mask length - 
so there is ultimately a route to these prefixes and at worse would result in 
"suboptimal" routing - or should I say: the remote network can't control its 
route propagation anymore.  In most case they are a stub networks with a single 
/24 reassigned from the upstream provider.  I have no traffic going directly to 
these networks and I don't expect any to go there anytime soon.

It's been close to 3 hours now since I dropped them - radio silence.

Whoever fears implementing RPKI/ROA/ROV, simply don't.  It's very easy to 
implement, validate and troubleshoot.

-Original Message-
From: Ben Maddison 
Sent: Thursday, July 4, 2019 11:51 AM
To: j...@ntt.net; Francois Lecavalier 
Cc: nanog@nanog.org
Subject: [External] Re: CloudFlare issues?

Hi Francois,

On Thu, 2019-07-04 at 17:33 +0200, Job Snijders wrote:
> Dear Francois,
>
> On Thu, Jul 04, 2019 at 03:22:23PM +, Francois Lecavalier wrote:
> >
> At this point in time I think the ideal deployment model is to perform
> the validation within your administrative domain and run your own
> validators.

+1

>
> > But I also have a question for all the ROA folks out there.  So far
> > we are not taking any action other than lowering the local-pref - we
> > want to make sure this is stable before we start denying prefixes.
> > So the question, is it safe as of this date to : 1.Accept valid, 2.
> > Accept unknown, 3. Reject invalid?  Have any large network who
> > implemented it dealt with unreachable destinations?  I'm wondering
> > as I haven't found any blog mentioning anything in this regard and
> > ClouFlare docs only shows example for valid and invalid, but nothing
> > for unknown.
>
We have been dropping Invalids since April, and have had only a
(single-digit) handful of support requests related to those becoming 
unreachable.

The larger challenge has been related to vendor implementation choices and 
bugs, particularly on ios-xe. Happy to go into more detail if anyone is 
interested.

I would recommend *not* taking any policy action that distinguishes Valid from 
Unknown. If you find that you have routes for the same prefix/len with both 
statuses, then that is a bug and/or misconfiguration which you could turn into 
a loop by taking policy action on that difference.

Cheers,

Ben
This e-mail may be privileged and/or confidential, and the sender does not 
waive any related rights and obligations. Any distribution, use or copying of 
this e-mail or the information it contains by other than an intended recipient 
is unauthorized. If you received this e-mail in error, please advise me (by 
return e-mail or otherwise) immediately. Ce courrier électronique est 
confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations 
qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des 
renseignements qu'il contient par une personne autre que le (les) 
destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier 
électronique par erreur, veuillez m'en aviser immédiatement, par retour de 
courrier électronique ou par un autre moyen.

Re: CloudFlare issues?

[Ben Maddison via NANOG]

Hi Francois,

On Thu, 2019-07-04 at 17:33 +0200, Job Snijders wrote:
> Dear Francois,
> 
> On Thu, Jul 04, 2019 at 03:22:23PM +, Francois Lecavalier wrote:
> > 
> At this point in time I think the ideal deployment model is to
> perform
> the validation within your administrative domain and run your own
> validators. 

+1

> 
> > But I also have a question for all the ROA folks out there.  So far
> > we
> > are not taking any action other than lowering the local-pref - we
> > want
> > to make sure this is stable before we start denying prefixes.  So
> > the
> > question, is it safe as of this date to : 1.Accept valid, 2. Accept
> > unknown, 3. Reject invalid?  Have any large network who implemented
> > it
> > dealt with unreachable destinations?  I'm wondering as I haven't
> > found
> > any blog mentioning anything in this regard and ClouFlare docs only
> > shows example for valid and invalid, but nothing for unknown.
> 
We have been dropping Invalids since April, and have had only a
(single-digit) handful of support requests related to those becoming
unreachable.

The larger challenge has been related to vendor implementation choices
and bugs, particularly on ios-xe. Happy to go into more detail if
anyone is interested.

I would recommend *not* taking any policy action that distinguishes
Valid from Unknown. If you find that you have routes for the same
prefix/len with both statuses, then that is a bug and/or
misconfiguration which you could turn into a loop by taking policy
action on that difference.

Cheers,

Ben

Re: Looking for audiovisual resources on Clos topologies

[Ben Maddison via NANOG]

Get Outlook for Android


From: NANOG  on behalf of Valdis Klētnieks 

Sent: Friday, May 3, 2019 7:22:52 PM
To: Sadiq Saif
Cc: nanog@nanog.org
Subject: Re: Looking for audiovisual resources on Clos topologies

On Fri, 03 May 2019 13:08:55 -0400, Sadiq Saif said:
> I recently read a APNIC blog post about LINE's network redesign [0] into
> a Clos topology. That lead to me RFC7938 [1] which has a fairly minimal
> explanation of the topology design itself.

>From the APNIC blog:

"In the case of LINE's network, where all servers in the data centre are
identified by eBGP, more than 10,000 ASNs are required."

They've traded L2 VLAN complexity for L3 ASN complexity.  What's the old
saying in computer science?  "All problems can be solved by adding a level
of redirection"?

> https://blog.apnic.net/2019/05/03/simplicity-is-key-to-network-redesign-for-line/

Apparently, "simplicity" is the new euphemism for "let's push all the surprising
emergent effects of our design to someplace new..."

RPKI Route Origin Validation - Africa

[Ben Maddison via NANOG]

Hello all.
In November 2018 during the ZAPF (South African Peering Forum) meeting in Cape 
Town, 3 major African ISP's announced that they would enable RPKI-based ROV 
(Route Origin Validation), including dropping Invalid routes as part of efforts 
to improve Internet routing security, on the 1st April, 2019.
On the 1st of April, Workonline Communications (AS37271) enabled ROV and began 
dropping Invalid routes. This applies to all eBGP sessions, both IPv4 and IPv6.
On the 5th of April, SEACOM (AS37100) enabled ROV and began dropping Invalid 
routes. This applies to eBGP sessions with public peers, private peers and 
transit providers, both for IPv4 and IPv6. eBGP sessions toward downstream 
customers will follow in 3 months time.
Implementation at the third ISP has yet to be completed. We are sure they will 
communicate with the community when they are ready to do so.
Please note that for the legal reasons previously discussed in various fora, 
neither Workonline nor SEACOM are utilising the ARIN TAL. As a result, any 
routes covered only by a ROA issued under the ARIN TAL will fall back to a 
status of Not Found. Unfortunately, this means that ARIN members will not see 
any improved routing security for their prefixes on our networks until this is 
resolved.
We will each re-evaluate this decision if and when ARIN's policy changes. We 
are hopeful that this will happen sooner rather than later.
If you interconnect with either of us and believe that you are experiencing any 
routing issues potentially related to this new policy, please feel free to 
reach out to either:
- noc@workonline.africa
- peer...@seacom.mu
Workonline Communications and SEACOM hope that this move encourages the rest of 
the ISP community around the world to ramp up their deployment of RPKI ROV and 
begin dropping Invalid routes. We appreciate the work that AT and others have 
carried out in the same vein.
In the mean time, we are happy to answer any questions you may have about our 
deployments.
Thanks,
Mark Tinka (SEACOM) & Ben Maddison (Workonline Communications).

Re: Report on Legal Barriers to RPKI Adoption

[Ben Maddison via NANOG]

Hi all,

Thanks Christopher and co-authors for this document. The issues that you have 
highlighted are critical to ensuring that SOV and other future applications of 
the RPKI can be deployed in production without becoming serious latent risk to 
the Internet community and RIR system.

As a case in point with respect to your recommendations regarding the RPA, we, 
AS37271, have announced that we will implement strict SOV (i.e. dropping 
Invalids) as of 1 April 2019.

As things stand today, we will not be making use of the ARIN TAL.

We have arrived at this decision primarily because we are not willing to be 
bound by the indemnification clause (paragraph 7) of the RPA. In our 
assessment, the potential (and unbounded) liability that we could be exposed to 
under that clause presents a substantial business risk, and that it is 
inappropriate given the nature of the service and the role of an RIR in 
providing authoritative data on the allocation of number resources.

I believe problems also exist in other sections of the RPA, and my strong 
preference would be for ARIN to dispense with it altogether. However, if 
paragraph 7 were to be removed, we would likely be inclined towards accepting 
it.

Since the RPA imposes substantial obligations and risks on the relying party, I 
also believe that putting convenience methods (such as click-through acceptance 
during install of RP software packages) in place will simply encourage users to 
agree to accept those risks without fully understanding them, thus storing up 
unintended legal risks for Internet operators in the future.
I therefore welcome Job and Nathalie's assertions that there is little interest 
in the community of RP software developers to implement these "features".

This mail is already plenty long enough, but I am happy to discuss in more 
detail, either on- or off-list, if others are interested.

Cheers,

Ben Maddison

Director
Workonline Communications (Pty) Ltd


From: NANOG  on behalf of Nathalie Trenaman 

Sent: 08 January 2019 12:40:33
To: Job Snijders
Cc: David Wishnick; Christopher S. Yoo; nanog@nanog.org
Subject: Re: Report on Legal Barriers to RPKI Adoption

Dear all,

After reading the report, I agree with Job it was well written and a must-read 
for everyone with an interest in RPKI, even outside the ARIN region. Well done!
As RIPE NCC is maintaining validator software, I would like to comment on point 
2:

2.   Developers of RPKI validation software should consider integrating 
acceptance of ARIN's RPA into their software workflows. ARIN recently enabled 
this possibility, and developers should deliberate on whether to capitalize on 
the opportunity.


To put it bluntly: item 2 is not going to happen.

We've discussed this extensively in the OpenBSD community (who are working on a 
new RPKI Validation implementation [source: rpki-client]), and concluded that 
collecting explicit consent to the RPA on behalf of ARIN is undesirable and 
without precedent. This doesn't exist for DNSSEC, TLS certificates, or IRR data 
- and we're not going to make an exception for ARIN and encumber each and every 
OpenBSD or rpki-client(1) installation.

I checked the temperature in the room of the other relevant RPKI Validation 
implementations, and it appears that *nobody* is planning to integrate 
acceptance of ARIN's RPA into their installation process.


I concur that for the RIPE NCC Validator this is something we don't want to 
implement.
Having said that, we do hear from our users that the current setup, where we 
point users to the ARIN TAL, is not optimal to say the least. Users simply 
don't understand why the other TALs automatically are installed and the ARIN 
TAL isn't, so we follow the discussions in the ARIN region closely.

Best regards,

Nathalie Trenaman
RIPE NCC





Op 6 jan. 2019, om 17:02 heeft Job Snijders mailto:j...@ntt.net>> 
het volgende geschreven:

Dear Christopher, David, NANOG community,

Thank you for your research and report. I found the report quite readable (not 
having a legal background) and well structured. Definitely edifying and worth 
the read! In this mail I'll reply specifically to a few points from the 
executive summary (and snip the rest).

For those of you who don't want to create a SSRN account here is a copy of the 
report:
http://instituut.net/~job/SSRN-id3309813.pdf


On Thu, 3 Jan 2019 at 23:53, Christopher S. Yoo 
mailto:cs...@law.upenn.edu>> wrote:
Here is a summary of our recommendations:
On the ROV side of the equation, the principal legal hindrances have to do with 
the terms and conditions governing access to the RPKI repository offered by 
ARIN in its Relying Party Agreement ("RPA"), and in the manner it has employed 
to ensure the agreement is binding. Regarding ROV:
1.   The goal of widespread ROV counsels in favor of ARIN reviewing its 
current approach to repository distribution, embodied in the RPA. We conclude 
that two paths would be