[routing-wg]2008-04 New Policy Proposal (Using the Resource Public Key Infrastructure to Construct Validated IRR Data)
PDP Number: 2008-04 Using the Resource Public Key Infrastructure to Construct Validated IRR Data Dear Colleagues, A new RIPE Policy Proposal has been made and is now available for discussion. This is a proposal to introduce a new registry that augments IRR data with the formally verifiable trust model of the Resource Public Key Infrastructure (RPKI) and provide ISPs with the tools to generate an overlay to the IRR which is much more strongly trustable. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2008-04.html We encourage you to review this proposal and send your comments to <routing-wg@ripe.net> before 27 May 2008. Regards, Filiz Yilmaz RIPE NCC Policy Development Officer
In iks.lists.ripe.routing-wg, you wrote:
Using the Resource Public Key Infrastructure to Construct Validated IRR Data
Good idea. Is this a SIDR WG proposal? Please summarize the alternatives.
Good idea. Is this a SIDR WG proposal?
no, as it clearly says, this was a ruediger idea which i stole in the rpki design effort.
Please summarize the alternatives.
trying to sign the irr with rpki certs when there is a serious trust model mismatch between the two; i.e. a bad idea. randy
Folks,
PDP Number: 2008-04 Using the Resource Public Key Infrastructure to Construct Validated IRR Data
We have ourselves a policy proposal. :) The discussion here should concentrate on whether it is useful to construct an IRR out of certified resources placed in the RPKI. If the answer is "yes," details of the implementation are probably best discussed on a smaller scale by the people that would end up doing the work. Kurtis will be presenting this on Monday afternoon during the plenary in Berlin, we will also have a quarter of an hour or so to discuss it during the working group meeting on Friday morning. Randy and Ruediger, whose idea it was, will also be around most of the week. Get your thinking caps on and let the discussion begin! All the best, Rob
Rob Evans wrote:
Folks,
PDP Number: 2008-04 Using the Resource Public Key Infrastructure to Construct Validated IRR Data
We have ourselves a policy proposal. :)
The discussion here should concentrate on whether it is useful to construct an IRR out of certified resources placed in the RPKI.
It may also be useful to consider this in the light of alternative approaches where the RPSL object is signed by the resource holder, using a signing certificate that is validatable in the context of a resource PKI. In this case the certificates in the RPKI would be used to validate that the object that was retrieved from the IRR was signed by the current holder of the resources that are described in the object, has not been altered or tampered in any way, and that trust in the validity of the object is no longer based just on the admission and management policies of the registry. Using digitally signed attestations to synthesise IRR objects, as per this proposal, and adding digital signatures to the IRR objects appear to be alternate paths in the overall direction of adding some mechanisms of explicit validation of IRR objects. What classes of IRR objects could be generated using the approach of generating IRR objects from RPKI data? regards, Geoff
It may also be useful to consider this in the light of alternative approaches where the RPSL object is signed by the resource holder, using a signing certificate that is validatable in the context of a resource PKI.
who signs as-set:? how does maintainer map to anything in rpki? ... as i said, bad impedance mismatch.
What classes of IRR objects could be generated using the approach of generating IRR objects from RPKI data?
route: randy
Randy Bush wrote:
It may also be useful to consider this in the light of alternative approaches where the RPSL object is signed by the resource holder, using a signing certificate that is validatable in the context of a resource PKI.
who signs as-set:?
If the as-set has a hierarchical name (as described in RFC 2725 and possibly elsewhere) then the signer would be the AS holder of the AS named in the hierarchical name form, wouldn't it?
how does maintainer map to anything in rpki?
I would've thought, after looking through the RFCs that explored this topic back in 1999 - 2000, that the maintainer of a inetnum object would be the address holder, the maintainer of the aut-num object would be the as number holder, and the maintainer of the route object would be the address holder, which would map back into the RPKI ... as
i said, bad impedance mismatch.
I'm not sure I can agree with this assertion at this stage.
What classes of IRR objects could be generated using the approach of generating IRR objects from RPKI data?
route:
I'm still wondering if that is a sufficient subset of the IRR information set. regards, Geoff
who signs as-set:?
If the as-set has a hierarchical name (as described in RFC 2725 and possibly elsewhere) then the signer would be the AS holder of the AS named in the hierarchical name form, wouldn't it?
nice theory. not reality.
how does maintainer map to anything in rpki?
I would've thought, after looking through the RFCs that explored this topic back in 1999 - 2000, that the maintainer of a inetnum object would be the address holder, the maintainer of the aut-num object would be the as number holder, and the maintainer of the route object would be the address holder, which would map back into the RPKI
except the reality of irr use does not always match that.
What classes of IRR objects could be generated using the approach of generating IRR objects from RPKI data?
route:
I'm still wondering if that is a sufficient subset of the IRR information set.
i'll take 80% of the gain for NONE of the pain, which is what ruediger's proposal provides. for those using the irr to generate filters, not changing tools is critical. we know how non-maintained irrd and ratoolset are, and we know how much it will cost us to touch our custom tools. ruediger's brilliant hack eliminates all those concerns. randy
participants (5)
-
Filiz Yilmaz -
Geoff Huston -
Lutz Donnerhacke -
Randy Bush -
Rob Evans