>
> How can such a large company have something so simple as SIP
> registration mangled up?
>
Very little incentive to fix it. The number of customers that are able to
switch providers when something like this doesn't work is a fractional
percentage of overall customer churn.
The MBAs say it's ch
Not really an escalation point above the registrar level.
https://www.icann.org/resources/pages/about-icann-faqs-2019-02-25-en
Q: Does ICANN help with domain ownership or registration disputes?
>
> A: *No*, ICANN does not get involved in disputes regarding domain
> ownership or registration. ICAN
>
> I've been fighting a similar issue. I'd like to throw in, a lot of mobile
> devices are geolocation dependent for time, and may completely disregard
> DHCP timezone and instead rely entirely on GeoLocation *even if it is
> woefully inaccurate, or unobtainable*.
>
1. RFC4833 *presumes* that the
My understanding has been that generally, if the cellular network signal
was above a certain threshold, phones won't even attempt to use wifi
calling. Some carriers used to let you flip a switch to force the phone to
prefer wifi over cellular, but some have removed that. ( Verizon for
example. )
I
On Tue, Jul 30, 2024 at 12:35 PM Innocent Obi
>> wrote:
>>
>>> Luckily it seems my org has since mitigated this, but it would be
>>> interesting to know the broader impacts/who is broadly impacted.
>>>
>>> On Tue, Jul 30, 2024 at 12:20 PM Tom Beecher wro
If you're only getting this now, you're probably in trouble, because
they're revoking affected certs in about 15 mins.
On Tue, Jul 30, 2024 at 2:53 PM Innocent Obi
wrote:
> Just in-case this hasn't made its way around:
> https://www.digicert.com/support/certificate-revocation-incident.
>
>
No, because there's no set schedule for these things.
Some publishers / consoles get content/patches up in advance to allow user
to pre-load. This can smooth out the bandwidth hits, but only if the users
enable the pre-load feature. Many don't. Other publishers just enable the
updates at once for
answers all of your
> concerns. Further, they remark that this was an especially sophisticated
> infection, that hid its tracks well.
>
>
>
> Lee
>
>
>
> *From:* NANOG *On
> Behalf Of *Tom Beecher
> *Sent:* Sunday, June 2, 2024 4:23 PM
> *To:* Dave Taht
> *Cc
That post from Mr. Perens about this is honestly really shitty.
1. Is he right that Lumen has to shoulder blame for not keeping CPE updated
with exploit free software? Certainly.
2. Making a claim that all 600k of these routers were being used as botnet
zombies without any supporting evidence is r
to be
solved.
Not engaging with RPKI because it doesn't perfectly solve every
BGP-adjacent issue is a poor argument.
On Fri, May 17, 2024 at 7:24 PM Ca By wrote:
>
>
> On Fri, May 17, 2024 at 4:20 PM Tom Beecher wrote:
>
>> RPKI is not a good solution for all network
>
> RPKI is not a good solution for all networks, especially those that are
> non-transit in nature and take reasonable mitigation actions like IRR
> prefix lists.
>
Some of the largest , most impactful route leaks have come from non-transit
networks reliant on IRR managed prefix lists.
On Fri, M
>
> Just because they were presented with the information doesn't mean they
> understand.
It's our job as operators to get involved and help them understand as best
as can be done, so that the proposals are as well informed as possible.
> Just because they understand doesn't mean they execute b
Same, this address for me is also gmail.
This is what Gmail shows me from earlier today, when the SPF record was not
present :
Message ID <
bff409fd0177c9caf1461e2439691...@polarismail--com.w.emailarray.com>
Created at: Thu, May 16, 2024 at 11:59 AM (Delivered after 77 seconds)
From: "Scott Q."
>
> I'm surprised nobody noticed for close to 10 days.
Probably because it wasn't 10 days.
On Thu, May 16, 2024 at 10:26 PM Scott Q. wrote:
> I'm surprised nobody noticed for close to 10 days. I was away from work
> and upon coming back I saw the little discussion there was , in my Spam
> fold
>
> That means that some IP addresses in the block 192.0.0.0/24 may be
> routable.
>
> So, I would not make this a bogon.
>
This ignores note 2 on the IANA definitions page, next to 192.0.0.0/24 :
> [2]
>
> Not useable unless by virtue of a more specific reservation.
>
> Which then lists the mor
Validin, made an interesting observation on this. I am also a Spectrum
residential customer, none of their equipment, run my own DNS server
(pihole).
My DHCP Assigned DNS servers are
2001:1998:f00:1::1
2001:1998:f00:2::1
bash-3.2$ dig -x 2001:1998:f00:1::1 +short
dns-cac-lb-01.rr.com.
bash-3.2$
now if this FEC stuff I see concurring is actually
> contained in Ethernet Frames? If so, please send a link to show the
> ethernet frame structure as it pertains to this 400g fec stuff. If so, I'd
> really like to know the header format, etc.
>
> -Aaron
> On 4/18/2024 1:17 PM, T
FEC is occurring at the PHY , below the PCS.
Even if you're not sending any traffic, all the ethernet control frame juju
is still going back and forth, which FEC may have to correct.
I *think* (but not 100% sure) that for anything that by spec requires FEC,
there is a default RS-FEC type that wil
>
> We've seen the same between Juniper and Arista boxes in the same rack
> running at 100G, despite cleaning fibres, swapping optics, moving ports,
> moving line cards, e.t.c. TAC said it's a non-issue, and to be expected,
> and shared the same KB's.
>
>
Just for extra clarity off those KB, proba
Notes I found that I took from smart optical people :
"PAM4 runs at much lower SNRs than NRZ, because you're trying to read 4
distinct voltage levels instead of 2.Even the cleanest system will have
some of that, so the only way to make it usable is to have FEC in place."
On Wed, Apr 17, 2024 at
Isn't FEC required by the 400G spec?
On Wed, Apr 17, 2024 at 3:45 PM Aaron Gould wrote:
> i did. Usually my NANOG and J-NSP email list gets me a quicker solution
> than JTAC.
>
> -Aaron
> On 4/17/2024 2:37 PM, Dominik Dobrowolski wrote:
>
> Open a JTAC case,
> That looks like a work for them
>
Agreed.
I think as a practical matter, the large majority of operators probably
only care about time from last update / EoRIB -> FIBs forwarding working.
As long as that time delta is acceptable for their environment and
circumstances, that's 'good enough'. Definitely some edge cases and
circumsta
>
> Also, BGP convergence isn't listed (nor do I rarely ever see it talked
> about in such sheets).
I feel like this shouldn't be listed on a data sheet for just the whitebox
hardware. The software running on it would be the gating factor.
On Fri, Apr 12, 2024 at 9:05 AM Mike Hammett wrote:
>
I don't think anything is 'easily fixed' on this topic.
I do however hope that everyone accepts at face value that the board,
staff, and PC are *trying* to do the right things here. Doesn't mean that
it *will* always be the right thing, or even that a majority of people can
agree on what the right
>
> My memory is a little fuzzy, but I think I recall one of the early WiT
> lunches hosted at NANOG that was women-only, where some men were upset
> for being "left out". Whether that was good or bad is less important
> than understanding what the outcome of a women-only activity is for
> women, e
There was a Women in Tech Mixer on Sunday in Charlotte as well. As I recall
there was a pretty decent attendance.
During my time on the PC, we always got a lot of feedback about Sunday when
the topic came up. Some members were strongly opposed to anything on Sunday
and didn't even like the Hackath
Yeah, cost to implement dst_as_path lookups far outweighs the usefulness
IMO. If you really want that it's much better to get it via BMP. ( Same
with communities and localpref in the extended gateway definition of
sflow. )
Fundamentally I've always disagreed with how sFlow aggregates flow data
wi
Lots of people are encountering this, yes.
You can try opening a case yourself, and hope it gets to someone with a
clue. If you don't have a support contract with them, your chances are
almost 0. If you do, your chances are slightly higher, but not by much.
most likely they will just tell you to '
>
> It may be a pain in the butt to get Cisco equipment, but their TAC is
> sublime. If something is critical enough, and you push hard enough, Cisco
> will move heaven and earth to solve your issue.
>
This was an amazing laugh on a Monday morning. Thanks!
On Thu, Mar 7, 2024 at 2:47 PM Joel Esl
>
> I think there is
> a very careful attitude around making sure not just anyone can get
> this information, especially after the Nashville bombing on Christmas
> Day 2020.
>
Keeping fiber location info close to the vest is nothing new. I'm not now
sure why/how you feel like this connects to the
>
> Erik Prince was on the PBD podcast saying he has a 70% chance in his head
> it was China.
>
Why do we care what his (almost certainly uninformed) opinion is?
On Thu, Feb 29, 2024 at 2:56 PM Javier J wrote:
> Where did you see this? Erik Prince was on the PBD podcast saying he has a
> 70% ch
Perhaps the provider only had a single person maintaining the tooling they
used to interact with the IRR records, that person left/was laid off, and
it broke. Perhaps they don't have anyone else that can make it work again,
and they don't want to hire someone else, so they fell back to paper.
Perh
>
> and it's affecting our customers' access to various ===>> websites.<<===
>
On Tue, Feb 20, 2024 at 6:15 PM Pui Ee Luun Edylie wrote:
> There must be a reason why the web site chooses the WAF list to block out
> the victim? If so why not the victim to contact the website to request them
> to
>
> I'm not going to participate in the security conversation, but we do
> absolutely need something to fill the role of NAT in v6. If it's already
> there or not, I don't know. Use case: Joe's Taco Shop. Joe doesn't want a
> down Internet connection to prevent transactions from completing, so he
>
>
> Any given layer of security can be breached with expense and effort.
> Breaching every layer of security at the same time is more challenging
> than breaching any particular one of them. The use of NAT adds a layer
> of security to the system that is not otherwise there.
>
>
> Think of it like
$/IPv4 address peaked in 2021, and has been declining since.
On Thu, Feb 15, 2024 at 16:05 Brian Knight via NANOG
wrote:
> On 2024-02-15 13:10, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
> > I've said it before, and I'll say it again:
> >
> > The only thing stopping global IPv6 deployment is
> >
e we can
> encourage and help people move towards IPv6 we can't force adoption through
> prevention of access to IPv4.
>
> Regards,
> Christopher Hawker
> --
> *From:* Owen DeLong
> *Sent:* Thursday, February 15, 2024 4:23 AM
> *To:* Chris
> Maybe this should have gone to the members mailing list, but I couldn’t
> find one.
>
>
>
memb...@nanog.org
On Thu, Feb 15, 2024 at 10:31 AM Howard, Lee via NANOG
wrote:
> I’m jumping on an earlier part of the thread.
>
>
>
> Based on what I heard at the Members Meeting and several follow up
>
> All we can do is educate people on the importance of IPv6 uptake, we can
> not force people to adopt it.
>
At this stage of the game, networks and products that don't support V6
aren't likely to do so unless there is a forcing function to make them do
it. Meaning money.
On Wed, Feb 14, 2024
None of the conversation was about COVID protocols.
Lowered in person attendance because of *individual concerns about health
risks* was mentioned. The conversation then went sideways into public
health policy and definitions, which absolutely doesn't belong on the list.
On Wed, Feb 14, 2024 at 7
n the current state of
COVID, if it's referred to as 'pandemic' or 'endemic' , etc. Nor does that
sort of convo really belong anywhere near this list.
On Tue, Feb 13, 2024 at 7:58 PM Glen A. Pearce wrote:
> On 11/02/2024 7:56 a.m., Tom Beecher wrote:
> > Yup. Pos
e thing I can guarantee is that will
> never happen, if nothing is done.
>
> Let's not think about ourselves for a moment, and think about the
> potential positive impact that this could bring.
>
> Regards,
> Christopher Hawker
> --
> *Fro
>
> PS: I know this because it will take 98 years of process before the
> RIRs can start allocating it.
>
Intense optimism detected!
On Tue, Feb 13, 2024 at 4:27 PM John Levine wrote:
> It appears that Lyndon Nerenberg (VE7TFX/VE6BBM) said:
> >And what are they going to do when 240/4 runs out?
>
> Now, we know there's definitely going to be some pushback on this. This
> won't be easy to accomplish and it will take some time.
It won't ever be 'accomplished' by trying to debate this in the media.
On Tue, Feb 13, 2024 at 5:05 AM Christopher Hawker
wrote:
> Hello all,
>
> [Note: I have
Yup. Post pandemic, the unfortunate hotel situation, and a non-zero number
of companies still have tight travel budgets.
It's been slowly creeping back though.
On Sun, Feb 11, 2024 at 8:44 AM Ryan Hamel wrote:
> Mike,
>
> The numbers have not bounced back to pre-pandemic levels, and it doesn't
>
>
> This sounded perfect, and I could beat my friend around the head with
> it… but reading further reveals:
> "Route aggregation and information reduction techniques (see
> Section 9.2.2.1) may optionally be applied.
>
> Any local policy that results in routes being added to an Adj-RIB-Out
> wi
ards.
On Thu, Feb 1, 2024 at 2:21 AM Frank Habicht wrote:
> On 01/02/2024 01:45, Tom Beecher wrote:
> > Seems a bit dramatic. Companies all over the world have been using other
> > people's public IPs internally for decades. I worked at a place 20 odd
> > years ago that
>
> Even though it is very risky to steal resources from an organization
> that can deploy a black helicopter or a nuclear warhead over you
>
Seems a bit dramatic. Companies all over the world have been using other
people's public IPs internally for decades. I worked at a place 20 odd
years ago th
>
> I see it mentioned in this doc:
>
> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/15-s/irg-15-s-book/irg-origin-as.pdf
You see SOVC mentioned, yes. But you don't see the word 'stale'.
Please don't just paste what ChatGPT says. It's not an authoritative
source.
>
> It that always true? I'd started off thinking that, but a friend of mine
> (yes, the same one that started this argument) convinced me that
> some forms of BGP summarization/aggregation don't always generate a "local"
> route…
>
> I'd also thought that I'd seen this when redistributing an IGP
>
> Unless overridden, BGP takes -distance- into account where distance =
> AS path length.
>
An AS_PATH length of 10 could be a physical distance of 1 mile.
An AS_PATH length of 1 could be a physical distance of 1000 miles.
BGP TE communities exist to provide signalling in the event that the
st
>
> Because big operators think it reasonable to localpref distance routes
> ahead of nearby ones so long as the distant routes arrive from
> customers. I'll remember that the next time folks complain about the
> size of the routing table. This one you did to yourselves.
>
That has absolutely noth
>
> Apparently there is a conflict between what you want and what 47787 wants.
> As you both seem to be paying customers, you should probably ask 3356 to
> resolve that instead of us random internet folks.
>
Calling 3356 and saying "I know your global routing policy is to prefer a
customer learned
>
> I feel your pain Bill, but from a slightly different angle. For years the
> large CDNs have been disregarding prepends. When a source AS disregards
> BGP best path selection rules, it sets off a chain reaction of silliness
> not attributable to the transit AS's. At the terminus of that chain
>
> As I already explained, neither the primary nor any of the backup
> providers directly peer with Centurylink, thus have no communities for
> controlling announcements to Centurylink.
No, but they do have an option to not announce to 47787.
https://docs.freerangecloud.com/en/bgp/communities
>
> I’d bet that 47787 is a paying century link customer. As such, despite the
> ugliness of the path, CL probably local prefs everything advertised by them
> higher than any non-paying link. I’m willing to bet 1299 is peered and not
> paying CL.
>
It's almost as if you've done this before. :)
Co
disagree.
On Sun, Jan 21, 2024 at 1:22 AM Jay R. Ashworth wrote:
> ----- Original Message -
> > From: "Tom Beecher"
> > To: "Lamar Owen"
> > Cc: nanog@nanog.org
> > Sent: Wednesday, January 17, 2024 8:06:07 PM
> > Subject: Re: "
>
> Because people keep responding.
>
Doesn't really make any difference. Mr. Chen filed his first draft in Dec
2016. He finds a reason to talk about it on every mailing list and forum
he can find, but doesn't spend any time engaging in the standards
processes, other than renewing his draft every
tix>
> The Brothers WISP <http://www.thebrotherswisp.com/>
> <https://www.facebook.com/thebrotherswisp>
> <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>
> --
> *From: *"Tom Beecher"
> *To: *"Mike Hammett"
>
> and none in the other two facilities you operate in that same building had
> any failures.
Quoting directly from their outage ticket updates :
CH2 does not have chillers, cooling arrangement is DX CRACs manufactured by
> another company. CH3 has Smart chillers but are water cooled not air co
Many CDNs have hardware options for self hosted caches. I think there would
likely be concerns about <20G of connectivity to those caches though. With
an incorrect setup, you could end up maxing out those links just with cache
fill traffic itself.
On Thu, Jan 18, 2024 at 6:54 AM Jérôme Nicolle w
>
> If these chillers are connected to BACnet or similar network, then I
> wouldn't rule out the possibility of an attack.
>
Don't insinuate something like this without evidence. Completely
unreasonable and inappropriate.
On Wed, Jan 17, 2024 at 8:31 AM Lamar Owen wrote:
> >This sort of mass fa
It only applies if you are purchasing their monitoring services. Not just
to use the site for info.
On Tue, Jan 16, 2024 at 5:04 PM scott via NANOG wrote:
>
>
> On 1/16/24 2:44 PM, Ian Chilton wrote:
>
> > Not a direct answer to your question, but if you're not aware of it,
> > https://bgp.tools
>
> If "EzIP" is about using 240/4 as CGNAT space, let's call it what it is,
> not rename something that already exists and attempt to claim it as a new
> idea.
>
Yes he is essentially re-creating NAT/CGNAT, but in a worse way.
If you ignore all the multitude of technical issues, if you grabbed a
>
> Gmail is therefore in violation of the RFC5822. It's quite clear how it
> should work per the RFC appendix.
>
Well, no. Asterisks added for emphasis.
This specification is intended as a definition of what message
>content format is to be passed between systems. Though some message
>
gional Area Networks) as "kites floating in
> the air over an geographic area anchored by an IPv4 address based cord".
> Although visually clear, it was too wordy. By using one concise word,
> *overlay*, Vint eloquently classified the EzIP network in terminology
> sense. It
<http://www.midwest-ix.com/>
> <https://www.facebook.com/mdwestix>
> <https://www.linkedin.com/company/midwest-internet-exchange>
> <https://twitter.com/mdwestix>
> The Brothers WISP <http://www.thebrotherswisp.com/>
> <https://www.facebook.com/thebrothe
I go into my cave to finish the todo list for the week, and I come out to
see Mr. Chen :
- Telling Randy Bush he should "read some history" on IPv6
- Implying that Vint Cerf ever said anything about EzIP
Fairly impressive sequence of self ownage.
On Fri, Jan 12, 2024 at 5:46 PM Randy Bush wrote:
tions>
> <https://twitter.com/ICSIL>
> Midwest Internet Exchange <http://www.midwest-ix.com/>
> <https://www.facebook.com/mdwestix>
> <https://www.linkedin.com/company/midwest-internet-exchange>
> <https://twitter.com/mdwestix>
> The Brothers WISP <http://w
>
> How far are we from that, in reality? I don't have any intention on using
> the space, but I would like to put some definition to this boogey man.
It's unknowable really.
Lots of network software works just fine today with it. Some don't. To my
knowledge some NOS vendors have outright refuse
Bear in mind that APNIC
> policy was changed 1/2 way through to drop 103/8 delegations from a /22 to
> a /23. Based on this, 65,536 x /23 delegations can be made to new members
> and as Peter said, if post-exhaustion policy is applied to 240/4 it'll go
> an extremely long way
s 'squatting'. Today, nobody's
usage of 240/4 internally impacts anyone else.
On Thu, Jan 11, 2024 at 12:37 PM Dave Taht wrote:
> On Thu, Jan 11, 2024 at 12:26 PM Tom Beecher wrote:
> >
> > Christopher-
> >
> >> Reclassifying this space, would add
strong case was presented to convert this space.
>
> https://www.ietf.org/archive/id/draft-schoen-intarea-unicast-240-00.html
>
> Regards,
> Christopher Hawker
>
> On Thu, 11 Jan 2024 at 20:40, Dave Taht wrote:
>
>> On Wed, Jan 10, 2024 at 11:06 AM Tom Beecher wrote
y
> routable IPv4 address. Then, the demand for IPv4 address is drastically
> reduced.
>
> 4)In brief, the 240/4 is to substitute that of 100.64/10. So that the
> need for the publicly routable IPv4 addresses is significantly reduced.
>
> Regards,
>
>
> Abe (2024
024 at 10:45 AM Michael Butler
wrote:
> On 1/10/24 10:12, Tom Beecher wrote:
> > Karim-
> >
> > Please be cautious about this advice, and understand the full context.
> >
> > 240/4 is still classified as RESERVED space. While you would certainly
> > be able
Karim-
Please be cautious about this advice, and understand the full context.
240/4 is still classified as RESERVED space. While you would certainly be
able to use it on internal networks if your equipment supports it, you
cannot use it as publicly routable space. There have been many proposals
o
>
> I did some research on this and it seems like perhaps the on-boot event
> handler launching a python daemon to do this active probing out each isp
> circuit and then making config changes in response to transit failures
> might be the best option available to us.
>
Pretty much, yes. They don't
>
> But why would AliExpress be redirecting to DDN space? Is this legitimate?
> Ali hoping to get away with squatting, or something else?
I've seen a large number of cases that a company was using someone else's
non-RFC1918 space for some reason, and that was accidentally exposed via
application
>
> i would expect that google announces the /16 at least from 'everywhere',
> yes.
>
I see the specific /18s Drew asked about initially. Didn't check for the
covering /16.
On Tue, Dec 5, 2023 at 1:29 PM Christopher Morrow
wrote:
> On Tue, Dec 5, 2023
>From my observations, all us-east-5 IPs are announced via transit and
peering at all of my locations Chicago and east.
On Mon, Dec 4, 2023 at 9:11 AM Drew Weaver wrote:
> Hello,
>
>
>
> We are trying to reduce latency to a region in Google Cloud which we are
> in the same city of. Latency is cu
172.253.X.X are Google DNS : https://www.gstatic.com/ipranges/publicdns.json
172.71.X.X are Cloudflare : https://www.cloudflare.com/ips-v4/#
On Sun, Dec 3, 2023 at 1:49 PM John Levine wrote:
> At contacts.abuse.net, I have a little stunt DNS server that provides
> domain contact info, e.g.:
>
Trying to put technical requirements like this into law and public policy
is an extremely terrible idea. This letter should never be sent.
The regulatory agencies today don't have the manpower or expertise to
adequately enforce the more generic broadband deployment rules. What
fantasy world exists
>
> Are you sure? The way I read it, that policy applies to -customer-
> announced routes, not broad Internet routes received from peers and
> transit.
>
You are reading it correctly.
On Wed, Nov 22, 2023 at 3:15 PM William Herrin wrote:
> On Wed, Nov 22, 2023 at 11:22 AM o...@delong.com wrote
Amir-
I have to take some issue with one comment you made in response to Job.
BGP-iSec, at this point, is just an academic study studying some new ideas
> and evaluating their impact in specific configurations, under specific
> assumptions etc.; hopefully, this may provide some help to the commun
>
> Comcast has to be the one contacting them
>
This is the correct answer. It's pretty straight forward ; Comcast needs to
get with Tata, say "hey, I'm announcing prefix FOO to you, your LGs don't
look like you're accepting it. Can we figure out why?"
On Fri, Nov 17, 2023 at 10:43 AM jim deleski
>
> Therefore, Cogent currently does not have and is not member of ARIN. It
> refuses to sign contract with ARIN and currently Cogent is not bound by
> this RUD rules and regulations.
>
> There is one downfall to not being ARIN member, Cogent cannot currently
> issue ROAs or RPKIs. They only update
>
> I imagine there is a some sort of coalescing industry standard out there,
> but so far I can’t find it.
>
There is not, and won't be for a long time, if ever.
There isn't a one size fits all solution.
On Thu, Nov 16, 2023 at 9:31 PM Tom Samplonius wrote:
>
> In the world of IRR and RPKI,
y as many to
state it's a "primary use case", especially relative to #1 and #2 on your
list.
On Thu, Nov 16, 2023 at 11:18 AM Christopher Morrow
wrote:
> On Thu, Nov 16, 2023 at 10:22 AM Tom Beecher wrote:
> >>
> >> In the service provider industry, its prima
>
> In the service provider industry, its primary use is for advertising
> address resources (IPv4/v6 and ASN)
Not really.
On Thu, Nov 16, 2023 at 9:19 AM Christopher Hawker
wrote:
> Hello everyone,
>
> Aftab Siddiqui is currently exploring the possibility of using Route
> Object Authorisation
>
> Last week somebody on the internet started a campaign to scan and perhaps
> to exploit some zero day ipsec vulnerabilities.
>
I've seen traffic like this for the better part of at least the last 7
years, fairly consistently.
It's definitely not something new.
On Mon, Nov 13, 2023 at 12:42 PM
Didn't think there was much confusion about it at this point.
The DOD has the assignments for the space, they can announce it whenever
they want, even if it's from a shell ASN.
On Wed, Nov 8, 2023 at 4:52 PM Dave Taht wrote:
> Anyone have an update as to where this effort, announcing qute a bit
>
> DNS isn’t the right place to attack this, IMHO.
>
...
> I’ve seen plenty of situations where the filters were just plain wrong and
> if the end user didn’t actively choose that filtration, the target site may
> be victimized without anyone knowing where to go to complain.
Not much different
>
> If it's too hard for me to figure out where you are, you just plain won't
> get the sale.
My experience with maps over the last decade tells me that even most
vendors don't actually know where they are. :)
On Thu, Oct 26, 2023 at 12:18 PM Mike Hammett wrote:
> Has anyone else noticed a tre
overing /22,
> which wouldn’t help in this case anyway.
>
> So I’m not sure why you think that’s a solution.
>
> Owen
>
>
> On Oct 22, 2023, at 10:45, Tom Beecher wrote:
>
> Look again, Tom. This is an attack vector using a LESS specific route. The
>> /22 gets disca
> Homepage: https://sites.google.com/site/amirherzberg/home
> `Applied Introduction to Cryptography' textbook and lectures:
> https://sites.google.com/site/amirherzberg/cybersecurity
>
>
>
>
> On Sun, Oct 22, 2023 at 1:50 PM Tom Beecher wrote:
>
>> Look again, Tom.
the
covering prefix as well isn't a good thing to do.
On Sun, Oct 22, 2023 at 1:39 PM Owen DeLong wrote:
> Look again, Tom. This is an attack vector using a LESS specific route. The
> /22 gets discarded, but a covering /0-/21 would not.
>
> Owen
>
> On Oct 22, 2023, at 10:06,
, 2023 at 1:24 PM William Herrin wrote:
> On Sun, Oct 22, 2023 at 10:06 AM Tom Beecher wrote:
> >> And is it your belief that this addresses the described attack vector?
> >> AFAICT, it does not.
> >
> > In the mixed RPKI / non-RPKI environment of today's
's internet, no it
doesn't. This does not mean that RPKI is deficient, or the AS 0 ROA doesn't
work as intended, as was stated.
On Sun, Oct 22, 2023 at 12:57 PM William Herrin wrote:
> On Sun, Oct 22, 2023 at 9:38 AM Tom Beecher wrote:
> >> He's saying that so
>
> Let me ground it a bit:
>
> He's saying that someone could come along and advertise 0.0.0.0/1 and
> 128.0.0.0/1 and by doing so they'd hijack every unrouted address block
> regardless of the block's ROA.
>
> RPKI is unable to address this attack vector.
>
https://www.rfc-editor.org/rfc/rfc6483
>
> I believe Jason's proposal is exactly what OP is looking for.
>
I would agree.
On Wed, Oct 18, 2023 at 11:28 AM Saku Ytti wrote:
> On Wed, 18 Oct 2023 at 17:39, Tom Beecher wrote:
>
> > Auto-bandwidth won't help here if the bandwidth reduction is 'sile
1 - 100 of 657 matches
Mail list logo
