Subject: [sidr] BCP for implementing RPKI?

From: "George, Wes E [NTK]" <[email-masked]>
Date: Mon, 4 Apr 2011 00:17:53 +0000

I had a conversation with a couple of folks while at IETF that they thought I should bring to the list for discussion.

While we have an operational considerations document that covers origin validation, it focuses mainly on policy and implementation
details of the validation machinery. We don't have anything that covers the back-end of implementing a proper RPKI (from the cache
upward, rather than downward towards the router). 

Put another way, a lot of the folks involved in this protocol's design and implementation are already intimately familiar with how
to manage things like ROAs to ensure that the underlying trust of the system is not compromised. 
I (and I assume other operators and likely the RIR staff) on the other hand. not so much. Keep in mind that while we might consult
with our security folks on implementation details, that doesn't necessarily mean that we'll do it right, since the level of
knowledge of the considerations here by the security folks may be limited. Since ultimately origin validation's trust level is only
as good as the trust level associated with management of the validation keys, I'm quite certain that additional rigor is necessary
in both the way that RIRs manage their POC records and authority to request, invalidate, and reissue keys, as well as how ISPs do
the same for their downstream customers, especially since these are likely to be managed through some form of automated back-office
system or customer portal.

So I think that there is a need for a document that covers things like identity and authority management, minimum levels of security
for key management, etc.

Basically, if you had to explain to someone how to ensure that the ROAs that are being delegated are:
1)	Delegated to the right person (right company, and person authorized to make the changes within the company)
2)	Have a reasonable assumption that they will not be compromised once delegated (proper key management)
3)	Methods for managing breaches, either due to failures in #1 (disgruntled/former employee) or failures in #2
How would you do it? Are there existing documents we can use as a baseline and just fill in some of the specific details in the form
of a few different use cases, such as RIR to primary resource holder, resource holder to delegate, etc? 
An example to illustrate the reason for this - we have a subsidiary that we bought that had their own address space. Somewhere along
the way, a former employee changed the whois and POC info in ARIN's database to point to a new company, and said new company started
threatening to announce "their" address space that we were squatting on. Obviously a quick contact to ARIN sorted this out, but
under less amiable circumstances, they could have invalidated our existing ROA, issued their own, and created a serious problem for
us. While the solution is primarily that companies need to stay on top of their POC records now, we need to make that clear as a
part of the documentation that we're providing on how to implement this system and we need to try to give ideas on how best to
improve the level of trust.

I'm happy to help play the part of RPKI n00b to ensure that a draft written to cover this answers the right questions, but for the
same reason, I cannot help much with actually writing it, and am hoping that there are folks interested in picking up this work.

Thanks, 
Wes George

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Sun, 3 Apr 2011 21:48:32 -0300

I see your point, although it seems to me that the underlying problem
might be more general than RPKI. The RIRs have also been operating
business CAs for some time and I dare say they (we?) are up to the
task of correctly managing cryptographic material

This does not mean breaches can´t occur, but rather that I believe
they will be handled appropriately.

That said, I believe documenting best practices is always a good idea.
Do you think a new, different document is needed or that practices you
want documented can be included in the CPS documents ?

regards

Carlos

On Sun, Apr 3, 2011 at 9:17 PM, George, Wes E [NTK]
<[email-masked]> wrote:
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>
>

-- 
--
=========================
Carlos M. Martinez-Cagnazzo
http://www.labs.lacnic.net
=========================

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Mon, 4 Apr 2011 12:52:15 +0000

-----Original Message-----
From: Carlos Martinez-Cagnazzo [mailto:[email-masked]] 
Sent: Sunday, April 03, 2011 8:49 PM
To: George, Wes E [NTK]
Cc: [email-masked]
Subject: Re: [sidr] BCP for implementing RPKI?

That said, I believe documenting best practices is always a good idea.
Do you think a new, different document is needed or that practices you want documented can be included in the CPS documents ?

regards

Carlos
[WEG] I'm open to either. In looking at the current use cases doc: http://tools.ietf.org/html/draft-ietf-sidr-usecases-01 it seems
to be more about the BGP side of the use cases rather than the RPKI, so either there needs to be a separate doc or this needs a new
section specifically devoted to the use cases I've been referring to.

---

From: Shane Amante <[email-masked]>
Date: Mon, 4 Apr 2011 07:40:02 -0600

> upward, rather than downward towards the router). 

+1

> So I think that there is a need for a document that covers things like identity and authority management, minimum levels of security

+1

> same reason, I cannot help much with actually writing it, and am hoping that there are folks interested in picking up this work.

+1

-shane

---

From: Stephen Kent <[email-masked]>
Date: Mon, 4 Apr 2011 15:53:26 -0400

At 12:17 AM +0000 4/4/11, George, Wes E [NTK] wrote:
>...
>
>Put another way, a lot of the folks involved in this protocol's 
>design and implementation are already intimately familiar with how

A minor point: Certs are issued to represent resource holdings.  ROAs are
signed by cert holders to authorize route origination. So, the primary security
concern in the RPKI is making sure that certs are issued to the right entities.

>...
>
>So I think that there is a need for a document that covers things 
>like identity and authority management, minimum levels of security
>for key management, etc.

The right levels will vary, depending on where one is in the allocation
hierarchy.  IANA and RIRs, and NIRs need to be very careful, as they 
have the ability to mis-issue certs for very large blocks of 
addresses. Big ISPs need to be careful, because they have large 
allocations, but not so big as an RIR. Small
ISPs and PI space holders are less of a concern, because the adverse 
impact of their mistakes are more limited. So, there is no 
one-size-fits all secruity best practices model that we can define.

>ROAs that are being delegated are:

Certs are used to represent delegation, not ROAs.

>1)	Delegated to the right person (right company, and person 
>authorized to make the changes within the company)
>2)	Have a reasonable assumption that they will not be 
>compromised once delegated (proper key management)
>3)	Methods for managing breaches, either due to failures in #1 
>(disgruntled/former employee) or failures in #2
>How would you do it?

if a CA makes an allocation error, it puts the offending certs on its CRL.

>Are there existing documents we can use as a baseline and just fill 
>in some of the specific details in the form
>of a few different use cases, such as RIR to primary resource 
>holder, resource holder to delegate, etc?

note that the RPKI CP provides top-level guidance for CA operations 
(and RP behavior). Nore details about what a CA does re security 
appears in the CPS for each CA.  For example, RIPE's CPS is available 
at 
http://www.ripe.net/lir-services/resource-management/certification/cps

Steve

---

From: Benno Overeinder <[email-masked]>
Date: Mon, 18 Apr 2011 16:42:07 +0200

> upward, rather than downward towards the router). 

We (SURFnet and NLnet Labs) are running an RPKI pilot project to find
answers to the same/similar questions.  I was also thinking of a BCP,
but I was not sure as it might be quite operational oriented.

I think we are more than happy to share insights and contribute to such
a document, BCP or in any other form.

Best,

-- Benno

-- 
Benno J. Overeinder
NLnet Labs
http://www.nlnetlabs.nl/