From fischerdouglas at gmail.com  Mon Mar  1 11:46:47 2021
From: fischerdouglas at gmail.com (Douglas Fischer)
Date: Mon, 1 Mar 2021 08:46:47 -0300
Subject: [RPKI] Improvements in RPKI ensuring backward compatibility - Would
 be possible?
In-Reply-To: <CAKEr4RQ-qb1yffNJahjVH-bRQ1+uAp+LfX+CasF5ZCa0yqSMyQ@mail.gmail.com>
References: <CAKEr4RQ-qb1yffNJahjVH-bRQ1+uAp+LfX+CasF5ZCa0yqSMyQ@mail.gmail.com>
Message-ID: <CAKEr4RS4hwWudyvjTGqP_B9EhuZoYcgOEGadaOGiLHWEho-LVQ@mail.gmail.com>

I recently sent this email(below) to the NLNetLabs RPKI list.
https://lists.nlnetlabs.nl/pipermail/rpki/2021-February/000261.html

And I was recommended to bring this topic to sidrops.


I am not yet familiar with the M.O. of this community, so I apologize and
accept guidance for any inappropriate behavior.

I am concerned to keep the healthy use of RTBH viable...
I know that this is not the best mechanism to solve problems with DDoS and
similar.
But in practice, it ends up being the most cost-effective tool for the
operator of the ASN itself that is being targeted by what I call "silly
attacks" to react and evade those attacks.

The purpose of this email is to present two possibilities that I have been
imagining for some time as good measures for RPKI.

Note: As I know that I am locked in the point of view of those who only see
the positive side of an idea ... I am open to seeing the negative side of
these ideas.

-----
1 - Increase the levels, officially in the protocol, the status of a route
based on the RPKI, Specially of Invalid Status.
-----
In the email below, this concept is reasonably well described.
I kindly ask you to read this detail below.

This is already possible to implement today if the protocol is "sliced" a
little, but it needs to be done using specific ROA validator engines, and
it needs to be done on a host that allows you to execute specific code,
which prevents this from being natively implemented and standard routers on
the market.

The idea is to give the ASN operator the autonomy to decide (on
routing-filter policies) what to do with some route, based on the detailed
RPKI status of that route.


P.S .: I have observed that other initiatives are inclined to go the same
way of further analyzing the status of the Route based on ROA. Unless
mistaken, there are discussions about this in projects involving some
Route-Server used by several IXPs to improve Police-Filtering of RTBH.

-----
2 - Add the possibility of using the "minimum prefix length" attribute in
RPKI ROAs.
-----
With that, I believe that the reality of the routes generated by the ASNs
would be better represented. In addition to allowing ROAs exclusively
created for RTBH and the like to be created.

Ex.1: An organization with an IPv4 / 16 block will rarely advertise this
block only with a single route. Whether for geographic reasons or for
routing strategy, it will probably advertise this in / 18-20 block.
Ex.2 .: This same organization may want to tell the world that Routes
originated by its own ASN, or by ASNs of scrubing companies, of the prefix
of this / 16 with the mask "LE 32" "GE 32" are valid.



Thanks in advance for your patience and comprehension.

--
Douglas Fernando Fischer
Eng? de Controle e Automa??o


---------- Forwarded message ---------
De: Douglas Fischer <fischerdouglas at gmail.com>
Date: ter., 23 de fev. de 2021 ?s 08:14
Subject: IETF draft - The Use of Maxlength in the RPKI
To: <rpki at lists.nlnetlabs.nl>


I don't know if this is the best forum to discuss this ...
If not, I apologize.

So far I was not aware of this draft, which already has 6 versions, and is
heading towards the final version.

https://tools.ietf.org/html/draft-ietf-sidrops-rpkimaxlen-06

As far as I could understand, the main reason for proposing this draft is
to enable a safe and fast way to make the security of the RPKI origin
validation also include the cases of RTBH ads that are generally of unique
IPs (/ 32 or / 128 ).

Honestly, so far I am undecided as to whether this is the best methodology
for such a solution.

Until now I was adopting (especially for route-servers) the methodology of
further analyzing the possible status of RPKI.
- Valid -> complements do not fit
- Unknown -> complements do not fit
- Invalid -> by previous ROA Date
- Invalid -> by Later ROA Date
- Invalid -> by ASN of Origin
- Invalid -> for less specific mask
- Invalid -> by more specific mask

Thus, in the route filtering tests received against Blackhole I was using
the following logic:

If (is into AS-SET My-Customer) and \
   (has Black-Hole-Community) and \
   ((is IPv4 and is /32) or (is IPv6 and is /128)) and \
   ((is RPKI Valid) or (is RPKI unknow) or (is RPKI invalid by mas more
specific)) then \
   accept as Blackhole...

P.S.: This is a very summarized way to express the logic... I had to do
some gymnastics to implement it... Converting RPKI JSONs belonging to each
AS-SET to Prefix-lists.


So I would like to hear from other colleagues about this Draft, and it will
change the way every ASN should filter RPKI, specially RTBH.


-- 
Douglas Fernando Fischer
Eng? de Controle e Automa??o
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/rpki/attachments/20210301/fd6cc2b4/attachment.htm>

From fischerdouglas at gmail.com  Mon Mar  1 11:48:00 2021
From: fischerdouglas at gmail.com (Douglas Fischer)
Date: Mon, 1 Mar 2021 08:48:00 -0300
Subject: [RPKI] Improvements in RPKI ensuring backward compatibility -
 Would be possible?
In-Reply-To: <CAKEr4RS4hwWudyvjTGqP_B9EhuZoYcgOEGadaOGiLHWEho-LVQ@mail.gmail.com>
References: <CAKEr4RQ-qb1yffNJahjVH-bRQ1+uAp+LfX+CasF5ZCa0yqSMyQ@mail.gmail.com>
 <CAKEr4RS4hwWudyvjTGqP_B9EhuZoYcgOEGadaOGiLHWEho-LVQ@mail.gmail.com>
Message-ID: <CAKEr4RREs2hjeRqMJuGv+ifX1Otk=Km_kqNfhMpAFn7GLgWBhA@mail.gmail.com>

Sorry!

Please disregard this e-mail...

Em seg., 1 de mar. de 2021 ?s 08:46, Douglas Fischer <
fischerdouglas at gmail.com> escreveu:

> I recently sent this email(below) to the NLNetLabs RPKI list.
> https://lists.nlnetlabs.nl/pipermail/rpki/2021-February/000261.html
>
> And I was recommended to bring this topic to sidrops.
>
>
> I am not yet familiar with the M.O. of this community, so I apologize and
> accept guidance for any inappropriate behavior.
>
> I am concerned to keep the healthy use of RTBH viable...
> I know that this is not the best mechanism to solve problems with DDoS and
> similar.
> But in practice, it ends up being the most cost-effective tool for the
> operator of the ASN itself that is being targeted by what I call "silly
> attacks" to react and evade those attacks.
>
> The purpose of this email is to present two possibilities that I have been
> imagining for some time as good measures for RPKI.
>
> Note: As I know that I am locked in the point of view of those who only
> see the positive side of an idea ... I am open to seeing the negative side
> of these ideas.
>
> -----
> 1 - Increase the levels, officially in the protocol, the status of a route
> based on the RPKI, Specially of Invalid Status.
> -----
> In the email below, this concept is reasonably well described.
> I kindly ask you to read this detail below.
>
> This is already possible to implement today if the protocol is "sliced" a
> little, but it needs to be done using specific ROA validator engines, and
> it needs to be done on a host that allows you to execute specific code,
> which prevents this from being natively implemented and standard routers on
> the market.
>
> The idea is to give the ASN operator the autonomy to decide (on
> routing-filter policies) what to do with some route, based on the detailed
> RPKI status of that route.
>
>
> P.S .: I have observed that other initiatives are inclined to go the same
> way of further analyzing the status of the Route based on ROA. Unless
> mistaken, there are discussions about this in projects involving some
> Route-Server used by several IXPs to improve Police-Filtering of RTBH.
>
> -----
> 2 - Add the possibility of using the "minimum prefix length" attribute in
> RPKI ROAs.
> -----
> With that, I believe that the reality of the routes generated by the ASNs
> would be better represented. In addition to allowing ROAs exclusively
> created for RTBH and the like to be created.
>
> Ex.1: An organization with an IPv4 / 16 block will rarely advertise this
> block only with a single route. Whether for geographic reasons or for
> routing strategy, it will probably advertise this in / 18-20 block.
> Ex.2 .: This same organization may want to tell the world that Routes
> originated by its own ASN, or by ASNs of scrubing companies, of the prefix
> of this / 16 with the mask "LE 32" "GE 32" are valid.
>
>
>
> Thanks in advance for your patience and comprehension.
>
> --
> Douglas Fernando Fischer
> Eng? de Controle e Automa??o
>
>
> ---------- Forwarded message ---------
> De: Douglas Fischer <fischerdouglas at gmail.com>
> Date: ter., 23 de fev. de 2021 ?s 08:14
> Subject: IETF draft - The Use of Maxlength in the RPKI
> To: <rpki at lists.nlnetlabs.nl>
>
>
> I don't know if this is the best forum to discuss this ...
> If not, I apologize.
>
> So far I was not aware of this draft, which already has 6 versions, and is
> heading towards the final version.
>
> https://tools.ietf.org/html/draft-ietf-sidrops-rpkimaxlen-06
>
> As far as I could understand, the main reason for proposing this draft is
> to enable a safe and fast way to make the security of the RPKI origin
> validation also include the cases of RTBH ads that are generally of unique
> IPs (/ 32 or / 128 ).
>
> Honestly, so far I am undecided as to whether this is the best methodology
> for such a solution.
>
> Until now I was adopting (especially for route-servers) the methodology of
> further analyzing the possible status of RPKI.
> - Valid -> complements do not fit
> - Unknown -> complements do not fit
> - Invalid -> by previous ROA Date
> - Invalid -> by Later ROA Date
> - Invalid -> by ASN of Origin
> - Invalid -> for less specific mask
> - Invalid -> by more specific mask
>
> Thus, in the route filtering tests received against Blackhole I was using
> the following logic:
>
> If (is into AS-SET My-Customer) and \
>    (has Black-Hole-Community) and \
>    ((is IPv4 and is /32) or (is IPv6 and is /128)) and \
>    ((is RPKI Valid) or (is RPKI unknow) or (is RPKI invalid by mas more
> specific)) then \
>    accept as Blackhole...
>
> P.S.: This is a very summarized way to express the logic... I had to do
> some gymnastics to implement it... Converting RPKI JSONs belonging to each
> AS-SET to Prefix-lists.
>
>
> So I would like to hear from other colleagues about this Draft, and it
> will change the way every ASN should filter RPKI, specially RTBH.
>
>
> --
> Douglas Fernando Fischer
> Eng? de Controle e Automa??o
>
>
>

-- 
Douglas Fernando Fischer
Eng? de Controle e Automa??o
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/rpki/attachments/20210301/01cfe2d1/attachment-0001.htm>

From lukas at ltri.eu  Thu Mar 11 21:13:07 2021
From: lukas at ltri.eu (Lukas Tribus)
Date: Thu, 11 Mar 2021 22:13:07 +0100
Subject: [RPKI] xrrtrcheck - RTR/VRP health check for IOS-XR
Message-ID: <CACC_My_TePWjY+AOGPN0wqp+Qz_CPj7Yz_HEk80R6tioE=0hyg@mail.gmail.com>

Dear list(s),


A few months ago I hacked together a python script, which connects via
NETCONF to IOS-XR boxes, and tries to determine the health of the RTR
servers and the local VRP cache.

It will iterate through the RTR server list and check:

- the RTR server state (should be connected)
- minimum VRP IPv4 count (default: 150000)
- minimum VRP IPv6 count (default: 20000)
- maximum deviation of VRP IPv4 count between RTR servers (default: 30000)
- maximum deviation of VRP IPv6 count between RTR servers (default: 10000)

It will return with nagios compatible exit-codes.

Maybe it could be useful for somebody. Note that I'm no longer
actively working on this script, but feel free to ask questions or
take over the code.


Code:
https://gist.github.com/lukastribus/695c9e780d118755271519d4d3cb54f3


cheers,
lukas

From martin at nlnetlabs.nl  Mon Mar 15 15:04:51 2021
From: martin at nlnetlabs.nl (Martin Hoffmann)
Date: Mon, 15 Mar 2021 16:04:51 +0100
Subject: [RPKI] =?utf-8?b?UlRSVFIgMC4xLjIg4oCYVGVuIEZvdXLigJkgUmVsZWFz?=
 =?utf-8?q?ed?=
Message-ID: <20210315160451.45a097db@glaurung.nlnetlabs.nl>

Hi!

We are happy to announce the latest release of RTRTR, version 0.1.2
?Ten Four.?

This is a small release that fixes an issue with the JSON unit
introduced in the previous version that would make it reject any JSON
format that had a metadata field present with content other than that
produced by OctoRPKI.

With this release we are also starting to publish Debian packages at
our package repository at https://packages.nlnetlabs.nl/

You can find more information about RTRTR including installation
instructions on Github at

   https://github.com/NLnetLabs/rtrtr

On behalf of the NLnet Labs RPKI Team,
Martin

From alex at nlnetlabs.nl  Thu Mar 25 12:29:38 2021
From: alex at nlnetlabs.nl (Alex Band)
Date: Thu, 25 Mar 2021 13:29:38 +0100
Subject: [RPKI] RPKI Discord server
Message-ID: <5AD5C1AC-7A09-4FC0-A7E6-1B9553F3EC6F@nlnetlabs.nl>

Dear RPKI list,

We are now also offering a Discord server dedicated to RPKI. 

This is the invite link:
https://discord.gg/NY5SWeJzec

We think Discord invites a different type of discussion and consider it a good addition to, and certainly not a replacement of, this mailing list.

The NLnet Labs code of conduct applies to the use of this service:
https://www.nlnetlabs.nl/conduct/

On behalf of the NLnet Labs team,

Alex