Resource Certification for non-RIPE NCC Members
Dear community members of the AP WG and the NCC Services WG, As you may have seen, Ive created a policy proposal to ask the RIPE NCC to allow Resource Certification for non-RIPE NCC member resource holders. (IXP / Legacy space and PI space holders) Currently we are in the phase: Discussion Open for discussion And I would like to invite you to the service wg mail list for your support for this policy and a discussion on wording of the policy. For those that are not subscribed to the NCC Services mail-list -=> http://www.ripe.net/mailman/listinfo/ncc-services-wg/ During the creation of the policy I made a small error in the intention to limit the policy to entities in the RIPE NCC service region and the policy currently states: The Internet resources reside within the RIPE NCC service region Ill update this in the review phase. Im not sure yet if we need to skip that part entirely or change it to the actual intention. Your input and stated support on the NCC Services WG mail list would be highly appreciated. Kind regards, Erik Bais Link to the policy proposal: https://www.ripe.net/ripe/policies/proposals/2013-04
Hi, On Mon, Jun 03, 2013 at 02:08:46PM +0200, Erik Bais wrote:
As you may have seen, Ive created a policy proposal to ask the RIPE NCC to allow Resource Certification for non-RIPE NCC member resource holders. (IXP / Legacy space and PI space holders)
Speaking as a router operator, I support this proposal. For services offered by the RIPE NCC, the history and colour of an IP prefix should not make a difference - so "PA", "PI" or "legacy" prefixes should be treated all the same. (If the community decides to abandon RPKI because of whatever reason, fine with me - but as long as the paying members have voted to keep the RPKI system running, it needs to work for all prefixes that the RIPE NCC feels authoritative to state "this person is entitled to decide who gets to route the prefix" - i.e. verified contract holders, LIRs, etc) Gert Doering -- internet operator -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On Mon, Jun 03, 2013 at 04:06:24PM +0200, Gert Doering wrote:
For services offered by the RIPE NCC, the history and colour of an IP prefix should not make a difference - so "PA", "PI" or "legacy" prefixes should be treated all the same.
Logically, if there is no policy for PA space, there should be none for PI/legacy space.
(If the community decides to abandon RPKI because of whatever reason,
The community *has* decided to abandon RPKI, at least where policy is concerned. rgds, Sascha Luck
And I would like to invite you to the service wg mail list for your support for this policy and a discussion on wording of the policy.
my routers do not know the difference between PI, PA, Legacy, or whatever. i suspect that no one has routers which differentiate. randy
Am Mo 03 Jun 2013 16:57:34 CEST schrieb Randy Bush:
my routers do not know the difference between PI, PA, Legacy, or whatever. i suspect that no one has routers which differentiate.
randy
+1 IMHO the whole system only make sense, when it is open for all resources! BR -- Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo@opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989
* Jens Ott:
IMHO the whole system only make sense, when it is open for all resources!
Wouldn't this mean that ARIN (or LACNIC or ...) could issue resource certification for resources allocated to you by RIPE NCC? Resource certification outside the regular hierarchical model can get very messy. (That's probably the most significant advantage of DNSSEC over the out-of-tree browser PKI.)
Subject: Re: [ncc-services-wg] Resource Certification for non-RIPE NCC Members Date: Mon, Jun 03, 2013 at 09:57:34AM -0500 Quoting Randy Bush (randy@psg.com):
And I would like to invite you to the service wg mail list for your support for this policy and a discussion on wording of the policy.
my routers do not know the difference between PI, PA, Legacy, or whatever. i suspect that no one has routers which differentiate.
a router that differentiates is not only a router but also a cgn. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 It's OKAY -- I'm an INTELLECTUAL, too.
In message <m24ndfqm1t.wl%randy@psg.com>, at 09:57:34 on Mon, 3 Jun 2013, Randy Bush <randy@psg.com> writes
my routers do not know the difference between PI, PA, Legacy, or whatever. i suspect that no one has routers which differentiate.
It might happen one day, if only a subset are present in a database that your router has been programmed to check authentication against, or only a subset are accompanied by a digital signature that becomes "de rigueur" to have. -- Roland Perry
On Mon, Jun 3, 2013 at 10:08 PM, Erik Bais <ebais@a2b-internet.com> wrote:
Dear community members of the AP – WG and the NCC Services WG,
As you may have seen, I’ve created a policy proposal to ask the RIPE NCC to allow Resource Certification for non-RIPE NCC member resource holders. (IXP / Legacy space and PI space holders)
Currently we are in the phase: Discussion – Open for discussion
And I would like to invite you to the service wg mail list for your support for this policy and a discussion on wording of the policy.
I support the proposal. Situation when 'all IP addresses are equal, but some addresses are more equal than others' does not make much sense to me. -- SY, Jen Linkova aka Furry
On Thu, Jun 06, 2013 at 11:54:44PM +1000, Jen Linkova wrote:
I support the proposal. Situation when 'all IP addresses are equal, but some addresses are more equal than others' does not make much sense to me.
Right now, there is no policy that allows for *any* resources to be (NCC-) signed. If this proposal passes, there will be a situation where there is a policy for PI/Legacy resources and *no policy* for PA resources. rgds, Sascha Luck
Hi Erik, Community, a couple of general comments before potentially going into details on the Services WG. Whether we need a formal "policy" or just an agreement (amongst the members of the NCC) to a Service Description and a review of the CPS as maintained by the NCC is a sideline issue, imho. For now using the framework of the PDP maybe useful and appropriate. I concur with other comments already, that - at the moment - there is, and probably shouldn't be - a different colour related to PA, PI, ERX, v4, v6, you name it. So, whatever we come up with should be "the same", technically. Looking at the proposed text for discussion, I sense a mindset of "the NCC is the sole source of the Certificates". This may be reasonable for those paries, which do have a direct Service Contract with the NCC (Direct End User, Legacy). For all the others, there is - or structurally, will be - a managed foodchain and Hierarchy. This may be ° the path of NCC - LIR for PA (v4+v6) - assignments, or ° the path of NCC - LIR - contract for DER (Direct Enduser Resources). In the end we SHOULD, imo, structure the service definition *and* the implementation to be congruent to this structe. I.e. the LIRs SHOULD be the parties issuing the certificates for those resources which are held by their users/customers, and for which there is a contract. Trying to bypass the LIRs and/or messing around with some sort of backdoor structure for cert.creation, and "verification" by the NCC, would become messy. We (my team) DO have real life experience, that such a disjunct and artificial mechanism is a pain, and a source for inconsistencies. And, last but not least, in order to potentially, in the (near?) future, overcome the "single point of failure thing" (that we are creating now by building a "proper" tree structure!), removing any and all notion of the Service Region would have my *strong* support. Not just because it will be difficult to find a proper definition of "reside within", but more so because it would open the chance to actually acquire certificates from more than one "root", aka CA. These multiple roots/CAs could either (preferably?) be the set of RIRs, but other parties as well. This would take away most of my worries and reservation related to the proliferation of the RPKI. Sorry for the long text ;-) Wilfried. Erik Bais wrote:
Dear community members of the AP – WG and the NCC Services WG,
As you may have seen, I’ve created a policy proposal to ask the RIPE NCC to allow Resource Certification for non-RIPE NCC member resource holders. (IXP / Legacy space and PI space holders)
Currently we are in the phase: Discussion – Open for discussion
And I would like to invite you to the service wg mail list for your support for this policy and a discussion on wording of the policy. For those that are not subscribed to the NCC Services mail-list -=> http://www.ripe.net/mailman/listinfo/ncc-services-wg/
During the creation of the policy I made a small error in the intention to limit the policy to entities in the RIPE NCC service region and the policy currently states:
• The Internet resources reside within the RIPE NCC service region
I’ll update this in the review phase. I’m not sure yet if we need to skip that part entirely or change it to the actual intention.
Your input and stated support on the NCC Services WG mail list would be highly appreciated.
Kind regards, Erik Bais
Link to the policy proposal: https://www.ripe.net/ripe/policies/proposals/2013-04
Hi Wilfried, First of all, let me say thanks for the feedback.
Whether we need a formal "policy" or just an agreement (amongst the members of the NCC) to a Service Description and a review of the CPS as maintained by the NCC is a sideline issue, imho.
For now using the framework of the PDP maybe useful and appropriate.
Looking at the proposed text for discussion, I sense a mindset of "the NCC is the sole source of the Certificates". This may be reasonable for those
So do I. paries,
which do have a direct Service Contract with the NCC (Direct End User, Legacy).
For all the others, there is - or structurally, will be - a managed foodchain and Hierarchy.
This may be ° the path of NCC - LIR for PA (v4+v6) - assignments, or ° the path of NCC - LIR - contract for DER (Direct Enduser Resources).
In the end we SHOULD, imo, structure the service definition *and* the implementation to be congruent to this structe. I.e. the LIRs SHOULD be the parties issuing the certificates for those resources which are held by their users/customers, and for which there is a contract.
Trying to bypass the LIRs and/or messing around with some sort of backdoor structure for cert.creation, and "verification" by the NCC, would become messy. We (my team) DO have real life experience, that such a disjunct and artificial mechanism is a pain, and a source for inconsistencies.
The proposal was specifically written without a structure on how the NCC should implement the system towards the PI or Legacy resource holders. In my opinion that is a complete different discussion than a decision on IF we want resource certification for resources of non-RIPE NCC members. I understand that it might be tempting to state how we want to have it implemented or even move into the area where we ask ourselves the question, who is going to pay for this and how? However in order to keep the discussion as simple as possible and not to force the discussion or proposal about how to do the implementation into a certain direction or to hand-cuff the NCC on how they operate the systems, it was specifically written without how / who / SHOULD or structure. It is simply a question to allow non-RIPE NCC members their resources to be certified. I'm sure that there will be questions after this, about what the better structure would be (option 1,2,3), implications etc etc.
And, last but not least, in order to potentially, in the (near?) future, overcome the "single point of failure thing" (that we are creating now by building a "proper" tree structure!), removing any and all notion of the Service Region would have my *strong* support. Not just because it will be difficult to find a proper definition of "reside within", but more so because it would open the chance to actually acquire certificates from more than one "root", aka CA.
The specific sentence has been adjusted as it was provided based on input during the discussion phase to: -the Internet resources are registered in the RIPE registry. As certification is very closely related to the registration of resources, I would like to limit it to the RIPE registry for now. I can see your point on a more global view and desire, however I would prefer to take small steps here. Let's get this in place for the resources in the RIPE registry. If we have this step taken, we can always adjust the specifics if we need/want to move to a more distributed model. Currently it is my goal to have this sorted for the resources in the RIPE registry.
These multiple roots/CAs could either (preferably?) be the set of RIRs, but other parties as well. This would take away most of my worries and reservation related to the proliferation of the RPKI.
As stated earlier, I'm not going, in the current discussion, going to move away from the as-is situation. There is a current implementation and it is missing most of the resources. Yes I see how a more distributed environment might be better, however it is beyond the scope of this proposal. Any discussion on a distributed model is in vain imho if we exclude the current group for which this proposal is created.
Sorry for the long text ;-) Wilfried.
Thanks for the input and I hope to have answered your questions. Regards & have a nice weekend, Erik Bais
As you may have seen, I’ve created a policy proposal to ask the RIPE NCC to allow Resource Certification for non-RIPE NCC member resource holders. (IXP / Legacy space and PI space holders)
As a PI holder and a router operator I support this proposal. I want others be able to verify my prefixes. RPKI, if used widely, can be a much more acurate source for routing information than the databases are. Even in RIPE region, where the database tends to be well maintained. The more resource holders are allowed to use RPKI, the better. I would even pay a fee for the signing process of my resources, just in case this is about money.
I must admit that i myself as PI holder and service operator completely agree with Dan and think that RPKI certification should be somehow achievable by PI holders themselves without need to do any kinds of requests to LIR. 2013/6/10 Dan Luedtke <maildanrl@gmail.com>
As you may have seen, I’ve created a policy proposal to ask the RIPE NCC to allow Resource Certification for non-RIPE NCC member resource holders. (IXP / Legacy space and PI space holders)
As a PI holder and a router operator I support this proposal. I want others be able to verify my prefixes.
RPKI, if used widely, can be a much more acurate source for routing information than the databases are. Even in RIPE region, where the database tends to be well maintained. The more resource holders are allowed to use RPKI, the better. I would even pay a fee for the signing process of my resources, just in case this is about money.
-- ~~~ WBR, Vitaliy Turovets NOC Lead @TV-Net ISP +38(093)265-70-55 VITU-RIPE X-NCC-RegID: ua.tv
Виталий Туровец wrote:
I must admit that i myself as PI holder and service operator completely agree with Dan and think that RPKI certification should be somehow achievable by PI holders themselves without need to do any kinds of requests to LIR.
So it seems you are meking a cse for a direct service relationship with the NCC, and not using the concept of the "Sponsoring LIR"? Wilfried.
2013/6/10 Dan Luedtke <maildanrl@gmail.com <mailto:maildanrl@gmail.com>>
> As you may have seen, I’ve created a policy proposal to ask the RIPE NCC to > allow Resource Certification for non-RIPE NCC member resource holders. (IXP > / Legacy space and PI space holders)
As a PI holder and a router operator I support this proposal. I want others be able to verify my prefixes.
RPKI, if used widely, can be a much more acurate source for routing information than the databases are. Even in RIPE region, where the database tends to be well maintained. The more resource holders are allowed to use RPKI, the better. I would even pay a fee for the signing process of my resources, just in case this is about money. -- [...] ~~~ WBR, Vitaliy Turovets NOC Lead @TV-Net ISP +38(093)265-70-55 VITU-RIPE X-NCC-RegID: ua.tv <http://ua.tv>
On Fri, Jun 07, 2013 at 03:32:31PM +0200, Wilfried Woeber wrote:
Whether we need a formal "policy" or just an agreement (amongst the members of the NCC) to a Service Description and a review of the CPS as maintained by the NCC is a sideline issue, imho.
For now using the framework of the PDP maybe useful and appropriate.
I respectfully suggest it is not. The current modus operandi for RPKI in the NCC service region is not only not based on a policy created by the PDP, it exists despite a policy proposal for that very subject having failed. Whether or not that creates a schism might be interesting to discuss, but is not relevant for the case at hand. What counts here is that the absence of policy is not an 'omission' or accident. So far I have seen support for 2013-04 based on symmetry or equality of PA, PI and other (former) special cases. While this might have merit operationally, it cannot support a parallel policy just because there's nothing to draw the parallel to. This point of order has not been addressed so far (and there are multiple solutions to this situation). Therefore I formally object to 2013-04 being elevated into the next PDP phase. -Peter
Peter Koch wrote:
On Fri, Jun 07, 2013 at 03:32:31PM +0200, Wilfried Woeber wrote: [...] Therefore I formally object to 2013-04 being elevated into the next PDP phase.
Fair enough, and I do see where you are coming from :-) But at least we started to discuss the mess around this rather wide and diverse topic. :-) I'll come back to Erik's reply separately, but *technically* I am not so much worried now about what the formal "wrapper" is, but rather to *eventually* get a hold of the architectural aspects of issuing certificates to the holders of *all* resources, irrespective of their "colour" - if at all. At least for me, it *does* make a difference, policy- and support-wise, if the implementation is "reasonable" or adds more grief.
-Peter
Wilfried.
participants (13)
-
Dan Luedtke
-
Erik Bais
-
Florian Weimer
-
Gert Doering
-
Jen Linkova
-
Jens Ott - Opteamax GmbH
-
Måns Nilsson
-
Peter Koch
-
Randy Bush
-
Roland Perry
-
Sascha Luck
-
Wilfried Woeber
-
Виталий Туровец