Re: Best TAC Services from Equipment Vendors

[Giorgio Bonfiglio via NANOG]

> On 7 Mar 2024, at 06:50, Saku Ytti  wrote:
> 
> The last case is so common that every first-line adopts the strategy of 
> 'pinging' you, regardless how good and clear information you provide, they 
> ask some soft-ball question, to see if you're still engaged.

No way - I never understood why HP and VMware support would call me 12/24 hours 
after I raised a case, essentially read it back to me and conclude with ‘okay 
assigning to an engineer now’. I last dealt with either of them 7 years ago but 
things haven’t likely changed.

This is it, to check if I’m still there! Quite absurd though to create a 
dependency on a phone call to start working on a support case for which I 
selected the email/portal contact method if you ask me though.

G

Re: How threading works (was Re: Root Cause Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block)

[Giorgio Bonfiglio via NANOG]

> I am so glad that you decided to come out to be a well-informed referee. 
> For more than one year, I have been accused of breaking the eMail etiquette 
> established by a standard, yet never identified. It seriously distracted our 
> attention from the topic of essence. You now have demonstrated that the 
> reverse appears to be the case. What a big surprise! 

Even if it doesn’t break the threading RFCs, I am at a loss looking for a 
reason why the subject line of a thread should be a/ arbitrarily changed 
without a correlated change in subject, b/ extended to a point where it takes 
1/3rd of the screen of my iPhone and doesn’t fit in the table view in my 
Thunderbird and c/ in a list with thousands of individuals be changed to 
include some sort of timestamp specific to one of them (202401102221.AYC).

Please, think at scale. If every single one of us had to randomly change 
subject at every response or add their own timestamp (why even?) 
202401151356.BG this would quickly get out of hand.

I don’t think we need to be in specific breach of an RFC to ask an individual 
which is clearly acting off the standard ML practice to please stop, no?

Re: One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: IPv4 address block

[Giorgio Bonfiglio via NANOG]

> 2) Assume that Google decided that they would no longer support IPv4 for any 
> of their services at a specific date a couple of years in the future. […] I 
> really expect something like this to be the next part of the end game for 
> IPv4.

It’s never gonna happen … why would Google, or any other internet property, 
launch something which artificially cuts the potential revenue pool to 
IPv6-ready customers?

I’m with you it would be amazing and a strong driver, but it’s just not in the 
realm of possibility…

Re: 202401100645.AYC Re: IPv4 address block

[Giorgio Bonfiglio via NANOG]

>> We don't need to extend IPv4, we need to figure out why we are in this
>> dual-stack mess, which was never intended, and how to get out of it.
> 
> it was intended.  it was the original transition plan.  like many things
> about ipv6, it could have been a bit better thought out.

What was not intended though was the transition period to last for 30 years and 
counting… If things go reasonably well we’re gonna be dual stack for another 
20, at least.

Re: Interesting Ali Express web server behavior...

[Giorgio Bonfiglio via NANOG]

How big would a network need to get, in order to come close to exhausing 
RFC1918 address space? […] If one was to allocate 10 addresses to each host, 
that means it would require 1,789,132 hosts to exhaust the space.
Total availability is not usually the problem - poor allocation of space done 
in the 80s is.

I’ve worked with a telco a while ago which had ‘run out of 10/8’ by having 
allocated multiple /16s to their largest sites for lan/mgmt/control. The plan 
to ‘free up IP space’ included resetting practically every 20 years old air 
conditioner they had in the country and put them in a different subnet, same 
for fire and access control systems (air conditioners and fire control 
specifically didn’t support IP address change, you had to drop the entire 
config).

If you think about the scale of the operation then suddenly 33/8 becomes very, 
very appealing.


- Christopher H.

On Sun, 10 Dec 2023 at 18:45, Sabri Berisha mailto:sa...@cluecentral.net> > wrote:
- On Dec 9, 2023, at 9:55 PM, Owen DeLong via NANOG nanog@nanog.org 
 wrote:

Hi,

> Location: http://33.3.37.57/  

> But why would AliExpress be redirecting to DDN space? Is this legitimate? Ali
> hoping to get away with squatting, or something else?

Not very long ago I worked for a well-known e-commerce platform where we nearly
ran out of RFC1918 space. We seriously considered using what was then
un-advertised DOD space to supplement RFC1918 space inside our data centers.

Perhaps AliExpress did get to that level of desperateness?

Thanks,

Sabri 

Re: Am I the only one who thinks this is disconcerting?

[Giorgio Bonfiglio via NANOG]

On a related note, I recently noticed Google became reachable again over IPv6 
from Cogent (I didn't have any automated testing in place so this can well have 
happened long ago - last posts I can find about the issue are from mid-2020).

 


 

 

It's apparently through Tata/6453 so looks like they figured it out. Does 
anyone have context on when / how this was done? Can't find anything on the 
internet!

 


 

 

>From Cogent's LG:

 


 

 

  6453 15169
     2001:550:0:1000::261c:143 (metric 102020) from 2001:550:0:1000::261c:153 
(38.28.1.67)
   Origin IGP, metric 4294967294, localpref 100, valid, internal, best, 
group-best
   Received Path ID 0, Local Path ID 1, version 175370
   Community: 174:11401 174:20666 174:21100 174:22005
   Originator: 38.28.1.67, Cluster list: 38.28.1.83

 


 

 


 

 
On 13/11/2023 20:38, Ryan Hamel wrote:
 
 
 Matt,
 
 
 Why would HE hijack Cogent's IP space? That would end in a lawsuit and 
potentially even more de-peering between them.
 
 
 
 Ryan Hamel
 
 
 
 
 

 
From: NANOG  on behalf of Matt 
Corallo 
 Sent: Monday, November 13, 2023 11:32 AM
 To: Bryan Fields ; nanog@nanog.org 
 Subject: Re: Am I the only one who thinks this is disconcerting? 
 
 
 
 
Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.
 
 
 On 11/8/23 2:23 PM, Bryan Fields wrote:
 > On 11/8/23 2:25 PM, o...@delong.com wrote:
 >> Seems irresponsible to me that a root-server (or other critical DNS 
 >> provider) would engage in a
 >> peering war to the exclusion of workable DNS.
 >
 > I've brought this up before and the root servers are not really an IANA 
 > function IIRC.  There's not
 > much governance over them, other than what's on root-servers.org.  I think a 
 > case could be made that
 > C is in violation of the polices on that page and RFC 7720 section 3.

 >
 > Basically none of the root servers want to change this and thus it's never 
 > going to change.  DNS
 > will fail and select another to talk to, and things will still work.
 
 At what point does HE just host a second C root and announce the same IPv6s? 
Might irritate Cogent,
 but its not more "bad" than Cogent failing to uphold the requirements for 
running a root server.
 
 Matt
 
 
 

-- 
www: grg.pw
email: m...@grg.pw
mobile: +44 7716 604314 / +39 393 1049073

 

Re: RESOLVED: Cogent Abuse - Bogus Propagation of ASN 36471

[Giorgio Bonfiglio via NANOG]

Do you mind following up on Matthew’s request for details - really interested 
to see the threat model there and how the RPKI part played out?

On 20 Jul 2023, at 18:06, Pete Rohrman  wrote:

 

All,

 


 

 

Cogent has shut down the compromised router.  This issue is resolved.  Thank 
you all for your help.

 


 

 


 

 


 
Pete 
 
 
Stage2 "Survivor Island" Bronze Medal Winner
 

 
 

 
 

 
 
On 7/20/23 12:59, Mike Hammett wrote:
 
 
If they (or anyone else) want to give me free service to use as I see fit 
(well, legally), I'll gladly accept their offer.
 
 

 
 -
 Mike Hammett
 Intelligent Computing Solutions
 http://www.ics-il.com
 
 Midwest-IX
 http://www.midwest-ix.com
 
 
 

 
From: "Tom Beecher" 
 To: "Matthew Petach" 
 Cc: nanog@nanog.org
 Sent: Thursday, July 20, 2023 11:38:50 AM
 Subject: Re: Cogent Abuse - Bogus Propagation of ASN 36471
 
 
 In short--I'm having a hard time understanding how a non-paying entity still 
has working connectivity and BGP sessions, which makes me suspect there's a 
different side to this story we're not hearing yet.   ^_^;
 

 
 
I know Cogent has long offered very cheap transit prices, but this seems very 
aggressive! :)  
 
 
 
 
On Thu, Jul 20, 2023 at 12:28 PM Matthew Petach mailto:mpet...@netflight.com> > wrote:
 
 
 

 
 
 
 
On Thu, Jul 20, 2023 at 8:09 AM Pete Rohrman mailto:prohr...@stage2networks.com> > wrote:
 
 
 

Ben,

 

Compromised as in a nefarious entity went into the router and changed passwords 
and did whatever.  Everything advertised by that comprised router is bogus.  
The compromised router is owned by OrgID: S2NL (now defunct).  AS 36471 belongs 
to KDSS-23  
.  The compromised router does not belong to Kratos KDSS-23 
 , and is 
causing routing problems.  The compromised router needs to be shut down.  The 
owner of the compromised router ceased business, and there isn't anyone around 
to address this at S2NL.  The only people that can resolve this is Cogent.   
Cogent's defunct customer's router was compromised, and is spewing out bogus 
advertisements.  
 

 

Pete

 
 

 
 

 
 
Hi Pete,
 

 
 
This seems a bit confusing. 
 

 
 
So, S2NL was a bill-paying customer of Cogent with a BGP speaking router.
 
They went out of business, and stopped paying their Cogent bills.
 
Cogent, out of the goodness of their hearts, continued to let a non-paying 
customer keep their connectivity up and active, and continued to freely import 
prefixes across BGP neighbors from this non-paying defunct customer.
 
Now, someone else has gained access to this non-paying, defunct customer's 
router (which Cogent is still providing free connectivity to, out of the 
goodness of their hearts), and is generating RPKI-valid announcements from it, 
which have somehow not caused a flurry of messages on the outages list about 
prefix hijackings.
 

 
 
The elements to your claim don't really seem to add up.
 
1) ISPs aren't famous for letting non-bill-paying customers stay connected for 
very long past the grace period on their billing cycle, let alone long after 
the company has gone belly-up.
 
2) It's not impossible to generate RPKI-valid announcements from a hijacked 
network, but it's very difficult to generate *bogus* RPKI-valid announcements 
from a compromised router--that's the whole point of RPKI, to be able to 
validate that the prefixes being announced from an origin are indeed the ones 
that are owned by that origin.
 

 
 
Can you provide specific prefix and AS_PATH combinations being originated by 
that router that are "bogus" and don't belong to the router's ASN?

 

 
 
If, however, what you meant is that the router used to be ASN X, and is now 
suddenly showing up as ASN 36471, and Cogent happily changed their BGP neighbor 
statements to match the new ASN, even though the entity no longer exists and 
hasn't been paying their bills for some time, then that would imply a level of 
complicity on Cogent's part that would make them unlikely to respond to your 
abuse reports.  That would be a very strong allegation to make, and the 
necessary level of documented proof of that level of malfeasance would be 
substantial.
 

 
 
In short--I'm having a hard time understanding how a non-paying entity still 
has working connectivity and BGP sessions, which makes me suspect there's a 
different side to this story we're not hearing yet.   ^_^;
 

 
 
Thanks!
 

 
 
Matt