Interesting, so it is an MTU problem after all, I take it there’s no way to
adjust the BPF (Berkeley Packet Filter) limit to let the 6020B sized PSNPs
through?
adam
From: Mark Tinka
Sent: Sunday, April 19, 2020 1:47 AM
To: Tony Li ; adamv0...@netconsultings.com
Cc: nanog@nanog.org
Subje
On 20/Apr/20 16:26, adamv0...@netconsultings.com wrote:
>
> Interesting, so it is an MTU problem after all, I take it there’s no
> way to adjust the BPF (Berkeley Packet Filter) limit to let the 6020B
> sized PSNPs through?
>
Probably could - but I'd prefer solutions that don't mess with the bas
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 in
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 l
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
>
> 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.
https://pc.nanog.org/static/published/meetings/NANOG75/1900/20190219_Yoo_Rpki_Legal_Barr
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.
>
> https://pc.nanog.org/static/published/meetings/NANOG75/1900/20190219_Yoo_Rpki_Legal_Barriers_v1.p
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
invalid prefix, although I don't see it (only invalid on
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
> inval
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 hij
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 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 savin
There is simple use case that will prove this page is giving false
positive
for their "name&shame" 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 ju
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 ste
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 implemen
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&shame" strategy.
> Any AS owner with default route only (yes it happens a lot) users will
> get:
> "YOUR ISP TE
> 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
cause
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> w
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&shame" strategy.
Any AS owner with default route only (yes it happens a lot) users
will
get:
"YOUR ISP
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 massiv
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 o
Enforcement Bureau requests interested consortia to file Letters of Intent
to conduct private traceback efforts pursuant to section 13(d) of the
TRACED Act
https://www.fcc.gov/document/eb-requests-letters-intent-traceback-consortium
The Pallone-Thune Telephone Robocall Abuse Criminal Enfo
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 i
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 leng
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
> offere
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, attacker
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
27 matches
Mail list logo
