Policy update request on certification of transferred IPv4 allocations
[Apologies for duplicate emails] Dear colleagues, Based on recent discussions on the RIPE Address Policy WG mailing list, the RIPE NCC is now seeking policy related action from the RIPE community with regards to clear guidelines on how it should proceed with certifying transferred IPv4 allocations. It has recently come to our notice, via two of the policy authors, that the original intention (in 2007) of the sentence "Re-allocated blocks will be signed to establish the current allocation owner" was that the transferred block *must* be signed *after* the transfer in order to completely establish holdership. This sentence can be found under section 5.5 of "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" here: http://www.ripe.net/ripe/docs/ripe-582#Transfers-of-Allocations Because the RIPE community provided guidance saying that certification should be an opt-in system, the RIPE NCC built an RPKI Certification system based on this opt-in notion, therefore it is not currently possible for the RIPE NCC to issue certificates without the resource holder initiating the process. Therefore, the RIPE NCC's interpretation and implementation of this specific sentence has been: Registration Services verifies and reflects the change in holdership of the re-allocated blocks by updating the database objects and internal records following the transfer. Any certificates that had been attached to these number resources before the transfer automatically become invalid/revoked due to the holdership change. The transfer recipient can then request a new certificate for the address space and the RIPE NCC will proceed to sign these resources to establish the current allocation holder. Therefore, the RIPE NCC does not make certification of any resources mandatory. As the sentence in section 5.5 of "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" is open to interpretation, the RIPE NCC is seeking representative(s) from the RIPE community to submit an update to ripe-582 that will replace this sentence with more accurate and appropriate wording or perhaps remove it completely. Kind regards, Andrew de la Haye Chief Operations Officer RIPE NCC
+1 appropriate wording /Bo
On Thu, Feb 21, 2013 at 4:23 AM, Andrew de la Haye < ripencc-management@ripe.net> wrote:
[Apologies for duplicate emails]
Dear colleagues,
Based on recent discussions on the RIPE Address Policy WG mailing list, the RIPE NCC is now seeking policy related action from the RIPE community with regards to clear guidelines on how it should proceed with certifying transferred IPv4 allocations.
It has recently come to our notice, via two of the policy authors, that the original intention (in 2007) of the sentence "Re-allocated blocks will be signed to establish the current allocation owner" was that the transferred block *must* be signed *after* the transfer in order to completely establish holdership.
This sentence can be found under section 5.5 of "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" here: http://www.ripe.net/ripe/docs/ripe-582#Transfers-of-Allocations
Because the RIPE community provided guidance saying that certification should be an opt-in system, the RIPE NCC built an RPKI Certification system based on this opt-in notion, therefore it is not currently possible for the RIPE NCC to issue certificates without the resource holder initiating the process.
Therefore, the RIPE NCC's interpretation and implementation of this specific sentence has been:
Registration Services verifies and reflects the change in holdership of the re-allocated blocks by updating the database objects and internal records following the transfer. Any certificates that had been attached to these number resources before the transfer automatically become invalid/revoked due to the holdership change. The transfer recipient can then request a new certificate for the address space and the RIPE NCC will proceed to sign these resources to establish the current allocation holder.
Therefore, the RIPE NCC does not make certification of any resources mandatory.
As the sentence in section 5.5 of "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" is open to interpretation, the RIPE NCC is seeking representative(s) from the RIPE community to submit an update to ripe-582 that will replace this sentence with more accurate and appropriate wording or perhaps remove it completely.
How about replacing; "Re-allocated blocks will be signed to establish the current allocation owner." with: "Re-allocated blocks will be signed to establish the current allocation holder if the receiving party chooses." ?? -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel
"Re-allocated blocks will be signed to establish the current allocation holder if the receiving party chooses."
Replace "will" with "may"? You could also add "so" before the word "chooses". D. -- Donal Cunningham IP Network Engineer, AirSpeed Telecom dcunningham@airspeed.ie | +353 1 428 7531
On 2/21/13 08:21 , Donal Cunningham wrote:
"Re-allocated blocks will be signed to establish the current allocation holder if the receiving party chooses."
Replace "will" with "may"? You could also add "so" before the word "chooses".
May I also suggest, s/signed/certified, and add to the end ", and any previous related certificates will be revoked." Revocation of previous related certificates is required if their are any, and not optional, new certificates for the new holder are optional. Put it all together and you get; "Re-allocated blocks may be certified to establish the current allocation holder if the receiving party so chooses, and any previous related certificates will be revoked." -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================
Hi, On Thu, Feb 21, 2013 at 08:52:18AM -0600, David Farmer wrote:
"Re-allocated blocks may be certified to establish the current allocation holder if the receiving party so chooses, and any previous related certificates will be revoked."
Works for me :-) - but now we need someone to volunteer to formally drive this through the policy development process (PDP)... Gert Doering -- APWG chair -- 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 21/02/2013 15:12, Gert Doering wrote:
On Thu, Feb 21, 2013 at 08:52:18AM -0600, David Farmer wrote:
"Re-allocated blocks may be certified to establish the current allocation holder if the receiving party so chooses, and any previous related certificates will be revoked."
Works for me :-) - but now we need someone to volunteer to formally drive this through the policy development process (PDP)...
This is a bad idea for two reasons: 1. I don't think it's a good idea to have non-atomic policy. I.e. if there's RPKI policy statements here where they don't really need to be, then this creates unnecessary confusion. If there is no statement about RPKI policy in here, then I expect the default action by the RIPE NCC will be to treat these allocations as regular allocation 2. by explicitly mentioning RPKI and certification, the proposal will be to create a RIPE policy which will permit certification for reallocated blocks only. This will do two things: 2.1. create a RIPE policy discrepancy between how RPKI is handled for reallocated resources and resources which are still assigned to their original holders. 2.2. re-open the discussion about resource certification at half-cock, which will lead to a re-run of the same arguments put forward for 2008-08. The intention of the policy change here is to fix a policy bug, and it would be a shame to have it ending up as an unnecessary re-hash of 2008-08. The easiest and simplest thing would be to drop the sentence completely, at which point the de-facto RIPE NCC procedures concerning certification will apply. If this seems like a sensible and pragmatic approach to others, I can oblige from the policy proposal point of view. Or someone else can, if they want. Nick
On Thu, Feb 21, 2013 at 04:15:19PM +0000, Nick Hilliard wrote:
2.2. re-open the discussion about resource certification at half-cock, which will lead to a re-run of the same arguments put forward for 2008-08. The intention of the policy change here is to fix a policy bug, and it would be a shame to have it ending up as an unnecessary re-hash of 2008-08.
Damn. I never looked at it from that angle. Nick is right, this creates RPKI policy by the back-door.
The easiest and simplest thing would be to drop the sentence completely, at which point the de-facto RIPE NCC procedures concerning certification will apply. If this seems like a sensible and pragmatic approach to others, I can oblige from the policy proposal point of view. Or someone else can, if they want.
In light of the above, this is eminently the most sensible solution. cheers, Sascha Luck
On Thu, Feb 21, 2013 at 11:27 AM, Sascha Luck <lists-ripe@c4inet.net> wrote:
On Thu, Feb 21, 2013 at 04:15:19PM +0000, Nick Hilliard wrote:
2.2. re-open the discussion about resource certification at half-cock,
which will lead to a re-run of the same arguments put forward for 2008-08. The intention of the policy change here is to fix a policy bug, and it would be a shame to have it ending up as an unnecessary re-hash of 2008-08.
Damn. I never looked at it from that angle. Nick is right, this creates RPKI policy by the back-door.
I'm not so sure it does, the word "may" doesn't obligate the NCC to do anything.
The easiest and simplest thing would be to drop the sentence completely,
at which point the de-facto RIPE NCC procedures concerning certification will apply. If this seems like a sensible and pragmatic approach to others, I can oblige from the policy proposal point of view. Or someone else can, if they want.
In light of the above, this is eminently the most sensible solution.
Probably. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel
On 2/21/13 10:30 , McTim wrote:
On Thu, Feb 21, 2013 at 11:27 AM, Sascha Luck <lists-ripe@c4inet.net <mailto:lists-ripe@c4inet.net>> wrote:
On Thu, Feb 21, 2013 at 04:15:19PM +0000, Nick Hilliard wrote:
2.2. re-open the discussion about resource certification at half-cock, which will lead to a re-run of the same arguments put forward for 2008-08. The intention of the policy change here is to fix a policy bug, and it would be a shame to have it ending up as an unnecessary re-hash of 2008-08.
Damn. I never looked at it from that angle. Nick is right, this creates RPKI policy by the back-door.
I'm not so sure it does, the word "may" doesn't obligate the NCC to do anything.
While I tend to agree that it doesn't actually create RPKI policy, the fact that it would be mentioning certificates or signing at all does create an impression that it is creating RPKI policy.
The easiest and simplest thing would be to drop the sentence completely, at which point the de-facto RIPE NCC procedures concerning certification will apply. If this seems like a sensible and pragmatic approach to others, I can oblige from the policy proposal point of view. Or someone else can, if they want.
In light of the above, this is eminently the most sensible solution.
Probably.
Given the lack of actual RPKI policy, it seems sensible to not create any confusion or give the impression that there is backdoor RPKI policy being created and just remove the sentence completely. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================
Why not stop RPKI certification? It looks unnecessary any brings for community too many difficulties in support and additional costs. In Russia can be used only GOST encryption and special certified equipment. So if operator will use RPKI-cerfification - then he will break Russian law. -- Alexey Ivanov LeaderTelecom
On 21/02/2013 16:30, LeaderTelecom Ltd. wrote:
Why not stop RPKI certification? It looks unnecessary any brings for community too many difficulties in support and additional costs.
Alexey, this is a different argument for another time. Right now, we need to fix a policy bug which is causing the RIPE NCC difficulties. Let's fix that and deal with the RPKI / certification issue separately. Nick
Dear Nick, This is simplest way to fix :) No RPKI - no problem with certification. -- Alexey Ivanov 21.02.2013 20:41 - Nick Hilliard написал(а): On 21/02/2013 16:30, LeaderTelecom Ltd. wrote:
Why not stop RPKI certification? It looks unnecessary any brings for community too many difficulties in support and additional costs.
Alexey, this is a different argument for another time. Right now, we need to fix a policy bug which is causing the RIPE NCC difficulties. Let's fix that and deal with the RPKI / certification issue separately. Nick
On 21/02/13 19:49, LeaderTelecom Ltd. wrote:
Dear Nick,
This is simplest way to fix :)
No RPKI - no problem with certification.
Some people want to use RPKI. It seems somewhat churlish to prevent them from doing so just because Russian members can't. But as Nick said, this is a different argument for a different time. I'd suggest (as the original author of this particular clause) that we just remove it. Times have changed. Nigel
I agree.
-----Original Message-----
I'd suggest (as the original author of this particular clause) that we just remove it. Times have changed.
Nigel
Milton L. Mueller Professor, Syracuse University School of Information Studies Internet Governance Project http://blog.internetgovernance.org
Hi,
Some people want to use RPKI. It seems somewhat churlish to prevent them from doing so just because Russian members can't. But as Nick said, this is a different argument for a different time.
I'd suggest (as the original author of this particular clause) that we just remove it. Times have changed.
That means that it is up to the parties themselves to revoke their current certificate (if they have one already) and create a new one if needed. The only question is how long would it be before the transfer be completed in the RIPE system, to allow the new LIR to setup their new ROA. Technically that shouldn't be an issue, but the selling party might be selling only a part of a certain allocation, leaving that prefix invalid and the new party need to be able to create a new valid ROA directly after the transfer. Not sure btw if the current RPKI system implementation checks ROA's for that specific LIR after a transfer is done... ( Alex B might know the answer on that ... ) Regards, Erik Bais
On 25 Feb 2013, at 11:51, Erik Bais <erik@bais.name> wrote:
Hi,
Some people want to use RPKI. It seems somewhat churlish to prevent them from doing so just because Russian members can't. But as Nick said, this is a different argument for a different time.
I'd suggest (as the original author of this particular clause) that we just remove it. Times have changed.
That means that it is up to the parties themselves to revoke their current certificate (if they have one already) and create a new one if needed.
There is no need for this. The content of the certificate is based on current Registry data. If resources are de-registered from an LIR, a new, updated certificate is automatically issued and any over-claiming ROAs will be invalidated.
The only question is how long would it be before the transfer be completed in the RIPE system, to allow the new LIR to setup their new ROA.
As soon as the Registry is updated and the resources are associated with the new holder, the LIR can optionally request a resource certificate for it. This does mean that a transition is not seamless; there is a gap where there is no certificate and no ROA, which has an effect on the RPKI validity state of the associated BGP announcements. More on that below.
Technically that shouldn't be an issue, but the selling party might be selling only a part of a certain allocation, leaving that prefix invalid and the new party need to be able to create a new valid ROA directly after the transfer.
The BGP announcement of a prefix will *not* be invalid in this case (a common misconception). There are three validity states of BGP announcements in relation to ROAs to consider: - valid (ROA exists) - invalid (ROA exists for the prefix, but for a different ASN or max prefix length) - unknown (no ROA exists for the prefix) So while a transfer is ongoing, the associated BGP announcements will be "unknown" because no ROA exists (yet). If this is a problem, because operators would like a system where any BGP announcement should be "valid" at all times for it to be routed, our system and processes would have to be changed to facilitate that.
Not sure btw if the current RPKI system implementation checks ROA's for that specific LIR after a transfer is done... ( Alex B might know the answer on that ... )
As said, the process is fully automated so no action is required from the transferring LIR. The LIR who receives the resources is free to request a certificate and create ROAs, if they so choose. Cheers, Alex
If this is a problem, because operators would like a system where any BGP announcement should be "valid" at all times for it to be routed, our system and processes would have to be changed to facilitate that.
A lot more needs to be changed in internet routing before that becomes a viable option :-) Sander
Hi Alex, Alex Band wrote: [...]
As soon as the Registry is updated and the resources are associated with the new holder, the LIR can optionally request a resource certificate for it. This does mean that a transition is not seamless; there is a gap where there is no certificate and no ROA, which has an effect on the RPKI validity state of the associated BGP announcements. More on that below.
Let's assume that there was a certificate for the full block of the current holder. Part of that space moves to a new holder. While it is "obvious", that there's no certificate for that space, it would also be "obvious", that the encompassing certificate would have to become invalid, e.g. by being revoked by the CA. Correct? If the answer is yes, such a transfer would endanger the routing stability of *both* parties? Wilfried.
Technically that shouldn't be an issue, but the selling party might be selling only a part of a certain allocation, leaving that prefix invalid and the new party need to be able to create a new valid ROA directly after the transfer.
The BGP announcement of a prefix will *not* be invalid in this case (a common misconception). There are three validity states of BGP announcements in relation to ROAs to consider:
- valid (ROA exists) - invalid (ROA exists for the prefix, but for a different ASN or max prefix length) - unknown (no ROA exists for the prefix)
So while a transfer is ongoing, the associated BGP announcements will be "unknown" because no ROA exists (yet). If this is a problem, because operators would like a system where any BGP announcement should be "valid" at all times for it to be routed, our system and processes would have to be changed to facilitate that.
Not sure btw if the current RPKI system implementation checks ROA's for that specific LIR after a transfer is done... ( Alex B might know the answer on that ... )
As said, the process is fully automated so no action is required from the transferring LIR. The LIR who receives the resources is free to request a certificate and create ROAs, if they so choose.
Cheers,
Alex
On 27 Feb 2013, at 15:42, Wilfried Woeber <Woeber@CC.UniVie.ac.at> wrote:
Hi Alex,
Alex Band wrote:
[...]
As soon as the Registry is updated and the resources are associated with the new holder, the LIR can optionally request a resource certificate for it. This does mean that a transition is not seamless; there is a gap where there is no certificate and no ROA, which has an effect on the RPKI validity state of the associated BGP announcements. More on that below.
Let's assume that there was a certificate for the full block of the current holder. Part of that space moves to a new holder. While it is "obvious", that there's no certificate for that space, it would also be "obvious", that the encompassing certificate would have to become invalid, e.g. by being revoked by the CA. Correct?
No. If an LIR requested a resource certificate, it will at all times reflect the Registry. So if certain resources are added or removed from an LIR, a new, updated certificate is issued automatically to reflect the new situation, without user interaction required. So this applies for both parties if they had certification enabled. The only thing the receiving party would have to do is create a ROA for the new address space, to authorise the BGP announcement they will be doing with it. Until that time, the announcement will will remain with the "unknown" state (so NOT invalid). -Alex
On 27/02/2013 14:42, Wilfried Woeber wrote:
Hi Alex,
Alex Band wrote:
As soon as the Registry is updated and the resources are associated with the new holder, the LIR can optionally request a resource certificate for it. This does mean that a transition is not seamless; there is a gap where there is no certificate and no ROA, which has an effect on the RPKI validity state of the associated BGP announcements. More on that below. Let's assume that there was a certificate for the full block of the current holder. Part of that space moves to a new holder. While it is "obvious", that
[...] there's no certificate for that space, it would also be "obvious", that the encompassing certificate would have to become invalid, e.g. by being revoked by the CA. Correct?
If the answer is yes, such a transfer would endanger the routing stability of *both* parties?
Yes, but from a practical point of view, the current holder will obtain a new certificate before relinquishing the partial block and the new holder will get a new certificate before using it. Nigel
Nick Hilliard wrote:
On 21/02/2013 15:12, Gert Doering wrote:
On Thu, Feb 21, 2013 at 08:52:18AM -0600, David Farmer wrote:
"Re-allocated blocks may be certified to establish the current allocation holder if the receiving party so chooses, and any previous related certificates will be revoked."
Works for me :-) - but now we need someone to volunteer to formally drive this through the policy development process (PDP)...
This is a bad idea for two reasons: [...] The easiest and simplest thing would be to drop the sentence completely, at which point the de-facto RIPE NCC procedures concerning certification will apply.
full support. Just as an observation, imho we are suffering from a mixup of terminology and a lack of experience with all the "funny" details of establishing a (sort of) hierarchical CA and RA environment. The RPKI is meant to create, distribute and manage certificates for the routing plane, not as a digital signature of ownership, true? The authoritative source of information about holdership is the up-to-date Numbers Registry.
If this seems like a sensible and pragmatic approach to others, I can oblige from the policy proposal point of view. Or someone else can, if they want.
Nick
Wilfried.
Wilfried Woeber wrote:
Nick Hilliard wrote: [...] The RPKI is meant to create, distribute and manage certificates for the routing plane, not as a digital signature of ownership, true?
Correction to self: ripe-549 1.4.1 says: "The certificates issued under this hierarchy are for authorisation in support of validation of claims of current holdings of address space and/or AS Numbers. With regard to routing security, an initial goal of this PKI is to allow the holder of a set of address blocks to be able to declare, in a secure fashion, the AS Number of each entity that is authorised to originate a route to these addresses, including the context of ISP proxy aggregation. Additional uses of the PKI, consistent with the basic goal cited above, are also permitted under this policy." while 1.4.2 says: "Any uses other than those described in section 1. 4. 1 are prohibited." which seems to be somewhat contradictory or at least inconsistent. and 1.3.2 seems to indicate that only RIPE NCC Members are eligible.
The authoritative source of information about holdership is the up-to-date Numbers Registry.
If this seems like a sensible and pragmatic approach to others, I can oblige from the policy proposal point of view. Or someone else can, if they want.
Nick
Wilfried. Wilfried
On 2/21/13 17:15 , "Nick Hilliard" <nick@inex.ie> wrote:
The easiest and simplest thing would be to drop the sentence completely, at which point the de-facto RIPE NCC procedures concerning certification will apply. If this seems like a sensible and pragmatic approach to others, I can oblige from the policy proposal point of view. Or someone else can, if they want.
+1. Support completely. Even willing to volunteer as token author for sake of the PDP if necessary. Remco This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383.
* Donal Cunningham <dcunningham@airspeed.ie> [2013-02-21 15:24]:
"Re-allocated blocks will be signed to establish the current allocation holder if the receiving party chooses."
Replace "will" with "may"? You could also add "so" before the word "chooses".
As this makes it completely optional I would suggest just removing the sentence. The receiver can always sign it if he chooses to do so. Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant
participants (17)
-
Alex Band -
Andrew de la Haye -
Bo Sixten Ståhle -
David Farmer -
Donal Cunningham -
Erik Bais -
Gert Doering -
LeaderTelecom Ltd. -
McTim -
Milton L Mueller -
Nick Hilliard -
Nigel Titley -
Remco Van Mook -
Sander Steffann -
Sascha Luck -
Sebastian Wiesinger -
Wilfried Woeber