Re: puck not responding

[Daniel Marks via NANOG]

We’re getting rocked by storms here in Michigan, could be related.

Sent from my iPhone

> On Feb 28, 2024, at 01:22, Hank Nussbacher  wrote:
> 
> 
> 

puck not responding

[Hank Nussbacher]

Re: Any info on AT Wireless Outage?

[Mark Seiden]

aside from the official pablum that was released about an “incorrect process 
used”
(which says exactly nothing) does anyone actually know anything accurate and 
more specific about the root cause?

(and why it took 11 hours to recover?)

> On Feb 22, 2024, at 11:15 AM, John Councilman  wrote:
> 
> From what I've read, they lost their database of SIM cards.  I could be wrong 
> of course.
> 
> On Thu, Feb 22, 2024 at 2:02 PM Dorn Hetzel  > wrote:
>> As widespread as it seemed to be, it feels like it would be quite a trick if 
>> it were a single piece of hardware.  Firmware load that ended badly, I 
>> wonder?
>> 
>> 
>> On Thu, Feb 22, 2024 at 1:51 PM Leato, Gary via NANOG > > wrote:
>>> Do you have the ability to expand on this at all? Do you mean a hardware 
>>> failure of some kind IE router, optitcs, etc?
>>> 
>>>  
>>> 
>>> From: NANOG >> > On Behalf Of R. Leigh Hennig
>>> Sent: Thursday, February 22, 2024 8:17 AM
>>> To: Robert DeVita mailto:radev...@mejeticks.com>>
>>> Cc: nanog@nanog.org 
>>> Subject: Re: Any info on AT Wireless Outage?
>>> 
>>>  
>>> 
>>> Word around the campfire is that it’s a Cisco issue.
>>> 
>>> 
>>> 
>>> 
>>> On Feb 22, 2024, at 8:03 AM, Robert DeVita >> > wrote:
>>> 
>>>  
>>> 
>>> Reports have it starting at 4:30 a.m.. SOS on all phones..
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>> 
>>> 
>>> Robert DeVita
>>> 
>>> CEO and Founder
>>> 
>>> t: (469) 581-2160 
>>>  | 
>>> 
>>> m: (469) 441-8864 
>>> e: radev...@mejeticks.com    
>>>  | 
>>> 
>>> w: mejeticks.com 
>>> a: 
>>> 
>>> 2323 N Akard Street
>>> 
>>> , 
>>> 
>>> Dallas
>>> 
>>> , 
>>> 
>>> 75201
>>> 
>>>    
>>>  
>>>     
>>>  
>>>  
>>> 
>>> 
>>> 
>>> The risk of trading futures and options can be substantial. All 
>>> information, publications, and material used and distributed by Advance 
>>> Trading Inc. shall be construed as a solicitation. ATI does not maintain an 
>>> independent research department as defined in CFTC Regulation 1.71. 
>>> Information obtained from third-party sources is believed to be reliable, 
>>> but its accuracy is not guaranteed by Advance Trading Inc. Past performance 
>>> is not necessarily indicative of future results.

Re: IPv6 connectivity to mx[1-4].smtp.goog.

[Christopher Morrow]

On Tue, Feb 27, 2024 at 12:03 PM 푀풶퓇풸표 풟풶퓋풾풹퓈 via NANOG
 wrote:
>
> Op 27-02-24 om 16:22 schreef Brotman, Alex:
>
> > We are seeing the same,
>
> Thanks.
>
> > You may also want to ask the mailop list.
>
>
> I was about to do that, when I noticed that the problem seems solved.

sorry about the noise.

Re: starlink ixp peering progress

[Bill Woodcock]

> On Feb 27, 2024, at 08:54, Dave Taht  wrote:
> One of the things I learned today was that starlink has published an 
> extensive guide as to how existing BGP AS holders can peer with them to get 
> better service.

Yes, essentially every AS does this.  The ones that follow best-practices tend 
to be pretty uniform:

https://pch.net/peering
https://aws.amazon.com/peering/policy/
https://www.bytedance.com/en/peering
https://peering.google.com/#/options/peering
https://openconnect.netflix.com/en/peering/
https://www.lumen.com/en-us/about/legal/peering-policy.html
http://peering.ovh.net/

Starlink’s peering policy is straight-forward and follows best practices.  Then 
there are ones that get a little further afield, some of which can get kinda 
unusual in their fine-print:

https://learn.microsoft.com/en-us/azure/internet-peering/policy
https://www.verizon.com/business/terms/peering/
https://www.zayo.com/wp-content/uploads/2022/07/Zayo-Global-IP-Interconnection-Policy-Final-1.pdf
https://wholesale.orange.com/international/en/peering-policy.html

> I am curious if there is a way to see how many have peered already?

Well, if Starlink operates a looking-glass, sure.  Or you can derive an idea, 
albeit an incomplete one, from public data.  If any national communications 
regulators are paying attention, they may have placed a regulatory requirement 
on Starlink to make this public data, though it might have to be dug out of 
regulatory compliance filings, and might not be up-to-date.

> how many they could actually peer with?

That you’d need to script, though many people have.  We have an internal tool 
that tells us that about our own network, and I suspect pretty much every 
network large enough to have a dedicated peering team does likewise.  If you 
were to write such a tool for nonspecific use, we have public datasets that 
would show you who potential peers were at each IXP, and what routes / how many 
addresses they were advertising at each IXP…  Obviously if you’re learning 
Deutche Telekom’s routes in Frankfurt and Munich, it matters somewhat less 
whether you also peer with them in Karlsruhe, assuming they’re advertising the 
same routes everywhere, though it’s still good.  If they’re doing regional 
announcement, you might need to peer with them in different location to 
“collect the whole set” of their routes.  That’s not so common now, though it 
was a fad for a while, maybe fifteen years ago.  I haven’t tried to quantify 
the degree of regional announcement lately… that’s a good small project for a 
student who wants to learn about routing and interconnection.

> And progress over time since inception is there a tool for that?

I think you’d have to throw together your own tools for that, or derive it from 
public data such as the routing archives that we, RIPE, and Route-Views 
maintain.

> Is there a better email list to discuss ixp stuff?

The two I know of are ixp-disc...@pch.net and ixp-disc...@itu.int.  Both are 
pretty quiet, though both have very helpful people on them.

   -Bill




signature.asc
Description: Message signed with OpenPGP

Re: starlink ixp peering progress

[Bill Woodcock]

> On Feb 27, 2024, at 08:54, Dave Taht  wrote:
> One of the things I learned today was that starlink has published an 
> extensive guide as to how existing BGP AS holders can peer with them to get 
> better service.

Yes, essentially every AS does this.  The ones that follow best-practices tend 
to be pretty uniform:

https://pch.net/peering
https://aws.amazon.com/peering/policy/
https://www.bytedance.com/en/peering
https://peering.google.com/#/options/peering
https://openconnect.netflix.com/en/peering/
https://www.lumen.com/en-us/about/legal/peering-policy.html
http://peering.ovh.net/

Starlink’s peering policy is straight-forward and follows best practices.  Then 
there are ones that get a little further afield, some of which can get kinda 
unusual in their fine-print:

https://learn.microsoft.com/en-us/azure/internet-peering/policy
https://www.verizon.com/business/terms/peering/
https://www.zayo.com/wp-content/uploads/2022/07/Zayo-Global-IP-Interconnection-Policy-Final-1.pdf
https://wholesale.orange.com/international/en/peering-policy.html

> I am curious if there is a way to see how many have peered already?

Well, if Starlink operates a looking-glass, sure.  Or you can derive an idea, 
albeit an incomplete one, from public data.  If any national communications 
regulators are paying attention, they may have placed a regulatory requirement 
on Starlink to make this public data, though it might have to be dug out of 
regulatory compliance filings, and might not be up-to-date.

> how many they could actually peer with?

That you’d need to script, though many people have.  We have an internal tool 
that tells us that about our own network, and I suspect pretty much every 
network large enough to have a dedicated peering team does likewise.  If you 
were to write such a tool for nonspecific use, we have public datasets that 
would show you who potential peers were at each IXP, and what routes / how many 
addresses they were advertising at each IXP…  Obviously if you’re learning 
Deutche Telekom’s routes in Frankfurt and Munich, it matters somewhat less 
whether you also peer with them in Karlsruhe, assuming they’re advertising the 
same routes everywhere, though it’s still good.  If they’re doing regional 
announcement, you might need to peer with them in different location to 
“collect the whole set” of their routes.  That’s not so common now, though it 
was a fad for a while, maybe fifteen years ago.  I haven’t tried to quantify 
the degree of regional announcement lately… that’s a good small project for a 
student who wants to learn about routing and interconnection.

> And progress over time since inception is there a tool for that?

I think you’d have to throw together your own tools for that, or derive it from 
public data such as the routing archives that we, RIPE, and Route-Views 
maintain.

> Is there a better email list to discuss ixp stuff?

The two I know of are ixp-disc...@pch.net and ixp-disc...@itu.int.  Both are 
pretty quiet, though both have very helpful people on them.

-Bill



signature.asc
Description: Message signed with OpenPGP

Re: IPv6 connectivity to mx[1-4].smtp.goog.

[푀풶퓇풸표 풟풶퓋풾풹퓈 via NANOG]

Op 27-02-24 om 16:22 schreef Brotman, Alex:


We are seeing the same,


Thanks.


You may also want to ask the mailop list.



I was about to do that, when I noticed that the problem seems solved.

--
푀풶퓇풸표

Re: TFTP over anycast

[William Herrin]

On Tue, Feb 27, 2024 at 10:02 AM Javier Gutierrez
 wrote:
> My design is very simplistic, I have 2 sets of firewalls that I
> will have advertising a /32 unicast to the network at each
> location and it will have a TFTP server behind each firewall.

Hi Javier,

That sounds straightforward to me with no major failure modes. I would
make the firewall part of my OSPF network and then add the tftp
servers to OSPF using FRR. Then I'd write a script to monitor the
local tftp server and stop frr if it detects any problems with the
tftp server. The local tftp server will always be closer than the
remote one via OSPF link costs, unless it goes offline. I assume you
also have an encrypted channel between the firewalls to handle traffic
that stays "inside" your security boundary, as tftp generally should.

Where you could get into trouble is if you add a third or additional
sites. If there's ever an equal routing cost from any one site to two
others, there's a non-zero risk of the failover process failing... and
you won't know it until you need it.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: TFTP over anycast

[Javier Gutierrez]

Thanks to you all for your answers, it has helped me a lot already.

My design is very simplistic, I have 2 sets of firewalls that I will have 
advertising a /32 unicast to the network at each location and it will have a 
TFTP server behind each firewall.

I have no intention to have this be part of the internet as it will be used to 
serve internal customers devices that require TFTP
For the setup where you are running Anycast on a datacenter, are you running it 
inside the datacenter only or across multiple datacenters? other than having to 
replicate IPs and file services between datacenters have you seen any other 
issues?


Kind regards,



Javier Gutierrez,

Network Architect – AS19016
https://www.peeringdb.com/net/4073

Westman Communications Group

[cid:2db642a4-fcf9-40b4-a719-2afd8097f2e9]1906 Park Ave. • Brandon, MB • R7B 0R9

[cid:8862c057-cdef-45f6-a0e3-497508d0d64a]204.720.1158
[cid:6a35147d-b3b0-44cf-bc96-6822377f5231] 
gutierr...@westmancom.com

[A close up of a sign  Description automatically 
generated]



[cid:486e0290-5d40-48dd-80eb-3be9a705b1e6][cid:425d7b57-d7e3-491d-9d22-910d4072b88a]
  [cid:ee77dd48-8761-498b-b45b-82b00e5bf553] 
   
[cid:547ce68d-d61c-40e3-b150-39bff72b8d6b] 
   
[cid:ba4751b3-edc0-484e-bb40-731ca94e8c84] 


This e-mail and any attachments contain confidential and privileged 
information. If you are not the intended recipient, please notify the sender 
immediately by return e-mail, delete this e-mail and destroy any copies. Any 
dissemination or use of this information by a person other than intended 
recipient is unauthorized and may be illegal.




From: NANOG  on behalf of 
Bill Woodcock 
Sent: Saturday, February 24, 2024 1:09 AM
To: Ask Bjørn Hansen 
Cc: nanog@nanog.org 
Subject: Re: TFTP over anycast


CAUTION: This email is from an external source. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.

The system Ask is describing is the traditional method of using anycast to 
geographically load-balance long-lived flows.  The first time I did that was 
with FTP servers in Berkeley and Santa Cruz, in 1989.

I did a bigger system, also load balancing FTP servers for Oracle, their 
public-facing documentation stores, with servers in San Jose and Washington DC, 
a couple of years later.   A couple of years further on and the World Wide Web 
was a thing, and everybody was doing it.

-Bill


On Feb 24, 2024, at 7:38 AM, Ask Bjørn Hansen  wrote:



On Feb 23, 2024, at 20:32, William Herrin  wrote:

The relay server `dhcplb` could, maybe, help in that scenario
(dhcplb runs on the anycast IP, the “real” DHCP servers on
unicast IPs behind dhcplb).

Although they used the word "anycast", they're just load balancing.

The idea is to run the relays on an anycasted IP (so the load balancer / relay 
IP is anycasted).

[….] Relying on ECMP for anycasted DHCP would be a disaster
during any sort of failure. Add or remove a single route from an ECMP
set and the hashed path selection changes for most of the connections.

Consistent hashing (which I thought was widely supported now in ECMP 
implementations) and a bit of automation in how announcements are added can 
greatly mitigate this.



Ask

Re: starlink ixp peering progress

[Warren Kumari]

Or this: https://bgp.tools/as/14593#peers


Personally I find bgp.tools to be the friendliest…

I realize that this thread is turning into an Me too! type
thread, but it does seem useful to share which tools work best for each of
us…

W



On Tue, Feb 27, 2024 at 7:33 AM, Marco Davids  wrote:

> Or this?
>
> https://bgp.he.net/AS14593#_peers6
>
> Op 27/02/2024 om 13:17 schreef b...@uu3.net:
>
> Well, for some basic overview you can use CAIDA AS rank.
>
> You can use it directly, or you may try my (more user friendly) frontend
> for it: http://as-rank.uu3.net/?as=14593
>
> -- Original message --
>
> From: Dave Taht 
> To: NANOG 
> Subject: starlink ixp peering progress
> Date: Tue, 27 Feb 2024 02:54:44 -0500
>
> One of the things I learned today was that starlink has published an
> extensive guide as to how existing BGP AS holders can peer with them to get
> better service.
>
> https://starlink-enterprise-guide.readme.io/docs/peering-with-starlink
>
> I am curious if there is a way to see how many have peered already, how
> many they could actually peer with?, and progress over time since
> inception what would be the right tools for that? This is pretty
> impressive for peering so far:
>
> https://www.peeringdb.com/net/18747
>
> Is there a better email list to discuss ixp stuff?
>
> --
> Marco
>

RE: IPv6 connectivity to mx[1-4].smtp.goog.

[Brotman, Alex via NANOG]

We are seeing the same, but seems like it's mostly affecting delivery for 
broadcom.com, and a few other smaller domains.  However, connectivity to the MX 
listed by gmail.com (and most other domains using GSuite, etc) are working fine 
over IPv6.

You may also want to ask the mailop list.

-- 
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
 

> -Original Message-
> From: NANOG 
> On Behalf Of Marco Davids (Private) via NANOG
> Sent: Tuesday, February 27, 2024 8:03 AM
> To: nanog@nanog.org
> Subject: IPv6 connectivity to mx[1-4].smtp.goog.
> 
> Hi,
> 
> At
> https://urldefense.com/v3/__https://internet.nl__;!!CQl3mcHX2A!Dc9AZo4F
> nrpVmuo3Ehg5iQUAd4uTAsCdz9MWYKJqFWyWK7_XnaDnWN3_DkOAVq2e5
> CXVOb2triASeebvdg$  we're seeing IPv6 connection issues on TCP port
> 25 (SMTP) to mx[1-4].smtp.goog.
> 
> Either 100% DROP (so no TCP connection) or ⅔ failure to setup connection.
> 
> Further testing seems to confirm the problem is bigger and on Google's side.
> 
> So, this fails:
> 
> echo 'quit' | nc -6 -w 3 mx1.smtp.goog. 25
> 
> and this works:
> 
> echo 'quit' | nc -4 -w 3 mx1.smtp.goog. 25
> 
> (on MacOS use -G instead of -w)
> 
> Is anyone else seeing this? Any idea what is causing this?
> 
> --
> Marco

Re: starlink ixp peering progress

[Mike Hammett]

The best way I've found (and it is indeed rather incomplete) is to have a BGP 
feed going to something like QRator from that AS (or a downstream AS) that then 
performs analytics on the BGP feed. Starlink is unlikely to have BGP customers, 
so that makes it a bit more difficult. 


https://radar.qrator.net/as/14593/ipv4/neighbors/peerings 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Dave Taht"  
To: "NANOG"  
Sent: Tuesday, February 27, 2024 1:54:44 AM 
Subject: starlink ixp peering progress 

One of the things I learned today was that starlink has published an 
extensive guide as to how existing BGP AS holders can peer with them 
to get better service. 

https://starlink-enterprise-guide.readme.io/docs/peering-with-starlink 

I am curious if there is a way to see how many have peered already, 
how many they could actually peer with?, and progress over time since 
inception what would be the right tools for that? This is pretty 
impressive for peering so far: 

https://www.peeringdb.com/net/18747 

Is there a better email list to discuss ixp stuff? 


-- 
https://blog.cerowrt.org/post/2024_predictions/ 
Dave Täht CSO, LibreQos 

IPv6 connectivity to mx[1-4].smtp.goog.

[Marco Davids (Private) via NANOG]

Hi,

At https://internet.nl we're seeing IPv6 connection issues on TCP port 
25 (SMTP) to mx[1-4].smtp.goog.


Either 100% DROP (so no TCP connection) or ⅔ failure to setup connection.

Further testing seems to confirm the problem is bigger and on Google's side.

So, this fails:

echo 'quit' | nc -6 -w 3 mx1.smtp.goog. 25

and this works:

echo 'quit' | nc -4 -w 3 mx1.smtp.goog. 25

(on MacOS use -G instead of -w)

Is anyone else seeing this? Any idea what is causing this?

--
Marco

Re: starlink ixp peering progress

[Marco Davids (Private) via NANOG]

Or this?

https://bgp.he.net/AS14593#_peers6

Op 27/02/2024 om 13:17 schreef b...@uu3.net:

Well, for some basic overview you can use CAIDA AS rank.

You can use it directly, or you may try my (more user friendly)
frontend for it: http://as-rank.uu3.net/?as=14593


-- Original message --

From: Dave Taht 
To: NANOG 
Subject: starlink ixp peering progress
Date: Tue, 27 Feb 2024 02:54:44 -0500

One of the things I learned today was that starlink has published an
extensive guide as to how existing BGP AS holders can peer with them
to get better service.

https://starlink-enterprise-guide.readme.io/docs/peering-with-starlink

I am curious if there is a way to see how many have peered already,
how many they could actually peer with?, and progress over time since
inception what would be the right tools for that? This is pretty
impressive for peering so far:

https://www.peeringdb.com/net/18747

Is there a better email list to discuss ixp stuff?




--
Marco

Re: starlink ixp peering progress

[borg]

Well, for some basic overview you can use CAIDA AS rank.

You can use it directly, or you may try my (more user friendly)
frontend for it: http://as-rank.uu3.net/?as=14593


-- Original message --

From: Dave Taht 
To: NANOG 
Subject: starlink ixp peering progress
Date: Tue, 27 Feb 2024 02:54:44 -0500

One of the things I learned today was that starlink has published an
extensive guide as to how existing BGP AS holders can peer with them
to get better service.

https://starlink-enterprise-guide.readme.io/docs/peering-with-starlink

I am curious if there is a way to see how many have peered already,
how many they could actually peer with?, and progress over time since
inception what would be the right tools for that? This is pretty
impressive for peering so far:

https://www.peeringdb.com/net/18747

Is there a better email list to discuss ixp stuff?


-- 
https://blog.cerowrt.org/post/2024_predictions/
Dave Täht CSO, LibreQos

Re: Why are paper LOAs still used?

[Jay Acuna]

On Mon, Feb 26, 2024 at 1:20 PM Joe via NANOG  wrote:
>
> One thing that I recently read on this mailing list, is that at least in the 
> US, a transmitting a fraudulent LOA is a federal crime - wire fraud. [0]
> Being able to hopefully charge and convict someone performing fraud is a 
> useful deterrent.

This would be just as true of an Emailed declaration signed with the
sender's name or other
digital representation of a signature.  If there is a fraudulent
scheme, then deliberately
providing a false emailed declaration of authorization just as criminal.

My suggestion would be that a LOA should only ever be used as a
Supportive document,
it could be used for that,  and Verifying the data using IRR or RPKI
after would still be necessary.
An LOA on its own should never be enough.

An LOA can still be Incorrect or Wrong due to a Typo'd ASN or IP
number, but Not fraudulent.
And even if the information is deliberately wrong it might not meet
the conditions for fraud.

It is also possible the sender of the LOA can send an erroneous
document and have No
legal responsibility for the results of incorrectly including some IP
or AS number on the form.

Surely a network service provider must have some level of duty to
verify the authenticity of
information furnished on the LOAs and confirm that the IP numbers are
Not incorrectly entered,
for example clerical errors in processing the document.

> -joe
--
-J

Re: BGP Monitoring

[Elmar K. Bins]

Hi Alex,

l...@qrator.net (Alexander Lyamin) wrote:

> Ray mentioned precisely that he wants to  monitor BGP announcements and
> route changes.
>
> Leak detection is kind of on a different level. You need a bit more  data
> to effectively detect them. ( I kind of know that).

Our use case is extremely simple, so the RIS feed gives us everything we need.
We don't need to qualify the leak, *any* leak from a local node is undesirable,
they tag everything NO_EXPORT. Anybody exporting must thus be dealt with.

But you gave me an idea regarding our datacenter prefixes...

Cheers,
Elmar.

Re: BGP Monitoring

[Ben Cox via NANOG]

Aha! That makes sense!

I was struggling to find any kind of public data on who runs it, so I
assumed whoever was presenting it probably runs / owned it

On Tue, Feb 27, 2024, 08:20 Fearghas Mckay  wrote:

>
>
> On 27 Feb 2024, at 01:28, Ben Cox via NANOG  wrote:
>
> I believe PacketVis is Massimo Candela , based on
> https://ripe85.ripe.net/archives/video/987/
>
>
> It is run by his brother rather than Massimo, but it is his BGPalerter
> software behind the family business :)
>
> f
>

Re: Why are paper LOAs still used?

[Carlos Friaças via NANOG]

Hi,
(please see inline)


On Mon, 26 Feb 2024, Tom Samplonius wrote:



 There is one purpose:  to facilitate IP fraud, and maintain currently 
fraudulently routed IPs.


Yes!


 Anyone can dummy up a LOA.  And there is still quite a lot of unrouted 
IP space.


Yes. But the endgame is not always the same, when miscreants push fake 
LOAs (for routing).


I was recently made aware about https://loa.tools

This is how easy it gets..



VPS providers know this, and know their customers are submitting fake 
LOAs.


Then it's a good idea to require cryptographic evidence of 
ownership/authorization, by resorting to RPKI/ROV.





But it is sort of the business VPS providers are in.


That can by true for some. I hope it isn't true for the majority of them.



 Is it some sort of serious crime in the US though?  Well, just submit 
the LOA from outside the US.  Plus, the entity being defrauded is the IP 
holder, not the VPS provider or their customer.  If you are an IP 
holder, good luck getting the VPS provider to give you a copy of the 
fake LOA.  It is not in their interest to throw their customers under 
the bus.  You would have to give them a court order.  So if you look 
for unrouted IP space, registered to a non-US organization (ex. Canada), 
and submit a fake LOA from another country (London, UK for instance), 
you are unlikely to get tracked down for wire fraud.


Good example, but there are also some less central 
jurisdictions/coutries/territories, where local law enforcement 
cooperation is even harder to get. And miscreants know this very well.




And you might ask, well, why would a VPS provider accept an LOA from 
the UK for an IP block registered to a Canadian organization?  Well, 
clearly it isn?t in the VPS provider?s interest to look into the LOAs 
too much.


While it doesn't change anything in the "interest" vector, resorting to 
RPKI/ROV would probably be less work.




As long as the IP space is unrouted, they will approve it.  The LOA is 
basically just a liability shield for the VPS provider.  It is not a 
crime to be deceived, though the due diligence beggars belief.


Even if the IP space is routed, can't anycast be invoked...? :-)))



 So I had this happen.  There was a /24 being hijacked by a VPS 
provider.  I told them this was fraud, and they asked me if I wanted to 
?rescind the LOA?.  I told them I never gave them a LOA.  They dropped 
the /24 immediately.  They refused to provide a copy of the LOA.  So 
pretty hard to pursue any sort of wire fraud charges.


That's the thing with LOAs for routing, the only way to be sure is to 
check if there is a valid ROA with the prefix, length and ASN. :-)


If the customer can't make a valid ROA, or make the legitimate owner 
produce one, then the claim on the LOA is bogus...




 So a VPS provider asking for a paper LOA is basically asking you to 
lie to them, to protect them from liability.  They will just drop the IP 
prefix if there is any contact from the actual IP holder.


If the legitimate IP holder has closed shop, there will not be a contact. 
And miscreants also know this very well...



Cheers,
Carlos




Tom




On Feb 26, 2024, at 10:57 AM, Seth Mattinen via NANOG  wrote:

Why do companies still insist on, or deploy new systems that rely on paper LOA 
for IP and ASN resources? How can this be considered more trustworthy than RIR 
based IRR records?

And I'm not even talking about old companies, I have a situation right now 
where a VPS provider I'm using will no longer use IRR and only accepts new 
paper LOAs. In the year 2024. I don't understand how anyone can go backwards 
like that.

~Seth

Re: Why are paper LOAs still used?

[Carlos Friaças via NANOG]

Hi All,

There is this blogpost from the FIRST netsec-sig group, about this topic, 
available at 
https://www.first.org/blog/20231222-Is-the-LoA-DoA-for-Routing



I totally agree with Christopher. The above blogpost ends with (for those 
who don't like to follow links):


"With the current level of RPKI adoption, now is time to adopt it as the 
best current practice, to discontinue the usage of LOAs for authorization 
of routing, and to instead rely on ROV, ROAs, and the cryptographic trust 
we all can obtain from them!"



Best Regards,
Carlos


On Tue, 27 Feb 2024, Christopher Hawker wrote:


Hi Seth,

LOAs can't be considered more trustworthy than IRR objects. The RIRs operate 
IRRdb services as part of the services they offer which
network operators should be using instead of the free and paid 
non-authoritative IRRdb operators.

If you don?t mind, could you please reach out to me off-list with who the VPS 
hosting provider is that is only accepting LOAs? I?d like to
reach out to them to discuss their decision.

I?m doing a talk at APRICOT 2024 on using ROAs to replace LOAs. In my view 
there's no reason why network operators cannot use ROAs instead
to validate the routes received from their peers, be they upstream or 
downstream.

Regards,
Christopher Hawker


Sent from my iPhone

  On 27 Feb 2024, at 1:57?am, Seth Mattinen via NANOG  
wrote:

  Why do companies still insist on, or deploy new systems that rely on 
paper LOA for IP and ASN resources? How can this be
  considered more trustworthy than RIR based IRR records?

  And I'm not even talking about old companies, I have a situation right 
now where a VPS provider I'm using will no longer use
  IRR and only accepts new paper LOAs. In the year 2024. I don't understand 
how anyone can go backwards like that.

  ~Seth

Re: BGP Monitoring

[Fearghas Mckay]

> On 27 Feb 2024, at 01:28, Ben Cox via NANOG  wrote:
> 
> I believe PacketVis is Massimo Candela , based on
> https://ripe85.ripe.net/archives/video/987/

It is run by his brother rather than Massimo, but it is his BGPalerter software 
behind the family business :)

f