Re: [routing-wg] European cable cut may impact transoceanic routes

[Hank Nussbacher]

On 20/10/2022 16:40, Nick Hilliard wrote:

Hank Nussbacher wrote on 20/10/2022 14:36:

https://trust.zscaler.com/zscloud.net/posts/12256

"We are aware of a major cable cut in the South of France that has 
impacted major subsea cables with connectivity to Asia, Europe, US and 
potentially other parts of the world. As a result of the cable cut, 
customers may see packet loss and or latency for websites and 
applications which traverse these impacted paths."


Really?  Not a peep on outages and nanog.  Hysteria mongering?


there was a vandalism job on a street chamber outside Marseille 
yesterday morning, which this may refer to.


https://twitter.com/Free_1337/status/1582714844658036737

Nick



I don't doubt it was real I just doubt whether it was "major" since if 
it was major I would have seen a post by Doug/Kentik and by QRator by 
now :-)


-Hank

--

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/routing-wg

[routing-wg] European cable cut may impact transoceanic routes

[Hank Nussbacher]

https://trust.zscaler.com/zscloud.net/posts/12256

"We are aware of a major cable cut in the South of France that has 
impacted major subsea cables with connectivity to Asia, Europe, US and 
potentially other parts of the world. As a result of the cable cut, 
customers may see packet loss and or latency for websites and 
applications which traverse these impacted paths."


Really?  Not a peep on outages and nanog.  Hysteria mongering?

-Hank


--

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/routing-wg

[routing-wg] Notice of Inquiry into Secure Internet Routing

[Hank Nussbacher]

Notice of Inquiry into Secure Internet Routing (i.e. what is wrong with 
BGP :-))


https://docs.fcc.gov/public/attachments/FCC-22-18A1.pdf


-Hank


--

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/routing-wg

Re: [routing-wg] RPKI vulnerable?

[Hank Nussbacher]

On 18/02/2022 10:54, Nathalie Trenaman wrote:

Hi Nick,


On 18 Feb 2022, at 09:53, Nick Hilliard  wrote:

Hank Nussbacher wrote on 18/02/2022 07:39:

We are working with large network providers and registrars on mitigating the 
vulnerabilities in RPKI deployments.


Has anyone from the RIPE NCC been in contact with this group?

Nick


No, we haven’t. This also sparked our curiosity, so we’re trying to contact 
them.


Haya posted on her Linkedin posting (3 hours ago) "RIPE NCC is on our 
list" in response to Ivo Dijkhuis asking "Dear Haya, we would certainly 
appreciate an invitation to that workshop."


So I guess RIPE NCC needs to find out who within the NCC has been 
getting Haya's emails.


Regards,
Hank



Kind regards,
Nathalie Trenaman
RIPE NCC



--

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/routing-wg

[routing-wg] RPKI vulnerable?

[Hank Nussbacher]

https://www.linkedin.com/posts/shulman_inter-domain-routing-connects-the-different-activity-6899635463775145984-BaQe


"We found that the current RPKI deployments are vulnerable - cyber 
criminals can disable RPKI in any network in the Internet. We evaluated 
such RPKI disabling attacks in the global Internet and found all the 
RPKI protected networks to be vulnerable. Often such attacks are 
extremely stealthy and do not trigger alerts. These attacks can be 
launched not only by governments, but also by cybercriminals and hackers.



We are working with large network providers and registrars on mitigating 
the vulnerabilities in RPKI deployments. Nevertheless, until the RPKI in 
the global Internet is patched, we caution that the operators should use 
additional measures to ensure that they do not fall prey to prefix hijacks."



H.


-Hank


--

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/routing-wg

Re: [routing-wg] RFO for RIPE NCC RPKI outage 16 February 2022

[Hank Nussbacher]

On 16/02/2022 19:46, Gert Doering wrote:

Hi,

On Wed, Feb 16, 2022 at 05:01:25PM +0100, Ties de Kock wrote:

This afternoon, between 13:00 UTC and 14:10 UTC rrdp.ripe.net was unavailable.

[..]

Thanks for this great postmortem writeup, and for being open about
what happened, and how things always go wrong at the same time
(service and monitoring).


Let me add to what Gert said.  Additional bonus points:
- sending out the postmortem the same day of incident
- total transparency

If this type of incident can happen to RIPE it can so easily happen to 
any of the best of us.


-Hank


--

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/routing-wg

Re: [routing-wg] RPKI Quarterly Planning

[Hank Nussbacher]

On 13/07/2021 16:33, Nathalie Trenaman wrote:

Hi Hank,

Op 13 jul. 2021, om 14:46 heeft Hank Nussbacher <mailto:h...@interall.co.il>> het volgende geschreven:


On 13/07/2021 14:08, Job Snijders via routing-wg wrote:

On Tue, Jul 13, 2021 at 05:25:11AM +0200, Daniel Karrenberg wrote:

It might also be that the operational community has chosen other fora to
discuss because this working group is not working.

What a strange thing to say. Of course there are other fora to discuss
RPKI, one of the most important ones is IETF's SIDROPS working group
(which is quite active!).
As for the road map - RIPE NCC indicated feedback can be shared with the
routing-wg@ or with r...@ripe.net <mailto:r...@ripe.net>. I myself 
opted to try the latter

route to re-iterate a request for publish dashboards and graphs about
the RPKI service which resulted in 'RPKI-2021-#01' being added to the
roadmap.
The motivation behind RPKI-2021-#01 is that many IXPs offer publicly
accessible graphs ala:
https://www.ams-ix.net/ams/documentation/total-stats 
<https://www.ams-ix.net/ams/documentation/total-stats>

https://portal.linx.net/ <https://portal.linx.net/>
https://www.jpnap.net/ix/traffic.html 
<https://www.jpnap.net/ix/traffic.html>

https://www.netnod.se/ix/statistics <https://www.netnod.se/ix/statistics>
https://de-cix.net/en/locations/frankfurt/statistics 
<https://de-cix.net/en/locations/frankfurt/statistics>

When incidents happen, these graphs enable the IX participants to
quickly understand whether 'something is wrong', because humans are
really good at pattern recognition.
I imagine that developing more insight into the RIPE NCC RPKI service
will offer the community similar benefits as what the community gleans
from these public IX stats, hence the ask for RPKI-2021-#01.
Kind regards,
Job


Tool missing that I would like to see:

Breakdown by country - unknowns + invalid ROAs.  Listed as a table of 
prefix + ASN.  Best I have found is https://stats.labs.apnic.net/roas 
<https://stats.labs.apnic.net/roas> which lists totals but doesn't 
provide a breakdown by specific prefix and ASN per country.  Maybe I'm 
missing it.


Regards,
Hank



Is this of any help? Romain Fontugne launched this tool this week:
https://ihr.iijlab.net/ihr/en-us/rov 
<https://ihr.iijlab.net/ihr/en-us/rov>  (worldwide)
https://ihr.iijlab.net/ihr/en-us/countries/FR 
<https://ihr.iijlab.net/ihr/en-us/countries/FR> (per country)


Perfect!

Thanks,
Hank

https://ihr.iijlab.net/ihr/en-us/networks/AS7922 
<https://ihr.iijlab.net/ihr/en-us/networks/AS7922> (per ASN)


Kind regards,
Nathalie Trenaman
RIPE NCC

Re: [routing-wg] RPKI Quarterly Planning

[Hank Nussbacher]

On 13/07/2021 14:08, Job Snijders via routing-wg wrote:

On Tue, Jul 13, 2021 at 05:25:11AM +0200, Daniel Karrenberg wrote:

It might also be that the operational community has chosen other fora to
discuss because this working group is not working.


What a strange thing to say. Of course there are other fora to discuss
RPKI, one of the most important ones is IETF's SIDROPS working group
(which is quite active!).

As for the road map - RIPE NCC indicated feedback can be shared with the
routing-wg@ or with r...@ripe.net. I myself opted to try the latter
route to re-iterate a request for publish dashboards and graphs about
the RPKI service which resulted in 'RPKI-2021-#01' being added to the
roadmap.

The motivation behind RPKI-2021-#01 is that many IXPs offer publicly
accessible graphs ala:

 https://www.ams-ix.net/ams/documentation/total-stats
 https://portal.linx.net/
 https://www.jpnap.net/ix/traffic.html
 https://www.netnod.se/ix/statistics
 https://de-cix.net/en/locations/frankfurt/statistics

When incidents happen, these graphs enable the IX participants to
quickly understand whether 'something is wrong', because humans are
really good at pattern recognition.

I imagine that developing more insight into the RIPE NCC RPKI service
will offer the community similar benefits as what the community gleans
from these public IX stats, hence the ask for RPKI-2021-#01.

Kind regards,

Job



Tool missing that I would like to see:

Breakdown by country - unknowns + invalid ROAs.  Listed as a table of 
prefix + ASN.  Best I have found is https://stats.labs.apnic.net/roas 
which lists totals but doesn't provide a breakdown by specific prefix 
and ASN per country.  Maybe I'm missing it.


Regards,
Hank

Re: [routing-wg] Looking for 1-2 peer MRT RIB file?

[Hank Nussbacher]

On 05/07/2021 15:29, Rene Wilhelm wrote:

Rene,

That is *exactly* what I need.
I owe you a beer when I attend the next physical RIPE.

Regards,
Hank



Hi Hank,

Maybe this http://www.ris.ripe.net/dumps/riswhoisdump.IPv4.gz helps ?

It lists all the IPv4 prefixes seen in the collective of latest RIS
table dumps, together with origin AS and number of peers that passed the
routes to RIS. You could filter on the latter to restrict the view to
"widely seen" routes.

There's an equivalent one for IPv6.

-- Rene

On 7/5/21 1:41 PM, Hank Nussbacher wrote:

On 04/07/2021 17:49, Clemens Mosig wrote:

Can any kind soul send me a file with all current prefixes (832K)?
Don't need AS path or anything else, just a file (txt, csv, whatever) 
of all 832+K prefixes.  Or point me where I can easily extract it.


Thanks,
Hank



Hi Hank,

Both repositories contain RIB files.
E.g.: 
http://archive.routeviews.org/route-views.eqix/bgpdata/2020.11/RIBS/
which contains the RIB from all peers of route-view.eqix at a given 
time. This is in MRT format as far as I know.


Not sure if there are route collectors with only 1 or 2 peers. You 
can always filter for one peer though (e.g. using bgpreader).


Cheers,
Clemens

On 04.07.21 16:41, Hank Nussbacher wrote:
 > Apologies for previous HTML email:
 >
 >
 > I am aware of the MRT files available from RIPE:
 >
 > 
https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/ris-raw-data 


 > I am aware of the MRT files available from routeviews:
 > http://archive.routeviews.org/
 >
 > What I am looking for is an MRT RIB file (not updates), for a single
 > peer or at most 2 peer router. Pointers?
 >
 > Thanks,
 > Hank
 >

Re: [routing-wg] Looking for 1-2 peer MRT RIB file?

[Hank Nussbacher]

On 04/07/2021 17:49, Clemens Mosig wrote:

Can any kind soul send me a file with all current prefixes (832K)?
Don't need AS path or anything else, just a file (txt, csv, whatever) of 
all 832+K prefixes.  Or point me where I can easily extract it.


Thanks,
Hank



Hi Hank,

Both repositories contain RIB files.
E.g.: http://archive.routeviews.org/route-views.eqix/bgpdata/2020.11/RIBS/
which contains the RIB from all peers of route-view.eqix at a given 
time. This is in MRT format as far as I know.


Not sure if there are route collectors with only 1 or 2 peers. You can 
always filter for one peer though (e.g. using bgpreader).


Cheers,
Clemens

On 04.07.21 16:41, Hank Nussbacher wrote:
 > Apologies for previous HTML email:
 >
 >
 > I am aware of the MRT files available from RIPE:
 >
 > 
https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/ris-raw-data 


 > I am aware of the MRT files available from routeviews:
 > http://archive.routeviews.org/
 >
 > What I am looking for is an MRT RIB file (not updates), for a single
 > peer or at most 2 peer router. Pointers?
 >
 > Thanks,
 > Hank
 >

[routing-wg] Looking for 1-2 peer MRT RIB file?

[Hank Nussbacher]

Apologies for previous HTML email:


I am aware of the MRT files available from RIPE:

https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/ris-raw-data
I am aware of the MRT files available from routeviews:
http://archive.routeviews.org/

What I am looking for is an MRT RIB file (not updates), for a single 
peer or at most 2 peer router. Pointers?


Thanks,
Hank

[routing-wg] Looking for 1-2 peer MRT RIB file?

[Hank Nussbacher]

  
  
I am aware of the MRT files available from RIPE:
https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/ris-raw-data
I am aware of the MRT files available from routeviews:
http://archive.routeviews.org/


What I am looking for is an MRT RIB file (not updates), for a
  single peer or at most 2 peer router. Pointers?


Thanks,
Hank

  

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

[Hank Nussbacher]

On 21/03/2021 13:43, Lukas Tribus wrote:

Hello,

On Sat, 20 Mar 2021 at 20:06, Hank Nussbacher  wrote:

I am not sure it is possible, but I would love to see some centralized
site where all dropped ROV invalids would appear.  This way I can see if
I have a problem as well as if someone tried to hijack my space but was
thwarted by the drop.


Monitoring ROV invalids in other people's networks (validators;
routers) is not possible and I doubt it ever will be.



We managed to create "Certificate Transparency" logs where all CAs send 
their certificates so with a little bit of IETF geekery I am sure an RFC 
can be designed so that everyone dumps their RPKI drops into some 
central stream/repository.  Yeah I know - I'm dreaming :-)


Regards,
Hank

Caveat: The views expressed above are solely my own and do not express 
the views or opinions of my employer

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

[Hank Nussbacher]

On 19/03/2021 10:06, Ben Maddison via routing-wg wrote:

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?


I am not sure it is possible, but I would love to see some centralized 
site where all dropped ROV invalids would appear.  This way I can see if 
I have a problem as well as if someone tried to hijack my space but was 
thwarted by the drop.


Regards,
Hank

Caveat: The views expressed above are solely my own and do not express 
the views or opinions of my employer

Re: [routing-wg] Improving operations at RIPE NCC TA (Was: Delay in publishing RPKI objects)

[Hank Nussbacher]

  
  
On 17/02/2021 17:58, Job Snijders via
  routing-wg wrote:


+1.


-Hank




  Dear RIPE NCC,

On Wed, Feb 17, 2021 at 11:28:32AM +0100, Nathalie Trenaman wrote:

  

  The multitude of RPKI service impacting events as a result from
maloperation of the RIPE NCC trust anchor are starting to give me
cause for concern.



I’m sorry to hear this. Transparency is key for us, this means that we
report any event. In this case, we were not compliant with our CPS and
this non-publishing period had operational impact.

  
  
>From the previous email there might be a misunderstanding about what
rpki-client and Routinator do. Both utilities help Relying Parties
validate X.509 signed CMS objects and transform the validated content
into authorizations and attestations. Neither utility is a SLA or CPS
compliance monitor. RIPE NCC - as CA operator - needs different tools.

Neither utility has been designed to interpret the Certification
Practise Policy (written in a natural language) and subsequently
programmatically transform the described 'Service Level' into metrics
suitable for monitoring.

A relying party can never tell the difference between a publication
pipeline being empty because CAs didn't issue new objects, or a
publication pipeline being empty because of a malfunction in one of RIPE
NCC's RPKI subsystems.

More examples of 'out of scope' functionality for Relying Party
software: validators don't monitor whether lirportal.ripe.net is
functional, whether RIPE NCC's BPKI API endpoints are operational, or
whether LIRs paid their invoices, the list is quite long. The validators
by themselves are the wrong tool for RPKI CPS/SLA monitoring.

You state "transparency is key for us", but I fear ad-hoc low-quality
a-posteriori reports are not the appropriate mechanism to impress and
reassure this community regarding 'transparency'.

I have some tangible suggestions to RIPE NCC that will improve the
reliability of the Trust Anchor and potentially help rebuild trust:

A need for Certificate Transparency
---

RIPE NCC should set up a Certificate Transparency project which publicly
shows which certificates (fingerprints) were issued when, and store such
information in immutable logs, accessible to all.

How can anyone trust a Trust Anchor which does not offer transparency
about its issuance process?

Lack of transparency to signer software
---

The RIPE NCC WHOIS database software is open source, as is most of the
software for RIPE Atlas, K-ROOT, and other efforts RIPE NCC has
undertaken over the years.

Why has the signer source code still not open sourced? Why can't members
review the code related to scheduled changes? Why is an organisation
proclaiming 'transparency' being opaque about how the RPKI certificates
are issued?

Lack of Public status dashboard
---

RIPE NCC should set up a website like https://rpki-status.ripe.net/
which shows dashboards with graphs and traffic lights related to each
(best effort) commitment listed in the CPS. RIPE NCC should continuously
publish & revoke & delete objects and verify whether those activities
are visible externally, and then automatically report whether any
potential delays observed are within the Service Levels outlined in the
CPS.

Metrics that come to mind:

* delta between last certificate issuance & successful publication
* Object count in the repository, repo size (and graphs)
* Time-To-Keyroll (and graphs on duration & frequency)
* Resource utilisation of various RPKI subsystems
* aggregate bandwidth consumption for RPKI endpoints (including rrdp, API, rsync)
* Graphs & logs of overlap between INRs listed on EE certificates under
  the RIPE TA and other commonly used TAs, matched against known
  transfers. This will help detect compromises as well as understand
  whether transfers are successful or not.
* Unique client IP count for RSYNC & RRDP for last hour/day/week
* Number of CS/hostmaster tickets mentioning RPKI

There is are plenty of aspects to monitor, perhaps some notes should be
copied from how the DNS root is monitored.

Lack of operational experience with BGP ROV at RIPE NCC
---

I believe the number of potential future incidents related to the RIPE
NCC Trust Anchor can be prevented (or remediation time reduced) if RIPE
NCC themselves apply RPKI based BGP Origin Validation 'invalid ==
reject' policies on the AS  EBGP border routers. RIPE NCC OPS
themselves having a dependency on the RPKI services will increase
organization-wide exposure to the (lack of) well-being of the Trust
Anchor services, and given the short communication channels between the
OPS team and the RPKI team my expectation is that we'll see problems
being solved faster and perhaps even problems being prevented.

An analogy: RIPE NCC is a 

Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)

[Hank Nussbacher]

On 20/02/2020 16:39, Petrit Hasani wrote:

I support this proposal.  Should have been done a long time ago.

Regards,
Hank


Dear colleagues,

Policy proposal 2019-08, "RPKI ROAs for Unallocated and Unassigned RIPE NCC Address 
Space", is now in the Review Phase.

The goal of the proposal is to ask the RIPE NCC to create ROAs with origin AS0 
for all unallocated and unassigned address space under its control.

The proposal has been updated following the last round of discussion. Version 2 
of the proposal includes a specification for the RIPE NCC to create all AS0 
ROAs under a specific Trust Anchor.

The RIPE NCC has prepared an impact analysis on this latest proposal version to 
support the community’s discussion.

You can find the proposal and impact analysis at:
https://www.ripe.net/participate/policies/proposals/2019-08
https://www.ripe.net/participate/policies/proposals/2019-08#impact-analysis

And the draft documents at:
https://www.ripe.net/participate/policies/proposals/2019-08/draft

As per the RIPE Policy Development Process (PDP), the purpose of this four week 
Review Phase is to continue discussion of the proposal, taking the impact 
analysis into consideration, and to review the full draft RIPE Policy Document.

At the end of the Review Phase, the Working Group (WG) Chairs will determine 
whether the WG has reached rough consensus. It is therefore important to 
provide your opinion, even if it is simply a restatement of your input from the 
previous phase.

We encourage you to read the proposal, impact analysis and draft document and send 
any comments to  before 20 March 2020.

Kind regards,

--
Petrit Hasani
Policy Officer
RIPE NCC

Re: [routing-wg] [anti-abuse-wg] An arrest in Russia

[Hank Nussbacher]

On 28/12/2019 21:09, Randy Bush wrote:

How these things slip through is when paperwork gets submitted that is
incorrect and falsified with fake signatures.

and the ncc has a job advert out to hire even more lawyers (no blame;
it's a mess).  can ripe keep from becoming arin?

randy


 It would be nice if RIPE NCC could provide as part of its annual 
report a list of incidents of this nature so we have an idea of how 
wide-spread this is - or not.



-Hank

Re: [routing-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)

[Hank Nussbacher]

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

Re: [routing-wg] Fwd: [bcop] Abstract of the MANRS BCOP

[Hank Nussbacher]

On 28/05/2018 14:53, Job Snijders wrote:
> On Thu, May 17, 2018 at 07:16:34PM +0300, Hank Nussbacher wrote:
>> On 17/05/2018 17:02, Benno Overeinder wrote:
>>
>> Maybe I'm missing it when reading the website and the BCOP but where
>> does it state to *not *allow /25 or more specifics?
> If someone registers a /25, and announces it, and the RPKI ROA allows
> it, then what is the problem? :-)
>
> - Job
>
I am not talking about a registered /25.  I am talking about someone
hijacking your /24 or your /21 by announcing a bunch of /25s. 


-Hank

Re: [routing-wg] Fwd: [bcop] Abstract of the MANRS BCOP

[Hank Nussbacher]

On 17/05/2018 17:02, Benno Overeinder wrote:

Maybe I'm missing it when reading the website and the BCOP but where
does it state to *not *allow /25 or more specifics?
The entire reason for MANRS is to prevent route hijacking.  An ISP that
allows /25s or /26s to be leaked will easily circumvent all filters and
protections put in place since the /25 will override the /24 that most
of us filter on.  Without it specifically stated, we can't come to an
ISP that just announced 1000 /25s and tell them they did something
wrong.  Cuz it doesn't appear anywhere in our BCOP.

Please clue me in as to what I am missing since the way it looks now, it
doesn't do what it is supposed to do.

Thanks,
Hank

> As discussed in the BCOP TF meeting on Monday, we want to inform the
> Routing WG on the status of the MANRS (https://www.manrs.org/manrs/) and
> the MANRS Abstract BCOP.
>
> MANRS have been presented a number of times at the BCOP TF and at the
> Routing WG.  The actual MANRS guidelines are published on the manrs.org
> website, but the BCOP TF had the opinion that a RIPE series document has
> value as a static reference to the MANRS.  With the community input and
> feedback an extended abstract has been written down (see attachment).
>
> Last year August the BCOP TF announced and closed the last call for
> comments on the MANRS Extended Abstract on the BCOP mailing list
> b...@ripe.net.  Somewhat delayed, we want announce on the Routing WG
> mailing list the last call for this document with a time window of two
> weeks (until June 1st).
>
> Thank you and best regards,
>
> Jan Zorz & Benno Overeinder
>
>
>  Forwarded Message 
> Subject: Re: [bcop] Abstract of the MANRS BCOP
> Date: Tue, 22 Aug 2017 15:44:12 +0200
> From: Benno Overeinder 
> To: BCOP Task Force 
> CC: Jan Zorz - Go6 
>
> This reminder is directed to the BCOP TF mailing list subscribers.
>
> In the BCOP TF meeting we announced a period of last comments on the
> extended MANRS BCOP abstract draft and to publish this as a RIPE document.
> We want to close the comments period in two weeks and move the draft
> further in the process to make it a RIPE document.  Note that the draft
> is an abstract of the MANRS BCOP and references the full MANRS BCOP that
> includes examples and can be extended in the future.  The MANRS extended
> abstract published as a RIPE document will be a stable document.
>
> Best regards,
>
> — Benno
>
>
>> On 8 May 2017, at 13:31, Andrei Robachevsky  wrote:
>>
>> Hi,
>>
>> The final version of the MANRS BCOP has been published on the MANRS
>> website: https://www.manrs.org/bcop/. Both a PDF and an online versions
>> are available.
>>
>> However, to bring the bcop process to an official closure, chairs
>> suggested that instead of publishing the MANRS BCOP as a RIPE document,
>> that might be too constrained, we publish just an abstract. And once the
>> BCOP global repository is in place, we can put it there in whatever
>> format is most convenient.
>>
>> I am attaching the abstract for your review and comments.
>>
>> Regards,
>>
>> Andrei
>> <20170508-MANRS-BCOP-abstract.txt><20170508-MANRS-BCOP-abstract.docx>

[routing-wg] Historical routing question

[Hank Nussbacher]

While giving a routing lecture today someone asked me
"Why was eBGP assigned an administrative distance of 20 which is better
than OSPF's administrative distance of 110.  What was the logic behind
that decision?"
I was unable to think of an answer.
Ideas?

Thanks,
Hank

[routing-wg] Comparison of open source switch software?

[Hank Nussbacher]

I know this is *routing* WG but I figured I would try anyway.

I have seen numerous comparisons and RIPE presentations on performance
issues of BIRD vs Quagga vs FRR.

I am looking for the same thing of switch software. 
Has anyone done a feature comparison between:
http://openvswitch.org/
https://www.openswitch.net/
https://cumulusnetworks.com/products/cumulus-linux/
...any other I am missing...
And even better - has anyone done a benchmark to see which performs best?

Thanks,
Hank

Re: [routing-wg] Bogon ASN Filter Policy

[Hank Nussbacher]

On 02/06/2016 22:43, Job Snijders wrote:
> Dear fellow network operators,
>
> In July 2016, NTT Communications' Global IP Network AS2914 will deploy a
> new routing policy to block Bogon ASNs from its view of the default-free
> zone. This notification is provided as a courtesy to the network
> community at large.
>
> After the Bogon ASN filter policy has been deployed, AS 2914 will not
> accept route announcements from any eBGP neighbor which contains a Bogon
> ASN anywhere in the AS_PATH or its atomic aggregate attribute.
>
> The reasoning behind this policy is twofold:
>
> - Private or Reserved ASNs have no place in the public DFZ. Barring
>   these from the DFZ helps improve accountability and dampen
>   accidental exposure of internal routing artifacts.
>
> - All AS2914 devices support 4-byte ASNs. Any occurrence of "23456"
>   in the DFZ is a either a misconfiguration or software issue.
>
> We are undertaking this effort to improve the quality of routing data as
> part of the global ecosystem. This should improve the security posture
> and provide additional certainty [1] to those undertaking network
> troubleshooting.
>
> Bogon ASNs are currently defined as following:
>
> 0   # Reserved RFC7607
> 23456   # AS_TRANS RFC6793
> 64496-64511 # Reserved for use in docs and code RFC5398
> 64512-65534 # Reserved for Private Use RFC6996
> 65535   # Reserved RFC7300
> 65536-65551 # Reserved for use in docs and code RFC5398
> 65552-131071# Reserved
> 42-4294967294   # Reserved for Private Use RFC6996
> 4294967295  # Reserved RFC7300
>
> A current overview of what are considered Bogon ASNs is maintained at
> NTT's Routing Policies page [2]. The IANA Autonomous System Number
> Registry [3] is closely tracked and the NTT Bogon ASN definitions are
> updated accordingly.
>
> We encourage network operators to consider deploying similar policies.
> Configuration examples for various platforms can be found here [4].
>
> NTT staff is monitoring current occurrences of Bogon ASNs in the routing
> system and reaching out to impacted parties on a weekly basis.
>
> Kind regards,
>
> Job
>
> Contact persons:
>
> Job Snijders , Jared Mauch ,
> NTT Communications NOC 
>
> References:
> [1]: https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00
> [2]: http://www.us.ntt.net/support/policy/routing.cfm#bogon
> [3]: https://www.iana.org/assignments/as-numbers/as-numbers.xhtml
> [4]: http://as2914.net/bogon_asns/configuration_examples.txt
>
You guys are my heroes!If 4-5 tier-0 ISPs would do exactly this,
bogus ASNs would disappear in a week.
Instead everyone talks while the problem gets larger (now over 5000):
http://www.cidr-report.org/as2.0/bogus-as-advertisements.html

-Hank

[routing-wg] Looking for a pgm to CIDRize

[Hank Nussbacher]

Dear revelers,

I am looking for a program or website that can take a list of sorted, 
overlapping prefixes and can reduce it to the most CIDRized format.


Example:

5.28.128.0/18
5.28.128.0/20
5.28.128.0/21
5.28.128.0/22
5.28.132.0/23
5.28.136.0/21
5.28.136.0/22
5.29.64.0/18
5.29.64.0/20
5.29.80.0/24
5.29.96.0/20
would reduce to just 2 lines:
5.28.128.0/18
5.29.64.0/18

In the long distant past, I seem to remember hearing or seeing of such a 
program.  Any pointers would be appreciated.


Happy New Year,
Hank