Straight Talk Wireless Contact

[Joshua Pool via NANOG]

Does anyone have a network or admin contact for Straight Talk wireless?

Regards,
 Josh

Re: What's going on with AS147028?

[Ben Cox via NANOG]

I run bgp.tools (with it's own route collectors, that people should
totally feed :) https://bgp.tools/kb/setup-sessions ) but I feel like
I can add some insight here to what I think is happening with
AS147028.

I've had multiple issues with networks feeding me that also are on
LL-IX (https://www.peeringdb.com/ix/2343) or LL-HOST (Maybe? AS59947).

It appears (based on my discussions with a few of the offending
networks) that LL-IX or LL-HOST strips their own ASN (59947) from the
path when you take up a transit or maybe (i'm not sure) peer on their
route servers on LL-IX

When you combine this and exporting to projects like RouteViews/RIPE
RIS/bgp.tools, you get a peer graph that looks like the feeder ASN is
peering with... almost everyone who AS59947 peers with.

This has become so much of a problem (as I am slightly mad for getting
this kind of data right) that bgp.tools disallows sessions to be setup
if it looks like the AS either is upstreamed by AS59947 or has a port
with LL-IX, (with a message to email me)

The users who do email me, about 50% of them commit to adding the
AS59947 ASN back on, and I enable their ability to export to
bgp.tools.

Hope this clears things up! This exact AS has been the cause of many
frustrations for me for a while now!

On Tue, Jul 12, 2022 at 11:22 PM Mike Leber via NANOG  wrote:
>
> This kind of thing is a problem from time to time with the data we get
> from route collectors.
>
> When we see it we have to add the culprit ASN to a filter list we keep
> in bgp.he.net.
>
> It tends to be a repeat problem with some collectors and some ASNs.
>
> We haven't really figured out why people send junk routes to route
> collectors.
>
> The things we've seen aren't just route leaks.  We've seen a variety of
> AS path spoofing.
>
> We've already added this specific ASN to the filter list and pushed an
> update for bgp.he.net.
>
> Note, this email is specifically talking about routes received from
> route collectors and not routes operationally received by he.net via BGP
> sessions with actual networks.
>
> Mike.
>
> On 7/12/22 12:49 PM, Eric Dugas via NANOG wrote:
> > A friend of mine mentioned that both our Canadian ASNs were listed in
> > AS147028's peer list on https://bgp.he.net/AS147028 but we have no
> > adjacency to this network.
> >
> > Their peer count jumped from 1 in May 2022 to 1,800 and just a few
> > days ago jumped to 8,800. Beside NL-IX, all the IX they are listed on
> > are virtual IX with a few dozen "hobby networks".
> >
> > The only lead I have is they use HE as transit and they're pumping
> > back BGP feed to route collectors like RIPE RIS or Route Views with
> > routes stripped of HE's ASN.
> >
> > Eric
> >

Re: What's going on with AS147028?

[SteveYi Yo]

No reason to feed fake routes to route collectors.

Some BGP players (ASN Operator) like that, and make the AS number one in
stats.

[image: image.png]

Maybe someone knows bgp.tools, they also run route collectors but rejected
AS Number which joined LL-IX .
(This IXP removes the as-path and feeds to their rs client.)

I'm not targeting anyone, but feed fake route has no benefit, just vanity ;(

Best,
SteveYi Yo

Email: jackco...@steveyi.net
PGP: 114A A514 776D BEAF



On Wed, Jul 13, 2022 at 6:22 AM Mike Leber via NANOG 
wrote:

> This kind of thing is a problem from time to time with the data we get
> from route collectors.
>
> When we see it we have to add the culprit ASN to a filter list we keep
> in bgp.he.net.
>
> It tends to be a repeat problem with some collectors and some ASNs.
>
> We haven't really figured out why people send junk routes to route
> collectors.
>
> The things we've seen aren't just route leaks.  We've seen a variety of
> AS path spoofing.
>
> We've already added this specific ASN to the filter list and pushed an
> update for bgp.he.net.
>
> Note, this email is specifically talking about routes received from
> route collectors and not routes operationally received by he.net via BGP
> sessions with actual networks.
>
> Mike.
>
> On 7/12/22 12:49 PM, Eric Dugas via NANOG wrote:
> > A friend of mine mentioned that both our Canadian ASNs were listed in
> > AS147028's peer list on https://bgp.he.net/AS147028 but we have no
> > adjacency to this network.
> >
> > Their peer count jumped from 1 in May 2022 to 1,800 and just a few
> > days ago jumped to 8,800. Beside NL-IX, all the IX they are listed on
> > are virtual IX with a few dozen "hobby networks".
> >
> > The only lead I have is they use HE as transit and they're pumping
> > back BGP feed to route collectors like RIPE RIS or Route Views with
> > routes stripped of HE's ASN.
> >
> > Eric
> >
>

Re: What's going on with AS147028?

[August Yang via NANOG]

Just to name few others with the same issue.

AS140731
AS141011
AS141237

Best regards
August Yang

> On Jul 12, 2022, at 6:20 PM, Mike Leber via NANOG  wrote:
>
> This kind of thing is a problem from time to time with the data we get from 
> route collectors.
>
> When we see it we have to add the culprit ASN to a filter list we keep in 
> bgp.he.net.
>
> It tends to be a repeat problem with some collectors and some ASNs.
>
> We haven't really figured out why people send junk routes to route collectors.
>
> The things we've seen aren't just route leaks.  We've seen a variety of AS 
> path spoofing.
>
> We've already added this specific ASN to the filter list and pushed an update 
> for bgp.he.net.
>
> Note, this email is specifically talking about routes received from route 
> collectors and not routes operationally received by he.net via BGP sessions 
> with actual networks.
>
> Mike.
>
> On 7/12/22 12:49 PM, Eric Dugas via NANOG wrote:
>> A friend of mine mentioned that both our Canadian ASNs were listed in 
>> AS147028's peer list on https://bgp.he.net/AS147028 but we have no adjacency 
>> to this network.
>>
>> Their peer count jumped from 1 in May 2022 to 1,800 and just a few days ago 
>> jumped to 8,800. Beside NL-IX, all the IX they are listed on are virtual IX 
>> with a few dozen "hobby networks".
>>
>> The only lead I have is they use HE as transit and they're pumping back BGP 
>> feed to route collectors like RIPE RIS or Route Views with routes stripped 
>> of HE's ASN.
>>
>> Eric
>>



smime.p7s
Description: S/MIME cryptographic signature

Call for Participation -- ICANN DNSSEC and Security Workshop for ICANN75 Annual General Meeting

[Jacques Latour]

Call for Participation -- ICANN DNSSEC and Security Workshop for ICANN75  
Annual General Meeting

In cooperation with the ICANN Security and Stability Advisory Committee (SSAC), 
we are planning a DNSSEC and Security Workshop for the ICANN75 Annual General 
Meeting being held as a hybrid meeting from 17-22 September 2022 in the 
Malaysian Time Zone (UTC +8). This workshop date will be determined once ICANN 
creates a block schedule for us to follow; then we will be able to request a 
day and time. The DNSSEC and Security Workshop has been a part of ICANN 
meetings for several years and has provided a forum for both experienced and 
new people to meet, present and discuss current and future DNSSEC deployments.  
For reference, the most recent session was held at the ICANN74 Public Forum on 
Monday, 13 June 2022. The presentations and transcripts are available at 
https://74.schedule.icann.org/meetings/BCyJbniR9TpSCohBp#/, and
https://74.schedule.icann.org/meetings/WiPRZ59cBZDvj5ws2

The DNSSEC Workshop Program Committee is developing a program for the upcoming 
meeting.  Proposals will be considered for the following topic areas and 
included if space permits.  In addition, we welcome suggestions for additional 
topics either for inclusion in the ICANN75 workshop, or for consideration for 
future workshops.

1.  Global DNSSEC Activities Panel
For this panel, we are seeking participation from those who have been involved 
in DNSSEC deployment as well as from those who have not deployed DNSSEC but who 
have a keen interest in the challenges and benefits of deployment, including 
Root Key Signing Key (KSK) Rollover activities and plans.

2.  DNSSEC Best Practice
Now that DNSSEC has become an operational norm for many registries, registrars, 
and ISPs, what have we learned about how we manage DNSSEC?



  *   Do you still submit/accept DS records with Digest Type 1?
  *   What is the best practice around key roll-overs?
  *   What about Algorithm roll-overs?
  *   Do you use and support DNSKEY Algorithms 13-16?
  *   How often do you review your disaster recovery procedures?
  *   Is there operational familiarity within your customer support teams?
  *   What operational statistics have been gathered about DNSSEC?
  *   Are there experiences being documented in the form of best practices, or 
something similar, for transfer of signed zones?

Activities and issues related to DNSSEC in the DNS Root Zone are also desired.

3. DNSSEC Deployment Challenges
The program committee is seeking input from those that are interested in 
implementation of DNSSEC but have general or particular concerns with DNSSEC.  
In particular, we are seeking input from individuals that would be willing to 
participate in a panel that would discuss questions of the following nature:



  *   Are there any policies directly or indirectly impeding your DNSSEC 
deployment? (RRR model, CDS/CDNSKEY automation)
  *   What are your most significant concerns with DNSSEC, e.g., complexity, 
training, implementation, operation or something else?
  *   What do you expect DNSSEC to do for you and what doesn't it do?
  *   What do you see as the most important trade-offs with respect to doing or 
not doing DNSSEC?

4. Security Panel
The program committee is looking for presentations on DNS, DNSSEC, routing and 
other topics that could impact the security and/or stability of the Internet.

We are looking for presentations that cover implementation issues, challenges, 
opportunities and best practices for:



  *   Emerging threats that could impact the security and/or stability of the 
Internet
  *   DoH and DoT
  *   RPKI (Resource Public Key Infrastructure)
  *   BGP routing & secure implementations
  *   MANRS ( Mutually Agreed Norms for Routing Security)
  *   Browser security – DNS, DNSSEC, DoH
  *   EMAIL & DNS related security – DMARC, DKIM, TLSA, etc…

If you are interested in participating, please send a brief (1-3 sentence) 
description of your proposed presentation to 
dnssec-security-works...@icann.org 
by COB Friday, 12 August 2022.

Thank you,
Kathy and Andrew
On behalf of the DNSSEC Workshop Program Committee:
Steve Crocker, Shinkuro
Mark Elkins, DNS/ZACR
Jacques Latour, .CA
Russ Mundy, Parsons
Ondrej Filip, CZ.NIC
Yoshiro Yoneya, JPRS
Fred Baker, ISC
Dan York, Internet Society

Re: Frontier Dark Fiber

[Mike Hammett]

Oh, and I forgot to mention that my ICA has it. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Mike Hammett"  
To: nanog@nanog.org 
Sent: Wednesday, July 13, 2022 6:40:47 AM 
Subject: Frontier Dark Fiber 


I'm looking for a contact at Frontier that can discuss dark fiber. 


My current account exec says they don't offer it, yet prior conversations with 
him and a previous SE revealed that they very much did (just didn't have 
availability on the paths I wanted at the time). 


Their web site highlights it fairly proudly. 




I'm aware that availability varies. 


I'm aware that they likely don't want to sell it. 



- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

Frontier Dark Fiber

[Mike Hammett]

I'm looking for a contact at Frontier that can discuss dark fiber. 


My current account exec says they don't offer it, yet prior conversations with 
him and a previous SE revealed that they very much did (just didn't have 
availability on the paths I wanted at the time). 


Their web site highlights it fairly proudly. 




I'm aware that availability varies. 


I'm aware that they likely don't want to sell it. 



- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP