Re: List of GMAIL DNS *clients*?

[Peter Potvin via NANOG]

Google has a list of IPs for their services in a JSON format available in
their support section. Legitimate requests from Google should almost always
come from an IP within those subnets.

https://support.google.com/a/answer/10026322
https://support.google.com/a/answer/60764


Kind regards,
Peter Potvin


On Thu, Feb 29, 2024 at 16:17  wrote:

>
> Occasionally one of our log analyzers will block gmail DNS requests
> causing bounces when gmail claims our domain(s) are not authenticated,
> they can't get to our SPF etc.
>
> I'd like to whitelist them but does anyone know the list of IP blocks
> I need?
>
> --
> -Barry Shein
>
> Software Tool & Die| b...@theworld.com |
> http://www.TheWorld.com
> Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
> The World: Since 1989  | A Public Information Utility | *oo*
>

Re: Why are paper LOAs still used?

[Peter Potvin via NANOG]

I can’t speak for all providers but when it comes to some downstream
networks we will usually request an LOA as additional proof that the
customer is authorized to announce the prefixes, in addition to the IRR
objects and (where possible) RPKI ROAs. Mainly only a thing where RPKI is
not possible and the only route object available is in a non-auth database
such as RADB. Overall it helps keep a paper trail (as Tom said) in case
someone comes knocking.

Kind regards,
Peter


On Mon, Feb 26, 2024 at 14:13 Tom Beecher  wrote:

> 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.
>
> Perhaps they have a legal reason to require a paper trail and not rely on
> IRR records.
>
> Plenty of possibilities, all plausible.
>
> On Mon, Feb 26, 2024 at 1:58 PM 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: Peering Contact at AS16509

[Peter Potvin via NANOG]

Meant to reply to this thread earlier today, but a contact from 16509
reached out directly and got everything squared away for us.

On Mon, Feb 19, 2024 at 8:56 PM Tim Burke  wrote:

> We reached out some time ago using the contact on PeeringDB and had no
> issue, but the amount of transit consumed to get to 16509 is substantial
> enough to make responding worth their while.
>
> Their minimum peering is 100G, with 400G preferred, so it’s very possible
> that if you’re not consuming anywhere close to 100G, the lack of response
> could correlate to a lack of interest on their side.
>
> > On Feb 18, 2024, at 13:09, Peter Potvin via NANOG 
> wrote:
> >
> > 
> > If a contact who manages North American peering at AS16509 could reach
> out off-list, that would be appreciated. Myself and a few colleagues have
> attempted to reach out via the contacts listed on PeeringDB on multiple
> occasions over the last couple of months and have not been successful in
> reaching someone.
> >
> > Kind regards,
> > Peter Potvin
>

Peering Contact at AS16509

[Peter Potvin via NANOG]

If a contact who manages North American peering at AS16509 could reach out
off-list, that would be appreciated. Myself and a few colleagues have
attempted to reach out via the contacts listed on PeeringDB on multiple
occasions over the last couple of months and have not been successful in
reaching someone.

Kind regards,
Peter Potvin

Re: Diversity of MUAs (was Re: How threading works (was Re: Root Cause Re: 202401102221.AYC ...))

[Peter Potvin via NANOG]

*audible sigh*

Yet another useless thread added to my Gmail inbox because of a changed
subject line.

Can we please stop doing this for conversations that are about the same
topic? Numerous users on this list have clearly shown they are annoyed by
this, and frankly is something that the list admins should be looking into
- it spams everyone’s inboxes and makes conversations harder to follow.

Kind regards,
Peter

On Sun, Jan 14, 2024 at 01:34 Ellenor Bjornsdottir via NANOG <
nanog@nanog.org> wrote:

> On Sunday, January 14, 2024 6:01:45 AM UTC William Herrin wrote:
> > On Sat, Jan 13, 2024 at 12:58 PM Bryan Fields 
> wrote:
> > > On 1/12/24 3:04 PM, Mu wrote:
> > > > Would it be possible for you to reply in-thread, rather than
> creating a new thread with a new subject line every time you reply to
> someone?
> > > >
> > > > Trying to follow the conversation becomes very difficult for no
> reason.
> > >
> > > Threading has nothing to do with subject lines.  RFC822 (now 5822)
> specifies
> > > how this works based on message ID.  This thread displays fine in
> threaded
> > > mode in my MUA and in the archives.
> >
> > Hi Bryan,
> >
> > Respectfully, your MUA is not the only MUA. Others work differently.
> >
> > GMail, for example, follows the message IDs as you say but assumes
> > that if you change the subject line in your reply (more than adding
> > "Re:") then you intend to start a new thread from that point in the
> > discussion. It groups messages accordingly.
> >
> > This is not an unreasonable expectation: if you merely want to
> > continue the current conversation without going off on a new tangent
> > then there's no need for a different subject line.
> >
> > Regards,
> > Bill Herrin
>
> I have been using KMail to read this list. Just thought I'd throw my hat
> in the ring there, I guess!

Re: Issue with Geolocation in Lasvegas

[Peter Potvin via NANOG]

For Google-related sites specifically and if you haven't already, it's
worth publishing an RFC8805-compliant geofeed and submitting it to them via
their ISP portal at https://isp.google.com/ if you have an account with the
announcing ASN affiliated to it. This is assuming that the IP you specified
is linked to an organization and network you're affiliated with, which
based on your email's domain and the announcing ASN is most likely the case.

For other sites and geolocation databases, it's worth submitting the same
geofeed to each DB/provider individually via email or by following the
information on https://geolocatemuch.com/ to enable other DBs/providers to
automatically discover and update their databases.

Regards,
Peter Potvin


On Thu, Jan 4, 2024 at 2:17 AM Raja Sekhar Gullapalli via NANOG <
nanog@nanog.org> wrote:

>
>
> Team,
>
>
>
> We are having issues in our lasvegas office & it shows geolocation in all
> browsers as Israel instead of US region when we access news.google.com in
> our PC.
>
>
>
> Our public ip is 129.46.96.20.
>
>
>
> Can you help to whom we can contact to resolve the issue.
>
>
>
>
>
> Regards,
>
> Raja
>
>
>
>
>

Fastly Peering Contact

[Peter Potvin via NANOG]

Looking for someone on the Fastly peering team to reach out regarding
peering on a couple mutual IXPs - sent an email to the peering contact as
listed on PeeringDB and never heard back, and also have a few colleagues
who have experienced the same issue.

Regards,
Peter Potvin | Executive Director
--
*Accuris Technologies Ltd.*

Re: What are these Google IPs hammering on my DNS server?

[Peter Potvin via NANOG]

Did a bit of digging on Google's developer site and came across this:
https://developers.google.com/speed/public-dns/faq#locations_of_ip_address_ranges_google_public_dns_uses_to_send_queries

Looks like the IPs you mentioned belong to Google's public DNS resolver
based on that list on their site. They could also be spoofed though from a
DNS AMP attack, so keep that in mind.

Regards,
Peter Potvin | Executive Director
--
*Accuris Technologies Ltd.*


On Sun, Dec 3, 2023 at 1:51 PM John Levine  wrote:

> At contacts.abuse.net, I have a little stunt DNS server that provides
> domain contact info, e.g.:
>
> $ host -t txt comcast.net.contacts.abuse.net
> comcast.net.contacts.abuse.net descriptive text "ab...@comcast.net"
>
> $ host -t hinfo comcast.net.contacts.abuse.net
> comcast.net.contacts.abuse.net host information "lookup" "comcast.net"
>
> Every once in a while someone decides to look up every domain in the
> world and DoS'es it until I update my packet filters. This week it's
> been this set of IPs that belong to Google. I don't think they're
> 8.8.8.8. Any idea what they are? Random Google Cloud customers? A
> secret DNS mapping project?
>
>  172.253.1.133
>  172.253.206.36
>  172.253.1.130
>  172.253.206.37
>  172.253.13.196
>  172.253.255.36
>  172.253.13.197
>  172.253.1.131
>  172.253.255.35
>  172.253.255.37
>  172.253.1.132
>  172.253.13.193
>  172.253.1.129
>  172.253.255.33
>  172.253.206.35
>  172.253.255.34
>  172.253.206.33
>  172.253.206.34
>  172.253.13.194
>  172.253.13.195
>  172.71.125.63
>  172.71.117.60
>  172.71.133.51
>
> R's,
> John
>

Re: Any interpol contact

[Peter Potvin via NANOG]

Have you tried contacting them through the form on their website?
https://www.interpol.int/en/Contacts/Contact-INTERPOL

~ Peter


On Mon, Oct 30, 2023 at 8:27 AM Lu Heng  wrote:

> Hi
>
> We receive some network abuse request allegedly from Interpol, any contact
> from Interpol would be appreciated.
>

Re: ARIN whois contact abuse from ipv4depot aka Silicon Desert International Inc

[Peter Potvin via NANOG]

Definitely have received this same spam multiple times and so have a few
others I know. It's ridiculous that they resort to scraping public lists
and DBs to try and achieve what they're attempting to do.

Regards,
Peter Potvin | Executive Director
--
*Accuris Technologies Ltd.*



On Wed, Oct 11, 2023 at 7:52 PM Eric Kuhnke  wrote:

> Is anyone else receiving spam from this organization? Based on the
> contents of the cold solicitations they are sending us, and the addresses
> being sent to, they have scraped ARIN WHOIS data for noc and abuse POC
> contact info and recent ipv4 block transfers.
>
> It's trivially easy to block their entire domain at the mail server level,
> of course...
>
>
>

Re: Facebook IP Geolocation

[Peter Potvin via NANOG]

Hey there TJ,

I have, and unfortunately the databases listed there are reporting the
location correctly. It seems to be an issue specifically with Facebook from
what I'm able to diagnose. I've been reached out to by someone from their
network team regarding this so will update this thread when/if it gets
resolved.

Regards,
Peter Potvin | Executive Director
--
*Accuris Technologies Ltd.*
56A Mill St E, Unit #470, Acton, ON L7J 1H3 Canada
Email: peter.pot...@accuristechnologies.ca
Office: +1 (877) 352-6105
Network Operations Center: +1 (877) 321-1662


On Fri, Apr 28, 2023 at 6:21 AM TJ Trout  wrote:

> Have you checked these?
>
> https://thebrotherswisp.com/index.php/geo-and-vpn/
>
> On Fri, Apr 28, 2023, 1:58 AM Peter Potvin via NANOG 
> wrote:
>
>> Hey all,
>>
>> Recently a customer reached out to us regarding an IP of ours in Canada
>> that Facebook is somehow placing within China, despite our geolocation in
>> other databases showing up correctly as they're ingesting our geofeeds as
>> we had requested.
>>
>> Does anyone know which geolocation databases Facebook uses, and if
>> possible a contact at Meta we can reach out to so that this can be
>> investigated further?
>>
>> Thanks in advance!
>>
>> Regards,
>> Peter Potvin | Executive Director
>>
>> --
>> *Accuris Technologies Ltd.*
>>
>

Facebook IP Geolocation

[Peter Potvin via NANOG]

Hey all,

Recently a customer reached out to us regarding an IP of ours in Canada
that Facebook is somehow placing within China, despite our geolocation in
other databases showing up correctly as they're ingesting our geofeeds as
we had requested.

Does anyone know which geolocation databases Facebook uses, and if possible
a contact at Meta we can reach out to so that this can be investigated
further?

Thanks in advance!

Regards,
Peter Potvin | Executive Director
--
*Accuris Technologies Ltd.*

Re: ROA Will Expire Soon - ARIN

[Peter Potvin via NANOG]

I have been wondering the same thing when it comes to how ARIN's hosted
RPKI ROAs handle renewal. Do they automatically renew by default, do we
need to delete and re-create the ROA or do we have to reach out to the
helpdesk every time one is due to expire?

~ Peter

On Fri., Sep. 9, 2022, 10:12 a.m. Ca By,  wrote:

>
>
> On Fri, Sep 9, 2022 at 5:21 AM John Sweeting  wrote:
>
>> You can contact the ARIN Helpdesk at +1-703-227-0660. Someone will also
>> be sending you an email off list.
>>
>
> John
>
> Where is ARIN’s documented procedure for how hosted ROAs handle renewal
> prior to expiration ?
>
>
>
>> Sent from my iPhone
>>
>> > On Sep 9, 2022, at 8:01 AM, Terrance Devor  wrote:
>> >
>> > 
>> > Can someone from ARIN please reach out to me. We don't want the ROA to
>> expire...
>> >
>> > Kind Regards,
>> > Terrance
>>
>

-- 
The information contained in this message may be privileged, confidential 
and protected from disclosure. This message is intended only for the 
designated recipient(s). It is subject to access, review and disclosure by 
the sender's Email System Administrator. If you have received this message 
in error, please advise by return e-mail so that our address records can be 
corrected and please delete immediately without reading, copying or 
forwarding to others. Any unauthorized review, use, disclosure or 
distribution is prohibited.
Copyright © 2022 Accuris Technologies Ltd. All 
Rights Reserved.


L'information contenue dans ce message pourrait être de 
nature privilégiée, confidentielle et protégée contre toute divulgation. Ce 
message est destiné à l'usage exclusif du(des) destinataire(s) visé(s). Le 
gestionnaire de système du courrier électronique de l'expéditeur pourrait 
avoir accès à ce message, l'examiner et le divulguer. Si ce message vous 
est transmis par erreur, veuillez nous en aviser par courrier électronique 
à notre adresse, afin que l'on puisse corriger nos registres, puis veuillez 
le supprimer immédiatement, sans le lire, le copier ou le transmettre à des 
tiers. Tout examen, toute utilisation, divulgation ou distribution non 
autorisé de cette information est interdit.
Droit d'auteur © 

2022 
Accuris Technologies Ltd. Tous droits réservés.

Re: cogent and henet not peering

[Peter Potvin via NANOG]

Hey all,

Removing Cogent personnel and peering departments from this thread as I'm
sure they don't appreciate the nonsense coming from this list.

Regards,
Peter Potvin | Executive Director
--
*Accuris Technologies Ltd.*
11-300 Earl Grey Drive, Suite #124, Kanata, Ontario K2T1C1 Canada
Email: peter.pot...@accuristechnologies.ca
Office: +1 (877) 352-6105
Network Operations Centre: +1 (877) 321-1662


On Sat, Aug 20, 2022 at 8:51 PM VOLKAN KIRIK  wrote:

> yea whatever..
>
>  its upto mike leber and dave schaeffer to decide. they can either accept
> or reject the solution
>
> I have been always believing content creator/provider should pay expenses
> (at least excess traffic).
>
> because they put their server in some datacenter and reach all of the
> internet.. their backbone expenses are less..
>
> i can understand that todays datacenters including he.net are interested
> to participate in 200-300 IXPs.
>
> well that acceptable. it should be considered too
>
> so i would offer both companies 3 cent per mbps for excess traffic.
>
> ok bye
>
>
> 21.08.2022 03:25 tarihinde Forrest Christian (List Account) yazdı:
>
> But that traffic was likely requested by and for the benefit of the person
> the traffic is being sent to.
>
> I've always found the argument that the quantity of traffic is the
> indicator of who should pay to be questionable.
>
> If I'm an end user on an eyeball user and request a big download or
> streaming from a provider, isn't it me that caused that traffic to flow?
> One could argue that I am the one that needs to pay.
>
> On the other hand, one could argue that it's the provider of the content
> that I requested that needs to pay, since it's their content which is being
> distributed.
>
> When you get to peering between two providers it's almost impossible to
> decide who needs to pay.As I mentioned above, passing that traffic is
> actually to the benefit of both providers.
>
> About the only settlement I could see is where one of the providers is
> bearing most of the transport costs.  For example a regional provider only
> peering at one exchange point might expect some settlement costs with a big
> international provider that is effectively carrying their traffic both
> directions around the globe.  But the quantity of that type of traffic is
> likely minimal in the grand scheme of things. Even then one might argue
> that connectivity to the small provider is still valuable to the customers
> of the large provider.
>
> On Fri, Aug 19, 2022, 9:32 AM VOLKAN KIRIK  wrote:
>
>> the more uploading side pays each month for the excess amount.
>>
>> as content networks are supposed to pay expenses.
>>
>>
>> what do you think?
>>
>>
>> 19.08.2022 18:28 tarihinde Mike Hammett yazdı:
>>
>> The problem them becomes *who* pays? When do the tables turn as to who
>> pays?
>>
>> The alpha gets paid and the beta does the paying?
>>
>> The network with more POPs gets paid?
>>
>> The network with more downstream ASes gets paid?
>>
>> Is it the same for IPv4 as it is for IPv6?
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions 
>> 
>> 
>> 
>> 
>> Midwest Internet Exchange 
>> 
>> 
>> 
>> The Brothers WISP 
>> 
>> 
>> --
>> *From: *"VOLKAN KIRIK"  
>> *To: *"Rubens Kuhl"  
>> *Cc: *nanog@nanog.org, dschaef...@cogentco.com, peer...@cogentco.com
>> *Sent: *Friday, August 19, 2022 10:22:00 AM
>> *Subject: *Re: cogent and henet not peering
>>
>> this is 50/50 situation. nobody has to peer for free.
>>
>> but everyone can.
>>
>> lets just say above 1:1 ratio he.net pays their own ip transit price to
>> cogent for paid peering excess amount and both sides monitor traffic
>>
>> we can solve this issue by becoming middlemen worldwide...
>>
>> both operators are cheap and they could all compete in quality.
>>
>> level3 pays comcast reasonable (cheap) price (under NDA maybe?). why
>> wouldnt mleber?
>>
>> but to make it fair, as he.net becomes ww tier-1 operator day-by-day,
>> lets just limit pricing to excess amount of traffic
>>
>> thanks for reading
>>
>> would appreciate your support
>>
>>
>> 19.08.2022 18:09 tarihinde Rubens Kuhl yazdı:
>>
>> OTOH, knowing that Cogent loves splitting the global Internet is one
>> good reason to not contract their services.
>> I think they sell traffic to their private Intranet. Which is huge,
>> but doesn't encompass the whole Internet.
>>
>>
>> Rubens
>>
>> On 

Re: Test email

[Peter Potvin via NANOG]

Why did moderation let this through the filters? I don't believe that
testing email functionality is the intended use case of the NANOG mailing
list.

Also worth noting that the website for the domain this came from says the
owner of the site specializes in "anti-spam", which based on this email
alone doesn't look to be the case. Anyone else agree?

Regards,
Peter


On Mon., Jun. 20, 2022, 4:15 a.m. ,  wrote:

>
> Hello,
>
> Checking Email Functionality.
>
> Hosting Support
> Thank you,
>

-- 
The information contained in this message may be privileged, confidential 
and protected from disclosure. This message is intended only for the 
designated recipient(s). It is subject to access, review and disclosure by 
the sender's Email System Administrator. If you have received this message 
in error, please advise by return e-mail so that our address records can be 
corrected and please delete immediately without reading, copying or 
forwarding to others. Any unauthorized review, use, disclosure or 
distribution is prohibited.
Copyright © 2022 Accuris Technologies Ltd. All 
Rights Reserved.


L'information contenue dans ce message pourrait être de 
nature privilégiée, confidentielle et protégée contre toute divulgation. Ce 
message est destiné à l'usage exclusif du(des) destinataire(s) visé(s). Le 
gestionnaire de système du courrier électronique de l'expéditeur pourrait 
avoir accès à ce message, l'examiner et le divulguer. Si ce message vous 
est transmis par erreur, veuillez nous en aviser par courrier électronique 
à notre adresse, afin que l'on puisse corriger nos registres, puis veuillez 
le supprimer immédiatement, sans le lire, le copier ou le transmettre à des 
tiers. Tout examen, toute utilisation, divulgation ou distribution non 
autorisé de cette information est interdit.
Droit d'auteur © 

2022 
Accuris Technologies Ltd. Tous droits réservés.

Re: Bgpmon alternative

[Peter Potvin via NANOG]

I second this recommendation, I use BGPalerter for all of my BGP
announcement and RPKI monitoring. It is a great application to have added
to any Network Operator's toolkit.

Regards,
Peter

On Wed., Jun. 15, 2022, 9:55 a.m. Job Snijders via NANOG, 
wrote:

> Hi,
>
> I recommend taking a look at
> https://github.com/nttgin/BGPalerter
>
> https://www.lacnic.net/innovaportal/file/4489/1/bgpalerter_lacnic33.pdf
>
> It offers a great blend of BGP and RPKI ROA monitoring
>
> Kind regards,
>
> Job
>
> On Wed, 15 Jun 2022 at 16:45, Mehmet Akcin  wrote:
>
>> Hi there
>>
>> What are the best alternatives to BGPmon these days?
>>
>> Goal is to try to monitor bgp routing changes for specific prefixes.
>>
>> Mehmet
>> --
>> Mehmet
>> +1-424-298-1903
>>
>

-- 
The information contained in this message may be privileged, confidential 
and protected from disclosure. This message is intended only for the 
designated recipient(s). It is subject to access, review and disclosure by 
the sender's Email System Administrator. If you have received this message 
in error, please advise by return e-mail so that our address records can be 
corrected and please delete immediately without reading, copying or 
forwarding to others. Any unauthorized review, use, disclosure or 
distribution is prohibited.
Copyright © 2022 Accuris Technologies Ltd. All 
Rights Reserved.


L'information contenue dans ce message pourrait être de 
nature privilégiée, confidentielle et protégée contre toute divulgation. Ce 
message est destiné à l'usage exclusif du(des) destinataire(s) visé(s). Le 
gestionnaire de système du courrier électronique de l'expéditeur pourrait 
avoir accès à ce message, l'examiner et le divulguer. Si ce message vous 
est transmis par erreur, veuillez nous en aviser par courrier électronique 
à notre adresse, afin que l'on puisse corriger nos registres, puis veuillez 
le supprimer immédiatement, sans le lire, le copier ou le transmettre à des 
tiers. Tout examen, toute utilisation, divulgation ou distribution non 
autorisé de cette information est interdit.
Droit d'auteur © 

2022 
Accuris Technologies Ltd. Tous droits réservés.

Re: Cogent & Google reachability stable?

[Peter Potvin via NANOG]

I've had zero issues reaching Google via Cogent, however Google didn't pick
up transit from Cogent themselves: They got transit from Tata, which makes
them reachable via Cogent due to the peering relationship between Cogent
and Tata.

Regards,
Peter

On Wed, Jun 8, 2022 at 6:45 PM David Hubbard 
wrote:

> It seemed like a decade in the making but has the IPv6 transit between
> Cogent and Google (via that showed up last fall remained stable?  I’d ruled
> them out on a number of projects for this reason but may reconsider if it
> has been reliable.  Appears HE (ASN6939) is still unreachable though…  I
> feel like less entities are single homed to HE, but it would still be a
> calculated risk.
>
>
>
> Thanks,
>
> David
>

-- 
The information contained in this message may be privileged, confidential 
and protected from disclosure. This message is intended only for the 
designated recipient(s). It is subject to access, review and disclosure by 
the sender's Email System Administrator. If you have received this message 
in error, please advise by return e-mail so that our address records can be 
corrected and please delete immediately without reading, copying or 
forwarding to others. Any unauthorized review, use, disclosure or 
distribution is prohibited.
Copyright © 2022 Accuris Technologies Ltd. All 
Rights Reserved.


L'information contenue dans ce message pourrait être de 
nature privilégiée, confidentielle et protégée contre toute divulgation. Ce 
message est destiné à l'usage exclusif du(des) destinataire(s) visé(s). Le 
gestionnaire de système du courrier électronique de l'expéditeur pourrait 
avoir accès à ce message, l'examiner et le divulguer. Si ce message vous 
est transmis par erreur, veuillez nous en aviser par courrier électronique 
à notre adresse, afin que l'on puisse corriger nos registres, puis veuillez 
le supprimer immédiatement, sans le lire, le copier ou le transmettre à des 
tiers. Tout examen, toute utilisation, divulgation ou distribution non 
autorisé de cette information est interdit.
Droit d'auteur © 

2022 
Accuris Technologies Ltd. Tous droits réservés.

Re: Announcement of Experiments

[Peter Potvin via NANOG]

In my honest opinion, it's the fact that they're going to be using random
AS's without prior consent from those that hold said AS's, and only giving
operators a week to opt-out of something that they never opted into in the
first place.

Regards,
Peter

On Mon, May 2, 2022 at 2:10 PM Lars Prehn  wrote:

> Short Disclaimer: I frequently use the PEERING testbed myself, so I'm
> genuinely interested in where and why people draw the boundary of what's
> fine and what's not.
>
> Iirc., the route collectors see a (drastically varying) number of
> poisoned routes (assuming everything within a loop is poisoning) in the
> DFZ at any point in time, affecting a (drastically varying) number of
> ASNs, prefixes, and paths. So why would you expect this experiment to be
> noticeable at all---I mean, compared to the day-to-day, "1% of the
> Internet is beyond broken and does Yolo things" noise? Very similar
> experiments have run in the past (e.g., [1] in 2018); did you notice them?
>
> Would poisoning be tolerated if the PEERING testbed would be, e.g., some
> security-obsessed org that wants to avoid that your infrastructure
> touches any of its precious packets during the forwarding process? I
> guess what I want to figure out is: Is it the intention behind the
> poisoning experiments that bothers people or is the act of poisoning
> itself?
>
> Kind regards,
> Lars
>
> [1] https://arxiv.org/pdf/1811.03716.pdf
>
> On 02.05.22 16:33, Raymond Dijkxhoorn via NANOG wrote:
> > Hi!
> >
> >> > If I am interpreting this correctly that you are just going to yolo a
> >> > bunch of random ASNs to poison paths with, perhaps you should consider
> >> > getting explicit permission for the ASNs you want to use instead.
> >> >
> >> > A lot of operators monitor the DFZ for prefixes with their ASN in the
> >> > path, and wouldn't appreciate random support tickets because their NOC
> >> > got some alert. :)
> >
> >> Exatly that. How about you ask people to OPT-IN instead of you wanting
> >> people to OPT-OUT of whatever experiment you feel you need to do with
> >> other people's resources.
> >
> >> When you the last time you asked the entire internet?s  permission to
> >> announce routes ?
> >
> > I dont exactly understand what you try to say its not about the route
> > its about the path.
> >
> > If the insert 'my ASN' i certainly will complain wherever i can and no
> > i will not opt out from that. I will assume they just do use my ASN.
> > Weird thought?
> >
> > Bye, Raymond
>

-- 
The information contained in this message may be privileged, confidential 
and protected from disclosure. This message is intended only for the 
designated recipient(s). It is subject to access, review and disclosure by 
the sender's Email System Administrator. If you have received this message 
in error, please advise by return e-mail so that our address records can be 
corrected and please delete immediately without reading, copying or 
forwarding to others. Any unauthorized review, use, disclosure or 
distribution is prohibited.
Copyright © 2022 Accuris Technologies Ltd. All 
Rights Reserved.


L'information contenue dans ce message pourrait être de 
nature privilégiée, confidentielle et protégée contre toute divulgation. Ce 
message est destiné à l'usage exclusif du(des) destinataire(s) visé(s). Le 
gestionnaire de système du courrier électronique de l'expéditeur pourrait 
avoir accès à ce message, l'examiner et le divulguer. Si ce message vous 
est transmis par erreur, veuillez nous en aviser par courrier électronique 
à notre adresse, afin que l'on puisse corriger nos registres, puis veuillez 
le supprimer immédiatement, sans le lire, le copier ou le transmettre à des 
tiers. Tout examen, toute utilisation, divulgation ou distribution non 
autorisé de cette information est interdit.
Droit d'auteur © 

2022 
Accuris Technologies Ltd. Tous droits réservés.

Re: Routes to twitter via 8359 8359 8342

[Peter Potvin via NANOG]

I'm seeing the same thing from my edge routers in Toronto and New York but
am discarding the route on each due to it being RPKI invalid. Looks like a
potential hijack by a Russian ISP based on the origin ASN.

NLNOG RING also shows some of their peers accepting the invalid
announcement while others are accepting the correct one.
https://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=104.244.42.0/24

Regards,
Peter Potvin

On Mon., Mar. 28, 2022, 8:36 a.m. Drew Weaver, 
wrote:

> Is anyone else seeing this route destined for Twitter in the US being
> directed through 8359 announced by 8342?
>
>
>
> 104.244.42.0/24
>
>
>
> Just curious, replies off list welcome.
>
>
>
> -Drew
>
>
>
>
>
>
>

-- 
The information contained in this message may be privileged, confidential 
and protected from disclosure. This message is intended only for the 
designated recipient(s). It is subject to access, review and disclosure by 
the sender's Email System Administrator. If you have received this message 
in error, please advise by return e-mail so that our address records can be 
corrected and please delete immediately without reading, copying or 
forwarding to others. Any unauthorized review, use, disclosure or 
distribution is prohibited.
Copyright © 2022 Accuris Technologies Ltd. All 
Rights Reserved.


L'information contenue dans ce message pourrait être de 
nature privilégiée, confidentielle et protégée contre toute divulgation. Ce 
message est destiné à l'usage exclusif du(des) destinataire(s) visé(s). Le 
gestionnaire de système du courrier électronique de l'expéditeur pourrait 
avoir accès à ce message, l'examiner et le divulguer. Si ce message vous 
est transmis par erreur, veuillez nous en aviser par courrier électronique 
à notre adresse, afin que l'on puisse corriger nos registres, puis veuillez 
le supprimer immédiatement, sans le lire, le copier ou le transmettre à des 
tiers. Tout examen, toute utilisation, divulgation ou distribution non 
autorisé de cette information est interdit.
Droit d'auteur © 

2022 
Accuris Technologies Ltd. Tous droits réservés.

Re: "Permanent" DST

[Peter Potvin via NANOG]

>
> 2) Move every square inch of US territory 15 degrees to the east.


Mind if I ask where you got this? Nowhere can I find an article or bill
referencing this specific point. This article

references a Senate bill from March 9th 2021
 that
makes no mention of this point at all.

Regards,
Peter

On Tue, Mar 15, 2022 at 3:14 PM Jay R. Ashworth  wrote:

> In a unanimous vote today, the US Senate approved a bill which would
>
> 1) Cancel DST permanently, and
> 2) Move every square inch of US territory 15 degrees to the east.
>
> My opinion of this ought to be obvious from my rhetoric.  Hopefully, it
> will
> fail, because it's likely to be the end of rational time worldwide, and
> even
> if you do log in UTC, it will still make your life difficult.
>
> I'm poleaxed; I can't even decide which grounds to scream about this on...
>
> Hopefully, the House or the White House will be more coherent in their
> decision on this engineering construct.
>
> Cheers,
> -- jra
>
> --
> Jay R. Ashworth  Baylink
> j...@baylink.com
> Designer The Things I Think   RFC
> 2100
> Ashworth & Associates   http://www.bcp38.info  2000 Land
> Rover DII
> St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647
> 1274
>

-- 
The information contained in this message may be privileged, confidential 
and protected from disclosure. This message is intended only for the 
designated recipient(s). It is subject to access, review and disclosure by 
the sender's Email System Administrator. If you have received this message 
in error, please advise by return e-mail so that our address records can be 
corrected and please delete immediately without reading, copying or 
forwarding to others. Any unauthorized review, use, disclosure or 
distribution is prohibited.
Copyright © 2022 Accuris Technologies Ltd. All 
Rights Reserved.


L'information contenue dans ce message pourrait être de 
nature privilégiée, confidentielle et protégée contre toute divulgation. Ce 
message est destiné à l'usage exclusif du(des) destinataire(s) visé(s). Le 
gestionnaire de système du courrier électronique de l'expéditeur pourrait 
avoir accès à ce message, l'examiner et le divulguer. Si ce message vous 
est transmis par erreur, veuillez nous en aviser par courrier électronique 
à notre adresse, afin que l'on puisse corriger nos registres, puis veuillez 
le supprimer immédiatement, sans le lire, le copier ou le transmettre à des 
tiers. Tout examen, toute utilisation, divulgation ou distribution non 
autorisé de cette information est interdit.
Droit d'auteur © 

2022 
Accuris Technologies Ltd. Tous droits réservés.

Re: Geolocation Data : MAX MIND - Out of Sync

[Peter Potvin via NANOG]

Hey Paschal,

I've had this same issue previously with some geolocation DBs not
reflecting locations correctly. I managed to fix the issue by maintaining a
public RFC8805  geofeed and
submitting it to the various DB providers via email and allowing them to
poll it frequently for any updates. Here are a majority of the emails you
would need to contact with your published geofeed, if you choose to
implement one:

   - supp...@db-ip.com
   - supp...@ip2location.com
   - supp...@ipgeolocation.io
   - correct...@maxmind.com
   - ip-d...@digitalenvoy.net
   - ipintel@support.neustar
   - priv...@ipapi.co
   - supp...@bigdatacloud.com

Feel free to use the following template using the subject of "Geofeed for
" which I successfully used to have the above providers update their
databases (with a majority of updates published within a week or so):

Hello,
>
> Please use this geofeed for our IPs going forward.
>
> 
>
> Thanks.


Hope this information helps accomplish what you need!

Regards,
Peter

On Mon, Mar 14, 2022 at 6:09 AM Paschal Masha 
wrote:

> Hello,
>
> Not sure whether anyone out there is also experiencing this, seems MAX
> MIND (https://www.maxmind.com/en/geoip2-precision-demo
> ) geo database is
> extremely out of sync with whois records on RIRs DBs.
>
> It's ok(not 100%) to submit corrections for a few(if not less than few)
> blocks, but getting it all wrong for more that 4 to many blocks- that's a
> big deal..especially when other services( like, whatsmyip), believe you
> more that other DBs
>
> e.g 102.217.58.0/24 an AFRNIC allocation, appears in Turkey on MAX MIND,
> while ip2location and other geoDBs correctly displays this.
>
> IS there anyone- with power- from MAX MIND in this list that can help out?
> Please contact me offlist - sorry for the broadcast to the other members.
>
> Regards
> Paschal Masha | Engineering
> Skype ID: paschal.masha
>
>
>

-- 
The information contained in this message may be privileged, confidential 
and protected from disclosure. This message is intended only for the 
designated recipient(s). It is subject to access, review and disclosure by 
the sender's Email System Administrator. If you have received this message 
in error, please advise by return e-mail so that our address records can be 
corrected and please delete immediately without reading, copying or 
forwarding to others. Any unauthorized review, use, disclosure or 
distribution is prohibited.
Copyright © 2022 Accuris Technologies Ltd. All 
Rights Reserved.


L'information contenue dans ce message pourrait être de 
nature privilégiée, confidentielle et protégée contre toute divulgation. Ce 
message est destiné à l'usage exclusif du(des) destinataire(s) visé(s). Le 
gestionnaire de système du courrier électronique de l'expéditeur pourrait 
avoir accès à ce message, l'examiner et le divulguer. Si ce message vous 
est transmis par erreur, veuillez nous en aviser par courrier électronique 
à notre adresse, afin que l'on puisse corriger nos registres, puis veuillez 
le supprimer immédiatement, sans le lire, le copier ou le transmettre à des 
tiers. Tout examen, toute utilisation, divulgation ou distribution non 
autorisé de cette information est interdit.
Droit d'auteur © 

2022 
Accuris Technologies Ltd. Tous droits réservés.

Re: Docusign

[Peter Potvin via NANOG]

 Hey Bruno,

Would be better to describe what you're looking for instead of just asking
if someone from Docusign is here, that way if they are here or if someone
passes on your message to them they know what you need. Just my 2c.

Regards,
Peter

On Mon, Mar 14, 2022 at 11:29 AM Bruno Vane  wrote:

> Hello,
>
> Anyone from Docusign here?
>

-- 
The information contained in this message may be privileged, confidential 
and protected from disclosure. This message is intended only for the 
designated recipient(s). It is subject to access, review and disclosure by 
the sender's Email System Administrator. If you have received this message 
in error, please advise by return e-mail so that our address records can be 
corrected and please delete immediately without reading, copying or 
forwarding to others. Any unauthorized review, use, disclosure or 
distribution is prohibited.
Copyright © 2022 Accuris Technologies Ltd. All 
Rights Reserved.


L'information contenue dans ce message pourrait être de 
nature privilégiée, confidentielle et protégée contre toute divulgation. Ce 
message est destiné à l'usage exclusif du(des) destinataire(s) visé(s). Le 
gestionnaire de système du courrier électronique de l'expéditeur pourrait 
avoir accès à ce message, l'examiner et le divulguer. Si ce message vous 
est transmis par erreur, veuillez nous en aviser par courrier électronique 
à notre adresse, afin que l'on puisse corriger nos registres, puis veuillez 
le supprimer immédiatement, sans le lire, le copier ou le transmettre à des 
tiers. Tout examen, toute utilisation, divulgation ou distribution non 
autorisé de cette information est interdit.
Droit d'auteur © 

2022 
Accuris Technologies Ltd. Tous droits réservés.

Re: Can it really be this quiet?

[Peter Potvin via NANOG]

Q4 of 2021 is over, I think that the list is taking a well-deserved 
break (if you know what I mean).


Jokes aside, this is the first time I've really seen the NANOG list this 
quiet which is great news meaning everything is a-OK. Happy New Year 
everyone, hope you all have a safe one!


Regards,
Peter Potvin | Executive Director
--
Accuris Technologies Ltd.
11-300 Earl Grey Drive, Suite #124, Kanata, Ontario K2T1C1 Canada
Email: peter.pot...@accuristechnologies.ca
Office: +1 (877) 352-6105

On 2022-01-03 2:52 p.m., Douglas Vought via NANOG wrote:

On 1/3/2022 2:46 PM, Allen McKinley Kitchen (gmail) wrote:


Or has NANOG also succumbed to a signed-integer date problem?

Waiting to see what I get back..

..Allen


The integers are fine. That said, every mailing list I'm in is eerily 
quiet.


OpenPGP_0x8FDB92430D85B940.asc
Description: OpenPGP public key