From rv at NIC.DTAG.DE Mon Jul 7 08:53:59 2008 From: rv at NIC.DTAG.DE (Ruediger Volk, Deutsche Telekom T-Com - TE141-P1) Date: Mon, 07 Jul 2008 08:53:59 +0200 Subject: [ca-tf] Certification Proposal In-Reply-To: Your message of "Wed, 18 Jun 2008 12:45:56 +0200." <6523871A-8AD7-4BDC-96FA-3CDDBEE907D6@ripe.net> Message-ID: <19841.1215413639@x37.NIC.DTAG.DE> 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 at NIC.DTAG.DE From robert at ripe.net Mon Jul 7 11:22:57 2008 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 07 Jul 2008 11:22:57 +0200 Subject: [ca-tf] Certification Proposal In-Reply-To: <6523871A-8AD7-4BDC-96FA-3CDDBEE907D6@ripe.net> References: <51D68FB7-C325-47BE-8D6A-0CA0D8AF2745@ripe.net> <48402459.5060308@uk.easynet.net> <6523871A-8AD7-4BDC-96FA-3CDDBEE907D6@ripe.net> Message-ID: <4871E071.8070503@ripe.net> Hi, Please allow me to propose a few enhancements: > 10. Policy text New > > The RIPE NCC issues certificates upon request. > > The requester must be a RIPE NCC member LIR holding Provider Aggregatable > (PA) address space allocations. This excludes other RIRs. It seems likely that they can ask for certificates too - for resources that have been transferred to them from RIPE NCC. > 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). I suggest we say "including, but not limited to, the LIR Portal." The reason is that the draft IETF standards include another method (see SIDR "provisioning protocol"), which will be the "official" protocol for retrieving certificates form an IR. Actually, that is going to be the only standard method - everything else is region-specific. > 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. "revoked and/or not renewed" is a bit more general. Most of the time it's enough not to issue new certificates - the old ones will expire anyway. > The RIPE NCC will issue a resource certificate covering all PA > allocations held by the LIR at the time of the request. When there is a > change in the PA allocations held by the LIR, the RIPE NCC will ensure > that there is a single, up-to-date certificate reflecting the LIR's total > PA address holdings. Note that on the longer run, LIRs will get the chance to ask for certificates with only partial coverage. There can be a number of reasons for this: preparation for key-rollover, splits and transfers too. This leads me to the question: is the policy going to be updated later on, as new services / enhancements are made, or is it better to add wording for things we foresee already? Cheers, Robert From filiz at ripe.net Mon Jul 7 13:53:03 2008 From: filiz at ripe.net (Filiz Yilmaz) Date: Mon, 7 Jul 2008 13:53:03 +0200 Subject: [ca-tf] Certification Proposal In-Reply-To: <4871E071.8070503@ripe.net> References: <51D68FB7-C325-47BE-8D6A-0CA0D8AF2745@ripe.net> <48402459.5060308@uk.easynet.net> <6523871A-8AD7-4BDC-96FA-3CDDBEE907D6@ripe.net> <4871E071.8070503@ripe.net> Message-ID: Hello, On 7 Jul 2008, at 11:22, Robert Kisteleki wrote: > Hi, > > Please allow me to propose a few enhancements: > >> 10. Policy text New >> The RIPE NCC issues certificates upon request. >> The requester must be a RIPE NCC member LIR holding Provider >> Aggregatable >> (PA) address space allocations. > > This excludes other RIRs. It seems likely that they can ask for > certificates too - for resources that have been transferred to them > from RIPE NCC. > Any RIPE NCC member who is also an LIR can ask for certificates. Note the wording referring to both "member" AND an "LIR" ( a logical AND). In today's definition a member becomes an LIR once they start holding some allocation. I thought this is (at least initially) the intention, thus the wording. >> 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). > > I suggest we say "including, but not limited to, the LIR Portal." > The reason is that the draft IETF standards include another method > (see SIDR "provisioning protocol"), which will be the "official" > protocol for retrieving certificates form an IR. Actually, that is > going to be the only standard method - everything else is region- > specific. > During the TF meeting in March, I got the opinion that the TF was keen on mentioning a specific secure channel. In today's setup it is LIR portal and this was also agreed in that meeting. If there needs to be a change in this, I will appreciate a consensus among TF members. >> 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. > > "revoked and/or not renewed" is a bit more general. Most of the > time it's enough not to issue new certificates - the old ones will > expire anyway. > Rudiger also commented on this bit. I will appreciate other TF members' input on these issues too if we are going to change what has been agreed previously and discussed in the RIPE 56. Obviously we need consensus on this before we can publish a different proposal than the one presented in the meeting :). >> The RIPE NCC will issue a resource certificate covering all PA >> allocations held by the LIR at the time of the request. When there >> is a >> change in the PA allocations held by the LIR, the RIPE NCC will >> ensure >> that there is a single, up-to-date certificate reflecting the >> LIR's total >> PA address holdings. > > Note that on the longer run, LIRs will get the chance to ask for > certificates with only partial coverage. There can be a number of > reasons for this: preparation for key-rollover, splits and > transfers too. Technical crew seems to be keen on having one single certificate for all resources by default. I think key-rollovers and maybe even splits can be covered within a procedural how-to documentation. I agree transfers is a policy matter. However, this initial proposal is not to detail down these cases (yet). > > This leads me to the question: is the policy going to be updated > later on, as new services / enhancements are made, or is it better > to add wording for things we foresee already? > I answered this partially above. The idea is to start with a policy for the simplest case and then build up on it for the rest of the more complicated cases. This also follows the path of technical implementation phases. The proposal text reads the following in the Rationale: --- 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. --- Regards, Filiz > Cheers, > Robert > From robert at ripe.net Mon Jul 7 14:15:15 2008 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 07 Jul 2008 14:15:15 +0200 Subject: [ca-tf] Certification Proposal In-Reply-To: References: <51D68FB7-C325-47BE-8D6A-0CA0D8AF2745@ripe.net> <48402459.5060308@uk.easynet.net> <6523871A-8AD7-4BDC-96FA-3CDDBEE907D6@ripe.net> <4871E071.8070503@ripe.net> Message-ID: <487208D3.9020408@ripe.net> Filiz Yilmaz wrote: > Hello, > > On 7 Jul 2008, at 11:22, Robert Kisteleki wrote: > >> Hi, >> >> Please allow me to propose a few enhancements: >> >>> 10. Policy text New >>> The RIPE NCC issues certificates upon request. >>> The requester must be a RIPE NCC member LIR holding Provider >>> Aggregatable >>> (PA) address space allocations. >> >> This excludes other RIRs. It seems likely that they can ask for >> certificates too - for resources that have been transferred to them >> from RIPE NCC. >> > > Any RIPE NCC member who is also an LIR can ask for certificates. Note > the wording referring to both "member" AND an "LIR" ( a logical AND). In > today's definition a member becomes an LIR once they start holding some > allocation. > I thought this is (at least initially) the intention, thus the wording. I understand the intent and I agree with it. OTOH, this suggests that APNIC will not be able to get their certificate from us (as they are not an LIR). Talking to them, I have the impression that they'd like to get some cert from us :-) >>> 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). >> >> I suggest we say "including, but not limited to, the LIR Portal." The >> reason is that the draft IETF standards include another method (see >> SIDR "provisioning protocol"), which will be the "official" protocol >> for retrieving certificates form an IR. Actually, that is going to be >> the only standard method - everything else is region-specific. >> > > During the TF meeting in March, I got the opinion that the TF was keen > on mentioning a specific secure channel. In today's setup it is LIR > portal and this was also agreed in that meeting. If there needs to be a > change in this, I will appreciate a consensus among TF members. Sure, this is why I'm trying to facilitate that. As it is very likely that there will be a standard way to get the certificates (again, this is the "up-down" or "provisioning" protocol), it's reasonable to expect that external entities will want to use that. Other channels, such as the LIR portal access and hosted RPKI, are value added services. >>> The RIPE NCC will issue a resource certificate covering all PA >>> allocations held by the LIR at the time of the request. When there is a >>> change in the PA allocations held by the LIR, the RIPE NCC will ensure >>> that there is a single, up-to-date certificate reflecting the LIR's >>> total >>> PA address holdings. >> >> Note that on the longer run, LIRs will get the chance to ask for >> certificates with only partial coverage. There can be a number of >> reasons for this: preparation for key-rollover, splits and transfers too. > > > Technical crew seems to be keen on having one single certificate for all > resources by default. I think key-rollovers and maybe even splits can be > covered within a procedural how-to documentation. I agree transfers is a > policy matter. However, this initial proposal is not to detail down > these cases (yet). I don't think that we want (current, in-flux) technical matters to dictate the policy. Isn't it supposed to be the other way around? ;-) Then again, if the policy will say "certificates cover all PA allocations", then policy and functionality are aligned now. Cheers, Robert > Regards, > Filiz > > >> Cheers, >> Robert >> > From filiz at ripe.net Thu Jul 24 14:13:04 2008 From: filiz at ripe.net (Filiz Yilmaz) Date: Thu, 24 Jul 2008 14:13:04 +0200 Subject: [ca-tf] Certification Proposal In-Reply-To: <19841.1215413639@x37.NIC.DTAG.DE> References: <19841.1215413639@x37.NIC.DTAG.DE> Message-ID: 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) -------------- next part -------------- A non-text attachment was scrubbed... Name: proposal_in_template_draft02-3.doc Type: application/octet-stream Size: 26624 bytes Desc: not available Url : https://www.ripe.net/ripe/mail/archives/ca-tf/attachments/20080724/f2d9998e/attachment.obj -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: proposal_in_template_draft02-3.pdf Type: application/pdf Size: 48015 bytes Desc: not available Url : https://www.ripe.net/ripe/mail/archives/ca-tf/attachments/20080724/f2d9998e/attachment.pdf -------------- next part -------------- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: proposal_in_template_draft02-3.txt Url: https://www.ripe.net/ripe/mail/archives/ca-tf/attachments/20080724/f2d9998e/attachment.txt -------------- next part -------------- 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 at NIC.DTAG.DE >