On 27/Jul/18 16:40, Job Snijders wrote:
> This is awesome! I think it is important to have multiple high quality
> implementations so operators have a choice, this way we can work
> towards a healthy routing security software ecosystem and avoid
> mono-culture.
Yes, great to see more
> On 19 Jul 2018, at 23:04, Mark Tinka wrote:
>
>
>
> On 19/Jul/18 21:47, Michel Py wrote:
>
>> I understand that; if there is an easier way to do RPKI, people are going to
>> use it instead of the right way. However, I think that the blacklist targets
>> a different kind of customer :
Dear Alex,
On Thu, 26 Jul 2018 at 19:11, Alex Band wrote:
> NLnet Labs recently committed to building a full RPKI Toolset, including a
> (Delegated) Certificate Authority, a Publication Server and Relying Party
> software. As an RP implementation was the easiest way to get going, we now
>
Hi all,
Just wanted to share our (AS15703, True B.V.) experience as a hosting provider
with enabling RPKI invalid filtering (invalid == reject). We've secured (most
of) our routes since 2014 with ROAs but last Tuesday we have deployed filters
which reject RPKI invalid routes. We have had two
On 19/Jul/18 21:47, Michel Py wrote:
> I understand that; if there is an easier way to do RPKI, people are going to
> use it instead of the right way. However, I think that the blacklist targets
> a different kind of customer : the end user. We want the enterprise to
> certify their
> Mark Tinka wrote :
> but I want to be cautious about encouraging a parallel stream that slows down
> the deployment of RPKI.
I understand that; if there is an easier way to do RPKI, people are going to
use it instead of the right way. However, I think that the blacklist targets a
different
On 16/Jul/18 19:00, Paolo Lucente wrote:
> Hi Job, All,
>
> It is definitely great to see progress on the deployment side! I realize
> that there may be some gaps in the network operator toolchain, and this
> may be something i'd like to contribute to.
>
> For network operators to better
On 19/Jul/18 01:21, Job Snijders wrote:
> @ all - It would be good if operators ask their vendors if they can get
> behind this I-D https://tools.ietf.org/html/draft-ietf-sidrops-ov-clarify
I'm actually glad to see this (Randy, you've abandoned me, hehe).
We actually hit and troubleshot both
On 18/Jul/18 21:30, Michel Py wrote:
> Not much at all, I was actually trying you do do the RPKI part for me ;-)
> This script you wrote, to produce the list of prefixes that are RPKI invalid
> AND that do not have any alternative, make it run every x minutes on a fixed
> url (no date/time
On Wed, Jul 18, 2018 at 05:55:23PM -0400, Randy Bush wrote:
> > Can you elaborate what routers with what software you are using? It
> > surprises me a bit to find routers anno 2018 which can't do OV in
> > some shape or form.
>
> depends on how picky you are about "some shape or form."
I was
> Can you elaborate what routers with what software you are using? It
> surprises me a bit to find routers anno 2018 which can't do OV in some
> shape or form.
depends on how picky you are about "some shape or form."
draft-ietf-sidrops-ov-clarify was not written because it is usefully
> Job Snijders wrote :
> Can you elaborate what routers with what software you are using? It surprises
> me a bit to find routers anno 2018 which can't do OV in some shape or form.
They're not anno 2018 ! Cisco 3900 with 4 Gigs. Good enough for me, with the
current growth of the DFZ I may have
On Wed, Jul 18, 2018 at 07:30:48PM +, Michel Py wrote:
> Not in lieu, but when deploying RPKI is not (yet) possible. My
> routers are not RPKI capable, upgrading will take years (I'm not going
> to upgrade just because I want RPKI).
Can you elaborate what routers with what software you are
Mark,
>> Michel Py wrote:
>> If I understand this correctly, I have a suggestion : update these files at
>> a regular interval (15/20 min) and make them available for download with a
>> fixed name
>> (not containing the date). Even better : have a route server that announces
>> these prefixes
On 17/Jul/18 20:33, Michel Py wrote:
> If I understand this correctly, I have a suggestion : update these files at a
> regular interval (15/20 min) and make them available for download with a
> fixed name (not containing the date).
> Even better : have a route server that announces these
On 17/Jul/18 19:55, Job Snijders wrote:
> There are ~ 330 IPv6 invalids in the DFZ, and for 70 of those no
> alternative covering prefix exists.
Thanks, Job.
Mark.
> Job Snijders wrote :
>I calculated this here few days ago
> http://instituut.net/~job/rpki-report-2018.07.12.txt
> Markus Weber from KPN is generating a daily report here and drew similar
> conclusions: https://as286.net/data/ana-invalids.txt Markus scrapes all
> routes from the AS 286 PEs and
I don't want to over-state it, but 'number of prefices' slways feels
to me like a potential mis-measure. Not that you don't want to know
it, but % of announced space for a given origin-as feels like it might
be closer to the story, because there can be so many different ways to
announce it as dis-
On Tue, Jul 17, 2018 at 01:27:09PM +0200, Mark Tinka wrote:
> > Markus Weber from KPN is generating a daily report here and drew
> > similar conclusions: https://as286.net/data/ana-invalids.txt Markus
> > scrapes all routes from the AS 286 PEs and marks the routes for
> > which no valid or unknown
Hi Job, All,
It is definitely great to see progress on the deployment side! I realize
that there may be some gaps in the network operator toolchain, and this
may be something i'd like to contribute to.
For network operators to better understand the impact of BGP hijacks in
terms of revenue or
On 16/Jul/18 17:26, Job Snijders wrote:
> I calculated this here few days ago
> http://instituut.net/~job/rpki-report-2018.07.12.txt
>
> Markus Weber from KPN is generating a daily report here and drew similar
> conclusions: https://as286.net/data/ana-invalids.txt Markus scrapes all
> routes
On Sat, Jul 14, 2018 at 11:03:16AM +0200, Mark Tinka wrote:
> On 14/Jul/18 09:11, Baldur Norddahl wrote:
> > In the RIPE part of the world there is no excuse for not getting
> > RPKI correct because RIPE made it so easy. Perhaps the industry
> > could agree on enabling RPKI validation on all
On 14/Jul/18 14:04, Job Snijders wrote:
> I actually view it as a competitive advantage to carry a cleaner set of
> routes compared to the providers with a more permissive (or lack of)
> filtering strategy. Sometimes less is more.
Typically, I wouldn't disagree.
In practice, most customers
On Sat, 14 Jul 2018 at 15:07, Job Snijders wrote:
> I actually view it as a competitive advantage to carry a cleaner set of
> routes compared to the providers with a more permissive (or lack of)
> filtering strategy. Sometimes less is more.
* When you consider your addressable market 'clueful
On Fri, Jul 13, 2018 at 02:53:30PM +0200, Mark Tinka wrote:
> That, though, still leaves the problem where you end up providing a
> partial routing table to your customers, while your competitors in the
> same market aren't.
I actually view it as a competitive advantage to carry a cleaner set of
On 14/Jul/18 09:11, Baldur Norddahl wrote:
> In the RIPE part of the world there is no excuse for not getting RPKI
> correct because RIPE made it so easy. Perhaps the industry could agree on
> enabling RPKI validation on all european circuits for a start?
I think the first step (and what I'd
In the RIPE part of the world there is no excuse for not getting RPKI
correct because RIPE made it so easy. Perhaps the industry could agree on
enabling RPKI validation on all european circuits for a start?
Regards
Baldur
On 13/Jul/18 19:28, Christopher Morrow wrote:
> I think getting to Job's world is a goal, I think living in Mark's is a
> reality for a bit still.
> (yes, you could ALSO do some game playing where the customer ports for TSW
> were in a VRF with no 'bad' routes, but.. complexity)
This
On 13/Jul/18 18:37, Grant Taylor via NANOG wrote:
>
>
> Yep.
>
> You would almost need separate logical networks / VRF to be able to
> prevent the longest prefix match winning issue that you reminded me of.
Oooh, complexity - things we want to avoid :-).
Then again, we don't run the
On 13/Jul/18 18:37, Job Snijders wrote:
> That is exactly what I mean. Because of the golden rule "most-specific
> always wins" (and parts of the AS_PATH are pretty easy to spoof) it
> only makes sense to me to completely reject invalid routes.
Exactly my preference, and exactly what we did
On 13/Jul/18 18:25, Christopher Morrow wrote:
> it sounded like Mark didn't want to deal with that complexity in his
> network, until more deployment and more requests from customers like;
> Customer: "Hey, why did my traffic get hijacked to paY(omlut)pal.com
> yesterday?"
> Mark: "because
On 13/Jul/18 17:18, Grant Taylor via NANOG wrote:
>
>
> Please forgive the n00b question: But isn't that where carrying the
> prefixes through your network and conditionally advertising them to
> customers comes into play?
>
> Or does that run into complications where you must also have the
On Fri, Jul 13, 2018 at 12:41 PM Grant Taylor via NANOG
wrote:
> On 07/13/2018 10:25 AM, Christopher Morrow wrote:
>
> > but given:
> > 192.168.0.0/16 - valid
> > 192.168.0.0/17 - unknown
> > 192.168.0.0/24 - invalid
> >
> > your routing system will still forward toward the
On 07/13/2018 10:25 AM, Christopher Morrow wrote:
you get the option at input (from transit/peering edge say) to evaluate
the 'rpki status' of a particular route, then set normal bgp attributes
based on that evaluation, so yes you can:
valid == localopref 1000 && community-A
unknown
On Fri, Jul 13, 2018 at 4:25 PM, Christopher Morrow
wrote:
> On Fri, Jul 13, 2018 at 11:19 AM Grant Taylor via NANOG
> wrote:
>> The reading I did on RPKI / OV yesterday made me think that it is
>> possible to have validated routes preferred over unknown routes which
>> are preferred over
On Fri, Jul 13, 2018 at 11:19 AM Grant Taylor via NANOG
wrote:
>
> The reading I did on RPKI / OV yesterday made me think that it is
> possible to have validated routes preferred over unknown routes which
> are preferred over invalid routes. So I'd think that you could still
> have the routes
On 07/13/2018 06:53 AM, Mark Tinka wrote:
But yes, the majority of the issue was with routes learned from peers
and transit. That, though, still leaves the problem where you end up
providing a partial routing table to your customers, while your
competitors in the same market aren't.
Ouch.
On 13/Jul/18 14:43, Job Snijders wrote:
> Have you considered applying "invalid == reject" on just transit/peering
> sessions rather than customer sessions as an intermediate step? I bet
> most misconfigurations or hijacks didn't come in via your customers.
Yes, we did. The issue is some of
On Fri, Jul 13, 2018 at 02:37:32PM +0200, Mark Tinka wrote:
> Anyway, the operational issue we ran into was due to our aggressive
> policy to drop Invalids. The reason this became an issue was networks
> that ROA'd just their aggregates, but either forgot to or decided not to
> ROA the longer
On 12/Jul/18 19:50, Job Snijders wrote:
> Anyone here working to deploy RPKI based Origin Validation in their
> network and reject invalid announcements? Anything of note to share?
It's great to hear that this is catching up. To be honest, I haven't
kept up with the latest goings-on in this
40 matches
Mail list logo
