Re: softlayer.com

[andrew]

SoftLayer was aquirred by IBM, maybe reaching out to their NOC or support would 
be fruitful. IBM's DNS team is indeed mentioned in SoftLayers WHOIS info.

Have you attempted email the addresses listed in the WHOIS for their ASN?

network:Tech-Contact;I:
sysadm...@softlayer.com
network:Abuse-Contact;I:
ab...@softlayer.com

network:Updated-By:
ipad...@softlayer.com

Registrant Contact

Registrant Name Domain Administrator
Registrant Organization Softlayer Technologies, Inc.
Registrant Street   4849 Alpha Road
Registrant City Dallas
Registrant State/Province   TX
Registrant Postal Code  75244
Registrant Country  USUnited States

Registrant Phone+1.2144420600
Registrant Emailbjohn...@softlayer.com

Administrative Contact

Admin Name  Grace Micewicz
Admin Organization  International Business Machines Corporation
Admin StreetNew Orchard Road
Admin City  Armonk
Admin State/ProvinceNY
Admin Postal Code   10504
Admin Country   USUnited States

Admin Phone +1.9147654227
Admin Fax   +1.9147654370
Admin Email dns...@us.ibm.com

Regards.
Andrew Paolucci

‐‐‐ Original Message ‐‐‐
On Thursday, March 21, 2019 3:39 PM, John Alcock  wrote:

> Still looking for anyone from softlayer.com
>
> It has been a challenge.  Anything hosted by softlayer.com is being blocked.
>
> Here is a small list so far
>
> windowbook.tpondemand.com
> ahainstructornetwork.americanheart.org
> clover.com
> Cebroker.com
> Softlayer.com
> indeed.com & Enforce Staffing
>
> It is growing every day.
>
> John
>
> On Wed, Mar 20, 2019 at 12:35 PM John Alcock  wrote:
>
>> Afternoon,
>>
>> Thought I would start a new thread.  After researching, traceroutes, etc, I 
>> think I found my problem.
>>
>> 9 out of the 10 sites that subscribers on my new block is being hosted by 
>> softlayer.
>>
>> Anyone on the list have contacts with softlayer.  Right now I have an email 
>> to abuse.  The support line will not help me out.
>>
>> John

Comcast: Xfinity Flex - No emergency alerts for cordcutters

[Sean Donelan]

In advance of Apple TV's big announcement next week, other folks are 
announcing their new streaming TV boxes.  Comcast announced Xfinity Flex

today, a video streaming box.

Xfinity Flex looks and acts like a set-top box, but uses Internet, so it 
avoids all those pesky cable TV rules. But emergency alerts aren't 
mentioned, even in the fine print at the bottom of the page. I expect 
there are none.


I still hope a reporter asks Apple about emergency alerts at its big event
on Monday. Apple TV streaming may be awesome, as that tornado destroys 
your mobile trailer park.

Re: softlayer.com

[John Alcock]

Still looking for anyone from softlayer.com

It has been a challenge.  Anything hosted by softlayer.com is being blocked.

Here is a small list so far

windowbook.tpondemand.com
ahainstructornetwork.americanheart.org
clover.com
Cebroker.com
Softlayer.com
indeed.com & Enforce Staffing

It is growing every day.

John

















On Wed, Mar 20, 2019 at 12:35 PM John Alcock  wrote:

> Afternoon,
>
> Thought I would start a new thread.  After researching, traceroutes, etc,
> I think I found my problem.
>
> 9 out of the 10 sites that subscribers on my new block is being hosted by
> softlayer.
>
> Anyone on the list have contacts with softlayer.  Right now I have an
> email to abuse.  The support line will not help me out.
>
> John
>

Re: well-known Anycast prefixes

[Bill Woodcock]

I imagine that the “description” of each entry in the list should include a 
machine-readable field indicating the use. 

There was a question about the use-case... I’m sure a lot of people in the ops 
community have their own reasons related to routing and filtering and so forth, 
but there’s also a huge demand for this kind of information, aggregated and 
sanity-checked, to support academic research at the graduate level. And the 
better we support those kids with real-world data, the more practical an 
education they receive, and the more ready they are to jump in to jobs we offer 
them in industry when they graduate. Supporting kids and networking graduate 
programs like that is a big part of our work, that tends not to be visible on 
the operations side. 

Academics downloaded routing-archive snapshots from us nearly 300 million 
times, last year, for example. 

-Bill


> On Mar 21, 2019, at 09:52, Ross Tajvar  wrote:
> 
> Not all any-casted prefixes are DNS resolvers and not all DNS resolvers are 
> anycasted. It sounds like you would be better served by a list of well-known 
> DNS resolvers.
> 
>> On Thu, Mar 21, 2019 at 12:35 PM Bryan Holloway  wrote:
>> 
>> On 3/21/19 10:59 AM, Frank Habicht wrote:
>> > Hi James,
>> > 
>> > On 20/03/2019 21:05, James Shank wrote:
>> >> I'm not clear on the use cases, though.  What are the imagined use cases?
>> >>
>> >> It might make sense to solve 'a method to request hot potato routing'
>> >> as a separate problem.  (Along the lines of Damian's point.)
>> > 
>> > my personal reason/motivation is this:
>> > Years ago I noticed that my traffic to the "I" DNS root server was
>> > traversing 4 continents. That's from Tanzania, East Africa.
>> > Not having a local instance (back then), we naturally sent the traffic
>> > to an upstream. That upstream happens to be in that club of those who
>> > don't have transit providers (which probably doesn't really matter, but
>> > means a "global" network).
>> 
>> /snip
>> 
>> > Greetings,
>> > Frank
>> > 
>> 
>> I can think of another ...
>> 
>> We rate-limit DNS from unknown quantities for reasons that should be 
>> obvious. We white-list traffic from known trusted (anycast) ones to 
>> prevent a DDoS attack from throttling legitimate queries. This would be 
>> a useful way to help auto-generate those ACLs.

Re: Amazon Prime video NOC contact

[Anne P. Mitchell, Esq.]

May I have (at least some of) your permission to put this in front of someone 
at AMZ?

Anne

Anne P. Mitchell, 
Attorney at Law
GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant
Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
Legislative Consultant
CEO/President, Institute for Social Internet Public Policy
Board of Directors, Denver Internet Exchange
Board of Directors, Asilomar Microcomputer Workshop
Legal Counsel: The CyberGreen Institute
Legal Counsel: The Earth Law Center
California Bar Association
Cal. Bar Cyberspace Law Committee
Colorado Cyber Committee
Ret. Professor of Law, Lincoln Law School of San Jose
Ret. Chair, Asilomar Microcomputer Workshop



> On Mar 21, 2019, at 10:13 AM, Brian Pierce  wrote:
> 
> Bradley & Davide,
>  
> I work for an ISP located in central Ohio and we’re experiencing the a 
> similar issue with a newly acquired IP Block, it’s flagged as a VPN/Proxy.
> I’ve not had any success trying their forums or trying to climb through their 
> customer service ladder to hope someone knowledgeable receives my ticket.
> Bradley, if you have any contact info I would greatly appreciate a message 
> off list.
> Davide, if you are able to resolve this issue, please advise how you were 
> able to do so.
>  
> From: NANOG  On Behalf Of Bradley Burch
> Sent: Wednesday, March 20, 2019 2:28 PM
> To: William Herrin 
> Cc: nanog@nanog.org; davide.gela...@wt-tech.it
> Subject: Re: Amazon Prime video NOC contact
>  
> ATTENTION: This email came from an external source. Do not open attachments 
> or click on links from unknown senders or unexpected emails.
>  
> I have had no luck from that forum.
> Davide, I will contact you off list.
>  
>  
> 
> On Mar 20, 2019, at 2:16 PM, William Herrin  wrote:
> 
> On Wed, Mar 20, 2019 at 11:03 AM Davide Gelardi  
> wrote:
> we are an italian ISP/WISP and we are experiecing trouble with Amazon 
> Prime Video. They blocked our customers that cannot view the video. The 
> error says that our IP class is located ouside italy. But this is wrong.
> 
> Have you a contact we can get in touch with?
>  
> Hi Davide,
>  
> You may have some luck here: 
> https://www.amazonforum.com/forums/digital-content/prime-video
>  
> Amazon staff working on Prime Video monitor and respond on that forum. The 
> individuals reading may not be the right people, but they'll likely be on a 
> first name basis with someone who is.
>  
> Regards,
> Bill Herrin
> 
>  
> -- 
> William Herrin  her...@dirtside.com  b...@herrin.us
> Dirtside Systems . Web: 

RE: Amazon Prime video NOC contact

[Brian Pierce]

Bradley & Davide,

I work for an ISP located in central Ohio and we’re experiencing the a similar 
issue with a newly acquired IP Block, it’s flagged as a VPN/Proxy.
I’ve not had any success trying their forums or trying to climb through their 
customer service ladder to hope someone knowledgeable receives my ticket.
Bradley, if you have any contact info I would greatly appreciate a message off 
list.
Davide, if you are able to resolve this issue, please advise how you were able 
to do so.

From: NANOG  On Behalf Of Bradley Burch
Sent: Wednesday, March 20, 2019 2:28 PM
To: William Herrin 
Cc: nanog@nanog.org; davide.gela...@wt-tech.it
Subject: Re: Amazon Prime video NOC contact

ATTENTION: This email came from an external source. Do not open attachments or 
click on links from unknown senders or unexpected emails.

I have had no luck from that forum.
Davide, I will contact you off list.



On Mar 20, 2019, at 2:16 PM, William Herrin 
mailto:b...@herrin.us>> wrote:
On Wed, Mar 20, 2019 at 11:03 AM Davide Gelardi 
mailto:ml-assoprovi...@wt-tech.it>> wrote:
we are an italian ISP/WISP and we are experiecing trouble with Amazon
Prime Video. They blocked our customers that cannot view the video. The
error says that our IP class is located ouside italy. But this is wrong.

Have you a contact we can get in touch with?

Hi Davide,

You may have some luck here: 
https://www.amazonforum.com/forums/digital-content/prime-video

Amazon staff working on Prime Video monitor and respond on that forum. The 
individuals reading may not be the right people, but they'll likely be on a 
first name basis with someone who is.

Regards,
Bill Herrin


--
William Herrin  her...@dirtside.com 
 b...@herrin.us
Dirtside Systems . Web: 

Re: well-known Anycast prefixes

[Bryan Holloway]

On 3/21/19 11:52 AM, Ross Tajvar wrote:
Not all any-casted prefixes are DNS resolvers and not all DNS resolvers 
are anycasted. It sounds like you would be better served by a list of 
well-known DNS resolvers.


True on both counts, and that's why I said "help".


On Thu, Mar 21, 2019 at 12:35 PM Bryan Holloway > wrote:



On 3/21/19 10:59 AM, Frank Habicht wrote:
 > Hi James,
 >
 > On 20/03/2019 21:05, James Shank wrote:
 >> I'm not clear on the use cases, though.  What are the imagined
use cases?
 >>
 >> It might make sense to solve 'a method to request hot potato
routing'
 >> as a separate problem.  (Along the lines of Damian's point.)
 >
 > my personal reason/motivation is this:
 > Years ago I noticed that my traffic to the "I" DNS root server was
 > traversing 4 continents. That's from Tanzania, East Africa.
 > Not having a local instance (back then), we naturally sent the
traffic
 > to an upstream. That upstream happens to be in that club of those who
 > don't have transit providers (which probably doesn't really
matter, but
 > means a "global" network).

/snip

 > Greetings,
 > Frank
 >

I can think of another ...

We rate-limit DNS from unknown quantities for reasons that should be
obvious. We white-list traffic from known trusted (anycast) ones to
prevent a DDoS attack from throttling legitimate queries. This would be
a useful way to help auto-generate those ACLs.

Re: well-known Anycast prefixes

[Ross Tajvar]

Not all any-casted prefixes are DNS resolvers and not all DNS resolvers are
anycasted. It sounds like you would be better served by a list of
well-known DNS resolvers.

On Thu, Mar 21, 2019 at 12:35 PM Bryan Holloway  wrote:

>
> On 3/21/19 10:59 AM, Frank Habicht wrote:
> > Hi James,
> >
> > On 20/03/2019 21:05, James Shank wrote:
> >> I'm not clear on the use cases, though.  What are the imagined use
> cases?
> >>
> >> It might make sense to solve 'a method to request hot potato routing'
> >> as a separate problem.  (Along the lines of Damian's point.)
> >
> > my personal reason/motivation is this:
> > Years ago I noticed that my traffic to the "I" DNS root server was
> > traversing 4 continents. That's from Tanzania, East Africa.
> > Not having a local instance (back then), we naturally sent the traffic
> > to an upstream. That upstream happens to be in that club of those who
> > don't have transit providers (which probably doesn't really matter, but
> > means a "global" network).
>
> /snip
>
> > Greetings,
> > Frank
> >
>
> I can think of another ...
>
> We rate-limit DNS from unknown quantities for reasons that should be
> obvious. We white-list traffic from known trusted (anycast) ones to
> prevent a DDoS attack from throttling legitimate queries. This would be
> a useful way to help auto-generate those ACLs.
>

Re: well-known Anycast prefixes

[Bryan Holloway]

On 3/21/19 10:59 AM, Frank Habicht wrote:

Hi James,

On 20/03/2019 21:05, James Shank wrote:

I'm not clear on the use cases, though.  What are the imagined use cases?

It might make sense to solve 'a method to request hot potato routing'
as a separate problem.  (Along the lines of Damian's point.)


my personal reason/motivation is this:
Years ago I noticed that my traffic to the "I" DNS root server was
traversing 4 continents. That's from Tanzania, East Africa.
Not having a local instance (back then), we naturally sent the traffic
to an upstream. That upstream happens to be in that club of those who
don't have transit providers (which probably doesn't really matter, but
means a "global" network).


/snip


Greetings,
Frank



I can think of another ...

We rate-limit DNS from unknown quantities for reasons that should be 
obvious. We white-list traffic from known trusted (anycast) ones to 
prevent a DDoS attack from throttling legitimate queries. This would be 
a useful way to help auto-generate those ACLs.

Re: well-known Anycast prefixes

[Job Snijders]

On Thu, Mar 21, 2019 at 06:59:18PM +0300, Frank Habicht wrote:
> On 20/03/2019 21:05, James Shank wrote:
> > I'm not clear on the use cases, though.  What are the imagined use cases?
> > 
> > It might make sense to solve 'a method to request hot potato routing'
> > as a separate problem.  (Along the lines of Damian's point.)
> 
> my personal reason/motivation is this:
> Years ago I noticed that my traffic to the "I" DNS root server was
> traversing 4 continents. That's from Tanzania, East Africa.
> Not having a local instance (back then), we naturally sent the traffic
> to an upstream. That upstream happens to be in that club of those who
> don't have transit providers (which probably doesn't really matter, but
> means a "global" network).

Luckily there are other root servers too! :)

> My Theory :
> So just because one I-root instance was hosted at a customer (or
> customer's customer), that got higher local-pref and now packets take
> the long way from Africa via Europe, NorthAmerica to Asia and that
> customer in Thailand. While closer I-root instances would obviously be
> along the way, just not from a paying customer, "only" from peering.
> 
> I don't know whether or not to blame that "carrier" for intentionally(?)
> carrying the traffic that far - presumably the $ they got for that from
> the I-root host in Thailand was worth it, and not enough customers
> complained enough about the latency?
> 
> But I think it would be worthwhile to give them an option and produce a
> mechanism of knowing what's anycasted.
> 
> Maybe (thinking of it) a solution for really well-known prefixes
> available at many instances/locations (like DNS root) would be to have
> their fixed set of direct transits at all the "global" nodes and
> everywhere else to tell peers to not advertise this to upstreams.

In all instances of what you mention you need cooperation from the
network which is routing in a (from your perspective) suboptimal way.

Either the customer of that upstream should use BGP communities to
localize the announcement, or the upstream themselves need to change
their routing policy to set 'same LOCAL_PREF everywhere' for some
prefixes. Of course any input channel into routing policy can be a
vector of abuse.

Even if you equalize the LOCAL_PREF attribute across your network edge,
you still have other tie breakers such as AS_PATH length. It is not
clear to me how a list of well-known anycast addresses, in practise,
would help swing the pendulum. In all cases you need cooperation from a
lot of networks, and the outcome is not clearly defined because we don't
have a true inter-domain 'shortest latency path' metric.

Kind regards,

Job

Re: well-known Anycast prefixes

[Frank Habicht]

Hi James,

On 20/03/2019 21:05, James Shank wrote:
> I'm not clear on the use cases, though.  What are the imagined use cases?
> 
> It might make sense to solve 'a method to request hot potato routing'
> as a separate problem.  (Along the lines of Damian's point.)

my personal reason/motivation is this:
Years ago I noticed that my traffic to the "I" DNS root server was
traversing 4 continents. That's from Tanzania, East Africa.
Not having a local instance (back then), we naturally sent the traffic
to an upstream. That upstream happens to be in that club of those who
don't have transit providers (which probably doesn't really matter, but
means a "global" network).

My Theory :
So just because one I-root instance was hosted at a customer (or
customer's customer), that got higher local-pref and now packets take
the long way from Africa via Europe, NorthAmerica to Asia and that
customer in Thailand. While closer I-root instances would obviously be
along the way, just not from a paying customer, "only" from peering.

I don't know whether or not to blame that "carrier" for intentionally(?)
carrying the traffic that far - presumably the $ they got for that from
the I-root host in Thailand was worth it, and not enough customers
complained enough about the latency?

But I think it would be worthwhile to give them an option and produce a
mechanism of knowing what's anycasted.

Maybe (thinking of it) a solution for really well-known prefixes
available at many instances/locations (like DNS root) would be to have
their fixed set of direct transits at all the "global" nodes and
everywhere else to tell peers to not advertise this to upstreams.

Greetings,
Frank

Re: Amazon Prime video NOC contact

[Bradley Burch]

I have had no luck from that forum.
Davide, I will contact you off list.



> On Mar 20, 2019, at 2:16 PM, William Herrin  wrote:
> 
>> On Wed, Mar 20, 2019 at 11:03 AM Davide Gelardi  
>> wrote:
> 
>> we are an italian ISP/WISP and we are experiecing trouble with Amazon 
>> Prime Video. They blocked our customers that cannot view the video. The 
>> error says that our IP class is located ouside italy. But this is wrong.
>> 
>> Have you a contact we can get in touch with?
> 
> Hi Davide,
> 
> You may have some luck here: 
> https://www.amazonforum.com/forums/digital-content/prime-video
> 
> Amazon staff working on Prime Video monitor and respond on that forum. The 
> individuals reading may not be the right people, but they'll likely be on a 
> first name basis with someone who is.
> 
> Regards,
> Bill Herrin
> 
> 
> -- 
> William Herrin  her...@dirtside.com  b...@herrin.us
> Dirtside Systems . Web: 

Re: well-known Anycast prefixes

[James Shank]

On 3/19/19 5:03 PM, Bill Woodcock wrote:
> 
> 
>> On Mar 19, 2019, at 1:55 PM, Frank Habicht  wrote:
>>
>> Hi,
>>
>> On 19/03/2019 23:13, Bill Woodcock wrote:
>>> Generally, static lists like that are difficult to maintain when
>>> they’re tracking multiple routes from multiple parties.
>>
>> agreed.
>> and on the other extreme, communities are very much prone to abuse.
>> I guess I could set any community on a number of prefixes (incl anycast)
>> right now
>>
>> So, I think a (moderated) BGP feed of prefixes a'la bogon from a trusted
>> {cymru[1], pch[2], ...}  could be good [3].
> 
> Ok, so, just trying to flesh out the idea to something that can be usefully 
> implemented…
> 
> 1) People send an eBGP multi-hop feed of well-known-community routes to a 
> collector, or send them over normal peering sessions to something that 
> aggregates…
> 
> 2) Because those are over BGP sessions, the counterparty is known, and can be 
> asked for details or clarification by the “moderator,” or the sender could 
> log in to an interface to add notes about the prefixes, as they would in the 
> IXPdir or PeeringDB.
> 
> 3) Known prefixes from known parties would be passed through in real-time, as 
> they were withdrawn and restored.
> 
> 4) New prefixes from known parties would be passed through in real-time if 
> they weren’t unusual (large/overlapping something else/previously announced 
> by other ASNs).
> 
> 5) New prefixes from known parties would be “moderated” if they were unusual.
> 
> 6) New prefixes from new parties would be “moderated” to establish that they 
> were legit and that there was some documentation explaining what they were.
> 
> 7) For anyone who really didn’t want to provide a community-tagged BGP feed, 
> a manual submission process would exist.
> 
> 8) Everything gets published as a real-time eBGP feed.
> 
> 9) Everything gets published as HTTPS-downloadable JSON.
> 
> 10) Everything gets published as a human-readable (and crawler-indexable) web 
> page.
> 
> Does that sound about right?
> 
> -Bill

Hi,

Interesting discussion and ideas.  I like how you've laid it out
above, Bill.

I'm not clear on the use cases, though.  What are the imagined use cases?

It might make sense to solve 'a method to request hot potato routing'
as a separate problem.  (Along the lines of Damian's point.)

Thanks!

James

-- 
James Shank
Senior Technical Advisor; Team Cymru, Inc.
jsh...@cymru.com; +1-847-378-3365; http://www.team-cymru.com/