Re: [ca-tf] Certification Proposal

[Filiz Yilmaz filiz@localhost]

Dear all,

I've asked what others thought of Ruediger's latest comments and no  
one said a word, so I decided I will send my comments hoping we can  
get the discussion going. This is very important, as I stated before,  
because I am not sure if there is now enough consensus among TF  
members for me to publish the proposal formally, which will carry  
Nigel's name (but on behalf of TF) on it as agreed.
So, here are my comments:

Regarding "allocation status" (vs "membership status"), I believe  
this will not practically work very well on our side. We do not have  
a clear definition of "allocation status". Strictly speaking, it is  
not defined within RIPE policies. Trying to set a definition from  
scratch within the scope of a service proposal such as certification  
has a big potential to complicate matters and it may be out of a  
certification service scope, (assuming the idea is to keep this  
proposal as a service proposal, which should fit within the current  
addressing policy framework).
It is best to have clear criteria to issue a certificate or not from  
the beginning. Please note that unclear criteria will put RIPE NCC  
staff in a difficult situation. It would be best to have a clear  
policy so that the RIPE NCC can also produce clear and well-defined  
procedures based on that policy. It is also very important that the  
users of the service (initially just LIRs) also understand clearly  
what this service entails and under which conditions the policy is  
allowing them to use it.
In general, the policy should cover best practices for those who are  
good users and who are the majority.
Having said that, we all understand how very strict certification  
criteria can cause operational problems for the few people who fail  
to abide with the criteria, perhaps without any bad intentions. After  
conducting some internal discussion here in the NCC,  I have made  
some further changes to the proposal. The proposal now mentions  
"grace period" mechanisms explicitly. This should ensure that the aim  
is to set a policy which will not break anything for those people who  
intend to keep their allocations and continue receiving a service as  
a RIPE NCC member. So the policy should be working for those who  
follow the general good path. The aim is to be able to stop the  
service to those people who choose to cease their service level with  
the RIPE NCC. So the consequences of not abiding with the set path  
will only apply to those who seem to be abusing the system in an  
ongoing manner. I think this what any sensible and useful policy is  
trying to achieve in general.
Please let me know if this helps or not?

I've made some other changes on the text. One of these changes is  
basically the  removal of the sentence about the "single  
certificate". This has been causing problems and confusion since day  
one. It came out that there are already some wording issues about  
what exactly a single certificate means on an engineering level, and  
what people literally understand from it. Also there may be cases  
where more than one certificate may be useful. So I removed this from  
the policy proposal. It seems the RIPE NCC can deal with different  
situations, according to different needs, case by case.
Please find all the changes mentioned above in the new draft I am  
attaching this mail. I would really appreciate it if everyone can  
state their opinion on this text and then we can publish it formally  
and open up it to community for discussion, as announced at RIPE 56.
Please also note that this proposal will still follow the RIPE PDP,  
which means there may be further and further edits on it, based on  
community feedback that may be received when it is open for  
discussion. So there is still room for discussion about it. Of course  
it is best to publish an almost complete proposal that will receive  
consensus easily, but some of the points may, by their nature,  
require a broader discussion.
I hope to hear from you soon. I will assume there is consensus to go  
public with this version of the proposal if I do not hear from anyone  
with objections by 18 August (this is almost 4 weeks from today,  
which fits with RIPE PDP phases in general :)).  I would appreciate  
if those who have objections can also come up with suggestions for  
alternative wording.
Kind regards,
Filiz

ps: Following attachments are for the same content, but in different  
formats (.doc, .pdf, .txt) for your convenience)

Attachment: proposal_in_template_draft02-3.doc
Description: Binary data

Attachment: proposal_in_template_draft02-3.pdf
Description: Adobe PDF document

1. Number (will be assigned by the RIPE NCC):
2. Policy Proposal Name: Initial Certification Policy for Provider Aggregatable Address Space Holders 
3. Author: 
a. name: Nigel Titley on behalf of Certification TF
b. e-mail:
c. organisation:
4. Proposal Version: 1.0
5. Submission Date: TBA
6. Suggested RIPE WG for discussion and publication: Address Policy 
7. Proposal type: new
8. Policy term: renewable
9. Summary of proposal

The RIPE NCC plans to deploy a certification service that can be used to secure uniqueness of resources. This proposal lays out guidelines for how LIRs can receive certificates over their Provider Aggregatable (PA) address space holdings and how these certificates should be maintained.

10. Policy text
New

The RIPE NCC issues certificates upon request for Provider Aggregatable (PA) address space allocations.

The requester must be a RIPE NCC member LIR holding Provider Aggregatable (PA) address space allocations.
 
When the RIPE NCC receives a certification request, they may ask for further details to ensure that the requester is the legitimate holder of the resource. 

The certificate will be issued via a secure channel that the RIPE NCC maintains for its members (at the time of this proposal this is LIR Portal). 

Maintenance and renewal of certificates will be tied to membership status of the LIR. In cases of continuing non-payment, cessation of membership and/or closing of the LIR, existing certificates will be revoked by the RIPE NCC.  A grace period will be provided before the RIPE NCC revokes or ceases renewal of any certificates. 


11. Rationale:
a. Arguments supporting the proposal

The RIPE Certification Task Force (CA-TF) was formed at RIPE 53 to advise, review and to provide feedback about a certification system. More details about the CA-TF can be found at: 
http://www.ripe.net/ripe/tf/certification/index.html

Since RIPE 53, the CA-TF has been looking at the system from several angles such as benefits and usefulness of it as well as operational, business and policy implications that it may bring. As these issues were narrowed down for discussion, CA-TF has reported to the community in time. 

This proposal is a product of the work done by the CA-TF. The task force has studied possible policy implications and decided that a short initial policy will be useful that will be a guideline for a certification system for the RIPE community to discuss. 

At this stage, only a policy for LIRs holding PA address space is proposed. The CA-TF believes that the system should cover PA resources initially, as this is the simplest case for the system. Once a policy for PA resources for LIRs has been discussed and the community has agreed on guidelines, then the CA-TF will consider more complicated scenarios, such as PI address space and ERX and legacy address space. This phased development is also inline with the technical implementation of the system, as certificates for PA allocations will be the first real cases for the certification system when it launches. Certification of other resources will be implemented later on. 

It is proposed that the validity of certificates is tied to membership status of an LIR. This is inline with the other services that the RIPE NCC provides to its members. In order to minimise any operational impact caused by the revocation or non-renewal of certificates, a grace period will be incorporated into RIPE NCC procedures.


b. Arguments opposing the proposal



On 7 Jul 2008, at 08:53, Ruediger Volk, Deutsche Telekom T-Com -  
TE141-P1 wrote:
> Dear Filiz, dear all,
>
> > Hello,
> >
> > As promised, attached please find a proposal in RIPE Proposal
> > template. I tried to address all the points that were raised and
> > commented by Nigel after RIPE 56.
> thanks to Filiz for doing good work.
>
> Sorry for raising concerns this late.
>
> Over the last few weeks my ideas and understanding of how the  
> certificate
> information can be quickly used for improving security of the  
> actual routing
> have deepened, and I'm now very much trying to promote this very  
> seriously.
> In the course of this activety I'm taking potential arguments very  
> serious
> that could discourage network operators and users could feel from  
> using RPKI
> to protect their address space and authorize route origination.
>
> In this light I have changed my evaluation of the "Michael Dillon  
> type"
> (and similar) of concern, and I firmly believe that we MUST create  
> a policy
> that clearly and explictly ensures that certificates will be securely
> protected against any accidental revocation.
>
> > For your convenience, I attached it in 3 different file
> > formats, .doc, pdf and .txt. All files have the same content.
> >
> > You will see the major points that were agreed by the TF and
> > presented in RIPE 56 have not changed but wording is polished. Some
> > Rationale is added as part of the proposal template too. I will be on
> > holidays for the next 2 weeks so if you can have a look and pass your
> > further comments if any until 7 July, it will be great.
> I think it is wrong to "tie validity of a certificate to membership  
> status";
> it would seem more correct to tie validity of certificates to
> "allocation status" - which can be more stable than membership.
> Yes, it is easy to refer to membership - because the status and rules
> are already there. "Allocation status" on the other hand most likely
> needs work - which however may be needed to take care of other types
> of address space and relationship.
>
> The question may be raised whether going forward with this policy  
> proposal
> modified to refer to "allocation status" is possible.
> I think that this should be possible (may be adopting some temporary
> definition);  so I'd suggest to modify the reference to  
> "membershiph status"
> to "allocation status"; publish start of activety to clarify/define
> "allocation status" with special care of making it "stable and  
> trustworthy",
> and push forward with the modified policy proposal as "first limited
> implementation step".
>
> Of course work on defining rules and processes for allocation  
> status would
> need to be started quickly; this probably is not an item for CA-TF,  
> though of
> course the consequences of having RPKI as a way of voiding existing
> allocations will have to be considered. (Sorry for all the cans of  
> worms...)
> I also think that introducing RPKI and expecting it's use for securing
> actual routing raises the severity of impact that actions of the  
> RIPE NCC
> can have to an unprecedented level. As a consequence I that the  
> argument
> "just apply membership status as for other services" REALLY DOES  
> NOT APPLY.
> BTW I suspect that within CA-TF we have not yet explictly looked at
> what the legal meaning of issuing the certificates is - or how  
> these will
> be defined.
>
> > Then once it is agreed, I can publish it as a formal proposal,
> > announce it to the community for discussion and start its formal PDP
> > cycle as agreed in RIPE 56.
> >
> > Kind regards,
> > Filiz Yilmaz
> Regards,
>   Rueidger
>
>
> Ruediger Volk
>
> Deutsche Telekom AG -- Internet Backbone Engineering
>
> E-Mail:  rv@localhost