2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Dear colleagues, A new RIPE Policy proposal, 2019-08, "RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space" is now available for discussion. This proposal aims to instructs the RIPE NCC to create ROAs with origin AS0 for all unallocated and unassigned address space under its control. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-08 As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal. We encourage you to review this proposal and send your comments to <routing-wg@ripe.net> before 29 November 2019. Kind regards, -- Petrit Hasani Policy Officer RIPE NCC
Hi all, On Thu, 2019-10-31 at 15:28 +0100, Petrit Hasani wrote:
Dear colleagues,
A new RIPE Policy proposal, 2019-08, "RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space" is now available for discussion.
This proposal aims to instructs the RIPE NCC to create ROAs with origin AS0 for all unallocated and unassigned address space under its control.
I support this proposal. We are one of the "not many operators" that try to maintain bogon filters at our eBGP edge, and we have also been rejecting rpki-ov invalids since earlier this year. This policy would therefore simplify our operations considerably. Cheers, Ben Maddison
I support this proposal. This will make announcement of unallocated/unassigned address space less profitable. Ian -----Original Message----- From: routing-wg <routing-wg-bounces@ripe.net> On Behalf Of Petrit Hasani Sent: 31 October 2019 14:29 To: routing-wg@ripe.net Subject: [routing-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space) Dear colleagues, A new RIPE Policy proposal, 2019-08, "RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space" is now available for discussion. This proposal aims to instructs the RIPE NCC to create ROAs with origin AS0 for all unallocated and unassigned address space under its control. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-08 As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal. We encourage you to review this proposal and send your comments to <routing-wg@ripe.net> before 29 November 2019. Kind regards, -- Petrit Hasani Policy Officer RIPE NCC Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website.
* Petrit Hasani
A new RIPE Policy proposal, 2019-08, "RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space" is now available for discussion.
I like it. Eminently sensible. +1 Tore
A new RIPE Policy proposal, 2019-08, "RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space" is now available for discussion. +1, it is useful and finally necessary Cheers Christian
Dear collegues, *chair hat on* I discussed with my co-chair Paul that it would be best if he handles judging the consensus on the 2019-08 policy proposal later on, this allows me to freely share my views in the process! *chair hat off* I question the benefits of this policy proposal, but am willing to be convinced. There are a few questions that come to mind about whether this mechanism is productive. 1/ What is the ROI? I think there is only a few prefixes in the default-free zone that are managed by RIPE NCC, but not assigned or allocated by RIPE NCC. So putting this machinery in place might not have that much benefit, while the cost of 'getting it wrong' could be substantial. 2/ Have the policy proposers considered offering this functionality through a separate RPKI TAL rather than the current main RIPE NCC RPKI TAL? This way folks would explicitly opt-in to obtain this data feed in an automated fashion. 3/ Once the resource is assigned, the resource holder can create a ROA. In the lifecycle of a resource it isn't clear to me what the benefit is to have a ROA covering it when it is not yet assigned/allocated. Thanks! Kind regards, Job On Thu, Oct 31, 2019 at 03:28:59PM +0100, Petrit Hasani wrote:
Dear colleagues,
A new RIPE Policy proposal, 2019-08, "RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space" is now available for discussion.
This proposal aims to instructs the RIPE NCC to create ROAs with origin AS0 for all unallocated and unassigned address space under its control.
You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2019-08
As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer.
At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal.
We encourage you to review this proposal and send your comments to <routing-wg@ripe.net> before 29 November 2019.
Kind regards,
-- Petrit Hasani Policy Officer RIPE NCC
Hi, On Thu, Oct 31, 2019 at 07:10:02PM +0000, Job Snijders wrote:
1/ What is the ROI? I think there is only a few prefixes in the default-free zone that are managed by RIPE NCC, but not assigned or allocated by RIPE NCC. So putting this machinery in place might not have that much benefit, while the cost of 'getting it wrong' could be substantial.
This was my first thought as well, but then I discovered this IPv6 thing :)
3/ Once the resource is assigned, the resource holder can create a ROA. In the lifecycle of a resource it isn't clear to me what the benefit is to have a ROA covering it when it is not yet assigned/allocated.
It does stop people from announcing unassigned space and spam from it (because the announcement would be "invalid" and no longer "unknown"). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On Thu, Oct 31, 2019 at 09:42:21PM +0100, Gert Doering wrote:
On Thu, Oct 31, 2019 at 07:10:02PM +0000, Job Snijders wrote:
1/ What is the ROI? I think there is only a few prefixes in the default-free zone that are managed by RIPE NCC, but not assigned or allocated by RIPE NCC. So putting this machinery in place might not have that much benefit, while the cost of 'getting it wrong' could be substantial.
This was my first thought as well, but then I discovered this IPv6 thing :)
Other than that there is lots of unassigned space in IPv6, and no shortage, what is the relevance? Did you take a look at how many unassigned/unallocated IPv6 prefixes (managed by RIPE NCC) are actually in the DFZ?
3/ Once the resource is assigned, the resource holder can create a ROA. In the lifecycle of a resource it isn't clear to me what the benefit is to have a ROA covering it when it is not yet assigned/allocated.
It does stop people from announcing unassigned space and spam from it (because the announcement would be "invalid" and no longer "unknown").
I understand it would hinder people's ability to announce unassigned space, but the question is whether the right balance is struck between inconveniencing folks that use unassigned space and the risk of inconveniencing folks that have to deal with the consequences of this approach. Kind regards, Job
On Fri, Nov 01, 2019 at 01:23:44AM +0000, Job Snijders wrote:
On Thu, Oct 31, 2019 at 09:42:21PM +0100, Gert Doering wrote:
On Thu, Oct 31, 2019 at 07:10:02PM +0000, Job Snijders wrote:
1/ What is the ROI? I think there is only a few prefixes in the default-free zone that are managed by RIPE NCC, but not assigned or allocated by RIPE NCC. So putting this machinery in place might not have that much benefit, while the cost of 'getting it wrong' could be substantial.
This was my first thought as well, but then I discovered this IPv6 thing :)
Other than that there is lots of unassigned space in IPv6, and no shortage, what is the relevance? Did you take a look at how many unassigned/unallocated IPv6 prefixes (managed by RIPE NCC) are actually in the DFZ?
I ran the numbers, as far as I can tell we only have a handful of IPv6 prefixes in the default-free zone that are RIPE NCC managed space, and in the 'reserved' category (looked at today's delegated-latest) Below is the list of those IPv6 prefxes and the AS_PATH towards the origin: 2a02:4680::/48 6762 31133 25159 42288 2a02:4680:2::/48 6762 31133 59533 2a02:4680:11::/48 3356 43727 62410 2a02:4680:12::/48 1299 1299 20485 48034 2a02:4680:1e::/48 174 31133 44941 2a02:4680:2e::/48 1299 1299 20485 51291 2a02:4680:31::/48 6762 31133 44941 2a02:4680:40::/48 1299 42861 35598 2a06:7780::/29 1299 3302 So we really have to wonder whether this is worth it, or whether a few emails or phone calls can also solve the issue. Kind regards, Job
On Fri, 2019-11-01 at 07:09 +0100, Job Snijders wrote:
On Fri, Nov 01, 2019 at 01:23:44AM +0000, Job Snijders wrote:
On Thu, Oct 31, 2019 at 09:42:21PM +0100, Gert Doering wrote:
On Thu, Oct 31, 2019 at 07:10:02PM +0000, Job Snijders wrote:
1/ What is the ROI? I think there is only a few prefixes in the default-free zone that are managed by RIPE NCC, but not assigned or allocated by RIPE NCC. So putting this machinery in place might not have that much benefit, while the cost of 'getting it wrong' could be substantial.
This was my first thought as well, but then I discovered this IPv6 thing :)
Other than that there is lots of unassigned space in IPv6, and no shortage, what is the relevance? Did you take a look at how many unassigned/unallocated IPv6 prefixes (managed by RIPE NCC) are actually in the DFZ?
I ran the numbers, as far as I can tell we only have a handful of IPv6 prefixes in the default-free zone that are RIPE NCC managed space, and in the 'reserved' category (looked at today's delegated-latest)
The issue for me is not that there are many such prefixes sitting in the DFZ in steady state, but that as part of attack-prep they can be stood up to defeat loose-urpf-based anti-spoofing mechanisms. We currently mitigate this using the team cymru bgp service, which has two primary drawbacks: 1. the dependency on the underlying transport of the multihop bgp session 2. the implicit trust that we place in TC (however merited) to make assertions about the status of the address space. The current proposal solves #2 outright. #1 would only be partially solved, given that we would still rely on connectivity between our validation caches and the ripe publication endpoints. However, this should be far less fragile in the face of short-term reachability issues than a bgp session. I still support. Cheers, Ben
Hi, On Fri, Nov 01, 2019 at 07:09:42AM +0100, Job Snijders wrote:
So we really have to wonder whether this is worth it, or whether a few emails or phone calls can also solve the issue.
Isn't that the whole question underlying RPKI deployment? What is it that we want to stop with RPKI? Only classic "prefix hijacking" (announcing space that is formally delegated somewhere) or other misuses of BGP, like "announce unallocated space, use that for spamming or other sorts of network attacks, withdraw announcement before people can track things back to you". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Dear Gert, On Fri, Nov 01, 2019 at 09:56:32AM +0100, Gert Doering wrote:
On Fri, Nov 01, 2019 at 07:09:42AM +0100, Job Snijders wrote:
So we really have to wonder whether this is worth it, or whether a few emails or phone calls can also solve the issue.
Isn't that the whole question underlying RPKI deployment?
I don't think it is. RPKI isn't the 'SDN controller for the Internet' :-)
What is it that we want to stop with RPKI? Only classic "prefix hijacking" (announcing space that is formally delegated somewhere) or other misuses of BGP, like "announce unallocated space, use that for spamming or other sorts of network attacks, withdraw announcement before people can track things back to you".
Yeah, in my mind RPKI exists to facilitate that people can better communicate their routing intentions to each other, with the RIR as a middle man certifiying that formal relations exist (in their role of assigning globally unique number resources to their stakeholders). The RPKI exists so that you and I can protect each other against misuse or misconfigurations of the our resources, and I consider the resources which don't (yet) have a holder are out of scope. That's also not where the money is, our business depend on the number resources that were assigned to us, the rest is less relevant. In this context, it again seems not entirely helpful that all RIRs are sitting on a 0.0.0.0/0 + ::/0 root cert, I wish we could come up with some way to restrict those certs to just the resources they actually manage, and perhaps through delegations from one RIR to another RIR keep transfers working. But this would only work if we have a coherent view on the RPKI which would in turn depend on certain legal barriers not existing... but alas, I'm getting off topic Kind regards, Job
What is it that we want to stop with RPKI?
<pedant> nothing. databases, even distributed ones are unlikely to start or stop anything. </pedant> otoh, the goal with rpki-based origin validation was to stop many of the daily accidental mis-originations. randy
Hi, (please see inline) On Fri, 1 Nov 2019, Gert Doering wrote:
Hi,
On Fri, Nov 01, 2019 at 07:09:42AM +0100, Job Snijders wrote:
So we really have to wonder whether this is worth it, or whether a few emails or phone calls can also solve the issue.
Isn't that the whole question underlying RPKI deployment?
What is it that we want to stop with RPKI? Only classic "prefix hijacking" (announcing space that is formally delegated somewhere)
With RPKI alone, mistakes. But when in doubt if network X has rights over network Y, it's rather simple to ask network X to create a proper ROA for network Y. If that *doesn't* happen, maybe some conclusions can be drawn. (there is a recent thread on the NANOG list where someone raised that "feature"...)
or other misuses of BGP, like "announce unallocated space, use that for spamming or other sorts of network attacks, withdraw announcement before people can track things back to you".
From *one* computer security emergency response team's angle: RPKI is a good first step. Then, hopefully, ASPA can be added at some point.
Playing the quick withdraw game will only work (and it is working, i suspect!) until people start understanding they need to log who announces what to them (24/7/365). Speaking about "network attacks" -- there is a lot of focus about the address space being hijacked, while major focus should be on those who receive the announcements. While it's terrible for the people/networks being impersonating, the potential targets are really everyone... ps: i wish to express support for 2019-08 in its current form. Cheers, Carlos
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi all, I am not opposed to this in principle. I see some value. However, I think it would be good to take an impact analysis into account in order to prioritise this relative to other rpki improvements. I agree with others who have said that there may be more valuable things for the ripe ncc to focus on, eg: - rpki ta key rolls - robustness wrt abuse of the system (producing thousands or millions of objects) - aspa path validation with rpki Tim
On 2 Nov 2019, at 10:52, Carlos Friaças via routing-wg <routing-wg@ripe.net> wrote:
Hi, (please see inline)
On Fri, 1 Nov 2019, Gert Doering wrote:
Hi,
On Fri, Nov 01, 2019 at 07:09:42AM +0100, Job Snijders wrote: So we really have to wonder whether this is worth it, or whether a few emails or phone calls can also solve the issue.
Isn't that the whole question underlying RPKI deployment?
What is it that we want to stop with RPKI? Only classic "prefix hijacking" (announcing space that is formally delegated somewhere)
With RPKI alone, mistakes.
But when in doubt if network X has rights over network Y, it's rather simple to ask network X to create a proper ROA for network Y.
If that *doesn't* happen, maybe some conclusions can be drawn. (there is a recent thread on the NANOG list where someone raised that "feature"...)
or other misuses of BGP, like "announce unallocated space, use that for spamming or other sorts of network attacks, withdraw announcement before people can track things back to you".
From *one* computer security emergency response team's angle: RPKI is a good first step. Then, hopefully, ASPA can be added at some point.
Playing the quick withdraw game will only work (and it is working, i suspect!) until people start understanding they need to log who announces what to them (24/7/365).
Speaking about "network attacks" -- there is a lot of focus about the address space being hijacked, while major focus should be on those who receive the announcements. While it's terrible for the people/networks being impersonating, the potential targets are really everyone...
ps: i wish to express support for 2019-08 in its current form.
Cheers, Carlos
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi, Let discuss the next scenario: there are two prefixes: x.x.0.0/24 and x.x.1.0/24, first one assigned to an ISP, second - unallocated. The proposal suggests that RIPE should create ROA with AS0 for x.x.1.0/24. Will it stop an attacker from squatting this address space? The answer will be No. An attacker will still be able to hijack x.x.0.0/23, which will have an 'unknown' status and will be passed on, as a result finally capturing traffic for x.x.1.0/24. While I support the goals behind this proposal, it seems that ROA with its current model of use is not applicable for this purpose. сб, 2 нояб. 2019 г. в 14:15, Tim Bruijnzeels <tim@nlnetlabs.nl>:
Hi all,
I am not opposed to this in principle. I see some value. However, I think it would be good to take an impact analysis into account in order to prioritise this relative to other rpki improvements. I agree with others who have said that there may be more valuable things for the ripe ncc to focus on, eg:
- rpki ta key rolls - robustness wrt abuse of the system (producing thousands or millions of objects) - aspa path validation with rpki
Tim
On 2 Nov 2019, at 10:52, Carlos Friaças via routing-wg < routing-wg@ripe.net> wrote:
Hi, (please see inline)
On Fri, 1 Nov 2019, Gert Doering wrote:
Hi,
On Fri, Nov 01, 2019 at 07:09:42AM +0100, Job Snijders wrote: So we really have to wonder whether this is worth it, or whether a few emails or phone calls can also solve the issue.
Isn't that the whole question underlying RPKI deployment?
What is it that we want to stop with RPKI? Only classic "prefix hijacking" (announcing space that is formally delegated somewhere)
With RPKI alone, mistakes.
But when in doubt if network X has rights over network Y, it's rather simple to ask network X to create a proper ROA for network Y.
If that *doesn't* happen, maybe some conclusions can be drawn. (there is a recent thread on the NANOG list where someone raised that "feature"...)
or other misuses of BGP, like "announce unallocated space, use that for spamming or other sorts of network attacks, withdraw announcement before people can track things back to you".
From *one* computer security emergency response team's angle: RPKI is a good first step. Then, hopefully, ASPA can be added at some point.
Playing the quick withdraw game will only work (and it is working, i suspect!) until people start understanding they need to log who announces what to them (24/7/365).
Speaking about "network attacks" -- there is a lot of focus about the address space being hijacked, while major focus should be on those who receive the announcements. While it's terrible for the people/networks being impersonating, the potential targets are really everyone...
ps: i wish to express support for 2019-08 in its current form.
Cheers, Carlos
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
-- Best regards, Alexander Azimov
This can be fixed by generating your own fake routes that would effectively blackhole all the unassigned traffic, using the publicated RIPE Invalid ROAs. Maria On November 3, 2019 5:12:54 PM GMT+01:00, Alexander Azimov <a.e.azimov@gmail.com> wrote:
Hi,
Let discuss the next scenario: there are two prefixes: x.x.0.0/24 and x.x.1.0/24, first one assigned to an ISP, second - unallocated. The proposal suggests that RIPE should create ROA with AS0 for x.x.1.0/24. Will it stop an attacker from squatting this address space?
The answer will be No. An attacker will still be able to hijack x.x.0.0/23, which will have an 'unknown' status and will be passed on, as a result finally capturing traffic for x.x.1.0/24.
While I support the goals behind this proposal, it seems that ROA with its current model of use is not applicable for this purpose.
сб, 2 нояб. 2019 г. в 14:15, Tim Bruijnzeels <tim@nlnetlabs.nl>:
Hi all,
I am not opposed to this in principle. I see some value. However, I think it would be good to take an impact analysis into account in order to prioritise this relative to other rpki improvements. I agree with others who have said that there may be more valuable things for the ripe ncc to focus on, eg:
- rpki ta key rolls - robustness wrt abuse of the system (producing thousands or millions of objects) - aspa path validation with rpki
Tim
On 2 Nov 2019, at 10:52, Carlos Friaças via routing-wg < routing-wg@ripe.net> wrote:
Hi, (please see inline)
On Fri, 1 Nov 2019, Gert Doering wrote:
Hi,
On Fri, Nov 01, 2019 at 07:09:42AM +0100, Job Snijders wrote: So we really have to wonder whether this is worth it, or whether a few emails or phone calls can also solve the issue.
Isn't that the whole question underlying RPKI deployment?
What is it that we want to stop with RPKI? Only classic "prefix hijacking" (announcing space that is formally delegated somewhere)
With RPKI alone, mistakes.
But when in doubt if network X has rights over network Y, it's rather simple to ask network X to create a proper ROA for network Y.
If that *doesn't* happen, maybe some conclusions can be drawn. (there is a recent thread on the NANOG list where someone raised that "feature"...)
or other misuses of BGP, like "announce unallocated space, use that for spamming or other sorts of network attacks, withdraw announcement before people can track things back to you".
From *one* computer security emergency response team's angle: RPKI is a good first step. Then, hopefully, ASPA can be added at some point.
Playing the quick withdraw game will only work (and it is working, i suspect!) until people start understanding they need to log who announces what to them (24/7/365).
Speaking about "network attacks" -- there is a lot of focus about the address space being hijacked, while major focus should be on those who receive the announcements. While it's terrible for the people/networks being impersonating, the potential targets are really everyone...
ps: i wish to express support for 2019-08 in its current form.
Cheers, Carlos
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
-- Best regards, Alexander Azimov
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
despite the fact that the amount of unassigned/unallocated IPv4 address blocks are so few, but I think the idea behind this proposal is merit, also I think it would be much more effective if it becomes a global policy on all RIRs. On Sun, Nov 3, 2019 at 9:50 PM Maria Matějka <jan.matejka@nic.cz> wrote:
This can be fixed by generating your own fake routes that would effectively blackhole all the unassigned traffic, using the publicated RIPE Invalid ROAs.
Maria
On November 3, 2019 5:12:54 PM GMT+01:00, Alexander Azimov < a.e.azimov@gmail.com> wrote:
Hi,
Let discuss the next scenario: there are two prefixes: x.x.0.0/24 and x.x.1.0/24, first one assigned to an ISP, second - unallocated. The proposal suggests that RIPE should create ROA with AS0 for x.x.1.0/24. Will it stop an attacker from squatting this address space?
The answer will be No. An attacker will still be able to hijack x.x.0.0/23, which will have an 'unknown' status and will be passed on, as a result finally capturing traffic for x.x.1.0/24.
While I support the goals behind this proposal, it seems that ROA with its current model of use is not applicable for this purpose.
сб, 2 нояб. 2019 г. в 14:15, Tim Bruijnzeels <tim@nlnetlabs.nl>:
Hi all,
I am not opposed to this in principle. I see some value. However, I think it would be good to take an impact analysis into account in order to prioritise this relative to other rpki improvements. I agree with others who have said that there may be more valuable things for the ripe ncc to focus on, eg:
- rpki ta key rolls - robustness wrt abuse of the system (producing thousands or millions of objects) - aspa path validation with rpki
Tim
On 2 Nov 2019, at 10:52, Carlos Friaças via routing-wg < routing-wg@ripe.net> wrote:
Hi, (please see inline)
On Fri, 1 Nov 2019, Gert Doering wrote:
Hi,
On Fri, Nov 01, 2019 at 07:09:42AM +0100, Job Snijders wrote: So we really have to wonder whether this is worth it, or whether a few emails or phone calls can also solve the issue.
Isn't that the whole question underlying RPKI deployment?
What is it that we want to stop with RPKI? Only classic "prefix hijacking" (announcing space that is formally delegated somewhere)
With RPKI alone, mistakes.
But when in doubt if network X has rights over network Y, it's rather simple to ask network X to create a proper ROA for network Y.
If that *doesn't* happen, maybe some conclusions can be drawn. (there is a recent thread on the NANOG list where someone raised that "feature"...)
or other misuses of BGP, like "announce unallocated space, use that for spamming or other sorts of network attacks, withdraw announcement before people can track things back to you".
From *one* computer security emergency response team's angle: RPKI is a good first step. Then, hopefully, ASPA can be added at some point.
Playing the quick withdraw game will only work (and it is working, i suspect!) until people start understanding they need to log who announces what to them (24/7/365).
Speaking about "network attacks" -- there is a lot of focus about the address space being hijacked, while major focus should be on those who receive the announcements. While it's terrible for the people/networks being impersonating, the potential targets are really everyone...
ps: i wish to express support for 2019-08 in its current form.
Cheers, Carlos
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
-- Best regards, Alexander Azimov
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Hi, On Sun, Nov 03, 2019 at 07:12:54PM +0300, Alexander Azimov wrote:
Let discuss the next scenario: there are two prefixes: x.x.0.0/24 and x.x.1.0/24, first one assigned to an ISP, second - unallocated. The proposal suggests that RIPE should create ROA with AS0 for x.x.1.0/24. Will it stop an attacker from squatting this address space?
The answer will be No. An attacker will still be able to hijack x.x.0.0/23, which will have an 'unknown' status and will be passed on, as a result finally capturing traffic for x.x.1.0/24.
This is unfortunate. But indeed, it would make this change far less effective for the cases I had in mind. So I am reconsidering and joining the "it might be somewhat beneficial, but there are more important RPKI things to fix" camp. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi, On Sun, Nov 03, 2019 at 03:04:06PM -0800, Randy Bush wrote:
"it might be somewhat beneficial, but there are more important RPKI things to fix" e.g.?
Nothing "in RPKI itself" (or if there is, I wouldn't be the one to understand the fine details), more in the processes @ NCC (and inter-RIR?) that have been mentioned before. "What Nick said" gert -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Petrit Hasani wrote on 31/10/2019 14:28:
A new RIPE Policy proposal, 2019-08, "RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space" is now available for discussion.
This policy is more relevant to IPv6, because there is lots of unallocated / unassigned IPv6 address space, and that situation will continue indefinitely. Having said that, there's been no evidence produced that ipv6 hijacking is a problem. Ipv6 is not a scarce resource; nor is unallocated / unassigned space as valuable for hijacking as ipv4. For IPv4, given the timescales of policy development, the policy (if accepted) would become active well after the RIPE NCC working ipv4 allocation pool was empty. Also, there's a waiting list policy for new IPv4 address space, which means that any new IPv4 addresses which become available are almost certain to be snapped up immediately. So the benefits of hours to days worth of invalidation seem small. In effect, this means that the RIPE NCC would end up creating ipv4 ROAs for: - the temporary address pool - the ixp pool - the /16 held in reserve and basically nothing else. From a political point of view, I'm deeply uncomfortable with the idea of the RIPE NCC setting out to make preemptive declarations of routability for anything other than holders of resource allocations / assignments. This is new and precedents like this could weaken the RIPE NCC's case if it were to argue in court that it was inappropriate for it to create false ROAs for address blocks. Overall, the technical value of this proposal is small, and it raises potentially difficult and awkward questions about precedent. I don't think that this is a good balance from the point of view of policy development. Nick
On Thu, 2019-10-31 at 19:34 +0000, Nick Hilliard wrote:
Petrit Hasani wrote on 31/10/2019 14:28:
A new RIPE Policy proposal, 2019-08, "RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space" is now available for discussion.
From a political point of view, I'm deeply uncomfortable with the idea of the RIPE NCC setting out to make preemptive declarations of routability for anything other than holders of resource allocations / assignments. This is new and precedents like this could weaken the RIPE NCC's case if it were to argue in court that it was inappropriate for it to create false ROAs for address blocks.
The declaration that is envisioned is more akin to "there is no party authorised to make routing attestations regarding this space". If by "false ROAs" you mean ones that contradict the intentions of the assignee, then this is hardly the same thing. Perhaps an alternative would be an resource x.509 attribute that says "this CA cert does not issue EE certs", so that any resources that it contains could be implicitly considered bogons unless delegated to a subordinate CA. This is of course a (large) protocol change. Cheers, Ben
Hi, i really like the idea of dropping unassigned address space via RPKI invalids, too. +1 Kind Regards Jan
On 31. Oct 2019, at 15:29, Petrit Hasani <phasani@ripe.net> wrote:
Dear colleagues,
A new RIPE Policy proposal, 2019-08, "RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space" is now available for discussion.
This proposal aims to instructs the RIPE NCC to create ROAs with origin AS0 for all unallocated and unassigned address space under its control.
You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2019-08
As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer.
At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal.
We encourage you to review this proposal and send your comments to <routing-wg@ripe.net> before 29 November 2019.
Kind regards,
-- Petrit Hasani Policy Officer RIPE NCC
On 31/10/2019 16:28, Petrit Hasani wrote: Totally support this proposal. -Hank
Dear colleagues,
A new RIPE Policy proposal, 2019-08, "RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space" is now available for discussion.
This proposal aims to instructs the RIPE NCC to create ROAs with origin AS0 for all unallocated and unassigned address space under its control.
You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2019-08
As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer.
At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal.
We encourage you to review this proposal and send your comments to <routing-wg@ripe.net> before 29 November 2019.
Kind regards,
-- Petrit Hasani Policy Officer RIPE NCC
Dear colleagues,
On 31 Oct 2019, at 15:28, Petrit Hasani <phasani@ripe.net> wrote:
Dear colleagues,
A new RIPE Policy proposal, 2019-08, "RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space" is now available for discussion.
On the surface this proposal has merit, but I have the impression that implementing AS0 ROAs for all unallocated and unassigned address space has the potential to be operationally problematic, given incoming and outgoing resource transfers, mergers and closures of organisations, etc., while at the same time may have limited value. If the policy is adopted, this is what the RIPE NCC RPKI team will spend the coming months on implementing. However, there are in my opinion more pressing matters to address. Nathalie Trenaman outlined several of them in her RIPE 79 presentation: https://ripe79.ripe.net/archives/video/258/ I can think of some others too, such as the ability for any organisation to (programatically) bring the RPKI system to its knees by creating huge amounts of /48 ROAs for an IPv6 block. I also think it would be more valuable for the RIPE NCC and the other RIRs to have a process in case a Trust Anchor needs to perform a planned or unplanned key roll. In short, I’d like the current RPKI system to be more robust before introducing a new puzzle piece. This is why I don’t support the proposal at this time. Kind regards, Alex Band NLnet Labs
Hi, I am supporting this proposal. +1 Regards, Kurt Kayser Am 31.10.19 um 15:28 schrieb Petrit Hasani:
Dear colleagues,
A new RIPE Policy proposal, 2019-08, "RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space" is now available for discussion.
This proposal aims to instructs the RIPE NCC to create ROAs with origin AS0 for all unallocated and unassigned address space under its control.
You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2019-08
As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer.
At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal.
We encourage you to review this proposal and send your comments to <routing-wg@ripe.net> before 29 November 2019.
Kind regards,
-- Petrit Hasani Policy Officer RIPE NCC
Dear colleagues, On Thu, 2019-10-31 at 15:28 +0100, Petrit Hasani wrote:
This proposal aims to instructs the RIPE NCC to create ROAs with origin AS0 for all unallocated and unassigned address space under its control.
You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2019-08
As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer.
I feel that the idea is good. But... It's true that there is not that much IPv4 "unallocated" remaining space yet, and therefore that it mostly concerns IPv6 space. However, if that policy is accepted and implemented, I'd say that it should be globally done with cooperation among other RIRs and even with space not delegated yet to any RIRs. So, maybe it's quite early to go on it ? Cheers, -- Clément Cavadore
Hi Clement,
I feel that the idea is good. But...
It's true that there is not that much IPv4 "unallocated" remaining space yet, and therefore that it mostly concerns IPv6 space. However, if that policy is accepted and implemented, I'd say that it should be globally done with cooperation among other RIRs and even with space not delegated yet to any RIRs.
Just to let you know that similar policy has already been approved by APNIC community in the September meeting and awaiting APNIC EC (Board) approval this month and will be implemented max by January 2020. https://www.apnic.net/community/policy/proposals/prop-132
So, maybe it's quite early to go on it ?
One RIR is already doing it, so I guess its not quite early for RIPE :) Regards, Aftab A. Siddiqui
Cheers, -- Clément Cavadore
Hi The other RIRs would adopt it as well if RIPE does it. Kind regards Bogdan On 11/1/2019 2:13 PM, Aftab Siddiqui wrote:
Hi Clement,
I feel that the idea is good. But...
It's true that there is not that much IPv4 "unallocated" remaining space yet, and therefore that it mostly concerns IPv6 space. However, if that policy is accepted and implemented, I'd say that it should be globally done with cooperation among other RIRs and even with space not delegated yet to any RIRs.
Just to let you know that similar policy has already been approved by APNIC community in the September meeting and awaiting APNIC EC (Board) approval this month and will be implemented max by January 2020.
https://www.apnic.net/community/policy/proposals/prop-132
So, maybe it's quite early to go on it ?
One RIR is already doing it, so I guess its not quite early for RIPE :) Regards,
Aftab A. Siddiqui
Cheers, -- Clément Cavadore
I’m guessing, in fact, that this proposal has been inspired from the APNIC proposal, which now is already a policy. It will be interesting to understand if the authors were aware of that, or if they reached the same conclusion, or there are different motivations, etc. Of course, I supported the APNIC proposal, and support it here. I will like to add that, even if I agree that the best path is probably a global policy, and possibly also an IETF document to back it, both of those, will require time. Meanwhile, I think is better to move on already in as many RIRs as we can, and then, if all the 5 RIRs adopt it, then we may want to try to have a common text and “convert” the policies into a global one. Regards, Jordi @jordipalet El 1/11/19 13:14, "routing-wg en nombre de Aftab Siddiqui" <routing-wg-bounces@ripe.net en nombre de aftab.siddiqui@gmail.com> escribió: Hi Clement, I feel that the idea is good. But... It's true that there is not that much IPv4 "unallocated" remaining space yet, and therefore that it mostly concerns IPv6 space. However, if that policy is accepted and implemented, I'd say that it should be globally done with cooperation among other RIRs and even with space not delegated yet to any RIRs. Just to let you know that similar policy has already been approved by APNIC community in the September meeting and awaiting APNIC EC (Board) approval this month and will be implemented max by January 2020. https://www.apnic.net/community/policy/proposals/prop-132 So, maybe it's quite early to go on it ? One RIR is already doing it, so I guess its not quite early for RIPE :) Regards, Aftab A. Siddiqui Cheers, -- Clément Cavadore ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
Your guess is correct. We have been inspired by the APNIC proposal. And yes agreed that a global policy would be best but as work already started we’ve decided to just file it with RIPE for now to at least get it started. Once other RIRs adopt this kind of work it can be turned into a global policy. Also we didn’t want to wait that long; a global policy can take very long. Also replying to some of the other comments in the thread; - amount of work: “it’ll take RIPE a lot of time or efforts to implement this”. I would want to wait with conclusions when RIPE (probably Nathalie) is done with the impact assessment. Only then we can take conclusions. - the impact of this proposal is limited: perhaps it is but should that withhold us from doin it? Speed limits and wearing seatbelts aren’t preventing every casualty in car accident as well but still we enforce those. Why not at least try to prevent potential hijacking? On Friday, November 1, 2019, JORDI PALET MARTINEZ via routing-wg < routing-wg@ripe.net> wrote:
I’m guessing, in fact, that this proposal has been inspired from the APNIC proposal, which now is already a policy. It will be interesting to understand if the authors were aware of that, or if they reached the same conclusion, or there are different motivations, etc.
Of course, I supported the APNIC proposal, and support it here.
I will like to add that, even if I agree that the best path is probably a global policy, and possibly also an IETF document to back it, both of those, will require time. Meanwhile, I think is better to move on already in as many RIRs as we can, and then, if all the 5 RIRs adopt it, then we may want to try to have a common text and “convert” the policies into a global one.
Regards,
Jordi
@jordipalet
El 1/11/19 13:14, "routing-wg en nombre de Aftab Siddiqui" < routing-wg-bounces@ripe.net en nombre de aftab.siddiqui@gmail.com> escribió:
Hi Clement,
I feel that the idea is good. But...
It's true that there is not that much IPv4 "unallocated" remaining space yet, and therefore that it mostly concerns IPv6 space. However, if that policy is accepted and implemented, I'd say that it should be globally done with cooperation among other RIRs and even with space not delegated yet to any RIRs.
Just to let you know that similar policy has already been approved by APNIC community in the September meeting and awaiting APNIC EC (Board) approval this month and will be implemented max by January 2020.
https://www.apnic.net/community/policy/proposals/prop-132
So, maybe it's quite early to go on it ?
One RIR is already doing it, so I guess its not quite early for RIPE :)
Regards,
Aftab A. Siddiqui
Cheers, -- Clément Cavadore
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company
This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
In an ideal world this proposal would not be necessary. In an ideal world, all prefixes would be covered by ROAs and we would not only drop invalids but also unknowns. But this world is not ideal, and until we have at least as many ROAs as route-objects (our route servers drop all announcements not covered by route objects AND drops invalids) this policy is a good step forward, so I support it. Wolfgang
On 31. Oct 2019, at 15:28, Petrit Hasani <phasani@ripe.net> wrote:
This proposal aims to instructs the RIPE NCC to create ROAs with origin AS0 for all unallocated and unassigned address space under its control.
-- Wolfgang Tremmel Phone +49 69 1730902 0 | wolfgang.tremmel@de-cix.net Executive Directors: Harald A. Summa and Sebastian Seifert | Trade Registry: AG Cologne, HRB 51135 DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net
On 10/31/19 3:28 PM, Petrit Hasani wrote:
A new RIPE Policy proposal, 2019-08, "RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space" is now available for discussion.
Hi, I'm not supporting this policy at this time mainly because the work by RIPE NCC needed to implement it is not worth the result. On the other hand, I think that a coordinated policy among all the RIRs is a better way to achieve the goal of rejecting all the bogon announcements by RPKI-enabled networks. -- antonio
participants (25)
-
Aftab Siddiqui -
Alex Band -
Alexander Azimov -
Antonio Prado -
Ben Maddison -
Carlos Friaças -
Christian Adler -
Clement Cavadore -
Ehsan Ghazizadeh -
Gert Doering -
Hank Nussbacher -
Ian Dickinson -
Jan -
Job Snijders -
JORDI PALET MARTINEZ -
Kurt Kayser -
Maria Matějka -
Melchior Aelmans -
Nick Hilliard -
Petrit Hasani -
Randy Bush -
RedCluster -
Tim Bruijnzeels -
Tore Anderson -
Wolfgang Tremmel