[routing-wg] Call for Presentations - RIPE 82

[Peter Lothberg]

Job,

Are you saying that the routing WG does not do it's job as
you are suggesting that "routing problems" might disrupt
the presentations?

I suggest that everyone go back to work and fix their networks
for everyone benefit, or do we need o have "routing 101?

I can redo one of the BGP4 talks from beginning of 1990's
if we forgot it all..

Today, any (forwarding) disruption longer than 200ms is
unacceptable. (Did you make sure your vendor did the
right thing in their HW/SW?)


-Peter

>
> We'll ask presenters to pre-recorded their talk to try to prevent local,
> logistcal, and/or routing problems from impacting the meeting. :-)
>
> Kind regards,
>
> Job, Paul, Ignas
> Routing Working Group Chairs

[routing-wg] Weekly Routing Table Report

[Routing Analysis Role Account]

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 20 Mar, 2021

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  852766
Prefixes after maximum aggregation (per Origin AS):  323236
Deaggregation factor:  2.64
Unique aggregates announced (without unneeded subnets):  405450
Total ASes present in the Internet Routing Table: 70882
Prefixes per ASN: 12.03
Origin-only ASes present in the Internet Routing Table:   60994
Origin ASes announcing only one prefix:   25179
Transit ASes present in the Internet Routing Table:9888
Transit-only ASes present in the Internet Routing Table:306
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  38
Max AS path prepend of ASN ( 37385)  33
Prefixes from unregistered ASNs in the Routing Table:  1034
Number of instances of unregistered ASNs:  1038
Number of 32-bit ASNs allocated by the RIRs:  35442
Number of 32-bit ASNs visible in the Routing Table:   29493
Prefixes from 32-bit ASNs in the Routing Table:  137004
Number of bogon 32-bit ASNs visible in the Routing Table:38
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:543
Number of addresses announced to Internet:   2916989056
Equivalent to 173 /8s, 221 /16s and 184 /24s
Percentage of available address space announced:   78.8
Percentage of allocated address space announced:   78.8
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.5
Total number of prefixes smaller than registry allocations:  289583

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   225916
Total APNIC prefixes after maximum aggregation:   65289
APNIC Deaggregation factor:3.46
Prefixes being announced from the APNIC address blocks:  222073
Unique aggregates announced from the APNIC address blocks:89207
APNIC Region origin ASes present in the Internet Routing Table:   11402
APNIC Prefixes per ASN:   19.48
APNIC Region origin ASes announcing only one prefix:   3248
APNIC Region transit ASes present in the Internet Routing Table:   1609
Average APNIC Region AS path length visible:4.5
Max APNIC Region AS path length visible: 30
Number of APNIC region 32-bit ASNs visible in the Routing Table:   6550
Number of APNIC addresses announced to Internet:  771087872
Equivalent to 45 /8s, 245 /16s and 222 /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-143673
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:244602
Total ARIN prefixes after maximum aggregation:   112452
ARIN Deaggregation factor: 2.18
Prefixes being announced from the ARIN address blocks:   245196
Unique aggregates announced from the ARIN address blocks:117070
ARIN Region origin ASes present in the Internet Routing Table:18755
ARIN Prefixes per ASN:13.07
ARIN 

[routing-wg] Call for Presentations - RIPE 82

[Job Snijders via routing-wg]

Dear RIPE Routing WG,

This is a call for presentation proposals for RIPE 82.

The RIPE 82 meeting takes place in about 8 weeks: https://ripe82.ripe.net/

We ask the Working Group and RIPE NCC for presentation proposals for the
illustrious 1 hour Routing WG slot on Thursday, May 20th 2021.

When you submit a proposal please also include slides for the chairs to
review. If you've presented similar material elsewhere please share with
us when and where.

We'll ask presenters to pre-recorded their talk to try to prevent local,
logistcal, and/or routing problems from impacting the meeting. :-)

Kind regards,

Job, Paul, Ignas
Routing Working Group Chairs

Re: [routing-wg] RPKI Route Origin Validation and AS3333

[Leo Vegoda]

Hi Nathalie,

On Fri, Mar 19, 2021 at 4:24 AM Nathalie Trenaman  wrote:

[...]

> > If the goal is to do this in a customer friendly way, perhaps consider
> > creating a website at something like: https://brokenrpki.ripe.net, on
> > a network that does not validate RPKI, so that users can be provided
> > with any analytical tools or step-by-step guides thought necessary.
>
> First of all, thanks for the warm support for ROV on AS. I’m reading all 
> mails and the discussion with great interest.
> Now, here Leo brings up a tricky point. If we would create such a website, 
> outside of our network, be would basically tell that other party to 
> never-ever do ROV themselves.
> I don’t think that we can (or should) demand that from another network.
> Also, other operational “back doors” are not a good idea, as we try to 
> equally protect the registry and the routing table. This will have 
> consequences. Operators who “locked themselves out” should use another 
> network to reach the LIR Portal.

I might not have been clear. Sorry. My intention was not for the RIPE
NCC to create a full-service LIR Portal on a network that doesn't use
RPKI. Instead, I was trying to suggest creating something like the
many DNSSEC validation checking websites that help you understand
where things have gone wrong. Being able to provide this analysis to
someone who has tripped over will allow you to provide them with
authoritative advice on the paths they could take to fix things.

> Apart from a big warning in the LIR Portal if they are about to do something 
> that can lock them out (as Gert mentioned) , there isn’t much we can do. And 
> from what I read here, there isn’t much more we should do.

This is definitely a good idea.

Kind regards,

Leo

Re: [routing-wg] RPKI Route Origin Validation and AS3333

[Nathalie Trenaman]

Hi all,


> Op 18 mrt. 2021, om 17:01 heeft Leo Vegoda  het volgende 
> geschreven:
> 
> Hi,
> 
> On Thu, Mar 18, 2021 at 8:03 AM Nathalie Trenaman  wrote:
> 
> [...]
> 
>> What is the Problem?
>> Currently, some of our upstream providers already perform ROV. This means 
>> that some of our members that potentially misconfigured their ROA or members 
>> who have lost control of creation and modification of their ROAs cannot 
>> reach our services via those peers.
> 
> [...]
> 
>> From an analysis we made on 10 February, there were 511 of such 
>> announcements from our members and End Users.
> 
> If the goal is to do this in a customer friendly way, perhaps consider
> creating a website at something like: https://brokenrpki.ripe.net, on
> a network that does not validate RPKI, so that users can be provided
> with any analytical tools or step-by-step guides thought necessary.

First of all, thanks for the warm support for ROV on AS. I’m reading all 
mails and the discussion with great interest. 
Now, here Leo brings up a tricky point. If we would create such a website, 
outside of our network, be would basically tell that other party to never-ever 
do ROV themselves. 
I don’t think that we can (or should) demand that from another network. 
Also, other operational “back doors” are not a good idea, as we try to equally 
protect the registry and the routing table. This will have consequences. 
Operators who “locked themselves out” should use another network to reach the 
LIR Portal. 

Apart from a big warning in the LIR Portal if they are about to do something 
that can lock them out (as Gert mentioned) , there isn’t much we can do. And 
from what I read here, there isn’t much more we should do. 

Kind regards,
Nathalie Trenaman
RIPE NCC

Re: [routing-wg] RPKI Route Origin Validation and AS3333

[Ben Maddison via routing-wg]

Hi Nathalie,

On 03/18, Nathalie Trenaman wrote:
> Dear Colleagues, Working Group,
> 
> As discussed previously in this mailing list, some community members
> expressed that they would like to see the RIPE NCC perform Route
> Origin Validation on AS. We decided to ask the community for
> advice and guidance on how we should proceed. 
> 
> What is Route Origin Validation?  Route Origin Validation is a
> mechanism by which route advertisements can be authenticated as
> originating from an expected autonomous system (AS).  The best current
> practice is to drop RPKI invalid BGP announcements. These are
> announcements that conflict with the statement as described in a Route
> Origin Authorization (ROA).
> 
I believe that you have hit the nail on the head here: dropping ROV
Invalids has (IMO) now become the best practice for operators of all
sizes. It is no longer some experimental technique for academics and
people that live at the bleeding edge.

We wouldn't have the same debate about dropping martians, right?

> What is AS?  This is the AS Number for the RIPE NCC’s main service
> network. It includes most of our *.ripe.net 
> websites, including the LIR Portal (my.ripe.net )
> and the RIPE Database. 
> 
> What is the Problem?  Currently, some of our upstream providers
> already perform ROV. This means that some of our members that
> potentially misconfigured their ROA or members who have lost control
> of creation and modification of their ROAs cannot reach our services
> via those peers. 
> 
> On the other hand, some of our upstream providers do not perform ROV,
> and if a member’s prefix is being announced by a hijacker, they cannot
> access our services. We already received a report about this.This is
> also not an ideal situation. 
> 
> From the network operations perspective, there are no obstacles to
> enable  ROV on AS, however, we have to consider that members or
> End Users who announce something different in BGP than their ROA
> claims, will be dropped and lose access to our services from their
> network. This includes the RPKI Dashboard where they can make changes
> to their ROAs. This is specially relevant when members operate
> certificate generation in hosted mode which is the current operation
> mode for almost all for our members. 
> 
Your explanation seems to suggest that the above scenarios are similar.
I would suggest that they are actually opposites of one-another:

If a network cannot access RIPE's online services because they broke
their routing, including through creating a conflicting ROA, the blame
lies with the operator of that network.

On the other hand, if a network cannot access those services because
RIPE's routers are selecting a route towards it that is identifiably
bogus using best current practices, including RPKI ROV, then the fault
lies with the RIPE NCC.

Again, no one would be wringing their hands because someone was unable
to get to the LIR portal from 10/8, right?

> From an analysis we made on 10 February, there were 511 of such
> announcements from our members and End Users.
> 
ROV is well deployed today. Either these routes are covered by Valid
aggregates, or these members are already experiencing widespread routing
issues.

In the later case, whilst that is unfortunate for those operators and
their customers in the short term, experiencing some inconvenience is
likely the only possible incentive for the problematic objects to get
cleaned up.

I don't think that RIPE or it's members should be expected to sit around
and wait for that to happen by magic.

> Our current RPKI Terms and Conditions do not mention that a Member or
> End User ROA should match their routing intentions, or any
> implications it may have if the ROA does not match their BGP
> announcement. If the community decides it is important that AS
> performs ROV, our legal team needs to update the RPKI Terms and
> Conditions to reflect the potential impact. 
> 
As others have already indicated, I don't think that this has any place
in those Ts

I'm sure that if RIPE were ever to be subject to a claim arising from a
member kicking themselves out of the LIR portal, you would find no
shortage of expert witnesses on this list queuing up to help have it
laughed out of court.

> I welcome a respectful discussion and look forward to your advice and
> guidance.
> 
I think that the feedback you have received in the last 24 hours is
quite unambiguous.

I hope we'll see some swift action in response.

Cheers,

Ben


signature.asc
Description: PGP signature

Re: [routing-wg] RPKI Route Origin Validation and AS3333

[Mikael Abrahamsson via routing-wg]

On Thu, 18 Mar 2021, Nathalie Trenaman wrote:

Currently, some of our upstream providers already perform ROV. This 
means that some of our members that potentially misconfigured their ROA 
or members who have lost control of creation and modification of their 
ROAs cannot reach our services via those peers.


Thanks for the outreach to the community. Indeed, as stated above, the 
more providers are enabling RPKI, the less consequential it is whether 
RIPE NCC is performing ROV or not. This, as the scales tip to "if you made 
a ROA mistake you can't talk to the Internet", it instead becomes 
important that RIPE NCC staff has deep knowledge in how the RPKI ecosystem 
works, including monitoring etc. That would be an upside to performing ROV 
and implementing all monitoring that should come with it. Then RIPE NCC 
will have staff with operational knowledge of all aspects of routing, ROV 
and RPKI. I believe this would be beneficial to RIPE NCC and the Internet 
as a whole.


Thanks.

--
Mikael Abrahamssonemail: swm...@swm.pp.se