Subject: [sidr] additions and changes to agenda on Friday

From: "Murphy, Sandra" <[email-masked]>
Date: Tue, 6 Nov 2012 17:35:46 +0000

We have three new topics to add to the agenda on Friday.

Carlos Martinez would like to present a new version of draft-rogaglia-sidr-multiple-publication-points.

Sue Hares, idr co-chair, would like to request a review of work she is doing in a limited re-write of the base BGP spec, to fix errata in error handling.  She is aware that error handling can be a source of security issues and wants to be sure any issues are considered in the re-write.

I would like to open a discussion with the wg concerning the recently announced ARIN relying party agreement.  I have concerns about this agreement's impact on the envisioned RPKI architecture and dominant use.  I think the wg needs to consider the potential impact and any potential mechanisms that would lessen impact.  Note that the IETF can not interfere with ARIN legal decisions!

These revisions will be reflected in a more detailed agenda shortly.

--Sandy

---

From: Danny McPherson <[email-masked]>
Date: Wed, 7 Nov 2012 13:29:57 -0500

> I would like to open a discussion with the wg concerning the recently announced ARIN relying party agreement.  I have concerns about this agreement's impact on the envisioned RPKI architecture and…

Sandy, 
Can you elaborate what your "concerns about this agreement's impact on the envisioned RPKI architecture and dominant use" are?  Do you have a reference or outline we can review prior to the discussion in order to keep this from being a bash-the-RIR-and-force-them-into-submission-for-trying-to-deploy-this-stuff fest?

Thanks, 

-danny

---

From: "Murphy, Sandra" <[email-masked]>
Date: Wed, 7 Nov 2012 19:28:21 +0000

Sure.

The relying party agreement is available at:

https://www.arin.net/resources/rpki/rpa.pdf

My concerns derive from the section PROHIBITED CONDUCT.

That section says it forbids the relying party (the one retrieving RPKI data from ARIN and validating wrt the ARIN trust anchor) from transferring, giving access to, copying, broadcasting, etc., any "related content". 

I think that could impact the envisioned architecture and dominant use cases,

 It also forbids "derivative works".

I think that could impact looking-glass-like or route-views-like public services, the many different sites that are reporting status and route validity, etc, so an impact on operational usability.

A couple of people have suggested mechanisms that might suit ARIN and minimize the impact and might be worth exploring.

At the ARIN meeting week before last, this was a topic of off-agenda discussions. I and others did have a chance to talk to top ARIN staff.  So they are aware.

And it is not intended to be a "bash-the-RIR" and certainly not a "-and-force-them-into-submission", since we have no authority over ARIN legal decisions.

--Sandy

________________________________________
From: [email-masked] [[email-masked]] on behalf of Danny McPherson [[email-masked]]
Sent: Wednesday, November 07, 2012 1:29 PM
To: Murphy, Sandra
Cc: [email-masked]
Subject: Re: [sidr] additions and changes to agenda on Friday

Sandy,

Thanks,

-danny

_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: Danny McPherson <[email-masked]>
Date: Wed, 7 Nov 2012 14:32:48 -0500

> I think that could impact the envisioned architecture and dominant use cases,

Agreed!

> A couple of people have suggested mechanisms that might suit ARIN and minimize the impact and might be worth exploring.

Can you (or those folks) share those on the list for consideration?

> And it is not intended to be a "bash-the-RIR" and certainly not a "-and-force-them-into-submission", since we have no authority over ARIN legal decisions.

Good, thanks!

-danny

---

From: John Curran <[email-masked]>
Date: Wed, 7 Nov 2012 23:12:34 +0000

> I think that could impact the envisioned architecture and dominant use cases,

Sandy - Could you elaborate on this just a bit?  i.e. which types of parties 
are expected to be subject to the relying party agreement would also need
to share the obtained information with others? (others who would potentially 
be unaware of the RPA as well as the CP and CPS, in all likelihood...?) 

> I think that could impact looking-glass-like or route-views-like public services, the many different sites that are reporting status and route validity, etc, so an impact on operational usability.

This can be addressed directly, as it is not the intent of ARIN to interfere
in any way with such reporting and summary services.  Obviously, it is directly
intended to prevent us from having parties relying on the published objects
themselves who are not also aware of the various terms and conditions which 
apply.  If you are running a reporting or status RPKI public service, feel 
free to ask me directly and I'll send you an official note that says "feel 
free to summarize our published data for such purposes."  If we can find a 
way to increment the RPA to safely exclude such status & reporting uses in
the future, we will do so.

Thanks!
/John

John Curran
President and CEO
ARIN

---

From: Randy Bush <[email-masked]>
Date: Thu, 08 Nov 2012 08:17:50 +0900

> which types of parties are expected to be subject to the relying party
> agreement would also need to share the obtained information with
> others? (others who would potentially be unaware of the RPA as well as
> the CP and CPS, in all likelihood...?)

sita has cache and has agreed to arin's silliness.  rama, trying not to
put load on CA publishers, rsyncs sita's cache and wants to validate it.
hanuman rsyncs rama's cache, ...

randy

---

From: Michael Sinatra <[email-masked]>
Date: Wed, 07 Nov 2012 16:48:09 -0800

On 11/07/2012 10:29, Danny McPherson wrote:

> Sandy, Can you elaborate what your "concerns about this agreement's
> impact on the envisioned RPKI architecture and dominant use" are?  Do
> you have a reference or outline we can review prior to the discussion
> in order to keep this from being a
> bash-the-RIR-and-force-them-into-submission-for-trying-to-deploy-this-stuff
> fest?

In addition to Sandy's concerns, the agreement contains a third-party 
indemnification clause (as do other ARIN RPKI-related agreements) that 
makes it difficult for many state and federal government (and large 
EDUs) to simply click through and sign.  In most of these environments, 
the network engineers who would be wanting to try out RPKI would not be 
permitted to agree to such indemnification.  This may also be true at 
large corporations.

This, I think, has very little architectural impact, but it does mean 
additional hoops for operators (like myself) to experiment with RPKI 
and/or put it in production.  As such, further discussion is probably 
out of scope for SIDR, and I will take this to arin-discuss@ 
accordingly.  But I did want to give this group an FYI that this may be 
at least a speed-bump on the deployment front.

michael

---

From: Danny McPherson <[email-masked]>
Date: Wed, 7 Nov 2012 20:19:09 -0500

On Nov 7, 2012, at 7:48 PM, Michael Sinatra wrote:

> 
> In addition to Sandy's concerns, the agreement contains a third-party indemnification clause (as do other ARIN RPKI-related agreements) that makes it difficult for many state and federal government (and large EDUs) to simply click through and sign.  In most of these environments, the network engineers who would be wanting to try out RPKI would not be permitted to agree to such indemnification.  This may also be true at large corporations.

> This, I think, has very little architectural impact, but it does mean additional hoops for operators (like myself) to experiment with RPKI and/or put it in production.  As such, further discussion is probably out of scope for SIDR, and I will take this to arin-discuss@ accordingly.  But I did want to give this group an FYI that this may be at least a speed-bump on the deployment front.

Thanks for the feedback and explanation Michael, I understand. 

Quite frankly, I share _ARIN's concern about the implications of this and their resulting exposures, and I appreciate their careful consideration of this issue.   It's certainly on _my "Risks relating to our business" radar.

I also appreciate Sandy's attempt to consider this in the context, i.e., "I think the wg needs to consider the potential impact and any potential mechanisms that would lessen impact."  and I would add "and figure out what the real constraints are and iterate our problem space and design/solutions space to accommodate these concerns."

Impacting state in routers through this machinery introduces new parties to the Internet routing system control plane, and ARIN clearly takes this seriously -- I'm glad.   

Introducing RPKI data directly into routers, which this WG is doing, will result in controls effectuated in the routing system.  This has system-wide implications and will impact my network *whether I participate in that system or not*.  This IS a fundamental architectural change to how things work today, and we all need to consider the implications very carefully.  

This fuels a great deal of my concern here, particularly when I don't see this solving some pretty fundamental issues, such as the Google incident today.

-danny

---

From: John Curran <[email-masked]>
Date: Thu, 8 Nov 2012 01:26:37 +0000

> hanuman rsyncs rama's cache, ...

In the above circumstance, how do rama and hanuman find and consider 
the terms and conditions of the CA's CP/CPS prior to building reliance
upon its surmised authentication and/or non-repudiation capabilities?

/John

---

From: Randy Bush <[email-masked]>
Date: Thu, 08 Nov 2012 10:33:02 +0900

> upon its surmised authentication and/or non-repudiation capabilities?

they don't.  they are too busy running networks, and assume CAs do their
damned jobs.

randy

---

From: John Curran <[email-masked]>
Date: Thu, 8 Nov 2012 01:54:08 +0000

> they don't.  they are too busy running networks, and assume CAs do their

We may be working on somewhat different assumptions, given that the PKIX 
certificate architecture was defined to be just like an other Internet 
PKI certificate system, i.e. there is no automatic legal binding between 
the CA and the relying party, and relying parties are responsible for 
determining whether their application of the certificates of a given CA 
is appropriate in light of applicable CP and CPS.  RFC 5280 states this 
as a basic requirement of the PKIX profile in section 2:

   "A certificate user should review the certificate policy generated by
    the certification authority (CA) before relying on the authentication
    or non-repudiation services associated with the public key in a
    particular certificate.  To this end, this standard does not
    prescribe legally binding rules or duties."

In your example, is sita taking on this responsibility on behalf of rama 
and hanuman?  It is not apparent that this type of application is within
the standard's stated requirements, so it should not be surprising that 
there's an impedance mismatch occurring.

FYI,
/John

---

From: Randy Bush <[email-masked]>
Date: Thu, 08 Nov 2012 11:09:21 +0900

> and hanuman?

no need.  this is object based security.  rama and hanuman have tals and
validate.  having every cache in the world hit the CAs is not gonna
scale.

you may want to look at my ripe and nanog presos on the scaling
experiments we did.

randy

---

From: John Curran <[email-masked]>
Date: Thu, 8 Nov 2012 03:27:02 +0000

On Nov 7, 2012, at 9:09 PM, Randy Bush <[email-masked]>
 wrote:

> validate.  

This would leave Rama and hanuman dependent on the CA services but 
not aware of the CPS term and conditions despite the explicit 
requirement specified in the PKIX profile?   If instead they get 
the TAL from the RIR CA (once), then they can then readily validate 
the objects but will also be aware of the relevant CA certificate 
policies that are to be considered before establishing reliance
on these services.  

/John

---

From: Randy Bush <[email-masked]>
Date: Thu, 08 Nov 2012 12:39:57 +0900

> This would leave Rama and hanuman dependent on the CA services but not
> aware of the CPS term and conditions despite the explicit requirement
> specified in the PKIX profile?

OMG!!!  my router forgot to call her lawyer!  call the network police?

john, you have been out of ops for waaaaay too long.

randy

---

From: Shane Amante <[email-masked]>
Date: Wed, 7 Nov 2012 22:48:54 -0500

Michael,

> This, I think, has very little architectural impact, but it does mean additional hoops for operators (like myself) to experiment with RPKI and/or put it in production.  As such, further discussion…

I (also) commend ARIN for their due diligence on this matter.  Commercial operators, in particular, should carefully evaluate the risks posed to their core business (selling Internet transit) by now being reliant on certificate information that directly affects _reachability_information_ carried within their network.  That certificate information is maintained by an outside party that's outside the operator organization's _direct_ (immediate) control and for which they, seemingly, have no recourse if (when?) something goes wrong.  That risk without remedies/recourse is not something commercial entities are prone to voluntarily accept.

Obviously, each operator should seek advice from their own legal counsel as to the risks and make their own decisions.

-shane

---

From: John Curran <[email-masked]>
Date: Thu, 8 Nov 2012 03:55:02 +0000

> john, you have been out of ops for waaaaay too long.

I know that just smashing the bits together until they click seems like 
a lot of fun, but the semantics behind the PKIX certificates are actually 
there for good reason. While I'm sure you can make the bits syntactically
fit, it is equally important that there is an actual meeting of the minds
regarding the nature of the services to provided by the CA and to be used 
by the relying party.

/John

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 8 Nov 2012 00:56:48 -0500

> regarding the nature of the services to provided by the CA and to be used

are you really saying that the RP should simply download (or have
downloaded as part of the repository data) the CPS documents? Would
that resolve the problem here? (I think that's all the arin doc is
actually doing, making me download a cps and read/review/agree to that
document, right?)

-chris

---

From: heasley <[email-masked]>
Date: Thu, 8 Nov 2012 07:07:32 +0000

Thu, Nov 08, 2012 at 03:27:02AM +0000, John Curran:
> requirement specified in the PKIX profile?

It looks like a SHOULD to me, not a MUST.  no?

---

From: "Murphy, Sandra" <[email-masked]>
Date: Thu, 8 Nov 2012 11:25:44 +0000

Speaking as regular ol' member

On Wednesday, November 07, 2012 10:48 PM, Shane Amante [[email-masked]] said:

>Commercial operators, in particular, should carefully evaluate the risks posed to
> their core business (selling Internet transit) by now being reliant on certificate 
>information that directly affects _reachability_information_ carried within their 
>network.  That certificate information is maintained by an outside party that's 
>outside the operator organization's _direct_ (immediate) control and for
> which they, seemingly, have no recourse if (when?) something goes wrong.

I think the Internet is already there.

There are ISPs that spend considerable energy creating prefix filters from IRR data and strongly encourage their customers to register in IRRs.  Those registers are maintained by an outside party that's outside the operator organization's direct control.  Those registered objects directly affect reachability information carried within their network.

Commercial operators have been comfortable with this mode of operation for many years.  I doubt whether any of them have felt the need to carefully evaluate the risks or consult their legal departments.  It has been best current practice and urged on operators at *OG meetings.

I don't think we want people asking ISPs that use IRRs why they run such a risky operation.

--Sandy, speaking as regular ol' member

________________________________________
From: [email-masked] [[email-masked]] on behalf of Shane Amante [[email-masked]]
Sent: Wednesday, November 07, 2012 10:48 PM
To: Michael Sinatra
Cc: [email-masked]; Murphy, Sandra
Subject: Re: [sidr] additions and changes to agenda on Friday

Michael,

-shane

---

From: Danny McPherson <[email-masked]>
Date: Thu, 8 Nov 2012 07:40:11 -0500

On Nov 8, 2012, at 6:25 AM, Murphy, Sandra wrote:

> I doubt whether any of them have felt the need to carefully evaluate the risks or consult their legal departments. 

And therein lies the disconnect!  

I think it'd be extremely naive to think that operators don't know, or care about, or evaluate the risks of the systems that enable their operations.  If this weren't the case, many of those folks that have expressed concern here would not do so.

Given that our services and businesses rely on these systems with varying levels of buffers, I assure you that _many [most] operators DO carefully evaluate the risks and consult their legal departments.  This isn't simply a science project.

> I don't think we want people asking ISPs that use IRRs why they run such a risky operation.

I think that's exactly what we want.  That's the purpose of engineering and risk management, and why operators that operate commercial networks, care a whole lot when you introduce a new dependency. 

-danny

---

From: "Murphy, Sandra" <[email-masked]>
Date: Thu, 8 Nov 2012 13:17:39 +0000

Shane's message said that reliance on outside parties was a risk.  I was pointing out that operators already are relying on outside parties.  Whatever means they employ now to evaluate risk or legal impact, they are comfortable with outside parties.

If operators always consult their legal departments on deploying new features, then there is no need to advise them to consult their legal departments.

Tutorials galore urging use of route filters (and drafts describing same) never find it necessary to add "and consult your legal department".  Perhaps as you say, that is because operators always consult their legal departments.  But if so, this is no different.

--Sandy, speaking as regular ol' member
________________________________________
From: Danny McPherson [[email-masked]]
Sent: Thursday, November 08, 2012 7:40 AM
To: sidr wg list; Murphy, Sandra
Subject: Re: [sidr] additions and changes to agenda on Friday

-danny

---

From: Danny McPherson <[email-masked]>
Date: Thu, 8 Nov 2012 08:44:34 -0500

> Shane's message said that reliance on outside parties was a risk.  I was pointing out that operators already are relying on outside parties.  Whatever means they employ now to evaluate risk or lega…

That's a rather liberal use of "comfortable", methinks.

> If operators always consult their legal departments on deploying new features, then there is no need to advise them to consult their legal departments.

This is incorrect.  

It's "Risks to our business" -- "risks" is plural, and new risks that do not lessen overall residual threats are problematic in real companies, especially public ones.

-danny

---

From: Shane Amante <[email-masked]>
Date: Thu, 8 Nov 2012 09:01:06 -0500

Sandy,

> --Sandy, speaking as regular ol' member

There is not, in my understanding, a single root for the IRR's.  Although RIR's for a particular region do allocate and register those resources (IP prefixes, ASN's, etc.) into their respective IRR instance ... there is absolutely nothing stopping the resource holder from registering their resources in one, or more, "3rd-party IRR" instances /not/ run or controlled by any RIR, i.e.: RADB, ALT.DB, etc.  IMO, the ability to do that constitutes "risk mitigation" on the part of the resource holder who publishes their objects (customer) as well as the _direct_ ISP's (from whom their buy service) that consume those objects, since there is no single, central authority with direct control over their business.

That said, I acknowledge the downside with the present IRR model is that, in most instances, no IRR can express authority for the resources held in their IRR DB.  IMO, that creates a problem for /3rd-parties/ -- researchers, LEO, etc. -- who have no direct (contractual) relationship with both the ISP and their customer, since those third-parties have a difficult time in understanding which IRR to believe has the most up-to-date copy of resources.  However, keep in mind (and this is key here), that each ISP *does* have a direct contractual relationship with its customers.  At the time such contracts are signed, the customer must tell the ISP which specific IRR instance(s) the customer has registered and maintains their IRR objects, which gets around at least /part/ (but, not all) of the problem.  

Before you respond with: each RP (ISP) in the RPKI system is free to choose whatever TA's they want to mitigate such risks -- I would ask: if ISP's did that, how is that /any/ different from the operation of the present-day IRR model?  IMO, it's not clear that the RPKI is "fixing" anything, unless everyone voluntarily or _involuntarily_ accepts a single-rooted RPKI as the sole source of resource information ...

As with many things, risk is subjective and each party in a system should decide for themselves what constitutes acceptable risk for their operations.

-shane

P.S. -- I apologize for having veered off of technical topics for an IETF mailing list.  I will refrain from responding to this thread further.

---

From: "Murphy, Sandra" <[email-masked]>
Date: Thu, 8 Nov 2012 14:37:17 +0000

On Thursday, November 08, 2012 8:44 AM, Danny McPherson [[email-masked]] said:

>> If operators always consult their legal departments on deploying new features, 
>>then there is no need to advise them to consult their legal departments.
>
>This is incorrect.
>
>It's "Risks to our business" -- "risks" is plural, and new risks that do not lessen 
>overall residual threats are problematic in real companies, especially public ones.

I think you may have misread my statement.  I did not say there was no need to consult their legal departments.  I said there was no need to advise them to consult their legal department.  Your thesis was that they always do.  So no need to tell then to do it.

--Sandy

---

From: Arturo Servin <[email-masked]>
Date: Thu, 08 Nov 2012 10:12:53 -0500

> validate.  having every cache in the world hit the CAs is not gonna

	Yes, perhaps we need a different architecture and transport protocol.

	But that is beyond this thread and topic.

> you may want to look at my ripe and nanog presos on the scaling

	More arguments to think on alternate paths.

as

---

From: Danny McPherson <[email-masked]>
Date: Thu, 8 Nov 2012 10:54:17 -0500

On Nov 8, 2012, at 9:37 AM, Murphy, Sandra wrote:
> 
> I think you may have misread my statement.

No, I didn't: On Nov 8, 2012, at 6:25 AM, Murphy, Sandra wrote:

"I doubt whether any of them have felt the need to carefully evaluate the risks or consult their legal departments." 

In response: November 8, 2012 7:40:11 AM EST, I said:

"Given that our services and businesses rely on these systems with varying levels of buffers, I assure you that _many [most] operators DO carefully evaluate the risks and consult their legal departments."

>   I did not say there was no need to consult their legal departments.  I said there was no need to advise them to consult their legal department.

>  Your thesis was that they always do.  

No, it wasn't - go reread [1], or see text above.  Please don't tell me what I said, and please don't assume operators are naive.

-danny

[1] inline below:

Begin forwarded message:

> From: Danny McPherson <[email-masked]>
> Date: November 8, 2012 7:40:11 AM EST
> To: sidr wg list <[email-masked]>, Sandra Murphy <[email-masked]>
> 
>

---

From: "Murphy, Sandra" <[email-masked]>
Date: Thu, 8 Nov 2012 15:55:16 +0000

Sorry, you did not say "all" you said "most"

--Sandy
________________________________________
From: Danny McPherson [[email-masked]]
Sent: Thursday, November 08, 2012 10:54 AM
To: Murphy, Sandra
Cc: sidr wg list
Subject: Re: [sidr] additions and changes to agenda on Friday

-danny

[1] inline below:

---

From: Danny McPherson <[email-masked]>
Date: Thu, 8 Nov 2012 11:03:13 -0500

> Sorry, you did not say "all" you said "most"

Sandy, could you please not take this out of context?  I quoted it below, but one more time:

I said "_many [most] operators DO carefully evaluate the risks and consult their legal departments."

Do you agree with that?

-danny

---

From: "Murphy, Sandra" <[email-masked]>
Date: Thu, 8 Nov 2012 16:14:49 +0000

Sorry, I thought your complaint that I was misquoting was that I had said "all" when you said "most".

So your complaint that I am misquoting is...  what did I get wrong?

I'm lost in a maze of twisty passages.

--Sandy
________________________________________
From: Danny McPherson [[email-masked]]
Sent: Thursday, November 08, 2012 11:03 AM
To: Murphy, Sandra
Cc: sidr wg list
Subject: Re: [sidr] additions and changes to agenda on Friday

Do you agree with that?

-danny

---

From: Danny McPherson <[email-masked]>
Date: Thu, 8 Nov 2012 11:17:27 -0500

> So your complaint that I am misquoting is...  what did I get wrong?

This: 

=========================
On Nov 8, 2012, at 9:37 AM, Murphy, Sandra wrote:

"Your thesis was that they always do."
=========================

That is wrong, it is NOT my thesis.

> I'm lost in a maze of twisty passages.

Yes, apparently.

-danny

---

From: Michael Sinatra <[email-masked]>
Date: Thu, 08 Nov 2012 09:44:45 -0800

On 11/8/12 6:01 AM, Shane Amante wrote:
>>> Commercial operators, in particular, should carefully evaluate
>>> the risks posed to their core business (selling Internet transit)
>>> by now being reliant on certificate information that directly
>>> affects _reachability_information_ carried within their network.
>>> That certificate information is maintained by an outside party
>>> that's outside the operator organization's _direct_ (immediate)
>>> control and for which they, seemingly, have no recourse if
>>> (when?) something goes wrong.
>> 
>> There are ISPs that spend considerable energy creating prefix
>> filters from IRR data and strongly encourage their customers to
>> register in IRRs.  Those registers are maintained by an outside
>> party that's outside the operator organization's direct control.
>> Those registered objects directly affect reachability information
>> carried within their network.
>> 
>> Commercial operators have been comfortable with this mode of
>> operation for many years.  I doubt whether any of them have felt
>> the need to carefully evaluate the risks or consult their legal
>> departments.  It has been best current practice and urged on
>> operators at *OG meetings.
>> 
> There is not, in my understanding, a single root for the IRR's.
> Although RIR's for a particular region do allocate and register those
> resources (IP prefixes, ASN's, etc.) into their respective IRR
> instance ... there is absolutely nothing stopping the resource holder
> from registering their resources in one, or more, "3rd-party IRR"
> instances /not/ run or controlled by any RIR, i.e.: RADB, ALT.DB,
> etc.  IMO, the ability to do that constitutes "risk mitigation" on
> the part of the resource holder who publishes their objects
> (customer) as well as the _direct_ ISP's (from whom their buy
> service) that consume those objects, since there is no single,
> central authority with direct control over their business.
> 
> That said, I acknowledge the downside with the present IRR model is
> that, in most instances, no IRR can express authority for the
> resources held in their IRR DB.  IMO, that creates a problem for
> /3rd-parties/ -- researchers, LEO, etc. -- who have no direct
> (contractual) relationship with both the ISP and their customer,
> since those third-parties have a difficult time in understanding
> which IRR to believe has the most up-to-date copy of resources.
> However, keep in mind (and this is key here), that each ISP *does*
> have a direct contractual relationship with its customers.  At the
> time such contracts are signed, the customer must tell the ISP which
> specific IRR instance(s) the customer has registered and maintains
> their IRR objects, which gets around at least /part/ (but, not all)
> of the problem.
> 
> Before you respond with: each RP (ISP) in the RPKI system is free to
> choose whatever TA's they want to mitigate such risks -- I would ask:
> if ISP's did that, how is that /any/ different from the operation of
> the present-day IRR model?  IMO, it's not clear that the RPKI is
> "fixing" anything, unless everyone voluntarily or _involuntarily_
> accepts a single-rooted RPKI as the sole source of resource
> information ...
> 
> As with many things, risk is subjective and each party in a system
> should decide for themselves what constitutes acceptable risk for
> their operations.

I think these are very valid points from an operational standpoint, but
that is not the concern regarding the third-party indemnification
clause.  The third-party indemnification means that I have to assume all
of ARIN's liability arising from *my* use of the RPKI, if I choose to
use it.  IANAL, so it is not clear to me if that covers cases where
clearly ARIN is at fault.  I assume that the legitimate intention is to
avoid a MAPS-like situation, where the RIR gets sued because I choose
not to carry ISP-X's routes because of invalid ROAs.  But what if the
RIR does something stupid and breaks RPKI and I stop carrying ISP-X's
routes?  Do I have to assume the RIR's liability?  My layman's
perspective on this is that we should ditch the indemnification clause
and each have to assume our own risks--and that seems to be consistent
with your argument.

At any rate, I am pretty sure this issue isn't an IETF concern, and I
will raise this on arin-discuss@ later today or tomorrow.  ARIN members
are welcome to join me there.

michael

---

From: heasley <[email-masked]>
Date: Thu, 8 Nov 2012 18:16:34 +0000

> There are ISPs that spend considerable energy creating prefix filters from IRR data and strongly encourage their customers to register in IRRs.  Those registers are maintained by an outside party t…

Some operators maintain their own registry and mirror the database of others,
as we do.  Others run their own server which mirrors the DB of some subset of
registries.  Others rely on the servers operated by those who own the
registries (or other publicly available servers).

We'll do the same, to whatever extent possible, for rpki, so as to be as
independant as possible.

> Commercial operators have been comfortable with this mode of operation for many years.  I doubt whether any of them have felt the need to carefully evaluate the risks or consult their legal departm…

Not all that comfortable; but it is what we have.  we expend great effort to
insulate ourselves from failures.

---

From: Randy Bush <[email-masked]>
Date: Fri, 09 Nov 2012 18:07:33 +0900

> Yes, perhaps we need a different architecture and transport protocol.

measurement has shown that rsync is about as good as you're gonna do
performance-wise for a system where publication is centralized.

and have a look at the ripe publication loads late last month.  way to
go tim and alex.

> More arguments to think on alternate paths.

actually, the results were the opposite.

not that i am uninterested in working on future architectures.

randy

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 9 Nov 2012 09:35:18 -0500

Hi,

On Nov 9, 2012, at 4:07 AM, Randy Bush <[email-masked]> wrote:

> performance-wise for a system where publication is centralised.

Could you share those measurements?

When we did lab testing on this our results were rather different.

Presented at the interim in Vancouver:
http://www.ietf.org/proceedings/interim/2012/07/27/sidr/slides/slides-interim-2012-sidr-5-0.pdf

If one looks at just the simple case of performing a recursive rsync on a substantial rsync repository to determine if there are any updates, when there are none.. so just the overhead, determining this, no data transferred..

Then it's clear that rsync is not able to deal with substantial load and it's trivial to DoS.

http://www.ietf.org/proceedings/interim/2012/07/27/sidr/slides/slides-interim-2012-sidr-5-1.pdf

Here we proposed having a simple update file (10kB for test purposes) that can be fetched to determine if updates are needed. This performs several orders of magnitude better than doing a recursive rsync (5000 req/s vs 2 req/s on simple hardware). Then looking at the transport for just this file using http is roughly 10 times better than rsync (non-recursive, just that file).

> and have a look at the ripe publication loads late last month.  way to

I agree that given the current architecture a hierarchical structure is better for clients.

As I mentioned though this is hard on the server for substantial repositories (roughly 10 times today: 70k objects and up vs our 7k today).

> not that i am uninterested in working on future architectures.

Good. On that note I think it's worthwhile thinking about different complementary ways to deal with this. I.e. make the server side more scalable as well as considering flooding protocols and other ways to share data between RPs.

---

From: Arturo Servin <[email-masked]>
Date: Fri, 09 Nov 2012 11:36:00 -0500

Related to our presentation today, if you are curious about why we have
a lot of invalids:

IPv4
http://www.labs.lacnic.net/rpkitools/looking_glass/rest/invalid/cidr/0.0.0.0/0/

	For v6 our app does not support to query all the invalids, but you can
check with something like:

http://www.labs.lacnic.net/rpkitools/looking_glass/rest/all/cidr/2001%3A13c7%3A7002%3A%3A/48/

	Or just go to:

http://www.labs.lacnic.net/rpkitools/looking_glass/

Regards
as

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 14 Nov 2012 17:27:00 -0500

On Fri, Nov 9, 2012 at 9:35 AM, Tim Bruijnzeels <[email-masked]> wrote:
> Good. On that note I think it's worthwhile thinking about different
> complementary ways to deal with this. I.e. make the server side more
> scalable as well as considering flooding protocols and other ways to share
> data between RPs.

can we break the 'current protocol choice' away from the 'future
protocol choice(s)' discussion then? Meaning, can those folk
interested in pursuing alternate options decide on:
  1) size of a single repository (pick a large ISP as a for-instance,
some one like L3 who has ~30k customers, each with 5 routes average x2
for keyroll situations? - or better yet, make up your own set of
numbers, document them and the reasoning why)
  2) number of repositories in existence (say, number of ASN in the
global table, or ...)
  3) re-fetch times of every repository (3 hrs for instance for any
object type?)
  4) average network latency from fetcher to fetchee (~150ms for instance)

document that and then start looking at tradeoffs and consequences?
talking about other transports is good, I think to date we keep
getting muddled in 'but today works so...' If we want to re-think the
transport, or offer alternate transports for existing folks, let's
step away from 'today works'.

-chris
regular-guy-voice.