Re: [routing-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
> What is it that we want to stop with RPKI? nothing. databases, even distributed ones are unlikely to start or stop anything. otoh, the goal with rpki-based origin validation was to stop many of the daily accidental mis-originations. randy
Re: [routing-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
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
Re: [routing-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
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 signature.asc Description: OpenPGP digital signature
[routing-wg] Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 02 Nov, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 780897 Prefixes after maximum aggregation (per Origin AS): 297197 Deaggregation factor: 2.63 Unique aggregates announced (without unneeded subnets): 372349 Total ASes present in the Internet Routing Table: 66010 Prefixes per ASN: 11.83 Origin-only ASes present in the Internet Routing Table: 56764 Origin ASes announcing only one prefix: 24242 Transit ASes present in the Internet Routing Table:9246 Transit-only ASes present in the Internet Routing Table:266 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 51 Max AS path prepend of ASN ( 22394) 47 Prefixes from unregistered ASNs in the Routing Table:28 Number of instances of unregistered ASNs:28 Number of 32-bit ASNs allocated by the RIRs: 29349 Number of 32-bit ASNs visible in the Routing Table: 23994 Prefixes from 32-bit ASNs in the Routing Table: 109125 Number of bogon 32-bit ASNs visible in the Routing Table:12 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:323 Number of addresses announced to Internet: 2843181824 Equivalent to 169 /8s, 119 /16s and 131 /24s Percentage of available address space announced: 76.8 Percentage of allocated address space announced: 76.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.4 Total number of prefixes smaller than registry allocations: 260487 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 209431 Total APNIC prefixes after maximum aggregation: 60901 APNIC Deaggregation factor:3.44 Prefixes being announced from the APNIC address blocks: 203765 Unique aggregates announced from the APNIC address blocks:84924 APNIC Region origin ASes present in the Internet Routing Table: 10148 APNIC Prefixes per ASN: 20.08 APNIC Region origin ASes announcing only one prefix: 2808 APNIC Region transit ASes present in the Internet Routing Table: 1504 Average APNIC Region AS path length visible:4.6 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 5172 Number of APNIC addresses announced to Internet: 771110272 Equivalent to 45 /8s, 246 /16s and 53 /24s APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-141625 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:229412 Total ARIN prefixes after maximum aggregation: 106392 ARIN Deaggregation factor: 2.16 Prefixes being announced from the ARIN address blocks: 227432 Unique aggregates announced from the ARIN address blocks:104885 ARIN Region origin ASes present in the Internet Routing Table:18624 ARIN Prefixes per ASN:12.21 ARIN
Re: [routing-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
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 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.trem...@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
Re: [routing-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
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" 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.
Re: [routing-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
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
Re: [routing-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
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 > >
Re: [routing-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
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
Re: [routing-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
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 > before 29 November 2019. > > Kind regards, > > -- > Petrit Hasani > Policy Officer > RIPE NCC > > > > > smime.p7s Description: S/MIME Cryptographic Signature
Re: [routing-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
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 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [routing-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Dear colleagues, > On 31 Oct 2019, at 15:28, 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. 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
Re: [routing-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Hi, > 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 I have read the policy and I don't see any downside to doing this. Creating those ROAs reflects the intention correctly, so let's do this. Cheers, Sander
Re: [routing-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
On Thu, 2019-10-31 at 19:34 +, 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
Re: [routing-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
On Fri, 2019-11-01 at 07:09 +0100, Job Snijders wrote: > On Fri, Nov 01, 2019 at 01:23:44AM +, 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 +, 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
Re: [routing-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
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 before 29 November 2019. Kind regards, -- Petrit Hasani Policy Officer RIPE NCC
