Vincent Bernat писал 2020-04-22 15:26:
❦ 22 avril 2020 12:51 -04, Andrey Kostin:
BTW, has anybody yet thought/looked into extending RPKI-RTR protocol
for validation of prefixes received from peer-as to make ingress
filtering more dynamic and move away prefix filters from the routers?
It
Christopher Morrow писал 2020-04-22 14:05:
a question about the data types here...
So, a neighbor with no downstream ASN could be filtered directly with
ROA == prefixlist-content.
A neighbor with a downstream ASN has to be ROA (per asn downstream) ==
prefixlist-content.
So you'd now have to do
❦ 22 avril 2020 12:51 -04, Andrey Kostin:
> BTW, has anybody yet thought/looked into extending RPKI-RTR protocol
> for validation of prefixes received from peer-as to make ingress
> filtering more dynamic and move away prefix filters from the routers?
It could be used as is if the client
On Wed, Apr 22, 2020 at 11:45 AM Danny McPherson wrote:
>
> On 2020-04-21 12:36, Rubens Kuhl wrote:
> > On Tue, Apr 21, 2020 at 1:10 PM Matt Corallo via NANOG
> > wrote:
> >
> >> That’s an interesting idea. I’m not sure that LACNIC would want
> >> to issue a ROA for RIPE IP space after RIPE
On Wed, Apr 22, 2020 at 2:03 PM Christopher Morrow
wrote:
>
> On Wed, Apr 22, 2020 at 1:32 PM Danny McPherson wrote:
> >
> > On 2020-04-22 12:51, Andrey Kostin wrote:
> >
> > >
> > > BCP38 website doesn't proclaim anybody in person to be unsafe, but if
> > > it would be possible to make such
On Wed, Apr 22, 2020 at 1:32 PM Danny McPherson wrote:
>
> On 2020-04-22 12:51, Andrey Kostin wrote:
>
> >
> > BCP38 website doesn't proclaim anybody in person to be unsafe, but if
> > it would be possible to make such test it'd be more useful than that
> > RPKI test.
> >
> > BTW, has anybody yet
On 2020-04-22 12:51, Andrey Kostin wrote:
BCP38 website doesn't proclaim anybody in person to be unsafe, but if
it would be possible to make such test it'd be more useful than that
RPKI test.
BTW, has anybody yet thought/looked into extending RPKI-RTR protocol
for validation of prefixes
Jay R. Ashworth писал 2020-04-22 11:02:
Well, given how little the BCP38 website below has moved that football,
you're
not likely in much danger... :-)
Cheers,
-- jra
BCP38 website doesn't proclaim anybody in person to be unsafe, but if it
would be possible to make such test it'd be more
On 2020-04-21 12:36, Rubens Kuhl wrote:
On Tue, Apr 21, 2020 at 1:10 PM Matt Corallo via NANOG
wrote:
That’s an interesting idea. I’m not sure that LACNIC would want
to issue a ROA for RIPE IP space after RIPE issues an AS0 ROA,
though. And you’d at least need some kind of time delay to give
> From: "Andrey Kostin"
>
> Would be interesting to hear your opinion on this:
> https://isbgpsafeyet.com/
>
> We have cases when residential customers ask support "why is your
> service isn't safe?" pointing to that article. It's difficult to answer
> correctly considering that the asking
Baldur Norddahl писал 2020-04-21 02:49:
My company is in Europe. Lets say an attacker joins the IX in Seattle
a long way from here and a place we definitely are not present at. We
do however use Hurricane Electric as transit and they are peering
freely at Seattle. Everyone there thus sees our
Sure. This kinda falls under my point that we should be talking about basic
mitigation, then. I’m not aware of any previous discussion of creating policy
that instructs RIRs to do so. Again, with a basic step like that, plus a
validator-enforced time delay between when a RIR can remove a ROA
On Tue, Apr 21, 2020 at 1:10 PM Matt Corallo via NANOG
wrote:
> That’s an interesting idea. I’m not sure that LACNIC would want to issue a
> ROA for RIPE IP space after RIPE issues an AS0 ROA, though. And you’d at
> least need some kind of time delay to give other RIRs and operators and
> chance
On Tue, Apr 21, 2020 at 12:17 PM Matt Corallo via NANOG wrote:
>
> Not sure how this helps? If RIPE (or a government official/court) decides the
> sanctions against Iranian LIRs prevents them from issuing number resources to
> said LIRs, they would just remove the delegation. They’d probably
Not sure how this helps? If RIPE (or a government official/court) decides the
sanctions against Iranian LIRs prevents them from issuing number resources to
said LIRs, they would just remove the delegation. They’d probably then issue an
AS0 ROA to replace out given the “AS0 ROA for bogons”
Right until RIPE finishes deploying AS0 ROAs for bogons, which I recall is
moving forward :p.
> On Apr 21, 2020, at 03:01, Mark Tinka wrote:
>
>
>
>> On 21/Apr/20 08:51, Matt Corallo via NANOG wrote:
>>
>> Instead of RIRs coordinating address space use by keeping a public list
>> which is
That’s an interesting idea. I’m not sure that LACNIC would want to issue a ROA
for RIPE IP space after RIPE issues an AS0 ROA, though. And you’d at least need
some kind of time delay to give other RIRs and operators and chance to discuss
the matter before allowing RIPE to issue the AS0 ROA, eg
>> essentially agree. my pedantic quibble is that i would like to
>> differentiate between the RPKI, which is a database, and ROV, which
>> uses it.
>
> And I think that is a very important distinction to be clear about.
> Right now, it's not completely arrest-worthy to use RPKI and ROV
>
On 21/Apr/20 12:46, Randy Bush wrote:
> essentially agree. my pedantic quibble is that i would like to
> differentiate between the RPKI, which is a database, and ROV, which
> uses it.
And I think that is a very important distinction to be clear about.
Right now, it's not completely
> Anyhow I think some people think about RPKI in a way too binary manner
> 'because it is not secure, it is not useful'. Yes, AS_PATH
> authenticity is an open problem, but this doesn't mean RPKI is
> useless. Most of our BGP outages are not malicious, RPKI helps a lot
> there and RPKI creates a
On 20/Apr/20 20:21, Andrey Kostin wrote:
>
> So this means that there is no single source of truth for PRKI
> implementation all around the world and there are different shades,
> right? As a logical conclusion, the information provided on that page
> may be considered incorrect in terms of
On 21/Apr/20 08:51, Matt Corallo via NANOG wrote:
> Instead of RIRs coordinating address space use by keeping a public list which
> is (or should be) checked when a new peering session is added, RPKI shifts
> RIRs into the hot path of routing updates. Next time the US government
> decides
> On 21 Apr 2020, at 11:09, Baldur Norddahl wrote:
>
>
>
> On 21.04.2020 10.56, Sander Steffann wrote:
>> Hi,
>>
>>> Removing a resource from the certificate to achieve the goal you describe
>>> will make the route announcement NotFound, which means it will be accepted.
>>> Evil RIR would
On 21.04.2020 10.56, Sander Steffann wrote:
Hi,
Removing a resource from the certificate to achieve the goal you describe will
make the route announcement NotFound, which means it will be accepted. Evil RIR
would have to replace an existing ROA with one that explicitly makes a route
There are in fact five anchors. I am not sure ARIN would be able to stop
anyone holding RIPE space provided the resource holder uses RIPE RPKI
anchor for publishing his ROAs.
Regards,
Baldur
On 21.04.2020 08.51, Matt Corallo via NANOG wrote:
I find it fascinating that in this entire thread
Hi,
> Removing a resource from the certificate to achieve the goal you describe
> will make the route announcement NotFound, which means it will be accepted.
> Evil RIR would have to replace an existing ROA with one that explicitly makes
> a route invalid, i.e. issue an AS0 ROA for specific
tir. 21. apr. 2020 07.38 skrev Saku Ytti :
> On Tue, 21 Apr 2020 at 01:02, Baldur Norddahl
> wrote:
>
> > Yes but that makes the hijacked AS path length at least 1 longer which
> makes it less likely that it can win over the true announcement. It is
> definitely better than nothing.
>
> Attacker
On Tue, 21 Apr 2020 at 01:02, Baldur Norddahl wrote:
> Yes but that makes the hijacked AS path length at least 1 longer which makes
> it less likely that it can win over the true announcement. It is definitely
> better than nothing.
Attacker has no incentive to honor existing AS path,
On Mon, Apr 20, 2020 at 8:47 PM Denys Fedoryshchenko <
nuclear...@nuclearcat.com> wrote:
> If i am not wrong, for most routers implementing RPKI means spinning up
> VM
> with RPKI cache that need significant tinkering?
> I guess it is a blocker for many, unless some "ready made" solutions
>
On Mon, Apr 20, 2020 at 9:09 PM Randy Bush wrote:
> but it provides almost zero protection against malicious attack. the
> attacker merely has to prepend (in the formal, not cisco display) the
> 'correct' origin AS to their malicious announcement.
>
>
Yes but that makes the hijacked AS path
On Mon, Apr 20, 2020, at 21:54, Amir Herzberg wrote:
> Randy said, > From a practical standpoint, this doesn't actually tell
> the whole truth
> >
> > indeed. route origin validation, while a good thing, does not make
> > bgp safe from attack. this marketing fantasy is being propagated;
> > but
Denys Fedoryshchenko писал 2020-04-20 15:27:
And most important, the most common answer:
All Tier-1 implemented it? No.
Major hosting operators, such as AWS, gcloud, etc? - No.
So...
Absolutely, RPKI has different scale of effectiveness and benefits for
big telecoms or clouds vs small ISPs
Randy said,
>
> > From a practical standpoint, this doesn't actually tell the whole truth
>
> indeed. route origin validation, while a good thing, does not make
> bgp safe from attack. this marketing fantasy is being propagated;
> but is BS.
>
> origin validation was designed to reduce the
On 2020-04-20 22:01, Rubens Kuhl wrote:
On Mon, Apr 20, 2020 at 3:37 PM Denys Fedoryshchenko
wrote:
There is simple use case that will prove this page is giving false
positive
for their "name" strategy.
Any AS owner with default route only (yes it happens a lot) users
will
get:
"YOUR ISP
I remember having this discussion more than 20yrs ago, minus the ARIN bit,
couldn't get every to agree to it it then either :(. We don't need more
rules, we just need to start with basic hygiene. Was a novel idea :)
On Mon., Apr. 20, 2020, 2:41 p.m. Christopher Morrow, <
morrowc.li...@gmail.com>
> From a practical standpoint, this doesn't actually tell the whole truth
indeed. route origin validation, while a good thing, does not make
bgp safe from attack. this marketing fantasy is being propagated;
but is BS.
origin validation was designed to reduce the massive number of problems
On Mon, Apr 20, 2020 at 3:37 PM Denys Fedoryshchenko <
nuclear...@nuclearcat.com> wrote:
> There is simple use case that will prove this page is giving false
> positive
> for their "name" strategy.
> Any AS owner with default route only (yes it happens a lot) users will
> get:
> "YOUR ISP
On Mon, Apr 20, 2020 at 2:32 PM Alex Band wrote:
>
> On 20 Apr 2020, at 19:39, Christopher Morrow wrote:
> >
> > On Mon, Apr 20, 2020 at 12:25 PM Tom Beecher wrote:
> >>
> >> Technical people need to make the business case to management for RKPI by
> >> laying out what it would cost to
On 2020-04-20 19:24, Tom Beecher wrote:
Technical people need to make the business case to management for RKPI
by laying out what it would cost to implement (equipment, resources,
ongoing opex), and what the savings are to the company from protecting
themselves against hijacks. By taking this
There is simple use case that will prove this page is giving false
positive
for their "name" strategy.
Any AS owner with default route only (yes it happens a lot) users will
get:
"YOUR ISP TERRIBLE, HIS BGP NOT SAFE!".
But he have nothing to validate! His BGP is implemented safely,
its just
On 20 Apr 2020, at 19:39, Christopher Morrow wrote:
>
> On Mon, Apr 20, 2020 at 12:25 PM Tom Beecher wrote:
>>
>> Technical people need to make the business case to management for RKPI by
>> laying out what it would cost to implement (equipment, resources, ongoing
>> opex), and what the
Mark Tinka писал 2020-04-20 12:57:
On 20/Apr/20 18:50, Tom Beecher wrote:
I (and Ben, and a few others) are all too familiar with the ARIN
madness
around their TAL.
Simple - we just don't accept it, which means our networks will be
unsafe against North American resources. Highly doubtful my
On Mon, Apr 20, 2020 at 12:25 PM Tom Beecher wrote:
>
> Technical people need to make the business case to management for RKPI by
> laying out what it would cost to implement (equipment, resources, ongoing
> opex), and what the savings are to the company from protecting themselves
> against
On 20/Apr/20 19:01, Andrey Kostin wrote:
> Thank you Mark, Tom and Chris for your responses that confirmed my
> "mixed feelings" about this tool.
> As a side note, I mentioned from https://bgp.he.net/AS13335#_prefixes
> that AS13335 advertises a bunch or prefixes without RoA and even one
>
CloudFlare?
—
Chris Cummings
FROM: NANOG on behalf of Tom Beecher
DATE: Monday, April 20, 2020 at 10:35
TO: Andrey Kostin
CC: Nanog
SUBJECT: Re: "Is BGP safe yet?" test
( Speaking 100% for myself. )
I think it was tremendously irresponsible, especially in the context
of cur
On 20/Apr/20 18:50, Tom Beecher wrote:
>
> Work on a technical level, yes. But there are legal concerns in the
> ARIN region with that, some of which are spelled out here, by ACTUAL
> lawyers.
>
>
>
> We've seen that validators are free, and work very well.
>
Work on a technical level, yes. But there are legal concerns in the ARIN
region with that, some of which are spelled out here, by ACTUAL lawyers.
On 20/Apr/20 18:24, Tom Beecher wrote:
> Technical people need to make the business case to management for RKPI
> by laying out what it would cost to implement (equipment, resources,
> ongoing opex), and what the savings are to the company from protecting
> themselves against hijacks. By taking
On 20/Apr/20 17:31, Tom Beecher wrote:
> ( Speaking 100% for myself. )
>
> I think it was tremendously irresponsible, especially in the context
> of current events, to take a complex technical issue like this and
> frame it to the general public as a 'safety' issue.
>
> It's created articles
On 20/Apr/20 17:31, Mark Tinka wrote:
> On count two, my experience with doing the RPKI deployathon in Melbourne
> during this past APRICOT led to some random news web site talking about
> how "I would be shedding all invalid routes blah blah", which while not
> untrue, had locals all the way
50 matches
Mail list logo
