ServiceNow

[Mann, Jason via NANOG]

Anyone else having issues getting to service now? We use it for ticketing: 
montana.servicenowservices.com [149.96.184.230]. Im not seeing it in our 
internet routers nor on a couple of looking glass servers.

Re: BendTel ASN27008 moving router tonight

[Tim Howe]

On Tue, 30 Aug 2022 10:37:40 -0700
Tim Howe  wrote:

> Between 9 and 11pm tonight our colo provider must move our router to a
> new rack.
> I'll shut down bgp a bit after 9pm and then restore once I verify the
> router is back up correctly and interfaces are normalized.
> 

Everything appears back up and normalized.

-- 
Tim Howe   ti...@bendtel.com
Data Processing541-389-8252
BendTelGPG pubkey id: CBDE9FFE

Re: RFC: BOGONs over BGP, adding some ranges

[Dave Taht]

On Tue, Aug 30, 2022 at 10:17 AM James Shank  wrote:
>
> Dear NANOG!
>
> As many of you know, Team Cymru runs a free service delivering updated
> BOGONS to networks around the world. We've been doing this for decades
> at this point. For more information about this service, please see
> https://www.team-cymru.com/bogon.
>
> Recently, we've discussed internally a discrepancy between our BGP based
> feed and the other formats we deliver for our Traditional BOGONS feed.
> For historic reasons, we previously omitted delivery of some ranges that
> are BOGONS from our BGP advertisements. We are considering adding the
> below ranges back in, but want to hear feedback from the community on
> these ranges prior to advertising them, out of an abundance of caution.
>
> The below ranges are what we are currently considering advertising:
> 0/8 (this one we already have concluded is safe as it is already
> advertised in our "FULL BOGONS" set.)
> 127/8
> 224/4
> 240/4
>
> Note that 224/4 and 240/4 may be aggregated differently in our
> advertisement, but are broken out here to facilitate discussion.

I would like to make an effort to debogon 240/4 at least, or have an
authorized experiment to at least determine how fully bogon'd it is.

Some recent data about amazon and verizon:

https://labs.ripe.net/author/qasim-lone/2404-as-seen-by-ripe-atlas/

One question for me is how many folks rely on regular bogon updates
such as yours. There are others.

> So, fellow NANOGers, what say ye? I would love to hear your feedback,
> pro or con, well-reasoned with data points or general "argh! there be
> dragons!" sentiments.
>
> Looking forward to seeing folks in Hollywood for N86!
>
> Cheers!
>
> James
>
> --
> *James Shank*
> Chief Architect of Community Services and Sr. Security Evangelist
> e: jsh...@cymru.com
> o: +1 847 378-3365
>


-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC

Re: RFC: BOGONs over BGP, adding some ranges

[Glenn Kelley]

I would love to see this via BGP personally
Not sure of anything that it could cause  - and folks could filter out
something if needed/required



*Glenn S. Kelley, *I am a Connectivity.Engineer
Text and Voice Direct:  740-206-9624


a Division of CreatingNet.Works 
IMPORTANT: The contents of this email and any attachments are confidential.
They are intended for the named recipient(s) only. If you have received
this email by mistake, please notify Glenn Kelley, the sender, immediately
and do not disclose the contents to anyone or make copies thereof.


On Tue, Aug 30, 2022 at 12:15 PM James Shank  wrote:

> Dear NANOG!
>
> As many of you know, Team Cymru runs a free service delivering updated
> BOGONS to networks around the world. We've been doing this for decades
> at this point. For more information about this service, please see
> https://www.team-cymru.com/bogon.
>
> Recently, we've discussed internally a discrepancy between our BGP based
> feed and the other formats we deliver for our Traditional BOGONS feed.
> For historic reasons, we previously omitted delivery of some ranges that
> are BOGONS from our BGP advertisements. We are considering adding the
> below ranges back in, but want to hear feedback from the community on
> these ranges prior to advertising them, out of an abundance of caution.
>
> The below ranges are what we are currently considering advertising:
> 0/8 (this one we already have concluded is safe as it is already
> advertised in our "FULL BOGONS" set.)
> 127/8
> 224/4
> 240/4
>
> Note that 224/4 and 240/4 may be aggregated differently in our
> advertisement, but are broken out here to facilitate discussion.
>
> So, fellow NANOGers, what say ye? I would love to hear your feedback,
> pro or con, well-reasoned with data points or general "argh! there be
> dragons!" sentiments.
>
> Looking forward to seeing folks in Hollywood for N86!
>
> Cheers!
>
> James
>
> --
> *James Shank*
> Chief Architect of Community Services and Sr. Security Evangelist
> e: jsh...@cymru.com
> o: +1 847 378-3365
>
>

Re: RFC: BOGONs over BGP, adding some ranges

[James Shank]

Hi John!

Thanks for the comments!

If you're in Hollywood for N86, perhaps we can pour one our for 
multicast together... ;)


Cheers!

James

On 8/30/22 4:21 PM, John Kristoff wrote:

On Tue, 30 Aug 2022 13:15:40 -0400
James Shank  wrote:


224/4

If any were to cause a problem, I'd think this is the one that would be
most likely.  While inter-domain IP multicast is practically dead and
so the impact might not be so great (sorry multicast-wg and mboned
friends), there may be pockets of RP and link-local and site-local
GLOP-like things (e.g., for system imaging) things that I could imagine
might break.  Then again, break it, break it in a million little pieces,
ip.idr-multicast.die.die.die! :-)

John


--
*James Shank*
Chief Architect of Community Services and Sr. Security Evangelist
e: jsh...@cymru.com
o: +1 847 378-3365

Re: Providing geofeed info to Google

[Hugo Slabbert]

Good call, thanks. That appears to be via the assigned resources bit ("IP
Addresses" heading in Arin Online). Will give that a shot, thanks!

-- 
Hugo Slabbert


On Tue, Aug 30, 2022 at 1:38 PM Job Snijders  wrote:

> On Tue, Aug 30, 2022 at 01:28:18PM -0700, Hugo Slabbert wrote:
> > @Job:
> >
> > Thanks! I was aware of the RIPE whois option, but the relevant resources
> > for us are in ARIN.  I wasn't aware of the RPSL *remark* option for
> > providing that.  We should be able to give that a bash.
>
> Hmmm, there might be an obstacle due to lack of inetnum support in ARIN:
> https://www.arin.net/participate/community/acsp/suggestions/2021/2021-27/
>
> However there is good news: the last paragraph of RFC 9092 section 3
> suggests a workaround specific to ARIN:
>
> "Currently, the registry data published by ARIN are not the same
> RPSL as that of the other registries (see [RFC7485] for a survey
> of the WHOIS Tower of Babel); therefore, when fetching from ARIN
> via FTP [RFC0959], WHOIS [RFC3912], the Registration Data Access
> Protocol (RDAP) [RFC9082], etc., the "NetRange" attribute/key
> MUST be treated as "inetnum", and the "Comment" attribute MUST
> be treated as "remarks".
>
> Perhaps you insert a "Comment: Geofeed https://xxx/geofeed.csv; in the
> place where NetRange blobs come from?
>
> Kind regards,
>
> Job
>

Re: Providing geofeed info to Google

[Job Snijders via NANOG]

On Tue, Aug 30, 2022 at 01:28:18PM -0700, Hugo Slabbert wrote:
> @Job:
> 
> Thanks! I was aware of the RIPE whois option, but the relevant resources
> for us are in ARIN.  I wasn't aware of the RPSL *remark* option for
> providing that.  We should be able to give that a bash.

Hmmm, there might be an obstacle due to lack of inetnum support in ARIN:
https://www.arin.net/participate/community/acsp/suggestions/2021/2021-27/

However there is good news: the last paragraph of RFC 9092 section 3
suggests a workaround specific to ARIN:

"Currently, the registry data published by ARIN are not the same
RPSL as that of the other registries (see [RFC7485] for a survey
of the WHOIS Tower of Babel); therefore, when fetching from ARIN
via FTP [RFC0959], WHOIS [RFC3912], the Registration Data Access
Protocol (RDAP) [RFC9082], etc., the "NetRange" attribute/key
MUST be treated as "inetnum", and the "Comment" attribute MUST
be treated as "remarks".

Perhaps you insert a "Comment: Geofeed https://xxx/geofeed.csv; in the
place where NetRange blobs come from?

Kind regards,

Job

Re: Providing geofeed info to Google

[Hugo Slabbert]

Gonna multi-reply on this one:

@Benjamin:

> I was able to get access without peering with 15169 by getting access to
the ISP portal (isp.google.com) which does have Geofeed processing for my
AS, but I am unsure if you will get access without being an eyeball network.

Thanks; I'll give that bash. I think our org might have tried this
previously before my time, but will see where we get to.

@Christopher:

> For what it's worth I attempted to get access by filling out the same
portal and was told to go pound sand, so your results may very.

Good to know. :fingers-crossed:

@Job:

Thanks! I was aware of the RIPE whois option, but the relevant resources
for us are in ARIN.  I wasn't aware of the RPSL *remark* option for
providing that.  We should be able to give that a bash.

Can anyone confirm if Google respects the remark-based option?  Given the
authors and some of the wording, I would hope so?

-- 
Hugo Slabbert


On Tue, Aug 30, 2022 at 12:48 PM Job Snijders  wrote:

> Dear Hugo,
>
> On Tue, Aug 30, 2022 at 12:34:41PM -0700, Hugo Slabbert wrote:
> > Google folks:
> >
> > I see historical reference to needing to use the Google Peering Portal (
> > http://peering.google.com) if you need to provide Google with geofeed
> info
> > for GeoIP info on network blocks, ref
> > https://mailman.nanog.org/pipermail/nanog/2015-May/075229.html.
> >
> > Is that still the case?  Are there any avenues to provide Google with
> > geofeed info if you're *not* currently peering with 15169? Or to get
> access
> > to just the geofeed update portion of the Peering Portal?
>
> (I don't work for Google), but ...
>
> There is a RFC detailing how to find Geofeed data (and make Geofeed data
> findable): https://datatracker.ietf.org/doc/html/rfc9092
>
> The idea is that in inetnum/inet6num objects (which are maintained by
> the IP prefix holder), the holder can point to the location where
> Geofeed data can be found.
>
> There are a few methods:
>
> 1) Use the 'geofeed:' RPSL attribute (the RIPE Whois server supports
>this), example:
>
>$ whois -h whois.ripe.net 146.75.0.0/16 | grep geofeed
>geofeed:https://ip-geolocation.fastly.com/
>
> 2) A slightly uglier hack: stick a reference to the Geofeed location in
>a RPSL remark (should work in databases which don't (yet) support the
>'geofeed:' attribute), example:
>
>$ whois -h whois.ripe.net 2001:67c:208c::/48 | grep Geofeed
>remarks:Geofeed https://sobornost.net/geofeed.csv
>
> Kind regards,
>
> Job
>

Re: RFC: BOGONs over BGP, adding some ranges

[John Kristoff]

On Tue, 30 Aug 2022 13:15:40 -0400
James Shank  wrote:

> 224/4

If any were to cause a problem, I'd think this is the one that would be
most likely.  While inter-domain IP multicast is practically dead and
so the impact might not be so great (sorry multicast-wg and mboned
friends), there may be pockets of RP and link-local and site-local
GLOP-like things (e.g., for system imaging) things that I could imagine
might break.  Then again, break it, break it in a million little pieces,
ip.idr-multicast.die.die.die! :-)

John

Re: Providing geofeed info to Google

[Job Snijders via NANOG]

Dear Hugo,

On Tue, Aug 30, 2022 at 12:34:41PM -0700, Hugo Slabbert wrote:
> Google folks:
> 
> I see historical reference to needing to use the Google Peering Portal (
> http://peering.google.com) if you need to provide Google with geofeed info
> for GeoIP info on network blocks, ref
> https://mailman.nanog.org/pipermail/nanog/2015-May/075229.html.
> 
> Is that still the case?  Are there any avenues to provide Google with
> geofeed info if you're *not* currently peering with 15169? Or to get access
> to just the geofeed update portion of the Peering Portal?

(I don't work for Google), but ...

There is a RFC detailing how to find Geofeed data (and make Geofeed data
findable): https://datatracker.ietf.org/doc/html/rfc9092

The idea is that in inetnum/inet6num objects (which are maintained by
the IP prefix holder), the holder can point to the location where
Geofeed data can be found.

There are a few methods:

1) Use the 'geofeed:' RPSL attribute (the RIPE Whois server supports
   this), example:

   $ whois -h whois.ripe.net 146.75.0.0/16 | grep geofeed
   geofeed:https://ip-geolocation.fastly.com/

2) A slightly uglier hack: stick a reference to the Geofeed location in
   a RPSL remark (should work in databases which don't (yet) support the
   'geofeed:' attribute), example:

   $ whois -h whois.ripe.net 2001:67c:208c::/48 | grep Geofeed
   remarks:Geofeed https://sobornost.net/geofeed.csv

Kind regards,

Job

Re: Providing geofeed info to Google

[Christopher Munz-Michielin]

For what it's worth I attempted to get access by filling out the same 
portal and was told to go pound sand, so your results may very.


On 2022-08-30 12:40, Benjamin Hatton wrote:
I was able to get access without peering with 15169 by getting access 
to the ISP portal (isp.google.com ) which does 
have Geofeed processing for my AS, but I am unsure if you will get 
access without being an eyeball network.


On Tue, Aug 30, 2022 at 3:37 PM Hugo Slabbert  wrote:

Google folks:

I see historical reference to needing to use the Google Peering
Portal (http://peering.google.com) if you need to provide Google
with geofeed info for GeoIP info on network blocks, ref
https://mailman.nanog.org/pipermail/nanog/2015-May/075229.html.

Is that still the case?  Are there any avenues to provide Google
with geofeed info if you're *not* currently peering with 15169? Or
to get access to just the geofeed update portion of the Peering
Portal?

-- 
Hugo Slabbert

Re: Providing geofeed info to Google

[Benjamin Hatton]

I was able to get access without peering with 15169 by getting access to
the ISP portal (isp.google.com) which does have Geofeed processing for my
AS, but I am unsure if you will get access without being an eyeball network.

On Tue, Aug 30, 2022 at 3:37 PM Hugo Slabbert  wrote:

> Google folks:
>
> I see historical reference to needing to use the Google Peering Portal (
> http://peering.google.com) if you need to provide Google with geofeed
> info for GeoIP info on network blocks, ref
> https://mailman.nanog.org/pipermail/nanog/2015-May/075229.html.
>
> Is that still the case?  Are there any avenues to provide Google with
> geofeed info if you're *not* currently peering with 15169? Or to get access
> to just the geofeed update portion of the Peering Portal?
>
> --
> Hugo Slabbert
>

Providing geofeed info to Google

[Hugo Slabbert]

Google folks:

I see historical reference to needing to use the Google Peering Portal (
http://peering.google.com) if you need to provide Google with geofeed info
for GeoIP info on network blocks, ref
https://mailman.nanog.org/pipermail/nanog/2015-May/075229.html.

Is that still the case?  Are there any avenues to provide Google with
geofeed info if you're *not* currently peering with 15169? Or to get access
to just the geofeed update portion of the Peering Portal?

-- 
Hugo Slabbert

BendTel ASN27008 moving router tonight

[Tim Howe]

Between 9 and 11pm tonight our colo provider must move our router to a
new rack.
I'll shut down bgp a bit after 9pm and then restore once I verify the
router is back up correctly and interfaces are normalized.

-- 
Tim Howe   ti...@bendtel.com
Data Processing541-389-8252
BendTelGPG pubkey id: CBDE9FFE

RFC: BOGONs over BGP, adding some ranges

[James Shank]

Dear NANOG!

As many of you know, Team Cymru runs a free service delivering updated 
BOGONS to networks around the world. We've been doing this for decades 
at this point. For more information about this service, please see 
https://www.team-cymru.com/bogon.


Recently, we've discussed internally a discrepancy between our BGP based 
feed and the other formats we deliver for our Traditional BOGONS feed. 
For historic reasons, we previously omitted delivery of some ranges that 
are BOGONS from our BGP advertisements. We are considering adding the 
below ranges back in, but want to hear feedback from the community on 
these ranges prior to advertising them, out of an abundance of caution.


The below ranges are what we are currently considering advertising:
0/8 (this one we already have concluded is safe as it is already 
advertised in our "FULL BOGONS" set.)

127/8
224/4
240/4

Note that 224/4 and 240/4 may be aggregated differently in our 
advertisement, but are broken out here to facilitate discussion.


So, fellow NANOGers, what say ye? I would love to hear your feedback, 
pro or con, well-reasoned with data points or general "argh! there be 
dragons!" sentiments.


Looking forward to seeing folks in Hollywood for N86!

Cheers!

James

--
*James Shank*
Chief Architect of Community Services and Sr. Security Evangelist
e: jsh...@cymru.com
o: +1 847 378-3365

Re: Amprnet? (was Re: [anti-abuse-wg] Yet another BGP hijacking towards AS16509)

[borg]

Yeah, ARDC sold part of it to Amazon. I doubt they even had right to do
so due to 44/8 was an legacy IP range.. ARIN allowed it.. All too shady.

Anyway, according to AMPRnet that range was unallocated, so no active
radio ham networks were at that range, so I doubt it was someone
from AMPRnet. Getting parts of 44/8 reannounced by different gw
than ucsd.edu is not that easy after all.

-- Original message --

From: Ellenor Agnes Bjornsdottir 
To: nanog@nanog.org
Subject: Amprnet? (was Re: [anti-abuse-wg] Yet another BGP hijacking towards
AS16509)
Date: Tue, 30 Aug 2022 04:13:24 +

Wasn't 44/8 the space for AMPRNet?

I looked it up and they sold part of it to Amazon. Ok. Got it.

Possible that a potential highjack could be a good faith radio ham who
hasn't somehow been updated on the sale of that space? Or more likely to
be a malicious highjack?

On 8/23/22 02:05, Siyuan Miao wrote:
> Amazon was only announcing 44.224.0.0/11  at first.
> 
> https://bgp.tools/prefix/44.235.216.0/24
> 
> On Tue, Aug 23, 2022 at 4:03 AM Ronald F. Guilmette
>  wrote:
> 
> In message
> ,
> Siyuan Miao  wrote:
> 
> >Hjacking didn't last too long. AWS started announcing a more specific
> >announcement to prevent hijacking around 3 hours later. Kudos to
> Amazon's
> >security team :-)
> 
> Sorry.  I'm missing something here.  If the hijack was of
> 44.235.216.0/24 , then
> how did AWS propagate a "more specific" than that?
> 
> 
> Regards,
> rfg
> 
> --
> 
> To unsubscribe from this mailing list, get a password reminder, or
> change your subscription options, please visit:
> https://lists.ripe.net/mailman/listinfo/anti-abuse-wg
>