Re: Twitter security team?

[Ken Gilmour]

Because I didn't find the vulnerability, I'm not looking for a bug bounty
and I don't know what the vulnerability is, just seeing the effects of it.

On Thu, 18 Jul 2019 at 13:06, Ross Tajvar  wrote:

> Why is Hacker one wrong? Seems like this would be exactly what it's for.
>
> On Thu, Jul 18, 2019, 3:04 PM J. Hellenthal via NANOG 
> wrote:
>
>> Or maybe a tweet to @twittersecurity
>>
>> > On Jul 18, 2019, at 13:59, J. Hellenthal 
>> wrote:
>> >
>> >
>> > Yes/No ?
>> >
>> >
>> https://help.twitter.com/en/rules-and-policies/reporting-security-vulnerabilities
>> >
>> >> On Jul 18, 2019, at 13:45, Ken Gilmour  wrote:
>> >>
>> >> Anyone on the list know how to contact the Twitter Security team?
>> >>
>> >> Seems the new update allows an attacker to modify other people's
>> tweets. The "Hackerone" form for reporting a vulnerability is the wrong
>> form and the "My account has been hacked" form is also the wrong form. The
>> whole site has been compromised, I have evidence and can't contact anyone
>> due to the lack of an appropriate form and the fact that the security@
>> email address doesn't work.
>> >>
>> >> Thanks!
>> >
>>
>>

Re: Twitter security team?

[Ken Gilmour]

no

On Thu, 18 Jul 2019 at 12:59, J. Hellenthal  wrote:

>
> Yes/No ?
>
>
> https://help.twitter.com/en/rules-and-policies/reporting-security-vulnerabilities
>
> > On Jul 18, 2019, at 13:45, Ken Gilmour  wrote:
> >
> > Anyone on the list know how to contact the Twitter Security team?
> >
> > Seems the new update allows an attacker to modify other people's tweets.
> The "Hackerone" form for reporting a vulnerability is the wrong form and
> the "My account has been hacked" form is also the wrong form. The whole
> site has been compromised, I have evidence and can't contact anyone due to
> the lack of an appropriate form and the fact that the security@ email
> address doesn't work.
> >
> > Thanks!
>
>

Twitter security team?

[Ken Gilmour]

Anyone on the list know how to contact the Twitter Security team?

Seems the new update allows an attacker to modify other people's tweets.
The "Hackerone" form for reporting a vulnerability is the wrong form and
the "My account has been hacked" form is also the wrong form. The whole
site has been compromised, I have evidence and can't contact anyone due to
the lack of an appropriate form and the fact that the security@ email
address doesn't work.

Thanks!

Re: Colo in Africa

[Ken Gilmour]

I feel like I'm arguing with my teenager over why the WiFi is slow.

Re: Colo in Africa

[Ken Gilmour]

TBs of data is not really that much data on average when  you average it
over thousands of customers. The data is summarized, There are a ton of
other things happening in the background that I've already explained in the
thread and are really irrelevant to the task at hand which is finding a
facility in Africa that does Bare Metal servers. I've had a lot of helpful
people, despite the naysayers.

Thanks!

On Tue, 16 Jul 2019 at 11:23, Valdis Klētnieks 
wrote:

> On Tue, 16 Jul 2019 10:39:59 -0600, Ken Gilmour said:
>
> > These are actual real problems we face. thousands of customers load and
> > reload TBs of data every few seconds on their dashboards.
>
> If they're reloading TBs of data every few seconds, you really should have
> been
> doing summaries during data ingestion and only reloading the summaries.
> (Overlooking the fact that for dashboards, refreshing every few seconds is
> usually pointless because you end up looking at short-term statistical
> spikes
> rather than anything that you can react to at human speeds.  If you *care*
> in
> real time that the number of probes on a port spiked to 457% of average
> for 2
> seconds you need to be doing automated responses
>
> Custom queries are more painful - but those don't happen "every few
> seconds".
>

Re: Colo in Africa

[Ken Gilmour]

What matters is whether or not we can get a facility in Africa to provide
service to our customers from Bare Metal Servers :)

On Tue, 16 Jul 2019 at 16:07, C. A. Fillekes  wrote:

> Are they refreshing data they've already got, though?
> This is the classic use case for client-side caching.
>
> On Tue, Jul 16, 2019 at 5:56 PM Ken Gilmour  wrote:
>
>> We have a different use case to traditional analytics - We're aimed at
>> consumers and small businesses, so instead of a SOC with one big screen
>> refreshing 1 rows of only alert data every 30 seconds, we have
>> thousands of individuals refreshing all of their data every 30 seconds
>> because there are comparatively less alerts for individuals than
>> enterprises.
>>
>> What you "should" do often doesn't translate to what you "do" do.
>>
>> On Tue, 16 Jul 2019 at 11:23, Valdis Klētnieks 
>> wrote:
>>
>>> On Tue, 16 Jul 2019 10:39:59 -0600, Ken Gilmour said:
>>>
>>> > These are actual real problems we face. thousands of customers load and
>>> > reload TBs of data every few seconds on their dashboards.
>>>
>>> If they're reloading TBs of data every few seconds, you really should
>>> have been
>>> doing summaries during data ingestion and only reloading the summaries.
>>> (Overlooking the fact that for dashboards, refreshing every few seconds
>>> is
>>> usually pointless because you end up looking at short-term statistical
>>> spikes
>>> rather than anything that you can react to at human speeds.  If you
>>> *care* in
>>> real time that the number of probes on a port spiked to 457% of average
>>> for 2
>>> seconds you need to be doing automated responses
>>>
>>> Custom queries are more painful - but those don't happen "every few
>>> seconds".
>>>
>>

Re: Colo in Africa

[Ken Gilmour]

We have a different use case to traditional analytics - We're aimed at
consumers and small businesses, so instead of a SOC with one big screen
refreshing 1 rows of only alert data every 30 seconds, we have
thousands of individuals refreshing all of their data every 30 seconds
because there are comparatively less alerts for individuals than
enterprises.

What you "should" do often doesn't translate to what you "do" do.

On Tue, 16 Jul 2019 at 11:23, Valdis Klētnieks 
wrote:

> On Tue, 16 Jul 2019 10:39:59 -0600, Ken Gilmour said:
>
> > These are actual real problems we face. thousands of customers load and
> > reload TBs of data every few seconds on their dashboards.
>
> If they're reloading TBs of data every few seconds, you really should have
> been
> doing summaries during data ingestion and only reloading the summaries.
> (Overlooking the fact that for dashboards, refreshing every few seconds is
> usually pointless because you end up looking at short-term statistical
> spikes
> rather than anything that you can react to at human speeds.  If you *care*
> in
> real time that the number of probes on a port spiked to 457% of average
> for 2
> seconds you need to be doing automated responses
>
> Custom queries are more painful - but those don't happen "every few
> seconds".
>

Re: Colo in Africa

[Ken Gilmour]

Hi Mark,

Our "market" is actually the US - but we're experiencing unexpected success
across the world. A lot of our customers have selected "Africa" as their
region when signing up and they are in various countries around Africa,
they deserve to be served better within their continent at least.

We can't actually build POPs fast enough, so I want to throw as broad a net
as possible with our first POP in Africa and then branch out from there. We
have customers in South Africa, Tanzania, Nigeria, Egypt, Morocco and Ghana
for instance. I have resources for only one POP in Africa currently, need
to decide where to best serve as many as possible. We could serve Northern
Africa from EU and Southern Africa from Singapore, but having something
within the continent would be preferable.

Thanks!

Ken

On Tue, 16 Jul 2019 at 10:52, Mark Tinka  wrote:

>
>
> On 16/Jul/19 16:33, Ken Gilmour wrote:
>
> Hi Folks,
>
> I work for a Security Analytics org and we're looking to build a small POP
> in Africa.
>
>
> Where, in Africa? It's not a small place...
>
>
>
>1. Network needs to be able to receive millions of small PPS (as
>opposed to serving smaller numbers of larger files).
>
>
> Depending on where in Africa you want to deploy, there will be a choice of
> service providers.
>
>
>
>1. Can't be cloud (need bare metal servers / colo). We use the full
>capacity of each server, all the time.
>
>
> This is possible, but will depend on where, in Africa, you want to deploy.
>
>
>
>1. Must have good connectivity to most of the rest of Africa
>
>
> This is a tricky one, but if you know where you want to be, it will help
> to give you options.
>
>
>
>1. We can initially only have one POP
>
>
> Not a problem, but where?
>
>
> This is not like a normal website that we can just host on "any old
> provider", the requirements are very different.
>
> Is there a good location where we could either rent bare metal servers
> (something like Internap - preferred) or colocate servers within Africa
> that can serve most of the region?
>
>
> Africa is huge, with varying levels of quality of connectivity. The 3 main
> regions are East Africa (Kenya leading), Southern Africa (South Africa
> leading) and West Africa (Nigeria and Ghana leading).
>
> For North Africa, your options can swing between Egypt and Morocco.
>
> But stringing all of these locations together, particularly West and North
> to East and South, will not be straight forward.
>
>
>
>
> "Good" is defined as an area with stable connectivity and power, no legal
> restrictions on things like encryption, and good latency (sub 100ms) to the
> rest of Africa.
>
>
> Yes, all 5 will be difficult at this point in time.
>
> For most of that, hosting within Eastern and Southern Africa will be your
> best bets.
>
> West Africa ticks a lot of the boxes, but it's not very straight forward
> when it comes to co-lo.
>
>
>
>
> Our two closest POPs are in Singapore and The Netherlands, so I'd like
> something closer to the middle that can serve the rest of Africa. Middle
> East will be deployed after Africa.
>
>
> Singapore is closer to Eastern & Southern Africa. Will be too far to West
> Africa unless you want to switch in Europe.
>
> The Netherlands is okay for all of Africa.
>
> The Middle East is closer to Eastern Africa. Too far for West Africa
> unless you want to switch in Europe.
>
> Mark.
>

Re: Colo in Africa

[Ken Gilmour]

These are actual real problems we face. thousands of customers load and
reload TBs of data every few seconds on their dashboards. We have busy
servers. We tried cloud. I passionately hate it. We choose to use Bare
Metal.

On Tue, 16 Jul 2019 at 10:34, Akshay Kumar  wrote:

> Go look at the actual specifications for one of the metal boxes - you are
> not going to come close to maxing anything out with the workload you
> describe. FSB hasn't been a thing in over a decade. If you really wanted to
> go crazy you could do some build a custom solution in FPGA on the F1s.
>
> It's a moot point since none of this is going to be available in time but
> perf is a bogus reason and a lot of the times price is too.
>
> On Tue, Jul 16, 2019 at 5:12 PM Ken Gilmour  wrote:
>
>> Speed is not the issue, it's IO. Also streaming 100Gbps of video is very
>> different to streaming 100Gbps of files smaller than 100kb (average of
>> about 30kb) the issue on the network level is the number of connections and
>> CPU, on the server side it's IO and FSB
>>
>> On Tue, 16 Jul 2019 at 08:55, Akshay Kumar  wrote:
>>
>>> The 2nd requirement seems artificial. The new hypervisors have come a
>>> long way and the overhead is minimal. Also you can run bare metal instances
>>> in AWS if you really need them with 100Gbps.
>>>
>>> Just just use the South Africa AWS region.
>>>
>>> On Tue, Jul 16, 2019 at 3:35 PM Ken Gilmour 
>>> wrote:
>>>
>>>> Hi Folks,
>>>>
>>>> I work for a Security Analytics org and we're looking to build a small
>>>> POP in Africa. I am pretty clueless about the region so I was wondering if
>>>> you could help guide me in the right direction for research?
>>>>
>>>> The challenges:
>>>>
>>>>1. Network needs to be able to receive millions of small PPS (as
>>>>opposed to serving smaller numbers of larger files).
>>>>2. Can't be cloud (need bare metal servers / colo). We use the full
>>>>capacity of each server, all the time.
>>>>3. Must have good connectivity to most of the rest of Africa
>>>>4. We can initially only have one POP
>>>>
>>>> This is not like a normal website that we can just host on "any old
>>>> provider", the requirements are very different.
>>>>
>>>> Is there a good location where we could either rent bare metal servers
>>>> (something like Internap - preferred) or colocate servers within Africa
>>>> that can serve most of the region?
>>>>
>>>> "Good" is defined as an area with stable connectivity and power, no
>>>> legal restrictions on things like encryption, and good latency (sub 100ms)
>>>> to the rest of Africa.
>>>>
>>>> Our two closest POPs are in Singapore and The Netherlands, so I'd like
>>>> something closer to the middle that can serve the rest of Africa. Middle
>>>> East will be deployed after Africa.
>>>>
>>>> I hope this is the right place to ask.
>>>>
>>>> Thanks!
>>>>
>>>> Ken
>>>>
>>>

Re: Colo in Africa

[Ken Gilmour]

Speed is not the issue, it's IO. Also streaming 100Gbps of video is very
different to streaming 100Gbps of files smaller than 100kb (average of
about 30kb) the issue on the network level is the number of connections and
CPU, on the server side it's IO and FSB

On Tue, 16 Jul 2019 at 08:55, Akshay Kumar  wrote:

> The 2nd requirement seems artificial. The new hypervisors have come a long
> way and the overhead is minimal. Also you can run bare metal instances in
> AWS if you really need them with 100Gbps.
>
> Just just use the South Africa AWS region.
>
> On Tue, Jul 16, 2019 at 3:35 PM Ken Gilmour  wrote:
>
>> Hi Folks,
>>
>> I work for a Security Analytics org and we're looking to build a small
>> POP in Africa. I am pretty clueless about the region so I was wondering if
>> you could help guide me in the right direction for research?
>>
>> The challenges:
>>
>>1. Network needs to be able to receive millions of small PPS (as
>>opposed to serving smaller numbers of larger files).
>>2. Can't be cloud (need bare metal servers / colo). We use the full
>>capacity of each server, all the time.
>>3. Must have good connectivity to most of the rest of Africa
>>4. We can initially only have one POP
>>
>> This is not like a normal website that we can just host on "any old
>> provider", the requirements are very different.
>>
>> Is there a good location where we could either rent bare metal servers
>> (something like Internap - preferred) or colocate servers within Africa
>> that can serve most of the region?
>>
>> "Good" is defined as an area with stable connectivity and power, no legal
>> restrictions on things like encryption, and good latency (sub 100ms) to the
>> rest of Africa.
>>
>> Our two closest POPs are in Singapore and The Netherlands, so I'd like
>> something closer to the middle that can serve the rest of Africa. Middle
>> East will be deployed after Africa.
>>
>> I hope this is the right place to ask.
>>
>> Thanks!
>>
>> Ken
>>
>

Re: Colo in Africa

[Ken Gilmour]

Bingo

On Tue, 16 Jul 2019 at 09:30, Christopher Morrow 
wrote:

> Isn't the OP really asking here (not to have their selection of
> platform wrangled..):
>   "Where should I target my search: ZA only? is there anywhere else
> worth dropping my request?"
>
> and:
>   "Are there likely providers of solid colo aside from
> seacom/tinka-net or workonline/ben-net ?"
>
> On Tue, Jul 16, 2019 at 11:12 AM Akshay Kumar via NANOG 
> wrote:
> >
> > My bad. They announced that Oct 2018 so I figured they'd be close to it
> now. Yeah turns out it's mid 2020 :-(
> >
> >
> https://aws.amazon.com/blogs/aws/in-the-works-aws-region-in-south-africa/
> >
> > On Tue, Jul 16, 2019 at 4:02 PM Chris Knipe 
> wrote:
> >>
> >>
> >>
> >> On Tue, Jul 16, 2019 at 4:57 PM Akshay Kumar via NANOG 
> wrote:
> >>>
> >>> The 2nd requirement seems artificial. The new hypervisors have come a
> long way and the overhead is minimal. Also you can run bare metal instances
> in AWS if you really need them with 100Gbps.
> >>>
> >>> Just just use the South Africa AWS region.
> >>>
> >>
> >> ^^ You had me for a second there.  AWS ain't operational yet in South
> Africa.  Sometime 2020/2021 only.
> >>
>

Re: Colo in Africa

[Ken Gilmour]

Thanks for all the replies! (really fast!)

The requirement for Bare Metal is very specific. Dealing with high speed
large files is very different to dealing with high volume small files. We
regularly encounter bottlenecks at the FSB and at the IO level. Even things
like RAID slows us down, so we have to squeeze every iota of power out of
the servers that we can. Plus, most of our customers in Africa use our free
version so cost savings are also important, and so is accessibility.

On Tue, 16 Jul 2019 at 09:10, Bryan Fields  wrote:

> On 7/16/19 10:55 AM, Akshay Kumar via NANOG wrote:
> > The 2nd requirement seems artificial. The new hypervisors have come a
> long
> > way and the overhead is minimal. Also you can run bare metal instances in
> > AWS if you really need them with 100Gbps.
>
> Well the man wants bare metal, and while there's arguments for and against
> it,
> it's what he wants to buy :)
>
> That said, I'm one of those guys that likes owing my own hypervisor, don't
> need to worry about the side channel/memory/OOO execution attacks from
> rogue
> VM's if it's only my VM's on it.  Plus AWS ain't cheap either.
>
> --
> Bryan Fields
>
> 727-409-1194 - Voice
> http://bryanfields.net
>

Colo in Africa

[Ken Gilmour]

Hi Folks,

I work for a Security Analytics org and we're looking to build a small POP
in Africa. I am pretty clueless about the region so I was wondering if you
could help guide me in the right direction for research?

The challenges:

   1. Network needs to be able to receive millions of small PPS (as opposed
   to serving smaller numbers of larger files).
   2. Can't be cloud (need bare metal servers / colo). We use the full
   capacity of each server, all the time.
   3. Must have good connectivity to most of the rest of Africa
   4. We can initially only have one POP

This is not like a normal website that we can just host on "any old
provider", the requirements are very different.

Is there a good location where we could either rent bare metal servers
(something like Internap - preferred) or colocate servers within Africa
that can serve most of the region?

"Good" is defined as an area with stable connectivity and power, no legal
restrictions on things like encryption, and good latency (sub 100ms) to the
rest of Africa.

Our two closest POPs are in Singapore and The Netherlands, so I'd like
something closer to the middle that can serve the rest of Africa. Middle
East will be deployed after Africa.

I hope this is the right place to ask.

Thanks!

Ken

Re: bloomberg on supermicro: sky is falling

[Ken Matlock]

Would be remiss in our duties if we didn't also link AWS' blog, in response
to the Bloomberg article.

In short, AWS refutes many of Bloomberg's reporting in the article.

https://aws.amazon.com/blogs/security/setting-the-record-straight-on-bloomberg-businessweeks-erroneous-article/

Ken

On Thu, Oct 4, 2018 at 11:03 AM Randy Bush  wrote:

> re:
> https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies
>
> from a side convo with a well known sec researcher:
>
> >> saw that a couple of years back when apple tossed them out.  so who
> >> do we know that is for sure not poisoned.  and therein lies the rub.
> > Yup
>
> truth is, i am surprised they had to add a chip, and one of the larger
> dies was not already trojaned.
>
> have visions of the chinese implant on box A fighting with the american
> implant on box B with occasional jabs from the israelis from box C.
>
> what i would love to see/know is how apple tries to vet the macs made in
> shenzhen.
>
> randy
>

Re: O365 IP space

[Ken Matlock]

This list?

https://support.content.office.net/en-us/static/O365IPAddresses.xml

>From the linked-above page (it's somewhat obscured).

Ken


On Tue, Sep 25, 2018 at 11:14 AM ML  wrote:

> In the past I've pulled down an XML file that included the IP space for
> all of the O365 products.  Then I filtered, sorted and aggregated what I
> wanted for my internal use via a script.
>
> On 9/25/2018 12:35 PM, David Bass wrote:
>
> Sorry, I should have stated that I have already searched, and have seen
> the above mentioned docs as well as everything else on the first page of
> the search results.
>
> I guess what I was looking for was to see if somebody has already
> consolidated that list in to something easier to work with.
>
> On Tue, Sep 25, 2018 at 11:26 AM Job Snijders  wrote:
>
>> On Tue, Sep 25, 2018 at 12:18:50PM -0400, Steve Meuse wrote:
>> >
>> https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges
>>
>> I think it is cool that companies take the time and effort to publish
>> such useful lists. Keep it up!
>>
>> Kind regards,
>>
>> Job
>>
>
>

Re: Are any of you starting to get AI robocalls?

[Ken Chase]

And revenues wont be impacted because few have a cell for voice
anymore. With increasing data reliability we can move to voip
on phones and provider of choice who offer proper filtering and our
our own skill testing AI attendants

(Im thinking something along the lines of 'unladen swallow'.)

/kc


On Tue, Apr 03, 2018 at 07:26:36PM -0400, Jon Lewis said:
  >On Tue, 3 Apr 2018, Ken Chase wrote:
  >
  >>All this boils my blood. I am not sure why/how spoofing ph#s is legal. I get
  >>sms mass spam too.
  >
  >Whether or not its legal is irrelevant.  It's trivial to do if your link
  >to the PSTN is digital and you have a provider not filtering based on sent
  >caller-id.  It's kind of the PSTN version of the Internet's BCP-38 issue.
  >All providers should be filtering based on "valid" caller-id...but so many
  >don't do it, and the spoofing is nearly impossible to trace back to the
  >origin, so those who do it can safely ignore other laws because they know
  >they won't be caught.
  >
  >--
  > Jon Lewis, MCP :)   |  I route
  > |  therefore you are
  >_ http://www.lewis.org/~jlewis/pgp for PGP public key_

-- 
Ken Chase - m...@sizone.org Guelph Canada

Re: Are any of you starting to get AI robocalls?

[Ken Chase]

Just throw a dial tree plan in front of getting ahold of you. "Press 1 to
speak to a human." this foils most dialers which wait for a human to answer
before they throw anyone (anything?) on the line. They may also have the AI 
get through the unpleasantries before they stick a human on it.

Many voip providers offer a dial tree. I have a provider with a snazzy web drag 
n
drop tree construction system, so you dont need to learn m4/asterisk/linenoise
and even directs SMS's to email for me. I've set it up for my wife and myself
(hit 1 for me, 2 for her) and I use it on all my online ordering stuff because
I know they'll be hacked sooner or later and my info leaked into the wild for
abuse.

I dont know how cell companies expect to be able to continue to offer any
voice services with the lack of enforcement against robodialing - I get calls in
the middle of the night (and have to leave my phone on for on-call from random
customers I dont know the ph# for). Even though I give my direct cel # out to
almost no one, I get 3-5 random calls a week. (I dont doubt that phone hacks are
uploading people's contact lists to the cloud for further infection/robodials,
as well as plain war-dial trawls).

I have a spam contact with > 150 ph#s in it. (I need an app to share these and
subscribe to autoblock but havent gotten a round tuit it yet.) Worse, they're
spoofing real ph#s - I call back calls I didnt answer and they all claim they
didnt call me - because a robodialer spoofed a legit ph# to avoid mass filter
lists. (Beware ph#s that use your NXX - human gut reaction is to answer ph#s
that look like your own supposedly, but its likely a robodial).

All this boils my blood. I am not sure why/how spoofing ph#s is legal. I get
sms mass spam too.

Too much control is left in the sending side, need way better filtering tools
on the receiver. Soon enough however I hope to just be able to dispense with
voice communication and point customers at something else (even SMS would be
better). Im not sure we're at the point you can enforce that without pissing
off customers but we're close.

(I dont support capital punishment for much, but this might be one thing... :)

/kc


On Tue, Apr 03, 2018 at 06:32:19PM -0400, William Herrin said:
  >Howdy.
  >
  >Have any of you started to get AI robocalls? I've had a couple of
  >calls recently where I get the connect silence of a predictive dialer
  >followed by a woman speaking with call center background noise. She
  >gives her name and asks how I'm doing. The first time it happened it
  >seemed off for reasons I can't quite articulate, so I asked: "Are you
  >a robot or a person?" She responded "yes" and then launched in to a
  >sales pitch. The next time I asked, "where can I direct your call?"
  >She responded "that's good" and launched in to her pitch.
  >
  >Regards,
  >Bill Herrin
  >
  >
  >-- 
  >William Herrin .... her...@dirtside.com  b...@herrin.us
  >Dirtside Systems . Web: <http://www.dirtside.com/>

--
Ken Chase - m...@sizone.org Guelph Canada

Re: Yet another Quadruple DNS?

[Ken Chase]

uh, quad the f do you think you're doing?! 

you think anything.255 is routable by COTS gear? :)

maybe everyone who operates x.y/16 should be setting up their open resolvers on
x.y.x.y (can i get an rfc up in the hizzy? apr 1 is rsn.)

/kc


On Fri, Mar 30, 2018 at 05:02:27PM +, Feldman, Mark said:
  >Another one for the list...  We're working on fielding our quad-255 
(255.255.255.255) DNS.  It's currently pingable but not yet providing 
resolution.  We're aiming for an April 1st release.  One of the most 
widley-distributed quads out there.  We're thinking about calling it QUAdFF -- 
drink it up.  
  >
  >  Mark

-- 
Ken Chase - m...@sizone.org Guelph Canada

Re: Yet another Quadruple DNS?

[Ken Chase]

On Fri, Mar 30, 2018 at 09:30:00AM -0400, Christopher Morrow said:
  >I think there's ample evidence that everyone's enemy is 'the nsa' (or other
  >nation-state-actors) isn't there?

Or yourself, after you flip the EU off.

https://www.theregister.co.uk/2018/03/29/eu_dumps_30_ukowned_domains_into_brexit_bin/

Time to spoof x.x.x.x and x.x.y.y port 53 to keep your infra running.

/kc
-- 
Ken Chase - m...@sizone.org Guelph Canada

Re: Yet another Quadruple DNS?

[Ken Chase]

Who's got visible projects looking to detect this from various points/regimes
on the internet? 

(University of Toronto's IXMaps group whom I advised a few times over the
years did something similar for routes, not that BGPlay isnt out there, but
they translated it into human as a sociology project - borne of the Carnivore
era. https://www.ixmaps.ca/ )

Im glad no one said Namecoin yet.

Oops.

/kc


On Thu, Mar 29, 2018 at 04:26:47PM +, Baldur Norddahl said:
  >>
  >>
  >> Technically, tweaking your DNS resolver to lie (and/or to log) is much
  >> easier and faster (and way less expensive) than setting up a
  >> packet interception and rewriting device at line rate.
  >>
  >
  >It is just a static /32 route for well known DNS resolvers to the ISP
  >resolver. It is free and trivial. To make your resolver reply with the
  >correct IP you simply add all the well known /32 addresses to the localhost
  >interface.
  >
  >To get any service instead of just well known ones, you can use source
  >routing based on the port nummer 53. Direct this to a Linux server that
  >will NAT the traffic towards the ISP DNS. This is also trivial and free,
  >provided your routers support source routing (ours do).
  >
  >Detectable yes, but also hard to escape for the average user. They will
  >need to go full VPN. Running your own resolver will not work.
  >
  >Regards
  >
  >Baldur

-- 
Ken Chase - m...@sizone.org Guelph Canada

Re: Qu??bec Sales tax

[Ken Chase]

bell canada?

/kc

On Wed, Mar 28, 2018 at 05:45:26PM -0400, Alain Hebert said:
  >?? Same deal as Paypal and EBay.
  >
  >?? Netflix dropping their services in CDN/QC only serve 
  >attempt at making yet another market grab.
  >
  >
  >?? At the end Netflix may just charge the Tax and funnel it to the
  >govt.?? They'll still be making a bundle.
  >
  >?? ?? ( And with all the hardware already deployed locally at the
  >many exchanges ... )
  >
  >
  >?? Now if we can only break that damn 1930's licensing scheme so that
  >we can gain access to more content...?? Kinda annoyed that 
  >is hogging all the content with their vertical licensing agreements.
  >
  >-
  >Alain Hebertaheb...@pubnix.net
  >PubNIX Inc.
  >50 boul. St-Charles
  >P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
  >Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443
  >
  >On 03/27/18 18:21, Ken Chase wrote:
  >>If Netflix has no physical presence in Quebec, what the lever are they going
  >>to use to force this? A lawsuit in  in the
  >>US? What court is going to entertain a foreign jurisdiction's tax claim in
  >>their court? And how would that be then enforced?
  >>
  >>Canada has tried this before:
  >>
  
>>https://www.ctvnews.ca/business/u-s-judge-puts-halt-to-canadian-court-order-for-google-to-delist-search-results-1.3663055
  >>
  >>Court file: https://scc-csc.lexum.com/scc-csc/scc-csc/en/item/16701/index.do
  >>
  >>Im a big fan of Canada standing up for its sovereignty (I live here), but 
nice
  >>try.
  >>
  >>/kc
  >>
  >>
  >>On Tue, Mar 27, 2018 at 06:10:51PM -0400, Jean-Francois Mezei said:
  >>   >Not quite networking but probably relevant.
  >>   >
  >>   >The Canadian province of Qu??bec just introduced a new budget with
  >>   >basically the intent to force foreign digital companies who sell
  >>   >services to Qu??bekers to collect the local value added sales tax and
  >>   >remit those to the QC government.
  >>   >
  >>   >The goal is to capture tax from Netflix who has so far escaped taxation
  >>   >in Canada by having no legal/physical presence in Canada, no cache
  >>   >servers of its own etc. Netflix does not currently collect province
  >>   >information from customers (or any address info for that matter).
  >>   >
  >>   >They based many of their arguments on an OECD study (which ironically
  >>   >the Canadian federal government says is not completed yet (as excuse for
  >>   >not proceeding with similar tax).
  >>   >
  >>   >So foreign digital services will be required to require subscibers enter
  >>   >AND VALIDATE their address so that they have an accurate province field
  >>   >(validation remains to be finalized), and IF they sell more than $30,000
  >>   >to Qu??bec residents, will be required to self register with QC
  >>   >government to collect local sales tax (and remit to QC government).
  >>   >
  >>   >The Qu??bec budget expects that validation of address will be based on 
IP
  >>   >address geolocation or custoemrs send paper bills to prove place of
  >>   >residence.
  >>   >
  >>   >(Although requiring full address/phone number and sendint this to credit
  >>   >card network for authorization might constitute a better means to
  >>   >validate address).
  >>   >
  >>   >I suspect the big winners will be VPN services in the USA :-)
  >>   >
  >>   >Because many ISPs span multiple provinces, IP geolocation generally
  >>   >points to their HQ address, not necessarily the province of the
  >>   >subscriber. (This is especially true for DSL in bell Canada wholesale
  >>   >where currently a single point of connection between Bell and ISP allows
  >>   >full reach of all of its DSL territory in QC/ON. For Cable, ISPs require
  >>   >different IP pools for Rogers in Ontario and Vid??otron in Ontario (with
  >>   >a couple of exceptions where Vid??otron has service in a couple fo
  >>   >Ontario towns). In Western Canada, things are harder as Shaw serves BC,
  >>   >AB, SASK and MB.
  >>
  >>--
  >>Ken Chase - m...@sizone.org Guelph Canada
  >>
  >

-- 
Ken Chase - m...@sizone.org Guelph Canada

Re: Qu??bec Sales tax

[Ken Chase]

If Netflix has no physical presence in Quebec, what the lever are they going
to use to force this? A lawsuit in  in the
US? What court is going to entertain a foreign jurisdiction's tax claim in
their court? And how would that be then enforced?

Canada has tried this before:

https://www.ctvnews.ca/business/u-s-judge-puts-halt-to-canadian-court-order-for-google-to-delist-search-results-1.3663055

Court file: https://scc-csc.lexum.com/scc-csc/scc-csc/en/item/16701/index.do

Im a big fan of Canada standing up for its sovereignty (I live here), but nice
try.

/kc


On Tue, Mar 27, 2018 at 06:10:51PM -0400, Jean-Francois Mezei said:
  >Not quite networking but probably relevant.
  >
  >The Canadian province of Qu??bec just introduced a new budget with
  >basically the intent to force foreign digital companies who sell
  >services to Qu??bekers to collect the local value added sales tax and
  >remit those to the QC government.
  >
  >The goal is to capture tax from Netflix who has so far escaped taxation
  >in Canada by having no legal/physical presence in Canada, no cache
  >servers of its own etc. Netflix does not currently collect province
  >information from customers (or any address info for that matter).
  >
  >They based many of their arguments on an OECD study (which ironically
  >the Canadian federal government says is not completed yet (as excuse for
  >not proceeding with similar tax).
  >
  >So foreign digital services will be required to require subscibers enter
  >AND VALIDATE their address so that they have an accurate province field
  >(validation remains to be finalized), and IF they sell more than $30,000
  >to Qu??bec residents, will be required to self register with QC
  >government to collect local sales tax (and remit to QC government).
  >
  >The Qu??bec budget expects that validation of address will be based on IP
  >address geolocation or custoemrs send paper bills to prove place of
  >residence.
  >
  >(Although requiring full address/phone number and sendint this to credit
  >card network for authorization might constitute a better means to
  >validate address).
  >
  >I suspect the big winners will be VPN services in the USA :-)
  >
  >Because many ISPs span multiple provinces, IP geolocation generally
  >points to their HQ address, not necessarily the province of the
  >subscriber. (This is especially true for DSL in bell Canada wholesale
  >where currently a single point of connection between Bell and ISP allows
  >full reach of all of its DSL territory in QC/ON. For Cable, ISPs require
  >different IP pools for Rogers in Ontario and Vid??otron in Ontario (with
  >a couple of exceptions where Vid??otron has service in a couple fo
  >Ontario towns). In Western Canada, things are harder as Shaw serves BC,
  >AB, SASK and MB.

--
Ken Chase - m...@sizone.org Guelph Canada

Re: How are you configuring BFD timers?

[Ken Matlock]

Right, BFD on a dark fiber link (should) be immediately detected and the
detecting end should send a cease/stop/whatever message to the remote peer
to drop the neighbor relationship.

BFD really comes into it's own in a derived circuit (such as metro-E or
other type setup) where you can have an indirect failure (traffic does not
pass, but the last mile link remains up).

Ken


On Wed, Mar 21, 2018 at 10:44 AM, Alex Lembesis <alex.lembe...@tevapharm.com
> wrote:

> Correct, Luke.
>
> Best regards,
>
> Alex
>
>
>
> -Original Message-
> From: Luke Guillory (External) [mailto:lguill...@reservetele.com]
> Sent: Wednesday, March 21, 2018 12:37 PM
> To: Alex Lembesis; Job Snijders (External); Youssef Bengelloun-Zahr
> Cc: NANOG
> Subject: RE: How are you configuring BFD timers?
>
> He's asking because if it was dark the interface would go down when the
> link was lost and the router would pull routes. But PA to FL would lead me
> to believe it'll be a wave from some type of DWDM gear which brings us to
> BFD.
>
>
>
>
>
>
> Luke Guillory
> Vice President – Technology and Innovation
>
> Tel:985.536.1212
> Fax:985.536.0300
> Email:  lguill...@reservetele.com
>
> Reserve Telecommunications
> 100 RTC Dr
> Reserve, LA 70084
>
> 
> _
>
> Disclaimer:
> The information transmitted, including attachments, is intended only for
> the person(s) or entity to which it is addressed and may contain
> confidential and/or privileged material which should not disseminate,
> distribute or be copied. Please notify Luke Guillory immediately by e-mail
> if you have received this e-mail by mistake and delete this e-mail from
> your system. E-mail transmission cannot be guaranteed to be secure or
> error-free as information could be intercepted, corrupted, lost, destroyed,
> arrive late or incomplete, or contain viruses. Luke Guillory therefore does
> not accept liability for any errors or omissions in the contents of this
> message, which arise as a result of e-mail transmission. .
>
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Alex Lembesis
> Sent: Wednesday, March 21, 2018 11:31 AM
> To: Job Snijders (External); Youssef Bengelloun-Zahr
> Cc: NANOG
> Subject: RE: How are you configuring BFD timers?
>
> To speed up BGP routing convergence.  The (2x) dark fiber links from PA to
> FL are being used as Layer3 datacenter interconnects, where each datacenter
> has its own AS.  The DF is also carrying FCIP traffic, so we need failover
> to be as fast as possible.
>
> Best regards,
>
>
>
> Alex
>
>
>
> -Original Message-
> From: Job Snijders (External) [mailto:j...@instituut.net]
> Sent: Wednesday, March 21, 2018 12:25 PM
> To: Youssef Bengelloun-Zahr
> Cc: Alex Lembesis; NANOG
> Subject: Re: How are you configuring BFD timers?
>
> Silly question perhaps, but why would you do BFD on dark fiber?
>
> Kind regards,
>
> Job
>
> This message is intended solely for the designated recipient(s). It may
> contain confidential or proprietary information and may be subject to
> attorney-client privilege or other confidentiality protections. If you are
> not a designated recipient you may not review, copy or distribute this
> message. If you receive this in error, please notify the sender by reply
> e-mail and delete this message. Thank you.
>
> This message is intended solely for the designated recipient(s). It may
> contain confidential or proprietary information and may be subject to
> attorney-client privilege or other confidentiality protections. If you are
> not a designated recipient you may not review, copy or distribute this
> message. If you receive this in error, please notify the sender by reply
> e-mail and delete this message. Thank you.
>

Re: hijacking of 128.255.192.0/22

[Ken Chase]

A reason to de-aggregate down to /24s, to make hijacks more
difficult/less effective?

/kc


On Tue, Mar 20, 2018 at 04:20:47PM -0300, Alejandro Acosta said:
  >Hi Jay,
  >
  >?? Please note that there is Lacnog mailing list.., I will forward your
  >message. Not sure if it will work but worth giving it a try.
  >
  >
  >Regards,
  >
  >Alejandro,
  >
  >
  >
  >El 20/3/18 a las 2:35 p. m., Jay Ford escribi??:
  >> Something apparently in Brazil is hijacking 128.255.192.0/22, part of
  >> 128.255.0.0/16 which is held by the University of Iowa.?? AS 263971 is
  >> announcing 128.255.192.0/22 which Hurricane Electric is accepting &
  >> propagating.?? None of that has any authorization.
  >>
  >> I can't find any decent contact information for the originating
  >> entity, so I have reported it to ab...@he.net, but it'd be fabulous if
  >> some HE folks listening here could whack the hijacking faster than the
  >> abuse channels will get to it.?? Also useful would be some functional
  >> contact for AS263971.
  >>
  >> Any help will be appreciated.
  >>
  >> 
  >> Jay Ford, Network Engineering Group, Information Technology Services
  >> University of Iowa, Iowa City, IA 52242
  >> email: jay-f...@uiowa.edu, phone: 319-335-
  >

-- 
Ken Chase - m...@sizone.org

Re: MSFT reverse IP failure?

[Ken Chase]

Im not exactly sure what this is either, the client sent me a screenshot
that called itself the "microsoft connectivity analyzer", which had several
steps testing deliverability of email to their domain, with the final test
of an actual test email delivery failing.

/kc


On Mon, Feb 26, 2018 at 11:25:59PM +, Christian Kuhtz said:
  >Ken,
  >
  >A little difficult to say what this without knowing what 13.67.59.89 
actually is.   If this is an Azure deployment, ReverseFqdn needs to be 
populated on the Public IP address resource.  Please take a look here 
https://docs.microsoft.com/en-us/azure/dns/dns-reverse-dns-for-azure-services
  >
  >Thanks,
  >Christian
  >
  >
  >-Original Message-
  >From: NANOG <nanog-boun...@nanog.org> On Behalf Of Ken Chase
  >Sent: Monday, February 26, 2018 1:31 PM
  >To: nanog@nanog.org
  >Subject: Re: MSFT reverse IP failure?
  >
  >Having a client doing a test from the MSFT exchange tools site, which is 
failing.
  >
  >NOQUEUE: reject: RCPT from unknown[13.67.59.89]: 450 4.7.1 Client host 
rejected: cannot find your reverse hostname, [13.67.59.89];
  >
  >NetRange:   13.64.0.0 - 13.107.255.255
  >CIDR:   13.96.0.0/13, 13.104.0.0/14, 13.64.0.0/11
  >NetName:MSFT
  >
  >A bit of an oversight?
  >
  >/kc
  >-- 
  >Ken Chase - m...@sizone.org Guelph Canada

Re: MSFT reverse IP failure?

[Ken Chase]

Having a client doing a test from the MSFT exchange tools site, which is 
failing.

NOQUEUE: reject: RCPT from unknown[13.67.59.89]: 450 4.7.1 Client host 
rejected: cannot find your reverse hostname, [13.67.59.89];

NetRange:   13.64.0.0 - 13.107.255.255
CIDR:   13.96.0.0/13, 13.104.0.0/14, 13.64.0.0/11
NetName:MSFT

A bit of an oversight?

/kc
-- 
Ken Chase - m...@sizone.org Guelph Canada

Google Security Contact

[Ken Gilmour]

Hi,

There is a potential vulnerability in Gmail / Google Inbox which I need to
discuss and verify with the Google Security Team. Is there anyone on that
team here on NANOG who can contact me off-list please? Best to contact me
at k...@invinsec.com.

Thanks!

Ken

Re: IPv4 smaller than /24 leasing?

[Ken Chase]

$5k aint nothing. I started with less than that (but
hung off the colo's in house bw through NAC.net til I 
could wean off it). I imagine tiny communities (and say on
remote native reserves for eg) that $5k additional expense
could be limiting.

And soon to become even harder to setup an isp?

ttps://np.reddit.com/r/technology/comments/7o41rf/the_fcc_is_preparing_to_weaken_the_definition_of/ds6w3aw/

/kc
--
Ken Chase - m...@sizone.org GUelph Canada

Re: AS PATH limits

[Ken Chase]

Ive found some other stuff that's totally busted, but screw those who havent
patched their systems. We should not help them at all as knowlegeable stewards
of big chunks of bandwidth, we should just write stuff about how silly they
are instead:

 https://www.usenix.org/system/files/conference/woot14/woot14-kuhrer.pdf

read the first table on page 3 and then explain the philosophy of not caring
about this as a general issue affecting the entire internet. That's not, to
date, been the attitude I've seen in here or elsewhere amongst admins, and I
dont see why we should start now.

(And I'd fix it _right now_, but it's at my major customer's discretion. I've
explained the risks, he's taken them to heart. He too is an actual seasoned
admin (with quagga experience), but turned off his AS least year and got out of
the game. He has his reasons for waiting a bit longer.)

/kc


On Fri, Dec 22, 2017 at 11:11:44PM +, Nick Hilliard said:
  >William Herrin wrote:
  >> On Fri, Dec 22, 2017 at 5:45 PM, Nick Hilliard <n...@foobar.org> wrote:
  >> If you've been hit with a known service-affecting problem that can
  >> easily recur without warning and which will be service affecting if it
  >> hits again, common sense suggests that it would be a good idea to
  >> upgrade to a version of code which isn't affected.
  >> 
  >> Well, that's a brilliant platitude, but what do you do when it breaks
  >> over and over until the other guy upgrades?
  >
  >I dunno, maybe shake our fists and rage a bit about the existence of
  >service affecting bugs?  It's not like we haven't all been in this
  >position at one stage or another.
  >
  >The point was, though, that there's been several months since this bug
  >was discussed on nanog-l way back in balmy september, and given the fact
  >that it can completely wipe out connectivity without warning for those
  >affected, it would have been a good idea to deal with the problem in an
  >orderly way at the time rather than letting it interfere with eggnog and
  >seasonal good cheer, at one of the times of year where chunks of the
  >world are busy taking well-deserved holidays.
  >
  >On which point, seasonal cheers to all.
  >
  >Nick
  >

-- 
Ken Chase - k...@heavycomputing.ca skype:kenchase23 +1 416 897 6284 Toronto 
Canada
Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front 
St. W.

Re: AS PATH limits

[Ken Chase]

Push harder on upgrading. "Dec 30" is my earliest window I got from my customer
after previously pushing with previous events (didnt help that Cogent said "yeah
we agree these are silly, we'll be filtering more aggressively" -- this time it
snuck in from the less busy side of our network).

It's not even going to be service impacting, if we do everything correctly,
but *who knows for sure* :) Course more long path events occurring ARE service
impacting more than the risk during upgrade, so go figure.

Customers! Cant live with em, cant afford to live without em!

Nonetheless, I do think that backbones should be filtering ridiculous AS paths
just as a matter of course. Everyone fix their own stuff, and everyone help
the next guy downstream by stomping on sillyness. Generally been an internet 
mindset
that I've seen since even before the great renaming...

/kc


On Fri, Dec 22, 2017 at 05:50:36PM -0500, William Herrin said:
  >On Fri, Dec 22, 2017 at 5:45 PM, Nick Hilliard <n...@foobar.org> wrote:
  >
  >> William Herrin wrote:
  >> > The AS path lengths we're talking about are unreasonable.
  >>
  >> "unreasonable" is a peculiar word to use here :-)
  >>
  >> It's the internet and you can't expect other people not to do silly
  >> things from time to time.  This is a known problem and it isn't even the
  >> first time it's been discussed on nanog-l.
  >>
  >> If you've been hit with a known service-affecting problem that can
  >> easily recur without warning and which will be service affecting if it
  >> hits again, common sense suggests that it would be a good idea to
  >> upgrade to a version of code which isn't affected.
  >
  >
  >Well, that's a brilliant platitude, but what do you do when it breaks over
  >and over until the other guy upgrades?
  >
  >-Bill
  >
  >
  >
  >
  >-- 
  >William Herrin  her...@dirtside.com  b...@herrin.us
  >Dirtside Systems . Web: <http://www.dirtside.com/>

/kc
--
Ken Chase - m...@sizone.org Guelph Canada

Re: AS PATH limits

[Ken Chase]

quagga 0.99.22.4, yes i need to upgrade, as my other
router on 0.99.23.1 seems ok. now coordinating with
customers to get it upgraded is a different issue.

/kc


On Fri, Dec 22, 2017 at 05:40:28PM +, Nick Hilliard said:
  >What router software version are you running that barfs on long as-paths?
  >
  >Nick
  >
  >Ken Chase wrote:
  >> And again this morn at 08:35:19 EST (13:35 UTC). I dont have access to the
  >> router that fed us the long route, so I cant tell what it was (since we 
never
  >> consumed it before barfing).
  >> 
  >> Let's hope for no more over holiday season...
  >> 
  >> /kc
  >> 
  >> 
  >> On Fri, Oct 13, 2017 at 05:02:42PM -0400, Ken Chase said:
  >>   > It is happening AGAIN.
  >>   >
  >>   >And of course it started on a friday aft 15 min before quittin' time in 
EDT:
  >>   >
  >>   >Last time it was 186.177.184.0/23   0 174 262206 262206 262197 262197 
  >>   >
  >>   >*> 186.176.186.0/23 38.x.x.x 45050 0 174 262206 
262206 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
  >262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262
  >197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197
  > 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 2

Re: AS PATH limits

[Ken Chase]

And again this morn at 08:35:19 EST (13:35 UTC). I dont have access to the
router that fed us the long route, so I cant tell what it was (since we never
consumed it before barfing).

Let's hope for no more over holiday season...

/kc


On Fri, Oct 13, 2017 at 05:02:42PM -0400, Ken Chase said:
  > It is happening AGAIN.
  >
  >And of course it started on a friday aft 15 min before quittin' time in EDT:
  >
  >Last time it was 186.177.184.0/23   0 174 262206 262206 262197 262197 
  >
  >*> 186.176.186.0/23 38.x.x.x 45050 0 174 262206 262206 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 ?
  >
  >/kc
  >--
  >Ken Chase - m...@sizone.org Guelph Canada

-- 
Ken Chase - m...@sizone.org Guelph Canada

Re: Static Routing 172.16.0.0/32

[Ken Chase]

Right - usage of network and broadcast addresses will suddenly make all the
ToiletPaperLink devices upgrade themselves to a new firmware that the devs
released posthaste to handle them properly...

I like your upgrade-by-force ideas! (no, I do. Screw bad implimentations, let 
them
be binned!) (Tell me about your v6 adoption plans now.)

The Win95 thing was just a personal example of how these things can express
themselves...  was a good laugh at the time. The incidence and hilarity of
similar events has not materially changed in the intervening decades, we'll
all note.

Have fun with your .0's people! Let us know how your support dept likes em.

/kc

On Fri, Dec 08, 2017 at 10:47:09PM +, Job Snijders said:
  >On Fri, Dec 8, 2017 at 10:44 PM, Ken Chase <m...@sizone.org> wrote:
  >> why not use 192.0.2.0/24 addrs?
  >>
  >> lots of other ranges you could probably use safely.
  >>
  >>https://en.wikipedia.org/wiki/Reserved_IP_addresses
  >>
  >> Using .0 you're asking to exercise bugs and undefined implimentation 
choices
  >> of various tcp stacks and resolvers out there on myriad devices. Clever 
collision
  >> avoidance, but relies on a prayer.
  >
  >Please stop spreading Fear, Uncertainty and Doubt about valid CIDR
  >addresses. :-)
  >
  >> (IIRC try setting an NS record to resolve to 127.0.0.255 on windows 95 - it
  >> used to lock the OS up fun times. Someone had pointed some popular 
domain
  >> at us by accident, and having no entry and no negative caching of the day
  >> meant we were being hammerred on our 10mbps uplink, had to set something to
  >> get cached, so we did... several hours later a microsoft engineer called us
  >> and pleaded with us to use a different IP. :)
  >
  >Microsoft ended support for Windows 95 on December 31th 2001
  >
  >Kind regards,
  >
  >Job

-- 
Ken Chase - Guelph Canada

Re: Static Routing 172.16.0.0/32

[Ken Chase]

why not use 192.0.2.0/24 addrs?

lots of other ranges you could probably use safely.

   https://en.wikipedia.org/wiki/Reserved_IP_addresses

Using .0 you're asking to exercise bugs and undefined implimentation choices
of various tcp stacks and resolvers out there on myriad devices. Clever 
collision
avoidance, but relies on a prayer.

(IIRC try setting an NS record to resolve to 127.0.0.255 on windows 95 - it
used to lock the OS up fun times. Someone had pointed some popular domain
at us by accident, and having no entry and no negative caching of the day
meant we were being hammerred on our 10mbps uplink, had to set something to
get cached, so we did... several hours later a microsoft engineer called us
and pleaded with us to use a different IP. :)

/kc


On Fri, Dec 08, 2017 at 05:25:58PM -0500, William Herrin said:
  >On Fri, Dec 8, 2017 at 4:50 PM, Ryan Hamel <ryan.ha...@quadranet.com> wrote:
  >>
  >> I'm not implying HTTP, I'm implying a static route at each sites private
  >layer 3 router (it'll move to BGP in the future). The repository server
  >listens on the IP as well.
  >>
  >> My original question was the fact of using 172.16.0.0/32 as a usable IP
  >address (not even caring about anycast).
  >
  >> Internal private network that is reachable by clients.
  >
  >Hi Ryan,
  >
  >Clients meaning employee computers or clients meaning other networks who
  >subscribe to your service and connect with a VPN?
  >
  >The the former, save yourself grief and use a different /32.
  >
  >For the latter, it's semi-clever. It neatly avoids the problem of customers
  >using the same RFC1918 addresses as you. Even if they're using a subnet
  >like 172.16.0.0/24, a /32 route can usually override that one address
  >without ill effect.
  >
  >It's only semi-clever because the .0 address is a corner case in the code
  >and corner cases are where bugs are most likely to happen.  And if you're
  >sending clients from that address to another host with a regular 172.16
  >address anyway...
  >
  >Regards,
  >Bill Herrin
  >
  >
  >
  >
  >>
  >>
  >>  Original message 
  >> From: William Herrin <b...@herrin.us>
  >> Date: 12/8/17 1:45 PM (GMT-08:00)
  >> To: Ryan Hamel <ryan.ha...@quadranet.com>
  >> Cc: nanog@nanog.org
  >> Subject: Re: Static Routing 172.16.0.0/32
  >>
  >> On Fri, Dec 8, 2017 at 4:37 PM, Ryan Hamel <ryan.ha...@quadranet.com>
  >> wrote:
  >> > 1. A single known ip address that redirects to the closest internal repo
  >> server. 172.16.0.0/32 redirects to a usable subnet ip in 172.16.xx.xx by
  >> static route.
  >>
  >> Hi Ryan,
  >>
  >> Maybe if would help if you write the extended version because that's about
  >> as clear as mud. First you asked about routing. Now you imply HTTP.
  >>
  >> Regards,
  >> Bill Herrin
  >>
  >>
  >> --
  >> William Herrin  her...@dirtside.com  b...@herrin.us
  >> Dirtside Systems . Web: <http://www.dirtside.com/>
  >>
  >
  >
  >
  >-- 
  >William Herrin  her...@dirtside.com  b...@herrin.us
  >Dirtside Systems . Web: <http://www.dirtside.com/>

-- 
Ken Chase - m...@sizone.org Guelph Canada

Re: BGP next-hop self benefits

[Ken Chase]

On an IX, without next-hop-self peer A leaking peer B's routes they receive to
C will have C send direct to B on the IX (assuming flat layer 3 addressing,
and not multiple little /30s or /96s everywhere or something - do any
exchanges do that?)

This may seem more efficient than sending C's traffic to A to get to B (pumping 
up
the IX's usage graphs) but B may not have peering agreements with C.

Setting next-hop-self avoids this. An 'advantage' in some views. Not related to
n-h-s in an igp specifically, but an interesting (mis)use case.

/kc


On Fri, Dec 01, 2017 at 03:06:34PM +, craig washington said:
  >Hello everyone,
  >
  >
  >Question, what are the true benefits to using the next-hop self feature, 
doesn't matter what vendor.
  >
  >Most information I see is just to make sure you have reach-ability for 
external routes via IBGP, but what if all your IBGP knows the eBGP links?
  >
  >Is there a added benefit to using next hop self in this situation?
  >
  >
  >Any feedback is much appreciated, either for the question specifically or 
whatever else you got , L3VPN's or underlying technology that has to have 
that.
  >
  >
  >Thanks
  >
  >

-- 
Ken Chase - m...@sizone.org Guelph Canada

Re: Arista Layer3

[Ken Chase]

  >Arista DCS-7280SRA-48C6 is a 1ru box.??
  >
  >Has a nominally million route fib, Jericho+ 8GB of packet buffer.
  >control-plane is 8GB of ram andAMD GX-424CC SOC which is 4 core 2.4ghz.
  >We do direct fib injection with bird rather than the arista bgpd but the
  >control-plane is capable of managing quite a few bgp sessions.
  >
  >the 1/2ru 7280CR2K-30 and 60 are 2m route fib boxes with still heftier
  >control planes but they're a different class of box being all 100G and
  >requiring multi-chip/internal fabrics.

Sounds pretty good - hows your power draw on that thing? Why'd you pick Bird
in this case?

/kc


  >> /kc
  >>
  >> On Thu, Nov 30, 2017 at 10:45:09AM -0800, Tyler Conrad said:
  >>   >For Enterprise/DC, it works great. For service provider, they're not 
100%
  >>   >yet. The main issue is going to be around VRFs, as there's no 
interaction
  >>   >between them (at least in the code version I'm on, that may have changed
  >>   >recently or be changing soon). They'll work great as a P-Router, but if 
you
  >>   >need a PE with route leaking I'd look at another vendor.
  >>   >
  >>   >I use a couple pairs of 7280SRs as edge routers/border leaves. Multiple
  >>   >full table feeds without any issue.
  >>   >
  >>   >On Thu, Nov 30, 2017 at 10:36 AM, Romeo Czumbil 
>   >> wrote:
  >>   >
  >>   >> So I've been using Arista as layer2 for quite some time, and I'm 
pretty
  >>   >> happy with them.
  >>   >> Kicking the idea around to turn on some Layer3 features but I've been
  >>   >> hearing some negative feedback.
  >>   >> The people that I did hear negative feedback don't use Arista 
themselves.
  >>   >> (they just heard)
  >>   >>
  >>   >> So do we have any Arista L3 people out here that can share some 
negatives
  >>   >> or positives?
  >>   >>
  >>   >> Use case: Just some MPLS IPv4/IPv6 routing, l2vpn OSPF/BGP
  >>   >> Maybe 20k routes (no full internet routes)
  >>   >> 7050 Series
  >>   >> 7280 Series
  >>   >>
  >>   >> -Romeo
  >>   >>
  >>
  >
  >

Re: Arista Layer3

[Ken Chase]

Thx. Rather steer clear of microtik for now however.

Guess I shoulda mentioned a baseline 10G capability at least on 4 sfp+ ports
(I know there's some 2port Microtiks too). Everyone's got gig-to-the-home now,
I can't see how anyone plans 1G PE builds anymore. They'll be obsolete by the
time they're plugged in (10G for any medium sized op is almost obsolete 
already.)

/kc


On Thu, Nov 30, 2017 at 02:32:14PM -0500, Jared Mauch said:
  >
  >
  >> On Nov 30, 2017, at 2:17 PM, Ken Chase <m...@sizone.org> wrote:
  >> 
  >> Back to this discussion! :) Arista as a viable full-table PE router. Was 
hoping
  >> for better experience reports since last mention.
  >> 
  >> To make the Q bit more general, are there any PE routers yet that can 
handle 3-8
  >> full feeds and use an amp and 1U or so instead of 5 and 4U? Or we're ito 
whitebox/
  >> open routers still for that (bird/openbgp?) or microtiks?
  >
  >The 7280 is likely what you???re looking at.  Lots of folks also use 
MikroTik as well if
  >the traffic is in the 1G range or so.
  >
  >I for one use Arista for Layer3 for FTTH purposes as it gives me good 
software/hardware
  >support for my features.
  >
  >- Jared

Re: Incoming SMTP in the year 2017 and absence of DKIM

[Ken O'Driscoll]

On Wed, 2017-11-29 at 12:24 -0500, William Herrin wrote:
> Alright, so "horribly broken design" overstates the case but there are
> enough problems that weighting the absence of DKIM at something other
> than zero will surely do more harm than good.

+1. A DKIM signature by itself means nothing more than someone had the
ability to configure DKIM on an email server.

The signing domain (d=) is what matters as the signer needs access to the
zone in order to be able to publish the key, which may be interpreted as an
indication of trust.

DMARC requires the signing domain to be either exactly the same or share
the same organisational unit with the From address for this reason.

Even without DMARC, a receiver *could*, depending on the signing domain,
choose to interpret it as a positive signal. This is marginally better than
treating any DKIM signature or the absence thereof as a signal of any kind.

Personally, unless an author domain is publishing a DMARC policy of reject
or quarantine, I don't think recipients should be scoring based on DKIM at
all, perhaps with the exception of signing with a revoked key.

Ken.

-- 
Ken O'Driscoll / We Monitor Email
t: +353 1 254 9400 | w: www.wemonitoremail.com

Need to understand deliverability? Now there's a book:
www.wemonitoremail.com/book

keeping your cabinet clean (was Re: Looking for help @ 60 Hudson)

[Ken Chase]

a single U rail sandwiched in with no other access can be nearly impossible,
especially an old EOL one with no identifying marks to google.

Try to rack similar depth gear together. Nothing like having 1U 27" long
Intels sandwiching 1U of 3/4 depth supermicro between them - cant get your
hands in to do anything. 2U minimum together, but 3+ is better. Stash a headlamp
in the rack too to see into these wells.

Having more switchports than necessary (3 redundant 48 port switches with avg
2xc/box, avg 1.5U per box, 42U cabinet) allows 4' ethernet cables to be put in 
at
exactly 3.75' extension into a switchport - minimal extra slack, just enough
to manage the cable and keep it unstressed.  Folding spare cable into
management ladders makes manual tracing hard, and is bad form. Crimping your
own rj45 ends for exact lengths is risky. Done it many times (and once saw a 
tech do
it before a bgp session timed out on a damaged live cable! :), but results are
poorer than factory crimps and dont resist stress well. ('Sides, do you have 8
different colour spools? See below.)

Switch racking - I'd rather them on shelves not ears - then you can pull out
your backwards-facing switch ass-first from front of the cabinet and slide the
replacement in without moving cables too far -- trying to get the ears past
the cabling can be heinous (and most ears cause major cantilevering due to
deep heavy switches - after a few years I find things are bent from weight,
impinging on the U below). There are thin little 3" wide rail-edge 'shelves'
you can get, but your switch may not give the spare vertical mm required
(about 3-4mm) - works best with 2u+ sized gear where there's spare mm play.

Proper cable management trays/guides between the switches is great too (though
eats U). Your density/financials will determine if that's viable. Its worth
the U/sanity usually.

Out of U for cable mgmt but have spare depth? Bungee cords won't work as
anchor points to ziptie too - they sag in the heat over time. But rubber
bungees ('tarp straps') work great.

Though not for full 100m ether lengths, narrow gauge ethernet is key.  You can
fit like 8-12 of them into a run of what 4-5 took previously. I've had zero
issues with them with rack-lengths of cable. Worth the $.

I wish there was thin bicolour ethernet - it's sexy to have all your ether
coloured the same (or same per category - red mgmt, yellow public, white
internal) -- but then you need to know where the failed port 34 cable is...
tracing identically coloured cables can suck, your eyes start playing tricks
looking at 30 cables in a twisting bundle that you ziptied too tight trying to
be pretty - and under tension, yanking on them may not identify the right
cable properly -- even with labels (you stop trusting them anyway after the
first couple errors or when job security is thin).

I tend to use as many random colours as possible -- and note it in the switch
configs. If the switch config doesnt match, slow down and check things twice
from scratch. (Keep many colours and lengths handy for new installs! Blue is so
ugly - peach ftw, amirite?).

Note that no pattern of colour use will work - wire all mgmt ports as one 
colour,
or all ports of one server one colour - either way, you assume the colour means 
the cable is wired a certain way, and that leads to errors. With no pattern,
no dangerous assumptions are made - must check with the switch config. Maxing 
out
#s of different colours leads to easier identification/fewer chances of 
neighbouring
cables of same colour.

If the management layer of your company doenst have to slave over racks, this
is likely not an option. They like the pretty and impractical stuff best of 
course.

Labelling only works so well - in 100-120F exhaust paths most glue just melts
off. One client I had no input on the install for has 100s of little silvery
labels littering the floor/lower U of their cabinet. So pretty! And goey
cables. And thank god they're all white! Makes tracing so easy! :P

(Of course no one ever wires black ethernet, right? That's a capital offence!)

/kc


On Mon, Nov 13, 2017 at 05:05:35PM -0500, Chuck Anderson said:
  >On Mon, Nov 13, 2017 at 01:30:25PM -0800, Seth Mattinen wrote:
  >> On 11/13/17 12:49, Mike Hammett wrote:
  >> >Keep the humans out of the rack and you should be fine.
  >> >
  >> >Where should I send the invoice?:-P
  >> 
  >> 
  >> It's easy to keep a rack nice if you take the time. I've spent hours
  >> removing and replacing cables in neatly dressed bundles because
  >> equipment changes required a different length/type cable, but
  >> sometimes that's what you gotta do to keep things neat and tidy.
  >
  >Exactly.  Most people do not want to spend the time to do it properly.

--
Ken Chase - m...@sizone.org Guelph Canada

Re: AS PATH limits

[Ken Chase]

 It is happening AGAIN.

And of course it started on a friday aft 15 min before quittin' time in EDT:

Last time it was 186.177.184.0/23   0 174 262206 262206 262197 262197 

*> 186.176.186.0/23 38.x.x.x 45050 0 174 262206 262206 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 ?

/kc
--
Ken Chase - m...@sizone.org Guelph Canada

replacing compromised biometric authenticators

[Ken Chase]

(forking the thread here..)

Biometrics are still the new hotness out in North America. Cologix whom I deal
with in Canada has a dozen and a half odd POPs in canada/usa and I think has
fingerprinting at all sites.

If the current best operating practice is to avoid biometrics, why are they
still in use out here? Has anyone gotten the message? Is anyone in North America
ripping them out yet?

Other factors include your country's privacy regulations for storing
irreplaceable personal information, the burden of which might not be worth
the security 'benefit'.

/kc


On Wed, Oct 11, 2017 at 04:46:02PM -0400, William Herrin said:
  >On Wed, Oct 11, 2017 at 4:32 PM, J??rg Kost <j...@ip-clear.de> wrote:
  >
  >> Do you guys still at least have biometric access control devices at your
  >> Level3 dc? They even removed this things at our site, because there is no
  >> budget for a successor for the failing unit. And to be consistent, they
  >> event want to remove all biometric access devices at least across Germany.
  >>
  >
  >Hi  J??rg,
  >
  >IMO, biometric was a gimmick in the first place and a bad idea when
  >carefully considered. All authenticators can be compromised. Hence, all
  >authenticators must be replaceable following a compromise. If one of your
  >DCs' palm vein databases is lost, what's your plan for replacing that hand?
  >
  >Regards,
  >Bill Herrin
  >
  >
  >-- 
  >William Herrin  her...@dirtside.com  b...@herrin.us
  >Dirtside Systems . Web: <http://www.dirtside.com/>

-- 
Ken Chase - m...@sizone.org Guelph Canada

Re: Temp at Level 3 data centers

[Ken Chase]

As temp goes up wire resistance increases too, increasing heat, increasing
resistance, etc - and I find breakers trip more easily at hotter temps too.

/kc


On Wed, Oct 11, 2017 at 01:08:33PM -0400, Zachary Winnerman said:
  >That's a good point, though if you are running your breakers that close
  >I think you have bigger problems, as a power outage, however unlikely,
  >could cause your equipment to not come back up at all. Software updates
  >that reboot several servers in quick succession could also cause a
  >breaker to trip under those circumstances. Unfortunately, there's no way
  >to tell how close a breaker is to tripping without tripping it. Breakers
  >may have amp meteres and a rated size, but the actual load before
  >tripping is +-20% for common models, meaning a 20A breaker may trip as
  >low as 16A.

-- 
Ken Chase - m...@sizone.org Guelph Canada

Re: Temp at Level 3 data centers

[Ken Chase]

My house isnt built for moving furniture, it's built for living in. I've not
moved a bed in or out of the bedroom in 8 years now. But for the 15 minutes
I did move a bed, the door and hallway had to accomodate it.

Humans have to go into datacenters - often in an emergency. Complicating the
servicing of equipment by having sweat drip off you into the electronics is
not condusive to uptime.

/kc

On Wed, Oct 11, 2017 at 03:45:30PM +, Keith Stokes said:
  >There are plenty of people who say 80+ is fine for equipment and data 
centers aren???t built for people.
  >
  >However other things have to be done correctly.
  >
  >Are you sure your equipment is properly oriented for airflow (hot/cold 
aisles if in use) and has no restrictions?
  >
  >On Oct 11, 2017, at 9:42 AM, Sam Kretchmer 
<s...@coeosolutions.com<mailto:s...@coeosolutions.com>> wrote:
  >
  >with a former employer we had a suite at the L3 facility on Canal in
  >Chicago. They had this exact issue for the entire time we had the suite.
  >They kept blaming a failing HVAC unit on our floor, but it went on for
  >years no matter who we complained to, or what we said.
  >
  >Good luck.
  >
  >
  >On 10/11/17, 7:31 AM, "NANOG on behalf of David Hubbard"
  ><nanog-boun...@nanog.org<mailto:nanog-boun...@nanog.org> on behalf of 
dhubb...@dino.hostasaurus.com<mailto:dhubb...@dino.hostasaurus.com>> wrote:
  >
  >Curious if anyone on here colo??s equipment at a Level 3 facility and has
  >found the temperature unacceptably warm?  I??m having that experience
  >currently, where ambient temp is in the 80??s, but they tell me that??s
  >perfectly fine because vented tiles have been placed in front of all
  >equipment racks.  My equipment is alarming for high temps, so obviously
  >not fine.  Trying to find my way up to whomever I can complain to that??s
  >in a position to do something about it but it seems the support staff
  >have been told to brush questions about temp off as much as possible.
  >Was wondering if this is a country-wide thing for them or unique to the
  >data center I have equipment in.  I have equipment in several others from
  >different companies and most are probably 15-20 degrees cooler.
  >
  >Thanks,
  >
  >David
  >
  >
  >
  >---
  >
  >Keith Stokes
  >
  >
  >
  >

/kc
--
Ken Chase - m...@sizone.org Guelph Canada

Re: AS PATH limits

[Ken Chase]

Got this reply from cogent:

"We have isolated a BGP Routing discrepancy on the Backbone. That routing has 
been removed 
from the Network."

So apparently they agree they shouldn't just accept this bogosity. Good on em.

/kc
-- 
Ken Chase - m...@sizone.org Guelph Canada

Re: AS PATH limits

[Ken Chase]

I don't quite understand the exact situation that causes the issue - our
cogent facing router (quagga .99.22 debian) was receiving the route but that
session stayed up - it was it while sending or the other igp router (also
quagga .99.22) receiving (I think the latter) that was crashing their session.
Not quite sure why the cogent session didn't crash as well (or first, before
propagating the bad route).

At any rate, we should likely take this discussion to the quagga-users-l

/kc


On Sat, Sep 30, 2017 at 09:28:28PM -0400, Christopher Morrow said:
  >ii  quagga  0.99.22.4-3ubu i386   BGP/OSPF/RIP routing
  >daemon
  >
  >interestingly enough that isn't crashlooping nor is it bouncing bgp
  >sessions:
  >192.168.100.100  4 MYASN 16427178864000 2d23h32m
  >672475
  >
  >and it's happily showing me the route even...

-- 
Ken Chase - m...@sizone.org Guelph Canada

Re: Long BGP AS paths

[Ken Chase]

The quagga thread I read specifically indicates that some (most?) versions don't
accept the {n,m} regexp repeat format. Thus the regexps as long as the
path you want to filter... :/

..or upgrade.

/kc


On Sat, Sep 30, 2017 at 06:29:36PM -0400, William Herrin said:
  >To the chucklehead who started announcing a 2200+ byte AS path yesterday
  >around 18:27 EDT, I beg of you: STOP. You've triggered a bug in Quagga
  >that's present in all versions released in the last decade. Your
  >announcement causes routers based on Quagga to send a malformed update to
  >their neighbors, collapsing the entire BGP session. Every 30 seconds or so.
  >
  >For everyone else: please consider filtering BGP announcements with
  >stupidly long AS paths. There's no need nor excuse for them to be present
  >in the DFZ and you could have saved me a painful Saturday.
  >
  >Cisco:
  >
  >router bgp XXX
  > bgp maxas-limit 50
  >
  >
  >Juniper:
  >https://kb.juniper.net/InfoCenter/index?page=content=KB29321
  >
  >
  >Quagga:
  >
  >ip as-path access-list maxas-limit50 deny ^([{},0-9]+ ){50}
  >ip as-path access-list maxas-limit50 permit .*
  >
  >
  >Regards,
  >Bill Herrin
  >
  >
  >-- 
  >William Herrin  her...@dirtside.com  b...@herrin.us
  >Dirtside Systems . Web: <http://www.dirtside.com/>

-- 
Ken Chase - m...@sizone.org Guelph Canada

Re: AS PATH limits

[Ken Chase]

I dont see that as the solution. Someone else will offend again.

However, I also don't see trusting major backbones as our filters (for many
other reasons). Our software should be handling what's effectively a buffer 
overflow
or equivalent (beware long paths that are actually shellcode).

Quagga among others seems to be subject to this bug, pre 0.99.23 or so
(.99.24+ seems ok). So upgrading is a solution.

There was also some chatter on the quagga mailing list on how it's more
pleasant to stab your eyeballs out rather than constructing extremely long
regexp's that might work as a filter.

https://lists.quagga.net/pipermail/quagga-users/2017-September/thread.html

/kc


On Sat, Sep 30, 2017 at 05:30:03PM +0200, Niels Raijer said:
  >My message to NANOG about this from 12:31 UTC today is still in the 
moderation queue. I had opened a support case with Cogent before writing my 
message to NANOG and Cogent has let me know approximately 40 minutes ago that 
they have contacted their customer. 
  >
  >Niels 
  >
  >
  >
  >On 30 Sep 2017, at 17:09, sth...@nethelp.no wrote:
  >
  >>> If you're on cogent, since 22:30 UTC yesterday or so this has been 
happening
  >>> (or happened).
  >> 
  >> Still happening here. I count 562 prepends (563 * 262197) in the
  >> advertisement we receive from Cogent. I see no good reason why we
  >> should accept that many prepends.
  >> 
  >> Steinar Haug, Nethelp consulting, sth...@nethelp.no
  >

-- 
Ken Chase - m...@sizone.org  Guelph Canada

Re: AS PATH limits

[Ken Chase]

If you're on cogent, since 22:30 UTC yesterday or so this has been happening
(or happened).

*> 186.177.184.0/23 38.*.*.*45050 0 174 262206 262206 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 ?

oddly, i see other pops with 174 sources giving a more sane route (even 6939
is giving us a route that goes thru 174 after 2 hops). 'Sup, 174?

Wonder if this is just stuck in the router Im looking at and the update
process is failing because the route is too long to process properly for
removal or something. mmm, bugs!)

/kc
-- 
Ken Chase - m...@sizone.org Guelph Canada

Re: 2017 NANOG Elections General Information

[Ken Matlock]

Yep, I've been in this industry since.. '94 or so, and the absolute number
one reason that I do not participate in NANOG is that even going back as
far as I can remember it's been a good-old-boy's club.

Yes, there are some very smart people that speak up, but I see time and
time again the cliques and good-old-boys club mentality inherent in NANOG.
And because of this, the thinking and mindset of NANOG in general will (in
my opinion) never change.

As you mention there is definitely a 'cool kids' or Ivory tower mentality.
And I'm not sure that it really *can* be fixed and more welcoming of newer
members without risking alienating the old guard. So for the most part I
tease out the nuggets of wisdom I can, and ignore most of the mindless
arguments that we have been over time and time again about.

Ken


On Sun, Sep 10, 2017 at 6:00 PM, Scott Weeks <sur...@mauigateway.com> wrote:

>
> --- br...@shout.net wrote:
> From: Bryan Holloway <br...@shout.net>
>
> Had I been a first-time attendee, I would've felt like a
> high-school freshman being told who all the "cool seniors"
> were.
>
> Frankly, it was awkward and off-putting.
> ---
>
> Not only first time attendees, but also long time list
> participants are made to feel that way; me included for
> making comments about vendor spam or top posting.  I note
> that not only randy is doing what he says, but other old
> schoolers are now gone (such as vixie, li and others) who
> are folks that a person could learn a lot from.
>
> scott
>
> ps.  I always shot peas at the "cool kids" table in the
> lunch room in high school.  From time-to-time I want
> virtual peas to shoot now days...  >;-)
>

Re: Bell outage

[Ken Chase]

And can be hard to know without serious dilligence - two of our upstreams
happened to go through the same 360 networks conduit in montreal that "saw
significant rodent activity". Both were down for 6 hours. A couple customers
had some custom apps that relied on the two, each as redundancy to the other.

That didnt work out.

Getting salesdroids to give you the info can be very hard though, and even
tech dept's may not know what secondary providers their fibres run through or
where, readily.

/kc

On Fri, Aug 04, 2017 at 02:57:22PM -0400, Alain Hebert said:
  >Well,
  >
  >Saying they provided you with geographically diverse circuits versus
  >actually doing it, happen way too often.
  >
  >-
  >Alain Hebertaheb...@pubnix.net
  >PubNIX Inc.
  >50 boul. St-Charles
  >P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
  >Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

-- 
Ken Chase - m...@sizone.org Guelph Canada

Re: Multicom Hijacks: Do you peer with these turkeys (AS35916)?

[Ken Chase]

RIPE or one of dem dere responsible RIRs should hire him. 

I got a sales call in a few weeks with NTT, let's see if Job is successful
and then I can be duly impressed and even more interested in their products.

This shit actually matters, sometimes.

/kc

On Thu, Aug 03, 2017 at 12:23:51PM +0200, Job Snijders said:
  >Dear Ronald,
  >
  >Thanks for your report, we'll investigate.
  >
  >Kind regards,
  >
  >Job

-- 
Ken Chase - m...@sizone.org Guelph Canada

Re: Reporting/fixing broken airport/hotel/etc wifi?

[Ken Chase]

port 53 seems to be the biggest hole available, no one figures that anyone
will send actual data over port 53, other than DNS! (and they [have to] leave
TCP open, because of the nice handywavy implimentations of dns lookups :)

some captive portals intercept all IP traffic regardless of dns, others
intercept the DNS first and give some captive IP target instead for your cnn.com
lookup. The former are easy to send data over. 

(the latter sometimes you can put your targets into your HOSTS[.txt] file and
get there, though today most webpages are 250 urls from 45 different domains,
so have fun.)

$ apt-cache search iodine
iodine - tool for tunneling IPv4 data through a DNS server

http://code.kryo.se/iodine/

Sshuttle looks great thanks

/kc


On Fri, Jul 14, 2017 at 06:02:10PM -0400, Eric Tykwinski said:
  >
  >> On Jul 14, 2017, at 5:04 PM, Ken Chase <m...@sizone.org> wrote:
  >> 
  >> 
  >> This is exactly why i have SSHd on port 443 and 53 on one of my boxes/IPs. 
Once
  >> I got SSH sky's the limit on what I can fix/setup/tunnel.
  >> 
  >> /kc
  >> --
  >> Ken Chase - m...@sizone.org Guelph Canada
  >
  >This is my usual workaround as well.  
  >Props to Avery Pennarun: http://sshuttle.readthedocs.io/en/stable/index.html
  >for making my life even easier.
  >

-- 
Ken Chase - m...@sizone.org Guelph Canada

Re: Reporting/fixing broken airport/hotel/etc wifi?

[Ken Chase]

This is exactly why i have SSHd on port 443 and 53 on one of my boxes/IPs. Once
I got SSH sky's the limit on what I can fix/setup/tunnel.

/kc

On Fri, Jul 14, 2017 at 01:43:21PM -0700, Eric Kuhnke said:
  >I've found many times it's the other way around, with highly restrictive
  >captive portals that only allow traffic to 80 and 443. This is exactly the
  >reason why I have an OpenVPN server running in tcp mode (not udp) on 443.
  >
  >
  >On Fri, Jul 14, 2017 at 1:33 PM, Christopher Morrow <morrowc.li...@gmail.com
  >> wrote:
  >
  >> Was there a list of folks collecting to provide fix actions for
  >> hotel/airport/etc?
  >>
  >> Seems that IAD / Washington Dulles don't like "random" tcp/443 sites on the
  >> internet?  173.194.205.129
  >>
  >> for instance, ping, traceroute, http but no https :(
  >> https works just fine from lots of other places on the tubes... just not
  >> the dulles wifi.
  >>
  >> -chris
  >>

--
Ken Chase - m...@sizone.org Guelph Canada

Re: Some advice on IPv6 planning and ARIN request, please

[Ken Chase]

60 sites? Just ask for a /32.

/kc


On Fri, Jul 07, 2017 at 01:07:54PM -0400, Oliver O'Boyle said:
  >Hello,
  >
  >If anyone out there could provide some input or advice on how to best
  >handle our upcoming leap into IPv6, it would be much appreciated. I want to
  >make sure we're playing nicely and not causing anyone any unnecessary grief
  >before we deploy. We're currently in the planning stage and can make
  >whatever changes we need to.
  >
  >Situation:
  >
  >We're an end-user org and qualify for a /40 assignment because we operate
  >over 60 sites and some of those are/will be multihomed. We manage hotels in
  >Canada only, but from coast to coast to coast and everywhere in between.
  >Our corporate network and org structure is optimized for three regions. We
  >also have, and continue to grow into, cloud infrastructure and foresee
  >wanting to bring our own addresses (.e.g., to AWS VPC when that option
  >becomes available). As such, an obvious design strategy would be to break
  >the /40 into 4 x /42's. However, due to an imbalance in national site
  >distribution, 50% of our sites are located in one region (Region A).
  >Additionally, historical and forecasted growth indicates that it's
  >perfectly reasonable for us to expect growth of an additional 16 sites in
  >that same region over the next 3-5 years.
  >
  >We would prefer to summarize at the /42 level, announced from our last-mile
  >providers. There are 3 primary last-mile providers so this strategy would
  >help significantly reduce the number of global routes being injected. If we
  >split regions evenly at /42 and if we follow the /48-per-site best practice
  >(which I believe is justifiable in our situation - see below), Region A
  >will be at 50% usage immediately. Adding 16 more sites brings it to 75%
  >usage in only a few years. The other regions would be at ~33% usage (Region
  >B) and 15% usage (Region C) and will see moderate growth in 3-5 years.
  >Cloud will initially be at 2-4% usage (Region D) but will also grow quickly
  >within 3-5 years.
  >
  >Ideal situation: ARIN assigns us a /36 and we don't need to worry about
  >re-addressing. Even if they can offer us contiguous space with a second
  >request to increase our assignment, we would likely need to re-address a
  >significant portion of our sites which would be painful and time-consuming.
  >Less ideal situation #1: Split the first level of subnets unevenly at 1 x
  >/41 and 2 x /42 and hope we can carve out some of that space for use in our
  >cloud infrastructure. This strategy would solve our Region A problem and
  >would keep Regions B and C from going to 68% and 34% utilization
  >immediately but it would mess up Region D and impact Regions B and C.
  >Less ideal situation #2: Split the first level of subnets unevenly at 1 x
  >/41, 1 x /42, and 2 x /43. This strategy would solve our Region A and
  >Region B problems but would constrain Region C and Region D future growth
  >options somewhat.
  >Less ideal situation #3: Drop the /48 per site default to somewhere between
  >a /49 and /53 and hope we don't bust out of those. This strategy would
  >allow us to keep top-level aggregation at /42's but would move the site
  >assignments off the nibble boundaries.
  >Less ideal situation #4: Keep 4 x /42's and hope we don't expand out of
  >them in Region A. This strategy would imply we don't wish for our business
  >to grow and is pretty risky.
  >
  >I feel the /48 site default is justifiable because of the various
  >applications and services that are currently, or could likely be offered at
  >hotels. E.g., each room gets a /64 for all guest-internet devices
  >registered to that room. + IoT could result in the same rule (each room
  >gets a /64) or, perhaps a bit simpler, each class of IoT device is on a /64
  >or each IoT vendor is on a /64. There will also be new applications that
  >come out with similar possible needs. With some of our hotels in the
  >500-1000 room range, we're looking at as many as 2000 /64's per site in the
  >next 5 or so years. Plus backoffice/admin subnets.
  >
  >I think the ideal situation is out as ARIN policy wouldn't allow them to
  >assign us a /36 at this time. Unless someone knows something that can help
  >us here.
  >
  >Assuming we can't get a /36, my feeling is that less ideal situation #2 is
  >better than #3 is better than #1 is better than #4, assuming we're
  >following the following design best-practices:
  >
  >a) assign top-level aggregations evenly (which we'd be breaking a bit with
  >option #2)
  >b) reduce global routes as much as possible
  >c) stay on the nibble boundary as much as possible
  >d) default to /48 per site
  >
  >Any thoughts or advice would be much appreciated.
  >
  >Thanks in advance,
  >Oliver

-- 
Ken Chase - m...@sizone.org Guelph Canada

strange routing anomalies

[Ken Chase]

https://stat.ripe.net/widget/routing-history#w.resource=as15562=2017-01-15T00%3A00%3A00=2017-06-23T00%3A00%3A00=Maxmized
 :D

Nice job, Job.

/kc
-- 
Ken Chase - m...@sizone.org Guelph Canada

Re: Leasing /22 blocks

[Ken Chase]

Almost attractive pricing, but then we assume those IPs are trashed for life,
and attract blowback scan/hack traffic?

I would think that permanent sale is the only option, once one has removed all 
traces
of one's name from all records (irr and robtex and mxtoolbox and and and) 
before one does.

/kc


On Thu, Jun 01, 2017 at 01:57:07PM +, Luke Guillory said:
  >LogicWeb leases IPs, their pricing is below.
  >
  >/21 -1600$
  >/22 - 800$
  >/23 - 400$
  >/24 - 200$
  >
  >
  >
  >
  >Luke Guillory
  >Network Operations Manager
  >
  >Tel:985.536.1212
  >Fax:985.536.0300
  >Email:  lguill...@reservetele.com
  >
  >Reserve Telecommunications
  >100 RTC Dr
  >Reserve, LA 70084
  >
  
>_
  >
  >Disclaimer:
  >The information transmitted, including attachments, is intended only for the 
person(s) or entity to which it is addressed and may contain confidential 
and/or privileged material which should not disseminate, distribute or be 
copied. Please notify Luke Guillory immediately by e-mail if you have received 
this e-mail by mistake and delete this e-mail from your system. E-mail 
transmission cannot be guaranteed to be secure or error-free as information 
could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or 
contain viruses. Luke Guillory therefore does not accept liability for any 
errors or omissions in the contents of this message, which arise as a result of 
e-mail transmission. .
  >
  >-Original Message-
  >From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Aaron Gould
  >Sent: Thursday, June 01, 2017 8:53 AM
  >To: 'Security Admin (NetSec)'; nanog@nanog.org
  >Subject: RE: Leasing /22 blocks
  >
  >Someone recently reached out to me and asked me about this same thing... to 
which I responded by asking them how much they would pay me to lease my address 
space... here was their response...I'm pretty sure they are U.S.-based company. 
 I'd rather not say who they are... since I'm not sure I'm at liberty to do so.
  >
  >**
  >Please see below pricing (per month with 6 months commitment) :
  >
  >/19 - 2000$
  >/20 - 1200$
  >/21 - 600$
  >/22 - 400$
  >/23 - 200$
  >/24 - 100$
  >**
  >
  >- Aaron
  >
  >-Original Message-
  >From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Security Admin
  >(NetSec)
  >Sent: Friday, May 26, 2017 11:45 AM
  >To: 'nanog@nanog.org' <nanog@nanog.org>
  >Subject: Leasing /22 blocks
  >
  >Recently had someone offer to lease some IPv4 address space from me.  Have 
never done that before.
  >
  >I thought I would ask the group what a reasonable monthly rate for a /22 in 
the United States might be.
  >
  >Thanks in advance!
  >
  >Ed(ward) Ray
  >

Ken Chase - m...@sizone.org Guelph Canada

Re: Carrier classification

[Ken Chase]

so cogent has no routes to some amount of v6? ie no routes
to some prefixes?

/kc

On Mon, May 15, 2017 at 07:56:14PM -0700, Large Hadron Collider said:
  >My terminology of tiers are:
  >
  >Tier 1 - is in few or no major disputes, has no transit, and is able to
  >access over three nines percent of the internet
  >
  >Tier 2 - as Tier 1, but has transit.
  >
  >Cogent is neither on v6, and I have no clue about v4.
  >
  >HE is probably Tier 2 on v4, and is Tier 1 on v6.
  >
  >
  >On 15/05/2017 19:27, Ca By wrote:
  >> On Mon, May 15, 2017 at 6:44 PM Bradley Huffaker <bhuff...@caida.org> 
wrote:
  >>
  >>> On Sun, May 14, 2017 at 09:24:18AM +0200, Mark Tinka wrote:
  >>>> Nowadays, I'm hearing this less and less, but it's not completely gone.
  >>> Putting aside the question of their importance, there is a small number
  >>> of ISPs that do no pay for transit. If you don't call them Tier 1, what
  >>> do you call them? Transit Free Providers (TFPs)?
  >>
  >> I think the broader and more relevant question is -- Does it matter who
  >> pays who ? Why name an irrelevant characteristic?
  >>
  >> Cogent may not buy transit but i would not purchase their service since
  >> they fail to have full internet reach (google and HE)
  >>
  >> And xyz incumbent may have a poor network, but they may get free peering or
  >> may get paid-peering because of their incumbent / monopoly status... that
  >> is not a reason for me to purchase from them or think they are an elite
  >> tier 1.
  >>
  >> The dynamica of the day are more around reach and quality, not some legacy
  >> measure of how market-failure facilitate anti-social behavior
  >>
  >>
  >>
  >>> --
  >>> the value of a world model is not how accurately it captures reality
  >>> but how often it leads us to take appropriate action
  >>>
  >

-- 
Ken Chase - k...@heavycomputing.ca skype:kenchase23 +1 416 897 6284 Toronto 
Canada
Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front 
St. W.

Re: Need recommendation on an affordable internet edge router

[Ken Chase]

hows the power footprint? i never understood why each prefix cost
1mW to handle on most routers (and still took 2-3 minutes to converge)

/kc


On Thu, May 04, 2017 at 06:55:54PM -0600, Tyler Conrad said:
  >I use the 7280R in production. Love it.
  >
  >Pros: Cheap, fantastic API, can take (current) full tables of v4 and v6.
  >6x100G w 48x1/10G gives lots of flexibility.
  >
  >Cons: Lack of proper VRF support and minimal bgp address families. (If you
  >want strict isolation, or can use a separate device for route leaking, they
  >can still do most of what we want).
  >
  >On Thursday, May 4, 2017, Ken Chase <m...@sizone.org> wrote:
  >
  >> anyone have thoughts about/experience with the Arista 7280R / their
  >> flexroute engine?
  >>
  >> /kc
  >>
  >> On Thu, May 04, 2017 at 08:39:16PM +, c b said:
  >>   >We have a number of internet edge routers across several data centers
  >> approaching EOL/EOS, and are budgeting for replacements. Like most
  >> enterprises, we have been Cisco-centric in our routing/switching platforms.
  >> The ASR1Ks are too small for our needs and the ASR9Ks are prohibitively
  >> expensive and probably overkill. That being said, our IT staff is willing
  >> to look at other vendors if they are the right fit.
  >>   >
  >>   >
  >>   >Requirements:
  >>   >
  >>   >  *   Can handle full internet tables, both v4 and v6 with room for
  >> reasonable growth over the next 5 years.
  >>   >  *   VRF capability.
  >>   >  *   About 12-ish 10Gb ports and 10-ish 1Gb ports (24-ish total if
  >> they are 1Gb/10Gb select-rate ports.)
  >>   >  *   Full-Feature BGP (address-families, communities, peer-groups,
  >> etc...)
  >>   >  *   Used by carriers or large enterprises in a production role for at
  >> least a year (and not causing ulcers)
  >>   >  *   Affordable. I know that's subjective, but we need a solution that
  >> is as close as possible to commodity-pricing if this modernization effort
  >> balloons to include all of our data centers.
  >>   >
  >>   >We are open to named vendors and even so-called brite-box solutions. A
  >> little nervous about fringe solutions like pure whitebox with Quagga, but
  >> if the savings are there and people can vouch for it, we will consider it.
  >>   >
  >>   >In other words, if you've used it and stand by it, we value that input
  >> and will put it on the initial list. Also, if you chose solution-X after
  >> comparing it to solution-Y it would be very helpful to detail what you
  >> tested and why you chose.
  >>   >
  >>   >Thanks in advance.
  >>   >
  >>
  >> --
  >> Ken Chase - m...@sizone.org <javascript:;> Guelph Canada
  >>

Re: Need recommendation on an affordable internet edge router

[Ken Chase]

anyone have thoughts about/experience with the Arista 7280R / their
flexroute engine? 

/kc

On Thu, May 04, 2017 at 08:39:16PM +, c b said:
  >We have a number of internet edge routers across several data centers 
approaching EOL/EOS, and are budgeting for replacements. Like most enterprises, 
we have been Cisco-centric in our routing/switching platforms. The ASR1Ks are 
too small for our needs and the ASR9Ks are prohibitively expensive and probably 
overkill. That being said, our IT staff is willing to look at other vendors if 
they are the right fit.
  >
  >
  >Requirements:
  >
  >  *   Can handle full internet tables, both v4 and v6 with room for 
reasonable growth over the next 5 years.
  >  *   VRF capability.
  >  *   About 12-ish 10Gb ports and 10-ish 1Gb ports (24-ish total if they are 
1Gb/10Gb select-rate ports.)
  >  *   Full-Feature BGP (address-families, communities, peer-groups, etc...)
  >  *   Used by carriers or large enterprises in a production role for at 
least a year (and not causing ulcers)
  >  *   Affordable. I know that's subjective, but we need a solution that is 
as close as possible to commodity-pricing if this modernization effort balloons 
to include all of our data centers.
  >
  >We are open to named vendors and even so-called brite-box solutions. A 
little nervous about fringe solutions like pure whitebox with Quagga, but if 
the savings are there and people can vouch for it, we will consider it.
  >
  >In other words, if you've used it and stand by it, we value that input and 
will put it on the initial list. Also, if you chose solution-X after comparing 
it to solution-Y it would be very helpful to detail what you tested and why you 
chose.
  >
  >Thanks in advance.
  >

-- 
Ken Chase - m...@sizone.org Guelph Canada

intel remote management exploit

[Ken Chase]

How we all feeling about this? Trying hard to get a bead on how freaked
out we're all sposta be right this second. (Most of my gear is AMD, but
as the article indicates, your toaster probably has Intel in it too.)

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075=en-fr

some analysis:

http://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/

01:41 < azend|vps> Better hope your pfsense firewall isn't Intel based

see? and just before bed... (why do i check mail before bed...)

/kc
--
Ken Chase - m...@sizone.org Guelph Canada

Re: competent earthlink abuse contact please

[Ken O'Driscoll via NANOG]

On Thu, 2017-04-06 at 14:41 -0700, Dan Hollis wrote:
> A competent earthlink abuse contact please?
> 
> I am getting the runaround from people who are unable to read headers.
> 
> -Dan

Hi Dan,

There's usually an Earthlink presence over at Mailop:

https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Ken.

-- 
Ken O'Driscoll / We Monitor Email
t: +353 1 254 9400 | w: www.wemonitoremail.com

Re: Verizon Email RBL Whitelist

[Ken O'Driscoll via NANOG]

On Wed, 2017-04-05 at 18:08 +, Josh Niec wrote:
> If there is a Verizon Email Admin around, would you be able to contact me
> off-list about whitelisting a /24 network we have?  We have tried going
> through the Verizon whitelist ISP form online, as well as contacting
> numerous groups at Verizon without any success over the past few months.
> 
[...snip...]

Hi Josh,

The form's been broken for months. If you create an account on their forum
(https://forums.verizon.com/t5/Verizon-net-Email/bd-p/emailissues) and
raise your issue there, a support-rep will engage with you privately.

Ken.

-- 
Ken O'Driscoll / We Monitor Email
t: +353 1 254 9400 | w: www.wemonitoremail.com

Re: any issue with Centurylink yesterday

[Ken Matlock]

Yeah, it sounds like it. ICMP echo/echo reply was working end-to-end, but
it's possible they were blocking the Type 4 messages somewhere (I didn't
resort to packet captures to get THAT in-depth).

Ken

On Fri, Mar 17, 2017 at 10:15 AM, William Herrin <b...@herrin.us> wrote:

> On Fri, Mar 17, 2017 at 11:39 AM, Ken Matlock <matlock...@gmail.com>
> wrote:
>
>> I know most of the day yesterday my Centurylink DSL (Denver, CO) I was
>> having odd... issues, but only to some sites, and intermittent. I'd
>> have issues getting content from a URL (but pinging the host would be
>> fine,
>> and manual telnet to TCP/443 would work).
>
>
> Hi Ken,
>
> When I hear those symptoms my brain jumps to path MTU discovery.
>
> Regards,
> Bill Herrin
>
>
>
> --
> William Herrin  her...@dirtside.com  b...@herrin.us
> Dirtside Systems . Web: <http://www.dirtside.com/>
>

Re: any issue with Centurylink yesterday

[Ken Matlock]

Yeah, not sure that was related, as my issues started earlier in the day
(about 8am-9am Mountain time).

Either way it all seems fine today, no hiccups, no issues. so whatever it
was got resolved.

Ken


On Fri, Mar 17, 2017 at 9:02 AM, Pennington, Scott <
scott.penning...@cinbell.com> wrote:

> There may have been other events, but we were notified of a fiber cut in
> the Nashville area that impacted a few ckts for us around 6:30PM easter.
>
> -Scott
> 
> From: NANOG [nanog-boun...@nanog.org] on behalf of T Kawasaki via NANOG [
> nanog@nanog.org]
> Sent: Friday, March 17, 2017 8:35 AM
> To: NANOG
> Subject: any issue with Centurylink yesterday
>
> Guys,
> Is there any issues with centurylink yesterday? Through out day, peering
> from major iSPs to Centurylink had higher latency yesterday. I looked out
> now, it seems to settle down for now.
>
> Tatsuya
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential and/or privileged
> material. Any review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon, this information by persons or
> entities other than the intended recipient is prohibited. If you receive
> this in error, please contact the sender and destroy any copies of this
> document.
>

Re: any issue with Centurylink yesterday

[Ken Matlock]

I know most of the day yesterday my Centurylink DSL (Denver, CO) I was
having odd... issues, but only to some sites, and intermittent. I'd
have issues getting content from a URL (but pinging the host would be fine,
and manual telnet to TCP/443 would work). Latencies were *slightly* higher
than normal (36ms to a site vs 18ms normal), but I just chalked it up to
'Centurylink' and figured eventually it'd resolve itself.

This morning it all seems well again, so no idea WTF the problem was
(honestly I didn't look at it too much, as I was more motivated to go out
and enjoy the gorgeous weather instead).

Ken


On Fri, Mar 17, 2017 at 6:35 AM, T Kawasaki via NANOG <nanog@nanog.org>
wrote:

> Guys,
> Is there any issues with centurylink yesterday? Through out day, peering
> from major iSPs to Centurylink had higher latency yesterday. I looked out
> now, it seems to settle down for now.
>
> Tatsuya
>

Re: Regulatory Recovery Surcharge for Canadian corporations

[Ken Chase]

We've never seen anything like this on our Canadian transit bills (Cogent,
NAC, GTT, Hurricane.)

/kc
-- 
Ken Chase - m...@sizone.org Guelph Canada

Re: gagging *IX directors re snoop/block orders

[Ken Chase]

Just meant it as a parallel operational example. Both situations, while legally
distinct, present the same operational issues. 

Purposely breaking things - and then being required to keep the breakage secret 
-
is going to mess up a whole lot of things. (How does Chinese operators handle 
this?)

Additionally the snooping is an issue, though I can't imagine anyone depends on
an IX for maintaining secrecy at a contract level :/ Today's realities.

/kc


On Fri, Feb 17, 2017 at 10:03:00AM -0600, Mike Hammett said:
  >I'm not sure Cogent is on any IXes? 
  >
  >
  >
  >
  >- 
  >Mike Hammett 
  >Intelligent Computing Solutions 
  >http://www.ics-il.com 
  >
  >Midwest-IX 
  >http://www.midwest-ix.com 
  >
  >----- Original Message -
  >
  >From: "Ken Chase" <m...@sizone.org> 
  >To: nanog@nanog.org 
  >Sent: Friday, February 17, 2017 9:56:23 AM 
  >Subject: gagging *IX directors re snoop/block orders 
  >
  >And when you go to figure out why that IP wont ping through Cogent on 
  >your exchange, and start troubleshooting but can't get any answers 
  >as to why things are bust... 
  >
  >[ Clearly now an operational issue for NANOG. ] 
  >
  >Purposely breaking routing and not being able to talk about why is going to 
  >set many orgs at odds with their basic operational charters. I expect that 
  >a paid service will work when it's provided, including help debugging their 
end. 
  >
  >This is slightly different from a service provider, ostensibly you can 
  >go elsewhere to get service - but when you are a member of a nonprofit *IX 
  >(as we are with TorIX), things get a lot more complex. 
  >
  >I imagine contract lawyers are going to be all over this. 
  >
  
>https://www.theregister.co.uk/2017/02/17/linx_snoopers_charger_gagging_order/ 
  >
  >(their typo in the url) 
  >

/kc 
-- 
Ken Chase - m...@sizone.org Guelph/Toronto Canada 

gagging *IX directors re snoop/block orders

[Ken Chase]

And when you go to figure out why that IP wont ping through Cogent on
your exchange, and start troubleshooting but can't get any answers
as to why things are bust...

[ Clearly now an operational issue for NANOG. ]

Purposely breaking routing and not being able to talk about why is going to
set many orgs at odds with their basic operational charters. I expect that
a paid service will work when it's provided, including help debugging their end.

This is slightly different from a service provider, ostensibly you can
go elsewhere to get service - but when you are a member of a nonprofit *IX
(as we are with TorIX), things get a lot more complex.

I imagine contract lawyers are going to be all over this.

 https://www.theregister.co.uk/2017/02/17/linx_snoopers_charger_gagging_order/

(their typo in the url)

/kc
-- 
Ken Chase - m...@sizone.org Guelph/Toronto Canada

Re: backbones filtering unsanctioned sites

[Ken Chase]

They exist:

http://www.bloomberg.com/research/stocks/private/snapshot.asp?privcapId=26878307

http://canadabizdb.com/company/3264874/cogent-canada-inc

http://www.contracts-contrats.hc-sc.gc.ca/cfob/mssid/contractdisc.nsf/WEBbypurpose/A35BA8F8DB21C5E98525787E0066931A?OpenDocument=eng;

http://listings.ftb-companies-ca.com/l/112540553/Cogent-Canada-Inc-in-Toronto-ON

My cogent invoice:

Cogent Canada, Inc.
P.O.Box 46067
Postal Station A
Toronto, Ontario M5W 4K9

[ Dont visit the Cogent Canada facebook page. Not quite the same industry. Or
  the @CogentCanada twitter feed. (Something about semen vouchers.) ]

Anyway, they exist as a Canadian entity (and have even made submissions to
the CRTC bitching about rulings favouring Bell), so they're certainly
operating in Canada.

Anyone wanna file a complaint to the CCTS in Canada? https://www.ccts-cprst.ca/

/kc


On Tue, Feb 14, 2017 at 01:19:41PM -0500, Christopher Morrow said:
  >On Tue, Feb 14, 2017 at 1:10 PM, Jean-Francois Mezei <
  >jfmezei_na...@vaxination.ca> wrote:
  >
  >> On 2017-02-14 08:27, Jared Mauch wrote:
  >> > So risk avoidance on the part of the 100k other sites hosted by CF is
  >> now a conspiracy?
  >>
  >>
  >> Cogent is a backbone network that is international in scope.  When China
  >> tells a network to block the BBC that block happens only in China.
  >>
  >>
  >'when possible' (also, PRC is a special case...)
  >
  >you might make the analogy here to the singaporian 'block these 100
  >objectionable sites' law (since repealed I believe) though.
  >
  >
  >> If the USA wants to be like China and start blocking web sites it
  >> doesn't like, then it should only affect traffic in the USA.
  >>
  >>
  >yes, because of course the networks in question here are built around
  >national borders... and of course also on internal (to the nation)
  >boundaries.. and of course even more granularly on the internal, internal
  >national boundaries (country -> state -> county -. city -> burrough ->
  >apt-building -> floor - door -> room -> person -> device clearly cogent did
  >this as well)
  >
  >
  >> Google is a content company. Removing a company from its search results
  >> is a content issue, not a telecom issue.
  >>
  >> Cogent blocking an IP is a telecom issue and at least in canada should
  >> this be brought up at CRTC, would raise a Section 36 violation.
  >>
  >>
  >excellent, goodluck fellow traveler.
  >
  >
  >> And if transit providers start to block content, especially if they do
  >> not warn their ISP customers (so thei can warn their retail customers),
  >> then this is really not correct.
  >>
  >>
  >sure, but...
  >
  >what about dhs/ice revocation of domains in com/net/org/etc? :)
  >
  >
  >>
  >> In Canada, the supreme court has ruled, from different slants all
  >> reaching tghe conclusion that a neutral carrier is not responsible for
  >> the content that travels through its pipes. The second that carrier
  >> starts to exert control over content, it loses that immunity.
  >>
  >>
  >good thing cogent isn't a canadian company I suppose?
  >
  >
  >> Cogent blocking content affects traffic outside of the USA.
  >>
  >
  >
  >it sure does, you might have luck bringing this up with your equivalent to
  >the US State Department, no?

Ken Chase - m...@sizone.org Guelph/Toronto Canada

Re: backbones filtering unsanctioned sites

[Ken Chase]

If its not just cogent then we have an even larger issue -- that
theres asymetric application of rulings. So we should just assume
that if we can't get to something via cogent then all backbones
within the same jurisdiction(*) should or will also have the same sites/ips
blocked soon? And that it wasnt a fat finger/typo/someone forgot to
remove a block? So we're all just waiting for Level 3 to block TPB
too, and we still havent seen a legal ruling/order anywhere? 

* for various values of 'jurisdiction', in a world where all network
operators seeing a technical issue can immediately use their law degrees
to guess at which jurisdiction where, when and for how long, installed the
ban. (FAICT the ban on TPB @cogent is worldwide.)

/kc

On Fri, Feb 10, 2017 at 05:03:56PM -0500, Christopher Morrow said:
  >it's totally possible that the list here is really just a court-order
  >addition, right? I can't imagine that there is a cogent employee just evily
  >twiddling pens and adding random ips to blacklists...

  [...]

  >so it seems safe to assume that there's some court order cogent reacted to
  >:( we should fight that problem upstream.

--
Ken Chase - m...@sizone.org Guelph/Toronto Canada
Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front 
St. W.

Re: backbones filtering unsanctioned sites

[Ken Chase]

And because they're continuing to announce the /20, we run into their
blackhole unless we manually filter that /20. This is going to become
unworkable in short order once a bigger chunk of the internet starts doing
this.

/kc


On Fri, Feb 10, 2017 at 03:03:11PM -0500, Christopher Morrow said:
  >On Fri, Feb 10, 2017 at 1:39 PM, Mike Hammett <na...@ics-il.net> wrote:
  >
  >> Have we determined that this is intentional vs. some screw up?
  >>
  >>
  >if you look at the cogent LG it's pretty clear that the announce
  >reachability for the /20 that includes the tpb /32.. and that the /32 is
  >particularly routed elsewhere, and that the 'elsewhere' is coming form a
  >bgp speaker who's DNS says something along the lines of: "blackhole"...
  >
  >so... err, either someone fat-fingered OR intentionally entered a /32 into
  >the config management system :(
  >
  >
  >>
  >>
  >>
  >> -
  >> Mike Hammett
  >> Intelligent Computing Solutions
  >> http://www.ics-il.com
  >>
  >> Midwest-IX
  >> http://www.midwest-ix.com
  >>
  >> - Original Message -
  >>
  >> From: "Brielle Bruns" <br...@2mbit.com>
  >> To: nanog@nanog.org
  >> Sent: Friday, February 10, 2017 12:28:53 PM
  >> Subject: Re: backbones filtering unsanctioned sites
  >>
  >> On 2/9/17 9:18 PM, Ken Chase wrote:
  >> > https://torrentfreak.com/internet-backbone-provider-
  >> cogent-blocks-pirate-bay-and-other-pirate-sites-170209/
  >> >
  >> > /kc
  >> >
  >>
  >> Funny. Someone else got back:
  >>
  >> "Abuse cannot not provide you a list of websites that may be
  >> encountering reduced visibility via Cogent"
  >>
  >> I almost wish I had a Cogent circuit just to bring this up with an
  >> account rep. Almost.
  >>
  >> I'd very much so view this as a contractual violation on Cogent's part.
  >>
  >> Cogent keeps contacting me every year wanting to sell me service. This
  >> will be a good one to bring up when they call me next time.
  >>
  >> --
  >> Brielle Bruns
  >> The Summit Open Source Development Group
  >> http://www.sosdg.org / http://www.ahbl.org
  >>
  >>

-- 
Ken Chase - m...@sizone.org Guelph/Toronto Canada
Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front 
St. W.

Re: backbones filtering unsanctioned sites

[Ken Chase]

  >"Abuse cannot not provide you a list of websites that may be encountering
  >reduced visibility via Cogent"

They could, if they kept a list of forward lookups they had done to get IPs
that ended up in their blacklists. But just having the IPs it's impossible to
get the whole list of possible hostnames that point at it (reverse records are
singular, and often missing).

Nonetheless, it'd be nice to know how a single IP got onto the list - and what
Cogent's doing about situations where multiple other hostnames map onto the
same ip.

I have clietns that are Cogent customers, I'd just like to get informed before
I bring the hammer down.

/kc
-- 
Ken Chase - m...@sizone.org Guelph/Toronto Canada
Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front 
St. W.

backbones filtering unsanctioned sites

[Ken Chase]

https://torrentfreak.com/internet-backbone-provider-cogent-blocks-pirate-bay-and-other-pirate-sites-170209/

/kc
-- 
Ken Chase - m...@sizone.org Guelph Canada

Re: ticketmaster.com 403 Forbidden

[Ken Chase]

Seems to me this random prefix-based blocking by major sites, 
then let's-use-nanog-to-fix-it, is not a great methodology.

I block whole /18s and such to deal with .cn/.ru botnets too, but luckily my
cxs' cxs are mostly North American, few complaints yet. Sledgehammer style -
indelicate.

Is there a better method other than us sheep bleating helplessly at behemoths
who might not even have a presence on Nanog-l? 

This sledgehammer blacklisting results in a filter where smaller than /16
doesnt get addressed due to time cost of dealing with fewer revenue-generating
eyeballs per ticket.

Result: big ISPs win though sieve effect.

Google has adopted a 'blacklist for a while' policy with their spam control,
which mostly works but can leave you in the dark as to why you're continually
relisted for no obvious reason - no humans out there to help directly, so it's
back to bleating on nanog by Nate and friends.

What more 'official' and formalized mechanisms can we use?

/kc


On Mon, Feb 06, 2017 at 12:19:00PM -0500, Ethan E. Dee said:
  >So their policy says, if an ISP has one scalper, we'll block their entire
  >subnet and not tell them why?

-- 
Ken Chase - m...@sizone.org Guelph Canada

Re: ticketmaster.com 403 Forbidden

[Ken Matlock]

Honestly, I'm surprised they don't try and charge a 'convenience fee' while
implementing the block! ;-)

Ken

On Mon, Feb 6, 2017 at 10:19 AM, Ethan E. Dee <e...@globalvision.net> wrote:

> So their policy says, if an ISP has one scalper, we'll block their entire
> subnet and not tell them why?
>
>
>
> On 02/06/2017 11:49 AM, Suresh Ramasubramanian wrote:
>
>> My guess is you have or had sometime in the long distant past a scalper
>> operating on your network, using automated ticket purchase bots.
>>
>> If you still have that scalper around, you might want to turf him.  If
>> he’s ancient history, saying so might induce them to remove the block.
>>
>> --srs
>>
>> On 06/02/17, 8:45 AM, "nanog-boun...@nanog.org on behalf of
>> mike.l...@gmail.com" <nanog-boun...@nanog.org on behalf of
>> mike.l...@gmail.com> wrote:
>>
>>  Yup, i have a /22 that has the same problem. Support is useless...
>>   > On Feb 6, 2017, at 08:35, Ethan E. Dee <e...@globalvision.net>
>> wrote:
>>  >
>>  > It gives me a Forbidden error.
>>  > It has for over a year.
>>  > There support says they are not allowed to me why by their policy.
>>  > it is across an entire /19.
>>  > I gave up after the fifth time and encourage the customers to call
>> them individually.
>>  >
>>  >> On 02/06/2017 11:09 AM, Niels Bakker wrote:
>>  >> * charles.man...@charter.com (Manser, Charles J) [Mon 06 Feb
>> 2017, 16:21 CET]:
>>  >>> It seems that browsing to ticketmaster.com or any of the
>> associated IP addresses results in a 403 Forbidden for our customers today.
>> Is anyone else having this issue?
>>  >>
>>  >> http://help.ticketmaster.com/why-am-i-getting-a-blocked-forb
>> idden-or-403-error-message/
>>  >>
>>  >>
>>  >>-- Niels.
>>  >
>>
>>
>>
>

Re: St. Louis IX Launch

[Ken Chase]

congrats!

I am curious, is the IX non-for-profit as well? The wikipedia entry for IX's
doenst indicate which IX's are non-profit. Im curious as to the prevalence
and size (as well as the relative successes) of such IX's vs for profit models 
(equinix etc).

/kc


On Sun, Jan 15, 2017 at 06:30:45PM -0600, Mike Hammett said:
  >If you know someone that may be interested, we have a launch event later 
this week for our St. Louis IX. St. Louis is a bit different than our existing 
market in that we've partnered with a local non-profit that will be focusing on 
non-commercial Internet aspects. These sorts of things are innovation 
neighborhoods, IoT, healthcare, education, public safety, etc. They may (or may 
not) be the big volume things we're used to, but they need local, low-latency 
connectivity just as much. 
  >
  
>https://www.eventbrite.com/e/st-louis-regional-internet-exchange-preview-tickets-30329718003?aff=NANOG
 
  >
  >
  >
  >
  >- 
  >Mike Hammett 
  >Intelligent Computing Solutions 
  >
  >Midwest Internet Exchange 
  >
  >The Brothers WISP 
  >

-- 
Ken Chase - k...@heavycomputing.ca skype:kenchase23 +1 416 897 6284 Toronto 
Canada
Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front 
St. W.

Re: [Tier1 ISP]: Vulnerable to a new DDoS amplification attack

[Ken Chase]

Maybe he's found what's already known and posted 2 months ago (and every 2 
months?)
on nanog, the TCP 98,000x amplifier (which is a little higher than 100x), among
dozens of misbehaving devices, all >200x amp. 

 https://www.usenix.org/system/files/conference/woot14/woot14-kuhrer.pdf

(Table 1's 'total load risk', (not calculated; Im using potential #hosts * amp 
factor)
shows that each protocol listed curiously all have similar values, within 40%.
Little too curious, in fact. I'd expect distribution across a few magnitudes.)

/kc
--
Ken Chase - m...@sizone.org Guelph Canada

Re: Wanted: volunteers with bandwidth/storage to help save climate data

[Ken Chase]

On Wed, Dec 21, 2016 at 04:41:29PM -0800, Doug Barton said:
 [..]
  >>Everyone has a line at which "I don't care what's in the pipes, I just
  >>work here" changes into something more actionable.
  >
  >Stretched far beyond any credibility. Your argument boils down to, "If it's
  >a political thing that *I* like, it's on topic."

"If it's a politically-generated thing I'll have to deal with at an
operational level, it's on topic."

That work?

/kc
--
Ken Chase - m...@sizone.org

Re: Not a representative of gmx.com but their emails are being blocked by those who subscribe to the SORBS RBL.

[Ken O'Driscoll]

On Sat, 2016-12-17 at 20:15 -0800, Large Hadron Collider wrote:
> Does anyone have information on why this is, and if you represent SORBS 
> and/or GMX and/or both, would you please trouble yourself with 
> contacting me off-list?

You can find out why an IP was listed via their lookup facility:
http://www.
sorbs.net/lookup.shtml

You can request de-listing by opening a support request:
http://www.sorbs.net/cgi-bin/support

You don't need to be an IP block owner to request de-listing but you do need to 
be empowered to stop whatever caused the listing in the first place. Their 
support is very responsive.

Ken.

--  
Ken O'Driscoll / We Monitor Email
t: +353 1 254 9400 | w: www.wemonitoremail.com

Re: Wanted: volunteers with bandwidth/storage to help save climate data

[Ken Chase]

I seriously doubt that there's going to be a witchhunt even close to as well
funded as anti-torrent DMCA-wielding piracy hunters, and it's not even nearly
the same as keeping a copy of wikileaks.aes, or sattelite photos of
Streisand's campus, or photos of Elian Gonzales, a copy of deCSS, the 
cyberSitter
killfile, etc ("we've been here before.").

The issue will be 1000s of half copies that are from differing dates sometimes
with no timestamps or other metadata, no SHA256 sums, etc etc. It's going to be
a records management nightmare. Remember, all these agencies wont be shut down
on Jan 20th making that the universal time-stamp date. Some of them may even
be encouraged to continue producing data, possibly even cherry picked or 
otherwise
tainted. Others will carry on quietly, without the administration noticing.

Im glad some serious orgs are getting into it - U of T, archive.org, wikipedia, 
etc.
We'll have at least a few repo's that cross-agree on progeny, date, sha256, etc.

Only once jackboots are knocking on doors "where's the icecore sample data, 
Lebowski!"
will we really have to consider the quality levels of the other repos. Not that
they shouldnt be kept either, of course.

Remember, this is only one piece of the puzzle. The scientists can do as much 
data-
collecting as they want -- if the political side of the process wants to make 
'mentioning
climate change illegal' in state bills or other policies or department missions,
it's far more effective than rm'ing a buncha datasets.

http://abcnews.go.com/US/north-carolina-bans-latest-science-rising-sea-level/story?id=16913782

Nonetheless - mirror everything everywhere always...

/kc


On Fri, Dec 16, 2016 at 02:05:01PM -0500, Steven Miano said:
  >It would seem like the more copies the better, seemingly chunking this data
  >up and using .torrent files may be a way to both (a) ensure the integrity
  >of the data, and (b) enable an additional method to ensure that there are
  >enough copies being replicated (initial seeders would hopefully retain the
  >data for as long as possible)...
  >
  >On Fri, Dec 16, 2016 at 12:24 PM, Ken Chase <m...@sizone.org> wrote:
  >
  >> University Toronto's Robarts Library is hosting an all-day party tomorrow
  >> of
  >> people to surf and help identify datasets, survey and get size and details,
  >> authenticate copies, etc.
  >>
  >> fb event: https://www.facebook.com/events/1828129627464671/
  >>
  >> /kc
  >>
  >> On Fri, Dec 16, 2016 at 06:42:46PM +0200, DaKnOb said:
  >>   >We are currently working on a scheme to successfully authenticate and
  >> verify the integrity of the data. Datasets in https://climate.daknob.net/
  >> are compressed to a .tar.bz2 and then hashed using SHA-256. The final file
  >> with all checksums is then signed using a set of PGP keys.
  >>   >
  >>   >We are still working on a viable way to verify the authenticity of
  >> files before there are tons of copies lying around and there???s a working
  >> group in the Slack team I sent previously where your input is much needed!
  >>   >
  >>   >Thanks,
  >>   >Antonios
  >>   >
  >>   >> On 16 Dec 2016, at 18:30, Ken Chase <m...@sizone.org> wrote:
  >>   >>
  >>   >> Surfing through the links - any hints on how big these datasets are?
  >> Everyone's got
  >>   >> a few TB to throw at things, but fewer of us have spare PB to throw
  >> around.
  >>   >>
  >>   >> There's some random #s on the goog doc sheet for sizes (100's of TB
  >> for the
  >>   >> landsat archive seems credible), and there's one number that destroys
  >>   >> credibility of the sheet (1000 GB (100 ZB)) for the EPA
  >> archive.
  >>   >>
  >>   >> The other page has many 'TBA' entries for size.
  >>   >>
  >>   >> Not sure what level of player one needs to be to be able to serve a
  >> useful
  >>   >> segment of these archives. I realize some of the datasets are tiny
  >> (<GB)
  >>   >> but which ones are most important vs size (ie the win-per-byte ratio)
  >> isnt indicated.
  >>   >> (I know its early times.)
  >>   >>
  >>   >> Also I hope they've SHA512'd the datasets for authenticity before all
  >> these
  >>   >> myriad copies being flungabout are 'accused' of being manipulated 'to
  >> promote
  >>   >> the climate change agenda' yadda.
  >>   >>
  >>   >> Canada: time to step up! (Cant imagine the Natl Research Council
  >> would do so
  >>   >> on their mirror site, too much of a gloves-off slap in the face to
  

Re: Wanted: volunteers with bandwidth/storage to help save climate data

[Ken Chase]

University Toronto's Robarts Library is hosting an all-day party tomorrow of
people to surf and help identify datasets, survey and get size and details,
authenticate copies, etc.

fb event: https://www.facebook.com/events/1828129627464671/

/kc

On Fri, Dec 16, 2016 at 06:42:46PM +0200, DaKnOb said:
  >We are currently working on a scheme to successfully authenticate and verify 
the integrity of the data. Datasets in https://climate.daknob.net/ are 
compressed to a .tar.bz2 and then hashed using SHA-256. The final file with all 
checksums is then signed using a set of PGP keys.
  >
  >We are still working on a viable way to verify the authenticity of files 
before there are tons of copies lying around and there???s a working group in 
the Slack team I sent previously where your input is much needed!
  >
  >Thanks,
  >Antonios 
  >
  >> On 16 Dec 2016, at 18:30, Ken Chase <m...@sizone.org> wrote:
  >> 
  >> Surfing through the links - any hints on how big these datasets are? 
Everyone's got
  >> a few TB to throw at things, but fewer of us have spare PB to throw around.
  >> 
  >> There's some random #s on the goog doc sheet for sizes (100's of TB for the
  >> landsat archive seems credible), and there's one number that destroys
  >> credibility of the sheet (1000 GB (100 ZB)) for the EPA archive.
  >> 
  >> The other page has many 'TBA' entries for size.
  >> 
  >> Not sure what level of player one needs to be to be able to serve a useful 
  >> segment of these archives. I realize some of the datasets are tiny (<GB)
  >> but which ones are most important vs size (ie the win-per-byte ratio) isnt 
indicated.
  >> (I know its early times.)
  >> 
  >> Also I hope they've SHA512'd the datasets for authenticity before all these
  >> myriad copies being flungabout are 'accused' of being manipulated 'to 
promote
  >> the climate change agenda' yadda.
  >> 
  >> Canada: time to step up! (Cant imagine the Natl Research Council would do 
so
  >> on their mirror site, too much of a gloves-off slap in the face to Trump.)
  >> 
  >> /kc
  >> 
  >> 
  >> On Fri, Dec 16, 2016 at 06:02:46PM +0200, DaKnOb said:
  >>> If you???re interested, there???s also a Slack team: 
climatemirror.slack.com
  >>> 
  >>> You can find more info about that here:
  >>> 
  >>> - https://climate.daknob.net/
  >>> - http://climatemirror.org/
  >>> - http://www.ppehlab.org/datarefuge
  >>> 
  >>> Thank you for your help!
  >>> 
  >>> 
  >>>> On 16 Dec 2016, at 17:58, Rich Kulawiec <r...@gsp.org> wrote:
  >>>> 
  >>>> This is a short-term (about one month) project being thrown together
  >>>> in a hurry...and it could use some help.  I know that some of
  >>>> you have lots of resources to throw at this, so if you have an
  >>>> interest in preserving a lot of scientific research data, I've set
  >>>> up a mailing list to coordinate IT efforts to help out.  Signup via
  >>>> climatedata-requ...@firemountain.net or, if you prefer Mailman's web
  >>>> interface, http://www.firemountain.net/mailman/listinfo/climatedata
  >>>> should work.
  >>>> 
  >>>> Thanks,
  >>>> ---rsk
  >>>> 
  >>> 
  >> 

-- 
Ken Chase - m...@sizone.org Guelph Canada

Re: Wanted: volunteers with bandwidth/storage to help save climate data

[Ken Chase]

Surfing through the links - any hints on how big these datasets are? Everyone's 
got
a few TB to throw at things, but fewer of us have spare PB to throw around.

There's some random #s on the goog doc sheet for sizes (100's of TB for the
landsat archive seems credible), and there's one number that destroys
credibility of the sheet (1000 GB (100 ZB)) for the EPA archive.

The other page has many 'TBA' entries for size.

Not sure what level of player one needs to be to be able to serve a useful 
segment of these archives. I realize some of the datasets are tiny (<GB)
but which ones are most important vs size (ie the win-per-byte ratio) isnt 
indicated.
(I know its early times.)

Also I hope they've SHA512'd the datasets for authenticity before all these
myriad copies being flungabout are 'accused' of being manipulated 'to promote
the climate change agenda' yadda.

Canada: time to step up! (Cant imagine the Natl Research Council would do so
on their mirror site, too much of a gloves-off slap in the face to Trump.)

/kc


On Fri, Dec 16, 2016 at 06:02:46PM +0200, DaKnOb said:
  >If you???re interested, there???s also a Slack team: climatemirror.slack.com
  >
  >You can find more info about that here:
  >
  >- https://climate.daknob.net/
  >- http://climatemirror.org/
  >- http://www.ppehlab.org/datarefuge
  >
  >Thank you for your help!
  >
  >
  >> On 16 Dec 2016, at 17:58, Rich Kulawiec <r...@gsp.org> wrote:
  >> 
  >> This is a short-term (about one month) project being thrown together
  >> in a hurry...and it could use some help.  I know that some of
  >> you have lots of resources to throw at this, so if you have an
  >> interest in preserving a lot of scientific research data, I've set
  >> up a mailing list to coordinate IT efforts to help out.  Signup via
  >> climatedata-requ...@firemountain.net or, if you prefer Mailman's web
  >> interface, http://www.firemountain.net/mailman/listinfo/climatedata
  >> should work.
  >> 
  >> Thanks,
  >> ---rsk
  >> 
  >

-- 
Ken Chase - m...@sizone.org Guelph Canada

Re: Cogent NOC

[Ken Chase]

I was going to reply and repeat Job Snijders's indications of Thu, 7 Jul 2016 to

 Please review the excellent presentation from RA{T,S}:

https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf
https://www.youtube.com/watch?v=a1IaRAVGPEE

esp the pdf there, but in this case Randy's mtr does do a ping to the last
hop. He did have 4.1% pl to the endpoint for his specific setup and
current gear/route/etc.

However, I go through the same hostname'd router he does (he didnt provide an
ip, but paris-traceroute doesnt show me load balancing, at least visibly), and
I only get 0.3% pl. (Though, my immediate upstream DSL provider's router is 
giving
me 0.2% pl, so who knows what that 0.3% means at the far end, really.)

Without bidirectional concurrent mtr's (one from cogent back to him at the
same time), it's quite hard to say what's going on. Even then that's no 
guarantee
of diagnosis.

Here's just the most recent thread with some depth on how to read traces and 
packetloss:

http://seclists.org/nanog/2016/Jul/155

the whole thread is useful. But is only one of the dozens of times this has come
up on nanog. (Again: read that pdf!)

/kc


On Wed, Dec 14, 2016 at 05:53:56PM -0200, Kurt Kraut said:
  >Hello,
  >
  >
  >mtr packet loss column has no scientific precision and should not be
  >considered. It is not mtr fault but forwarding routers have a low priority
  >to respond to ICMP requests. The only way you can prove there is a problem
  >is a end to end ping, the regular ping command, not mtr.
  >
  >
  >Best regards,
  >
  >
  >Kurt Kraut
  >
  >2016-12-14 17:16 GMT-02:00 Randy <a...@djlab.com>:
  >
  >> Hi all,
  >>
  >> Anyone beyond front line support at cogento on list?
  >>
  >> Nanog is the last place I'd look for assistance but it seems support over
  >> at cogentco is not nearly what it used to be.
  >>
  >> Example MTR to cogen't own website (support doesn't utilize or understand
  >> MTR at all apparently):
  >>
  >> Host  Loss%   Snt   Last   Avg  Best  Wrst
  >> StDev
  >>  1. x.x.x.x 0.0%   1960.5  11.7   0.3
  >> 186.8  35.2
  >>  2. x.x.x.x 0.0%   1960.6  10.2   0.4
  >> 226.3  36.2
  >>  3. 38.88.249.209   0.0%   1960.9   1.1   0.7
  >> 17.7   1.2
  >>  4. te0-0-2-3.nr13.b023801-0.iad01.atl  0.0%   1961.0   1.0   0.8
  >>  2.0   0.1
  >>  5. te0-0-0-1.rcr22.iad01.atlas.cogent  2.0%   1962.1   1.9   1.0
  >>  3.3   0.4
  >>  6. be2961.ccr41.iad02.atlas.cogentco.  2.6%   1961.8   2.1   1.1
  >>  3.8   0.5
  >>  7. be2954.rcr21.iad03.atlas.cogentco.  2.6%   1962.0   2.3   1.2
  >>  9.4   0.7
  >>  8. be2952.agr11.iad03.atlas.cogentco.  0.5%   1962.7   2.6   1.5
  >>  6.8   0.6
  >>  9. cogentco.com4.1%   1962.1   2.0   1.0
  >> 16.8   1.1
  >>
  >> Pretty much the same to anywhere.   Packet loss begins at rcr22.iad01 and
  >> propagates all the way down the line.   Worse during peak hours, gone late
  >> at night.
  >>
  >> After three days of no email response for my ticket, I called and after an
  >> hour of my life I want back, front line support cannot reproduce the loss.
  >>  Final conclusion: "Your host is dropping packets".
  >>
  >> --
  >> ~Randy
  >>

--
Ken Chase - m...@sizone.org Guelph Canada

Re: Zoho Mail - SPF & DKIM Records...

[Ken O'Driscoll]

Hi Michael,

Yes, very familiar with Zoho. What's the problem you're encountering? Feel
free to get in touch off-list also.

Ken.

-- 
Ken O'Driscoll / We Monitor Email
t: +353 1 254 9400 | w: www.wemonitoremail.com

On Thu, 2016-11-24 at 18:06 +0300, Michael Bullut wrote:
> Greetings Team,
> 
> Has anybody set up SPF & DKIM for a domain whose e-mails are handled by
> Zoho? Running into trouble setting them up.
> 
> Warm regards,
> 
> Michael Bullut.
> 
> ---
> 
> *Cell:*
> *+254 723 393 114.**Skype Name:* *Michael Bullut.*
> *Twitter:*
> * @Kipsang <http://twitter.com/Kipsang/>*
> *Blog: http://www.kipsang.com/ <http://www.kipsang.com/>*
> *E-mail:* *m...@kipsang.com <m...@kipsang.com>*
> 
> *---*

Re: Syn flood to TCP port 21 from priveleged port (80)

[Ken Chase]

what's the density of open port 21s on the planet though? trying to estimate
the traffic resulting against the two target /21s. 

Your dump only has 2 ip's in it though, on your /19 so not representative.

My dump is 500 synacks returned in 14 seconds to 32 ips in a /22. This would 
give
128M ftp responders across the whole /0 (modulo actual space in use, etc,
so call it 32M responders?). (It's also a short timespan for a dump as well.)
Syn-ack seems to be a 58 byte packet (?ish).

32 * 10^6 * 500/14 * 58*8 / 10^9 = 530 Gbps

even if im off by 4 in density of ftp sites on the internet despite my already
reducing it by 4, we're talking ~100+ Gbps.

/kc


On Tue, Nov 01, 2016 at 03:59:49PM -0600, Selphie Keller said:
  >Yeah it is an odd ball attack for sure, here is a 5000 packet sample of
  >what I was seeing in connection to this attack
  >https://mystagic.io/80to21.pcap , don't think it's the entire /0 for ftp
  >port as I am not seeing it on many other subnets, which is why I am
  >thinking someone did a pre-scan before conducting this wacky attack,
  >otherwise, I would have likely seen other port 21's seeing activity, but so
  >far any IP that didn't have 21 as an actual service isn't seeing the syn
  >packets. This could be unique to my location, others observing this attack
  >may be able to chime in and report what they are seeing if they seen 80 src
  >syn to port 21 where 21 isn't an actual ftp running. Yeah this is pretty
  >easy to filter.
  >
  >On 1 November 2016 at 13:48, Ken Chase <m...@sizone.org> wrote:
  >
  >> Not sure why reflected RSTs are the goal here, they're not much of an
  >> amplification
  >> to the original syn size. Additionally causing a mild dos of my clients'
  >> stuff
  >> when it begins throttling # of connections, ie noticeable. (not that i
  >> want to
  >> help scriptkids improve their attacks...). Im guessing port 80 was chosen
  >> for improved
  >> fw piercing.
  >>
  >> Sure is widespread though, 5 clients on very different networks all seeing
  >> similar
  >> saturation. Someone has a nice complete prescanned list of open ftps for
  >> the
  >> entire internet out there (or are they just saturating the whole /0?)
  >>
  >> Easy to filter though:
  >>
  >> tcp and src port 80 and src net '(141.138.128.0/21 or 95.131.184.0/21)'
  >> and dst port 21
  >>
  >> Adapt for your fw rules of choice.
  >>
  >> /kc
  >>
  >>
  >> On Tue, Nov 01, 2016 at 07:39:40PM +, Van Dyk, Donovan said:
  >>   >I think Ken has nailed it. I think the source addresses are spoofed so
  >> you reflect the connection (tcp syn ack) to those source addresses. Get
  >> enough of those connections and the server is dead.
  >>   >
  >>   >Since your port 21 is open
  >>   >
  >>   >telnet 109.72.248.114 21
  >>   >Trying 109.72.248.114...
  >>   >Connected to 109.72.248.114.
  >>   >Escape character is '^]'.
  >>   >
  >>   >Your address was probably scanned and saw it could be used in the
  >> attack.
  >>   >
  >>   >Regards
  >>   >--
  >>   >Donovan Van Dyk
  >>   >
  >>   >SOC Network Engineer
  >>   >
  >>   >Office: +1.954.620.6002 x911
  >>   >
  >>   >Fort Lauderdale, FL USA
  >>   >
  >>   >
  >>   >
  >>   >
  >>   >The information contained in this electronic mail transmission and its
  >> attachments may be privileged and confidential and protected from
  >> disclosure. If the reader of this message is not the intended recipient (or
  >> an individual responsible for delivery of the message to such person), you
  >> are strictly prohibited from copying, disseminating or distributing this
  >> communication. If you have received this communication in error, please
  >> notify the sender immediately and destroy all electronic, paper or other
  >> versions.
  >>   >
  >>   >
  >>   >On 11/1/16, 3:29 PM, "Ken Chase" <m...@sizone.org> wrote:
  >>   >
  >>   >seeing an awful lot of port 80 hitting port 21. (Why would port 80
  >>   >ever be used as source?). Also saw a buncha cpanel "FAILED: FTP"
  >> alerts flickering
  >>   >on and off as the service throttled itself at a couple client sites
  >> I manage.
  >>   >
  >>   >I see 540 unique source IPs hitting 32 destinations on my network
  >> in just 1000
  >>   >packets dumped on one router.
  >>   >
  >>   >All from multiple sequential registered

Re: Syn flood to TCP port 21 from priveleged port (80)

[Ken Chase]

Not sure why reflected RSTs are the goal here, they're not much of an 
amplification
to the original syn size. Additionally causing a mild dos of my clients' stuff
when it begins throttling # of connections, ie noticeable. (not that i want to
help scriptkids improve their attacks...). Im guessing port 80 was chosen for 
improved
fw piercing.

Sure is widespread though, 5 clients on very different networks all seeing 
similar
saturation. Someone has a nice complete prescanned list of open ftps for the
entire internet out there (or are they just saturating the whole /0?)

Easy to filter though:

tcp and src port 80 and src net '(141.138.128.0/21 or 95.131.184.0/21)' and dst 
port 21

Adapt for your fw rules of choice.

/kc


On Tue, Nov 01, 2016 at 07:39:40PM +, Van Dyk, Donovan said:
  >I think Ken has nailed it. I think the source addresses are spoofed so you 
reflect the connection (tcp syn ack) to those source addresses. Get enough of 
those connections and the server is dead. 
  >
  >Since your port 21 is open
  >
  >telnet 109.72.248.114 21
  >Trying 109.72.248.114...
  >Connected to 109.72.248.114.
  >Escape character is '^]'.
  >
  >Your address was probably scanned and saw it could be used in the attack.
  >
  >Regards
  >--
  >Donovan Van Dyk
  >
  >SOC Network Engineer
  >
  >Office: +1.954.620.6002 x911
  >
  >Fort Lauderdale, FL USA
  >
  >
  >
  >
  >The information contained in this electronic mail transmission and its 
attachments may be privileged and confidential and protected from disclosure. 
If the reader of this message is not the intended recipient (or an individual 
responsible for delivery of the message to such person), you are strictly 
prohibited from copying, disseminating or distributing this communication. If 
you have received this communication in error, please notify the sender 
immediately and destroy all electronic, paper or other versions.
  > 
  >
  >On 11/1/16, 3:29 PM, "Ken Chase" <m...@sizone.org> wrote:
  >
  >seeing an awful lot of port 80 hitting port 21. (Why would port 80
  >ever be used as source?). Also saw a buncha cpanel "FAILED: FTP" alerts 
flickering
  >on and off as the service throttled itself at a couple client sites I 
manage.
  >
  >I see 540 unique source IPs hitting 32 destinations on my network in 
just 1000
  >packets dumped on one router. 
  >
  >All from multiple sequential registered /24s in whois, but all from one
  >management company:
  >
  >141.138.128.0/21 and 95.131.184.0/21
  >
  >role:   William Hill Network Services
  >abuse-mailbox:  networkservi...@williamhill.co.uk
  >address:Infrastructure Services 2 City Walk Sweet Street Leeds 
LS11 9AR
  >
  >AS49061
  >
  >course, synfloods can be spoofed... perhaps they're hoping for a 
retaliation
  >against WHNS.
  >
  >/kc
  >
  >On Tue, Nov 01, 2016 at 09:44:23PM +0300, Oleg A. Arkhangelsky said:
  >  >Hello,
  >  >
  >  >A couple of cuts from tcpdump output:
  >  >
  >  >21:31:54.995170 IP 141.138.131.115.80 > 109.72.248.114.21: Flags [S], 
seq 1376379765, win 8192, length 0
  >  >21:31:55.231925 IP 194.73.173.154.80 > 109.72.241.198.21: Flags [S], 
seq 2254756684, win 8192, length 0
  >  >21:27:50.413927 IP 95.131.188.179.80 > 109.72.248.114.21: Flags [S], 
seq 3619475318, win 8192, length 0
  >  >21:27:50.477014 IP 95.131.191.77.80 > 109.72.248.114.21: Flags [S], 
seq 2412690982, win 8192, length 0
  >  >
  >  >Does anyone seeing this right now (18:31 UTC)? I see this traffic
  >  >on at least two completely independent ISPs near Moscow. The
  >  >rate is about a few dozen PPS hitting all BGP-announced networks.
  >  >
  >  >--??
  >  >wbr, Oleg.
  >  >
  >  >"Anarchy is about taking complete responsibility for yourself."
  >  >?? ?? ?? Alan Moore.
  >
-- 
Ken Chase - m...@sizone.org Guelph Canada

Re: Syn flood to TCP port 21 from priveleged port (80)

[Ken Chase]

seeing an awful lot of port 80 hitting port 21. (Why would port 80
ever be used as source?). Also saw a buncha cpanel "FAILED: FTP" alerts 
flickering
on and off as the service throttled itself at a couple client sites I manage.

I see 540 unique source IPs hitting 32 destinations on my network in just 1000
packets dumped on one router. 

All from multiple sequential registered /24s in whois, but all from one
management company:

141.138.128.0/21 and 95.131.184.0/21

role:   William Hill Network Services
abuse-mailbox:  networkservi...@williamhill.co.uk
address:Infrastructure Services 2 City Walk Sweet Street Leeds LS11 9AR

AS49061

course, synfloods can be spoofed... perhaps they're hoping for a retaliation
against WHNS.

/kc

On Tue, Nov 01, 2016 at 09:44:23PM +0300, Oleg A. Arkhangelsky said:
  >Hello,
  >
  >A couple of cuts from tcpdump output:
  >
  >21:31:54.995170 IP 141.138.131.115.80 > 109.72.248.114.21: Flags [S], seq 
1376379765, win 8192, length 0
  >21:31:55.231925 IP 194.73.173.154.80 > 109.72.241.198.21: Flags [S], seq 
2254756684, win 8192, length 0
  >21:27:50.413927 IP 95.131.188.179.80 > 109.72.248.114.21: Flags [S], seq 
3619475318, win 8192, length 0
  >21:27:50.477014 IP 95.131.191.77.80 > 109.72.248.114.21: Flags [S], seq 
2412690982, win 8192, length 0
  >
  >Does anyone seeing this right now (18:31 UTC)? I see this traffic
  >on at least two completely independent ISPs near Moscow. The
  >rate is about a few dozen PPS hitting all BGP-announced networks.
  >
  >--??
  >wbr, Oleg.
  >
  >"Anarchy is about taking complete responsibility for yourself."
  >?? ?? ?? Alan Moore.

-- 
Ken Chase - m...@sizone.org Guelph Canada

Re: Another day, another illicit SQUAT - WebNX (AS18450) 103.11.67.0/24

[Ken Chase]

On Sat, Oct 29, 2016 at 10:32:12AM +1100, Mark Andrews said:  
  >It's not the RIR's job. They already provide the framework for 
  >ISP's to do the job of policing route announcements themselves. 
  >ISP's just need to use that framework.

What incentive do the ISPs have to enforce any of this though? 

In fact, they're making money sending bits over these prefixes. 

What incentives could be created that the ISPs wont balk at as it
might affect their accidental revenues from "oh, gee, I didnt know it
was being squatted! " prefixes?

/kc   
--       
Ken Chase - m...@sizone.org guelph canada

Re: Another day, another illicit SQUAT - WebNX (AS18450) 103.11.67.0/24

[Ken Chase]

On Fri, Oct 28, 2016 at 02:40:23PM -0700, Ronald F. Guilmette said:
  >I'm going to call these turkeys right now and just ask them, point
  >blank, what the bleep they think they're doing, routing unallocated
  >APNIC space. 

Makin' phat stacks.

One thing the RIRs could do is put pressure on AS's to not route
these objects, and start producing daily public output scores
for these orgs, and emailing them -- ultimately threatening them
with de-reg of their assets if they dont stop this nonsense.
Further more, could get the route db's involved in dereg threats.

Is the politcal will there tho?

Right now there's no stigma beyond nanog-l in being a bad actor
from where I sit.

/kc
-- 
Ken Chase - m...@sizone.org guelph canada

Re: Spitballing IoT Security

[Ken Matlock]

And I contend that the device manufacturer is only one part in this.

Yes, the manufacturers need to get better in securing their devices (that's
never been in question).

*But* the end users need to have better CPE that can do NetFlow/Sflow/etc
in a near real-time fashion. This would allow the end-user to act as a
check against the manufacturer(s) and see threats and DDoS packets
originating from their gear in real-time (and on the customer's CPE they
can get MAC or RFC1918 address to narrow it down better).

*But* that doesn't let the SP's off the hook either. The SP needs to be a
check against the end users as well, being able to do real-time (or
near-real time) flow data export/analysis. Why isn't it done currently?
Well, probably a few reasons (and more that I can't even imagine)

1) Cost - It's a real cost to put something like this in place, and upper
management does not want to spend money on something with little to no
return
2) Availability - How much SP gear even has the option to do any sort of
flow export/analysis?
3) Competition - If I am SP 'A' and I allow my customers to participate in
a DDoS against SP 'B' (who is a competitor of mine), that at least
indirectly harms my competitor, and all I have to do is absolutely nothing,
why would management in SP 'A' lift a finger to fix the problem? (Until the
DDoS is directed at them).

Fixing the current wave of 'IoT' devices and phones and Tv's etc is only
putting a bandaid on a broken arm. It gives the illusion of progress, but
the fact is the reason DDoS'es are still a problem (and honestly, they've
been a problem for decades, IRC servers and Netsplits/channel
takeovers/etc), is that each layer in the problem is pointing the finger at
the other layers and declaring them the cause of the problem and washing
their hands of it (not unlike current politics).

Until we accept that it's *everyone's* problem and work to fix the things
under our control and work as an advocate for the other layers, we will
continue to suffer attacks.

Ken



> I say again, the only way to solve these problems is if the devices
> are fundamentally secure by design, on the day they first ship to
> customers.  Post-sale patching is an ad hoc and haphazard catch-as-
> catch-can solution at best, and it's not something that most manufacturers
> have -any- financial incentive to even do.  They already got their
> money, on the day when the consumer bought the device.  The rest is
> just an afterthought.
>
> Regards,
> rfg
>

Re: Spitballing IoT Security

[Ken Matlock]

As a relative 'outsider' I see a lot of finger-pointing and phrasing this
as (effectively) someone else's fault.

To me this is a failing on a number of levels all contributing to the
problem.

1) The manufacturer - Backdoors, hidden accounts, remote access
capabilities, no proper security testing. No enforcing of security updates.
2) The end-user - No initiative on the end-user's perspective to gain even
a basic understanding of how the device works, connects, etc. Also no tools
or understanding of how to recognize *which* of their many devices on the
network might be compromised and participating in the botnet. (Only
indication they get is maybe their internet is slow)
3) The service providers - No effective monitoring of outgoing traffic from
the end users to identify botnets and DDoS in a real-time fashion

I contend that all 3 levels have failed in this, and nothing has
fundamentally changed (today it's IoT, before it was unpatched windows
boxes, etc) in decades. We keep talking about the problem but very little
actual action has occurred to *fix* the underlying issues.

- Manufacturers need to be held accountable for devices that go on the
internet (that includes *anything* that's connected. PCs, servers, routers,
IoT devices, etc)
- End users need to have ways to easily see what's going on over their
local networks, to see botnet-like activity and DDoS participation (among
other things) in a more real-time fashion
- Service providers need to be much more proactive in watching for threats
and identifying/blocking them at the source, not allowing the traffic to
flow to your peers and making it someone else's problem. Right now there's
a financial disincentive to doing this, in both real costs (standing up
monitoring gear/etc), and imagined (my ISP is SPYING on me!).

Until we fix all 3 of these main issues we're just going to keep going in
the same set of circles we do every time a 'new' threat/vector comes in.

Now, are these issues *easy*? Oh, heck no!  Are they *cheap*? Once again,
heck no! But to 'fix' this issue it will take all 3 levels being fixed.

If we continue to keep pointing fingers at "the other guy" as the root of
the problem we're inviting external forces (Legislation) to step in and
'fix' the problem for us (and it will just make it worse).

My 2 cents (adjust for inflation)
Ken

On Wed, Oct 26, 2016 at 1:40 PM, jim deleskie <deles...@gmail.com> wrote:

> So device is certified,  bug is found 2 years later.  How does this help.
> The info to date is last week's issue was patched by the vendor in Sept
> 2015, I believe is what I read. We know bugs will creep in, (source anyone
> that has worked with code forever) Also certification assuming it would
> work, in what country, would I need one, per country I sell into?  These
> are not the solutions you are looking for ( Jedi word play on purpose)
>
> On Wed, Oct 26, 2016 at 3:53 PM, JORDI PALET MARTINEZ <
> jordi.pa...@consulintel.es> wrote:
>
> > Exactly, I was arguing exactly the same with some folks this week during
> > the RIPE meeting.
> >
> > The same way that certifications are needed to avoid radio interferences,
> > etc., and if you don’t pass those certifications, you can’t sell the
> > products in some countries (or regions in case of EU for example),
> > authorities should make sure that those certifications have a broader
> > scope, including security and probably some other features to ensure that
> > in case something is discovered in the future, they can be updated.
> >
> > Yes, that means cost, but a few thousand dollars of certification price
> > increase, among thousands of millions of devices of the same model being
> > manufactured, means a few cents for each unit.
> >
> > Even if we speak about 1 dollar per each product being sold, it is much
> > cheaper than the cost of not doing it and paying for damages, human
> > resources, etc., when there is a security breach.
> >
> > Regards,
> > Jordi
> >
> >
> > -Mensaje original-
> > De: NANOG <nanog-boun...@nanog.org> en nombre de Leo Bicknell <
> > bickn...@ufp.org>
> > Organización: United Federation of Planets
> > Responder a: <bickn...@ufp.org>
> > Fecha: miércoles, 26 de octubre de 2016, 19:19
> > Para: <nanog@nanog.org>
> > Asunto: Re: Spitballing IoT Security
> >
> > In a message written on Wed, Oct 26, 2016 at 08:06:34AM -0400, Rich
> > Kulawiec wrote:
> > > The makers of IoT devices are falling all over themselves to rush
> > products
> > > to market as quickly as possible in order to maximize their
> > profits.  They
> > > have no time for security.  They don't concern themselves with
> > privacy
> > > impli

Re: Dyn DDoS this AM?

[Ken Chase]

(Inband signalling - bad except for BGP?)

General comment: why are we blaming the client devices for the lack of security?

This is like Microsoft villifying linux in the late 90s because "there's no
restrictions on use or packet crafting on the client side" - of course there
isn't, in Windows either -- cant trust the client side, ever. Check out online
gaming, so many h4x 'n bots.

Let's stop trying to fix the clients, there'll always be bad actors/crappy 
coding.

Let's fix the networks. 

Pay-to-play? People are sensitive in the pocketbooks. NetCoin or something to
purchase dataflows? I dont know. Also sounds terrible. ("That's an internet
tax!!!111"). But Something Must Be Done[tm], by us, soon, or we'll be
dealing with govt cures which will be worse than the disease.

Regulating devices will never happen. Have you checked out world trade
regulations?  The US can't get Chinese firms to stop shipping
deadly-to-the-touch chemwep/drug carfentanil, how we gonna enforce security
standards on COTS electronics? (More govt soln's/approvals too. Fear.)

We have control of the networks. Lets do something.

(cant find the carfentanil story on nytimes anymore, pulled?
http://www.nytimes.com/aponline/2016/10/07/world/asia/ap-as-china-chemical-weapons.html
 )

/kc


On Sat, Oct 22, 2016 at 04:54:47PM +0200, Mikael Abrahamsson said:
  >On Sat, 22 Oct 2016, Alexander Maassen wrote:
  >
  >>Remember ping packets containing +++ATH0 ?
  >
  >THat only worked because of patents:
  >
  >https://en.wikipedia.org/wiki/Time_Independent_Escape_Sequence
  >
  >Inband signaling is bad, mmmkay?
  >
  >-- 
  >Mikael Abrahamssonemail: swm...@swm.pp.se

--
Ken Chase - Guelph Canada

Re: A perl script to convert Cisco IOS/Nexus/ASA configurations to HTML for easier comprehension

[Ken Chase]

re more general 'network utilities' and scripts:

 http://sizone.org/m/hacks/cidrmath.pl

adds and removes subnets from networks giving list of remaining/aggregated 
(sub)nets.

I couldnt find an online calculator that does this, most are just for 
'translation' 
from subnet masks<>cidr or cisco inverse masks, etc.

Wrote it years ago cuz I had an itch. The included perl module populates a
hash entry per ip and I didnt want to write my own, so uses lots of ram+cpu on
big ops (/8 - /9 for eg). But great for earthly operations like /23 - /27 +
/28.

Yes I should start my own git repo, but i've been lazy.

No warranties provided.

If anyone has a faster/better one, that'd be handy.

/kc
--
Ken Chase - k...@sizone.org Toronto & Guelph Canada

RE: Level 3 voice outage

[Ken Warnimont]

There's all sorts of people online reporting problems with Level3 voice 
services - we're down for outbound calling, inbound is spotty.  Their portal is 
unreachable, can't get to any of their #'s...seems like the world is on fire 
over there.

We were a previous TW Telecom customer before Level3 bought them out, the 
service quality has definitely degraded since then.

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Mark Stevens
Sent: Tuesday, October 04, 2016 10:02 AM
To: nanog@nanog.org
Subject: Level 3 voice outage

Is anyone noticing issue with Level 3 voice? I can't even call their 800 number 
using one of my other carriers.

Mark

***
This email message, including any attachments, is intended solely for the 
designated person or entity to which the message is addressed, and may contain 
confidential information. It is strictly prohibited to review, distribute, 
copy, or print this email, including attachments, by any person or entity other 
than the designated addressee. 
If you have erroneously received this message, please contact the sender 
immediately and remove the data from any computer on which the message resides.

ATT contact?

[Ken Breeman]

Could someone from AT please contact me off list?

Your residential Internet DNS servers are redirecting all traffic destined
for Akamai hosted sites to your homepage...

Thanks,
Ken

bogon identified? how to track down bogus IPs/ASN's

[Ken Chase]

My turn for the newb question:

I've got a traceroute with this IP in it thats close to the end of the trace.

103.206.16.46

Chasing down this IP to see who the ISP a friend is using, figured out
the diff between ARIN and APNIC whois for IPs (..bit of a learning curve, not
sure why there's not just one whois interface syntax).

 whois -h whois.apnic.net -m 103.206.16.0/21 

shows only the upper /22 being registered with APNIC (if you do -m on
.16.0/22, there's no entry).

So it seems to me these Ips arent registered properly with APNIC (could it
be cross-registered with another RIR? Well it's not with ARIN who'd be the 
local.)

But I do see this block in global bgp tables so it wasnt like someone decided 
to use
10.10.10/24 or 1.2.3/24 in their routing infrastructure. They're actually 
announcing;

 sh ip bg 103.206.16.0  ends in a path with  394786 135022

looking up 394786 I see avetria networks. looking up 135022 I see nothing at 
ARIN.

At APNIC I get

as-block:   AS134557 - AS135580
descr:  APNIC ASN block
remarks:These AS numbers are further assigned by APNIC
remarks:to APNIC members and end-users in the APNIC region

but nothing more specific.

However, this does show up in radb as avetria networks as well. (and various 
geolocate
DBs put it in Melbourn.au though i know it's in use in Kitchener ontario).

So what's not matching up here?

/kc
--
Ken Chase - m...@sizone.org Guelph Ontario

Re: charges for prefix filter updates (was Re: Any ISPs using AS852 for IP Transit?)

[Ken Chase]

Followup: we did the quote/PO/sign-the-order dance. That took about 3-4 days
not including our side's lag (which was not insignificant, Im not the guy with
the pen). But now it's gone to provisioning and will be a standard *5 days*.

Cogent will do this in about 1-6 hours if you provide the LOA's with the 
request.
So will HE. And many others.

/kc


On Thu, Sep 15, 2016 at 02:28:50PM -0400, Ken Chase said:
  >I feel this can be a public topic:
  >
  >Rogers just charged us that for an update (one update, multiple entries).
  >We had to go through their quotation machinery too, took like 4-5 days. 
Additional
  >time was wasted because we contacted their tech dept directly at the start. 
(which
  >is what I do for all my other upstreams...)
  >
  >Kinda brutal.
  >
  >Cogent and HE nor NAC or Yipes or Tata ever did that to us.
  >
  >Nickle and diming -- why, cuz transit is a cheap commodity now, gotta make 
the
  >cash somewhere?
  >
  >That said Cogent offered us a static /26 along side our BGP years ago then 
warned
  >us it'd be $50/mo or something for that # of ips going forward. We didnt 
need it
  >so dispensed with it.
  >
  >/kc
  >
  >
  >On Thu, Sep 15, 2016 at 02:07:01PM -0400, Jason Lixfeld said:
  >  >If there are any ISPs who use TELUS/AS852 for IP Transit over BGP, I???d 
be interested in hearing from you.
  >  >
  >  >I???d like to compare notes to see if you are also paying $250 for each 
BGP prefix filter updated request, or if we???re the only ones???
  >  >
  >  >Thanks in advance!
  >
  >-- 
  >Ken Chase - m...@sizone.org Toronto Canada

Re: Request for comment -- BCP38

[Ken Chase]

This might break some of those badly-behaving "dual ISP" COTS routers out there
that use different inbound from outbound paths since each is the fastest of
either link.

I did this manually when I was messing around with multiple broadband links on
a fbsd router years ago, was glad it worked at the time.

/kc


On Mon, Sep 26, 2016 at 07:11:42AM -0700, Paul Ferguson said:
  >No -- BCP38 only prescribes filtering outbound to ensure that no packets 
leave your network with IP source addresses which are not from within your 
legitimate allocation.
  >
  > - ferg 
  >
  >
  >On September 26, 2016 7:05:49 AM PDT, Stephen Satchell <l...@satchell.net> 
wrote:
  >>Is this an accurate thumbnail summary of BCP38 (ignoring for the moment
  >>
  >>the issues of multi-home), or is there something I missed?
  >>
  >>> The basic philosophy of BCP38 boils down to two axioms:
  >>>
  >>> Don't let the "bad stuff" into your router
  >>> Don't let the "bad stuff" leave your router
  >>>
  >>> The original definition of "bad stuff" is limited to source-
  >>> address grooming both inbound and outbound.  I've expanded on the
  >>> original definition by including rule generation to control
  >>> broadcast address abuse.
  >
  >-- 
  >Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
Ken Chase - m...@sizone.org Toronto Canada

Re: Domain renawals

[Ken Chase]

EasyDNS has gone beyond the normal registrar dilligence and has
resisted bogus takedowns and other things, where many would just
bend over backwards. They can do this a bit more easily by being in Canada
as well:

https://www.techdirt.com/articles/20160606/10541834640/riaa-demands-takedown-thepiratebayorg-easydns-refuses-over-lack-due-process.shtml

https://www.techdirt.com/articles/20150107/17585829627/easydns-sued-refusing-to-take-down-website-without-court-order-then-hit-again-writing-about-lawsuit.shtml

https://www.techdirt.com/articles/20131127/02062025385/easydns-continues-to-fight-bogus-website-seizures-city-london-police-after-verisign-issues-no-decision.shtml

https://www.techdirt.com/articles/20150623/17321931439/icanns-war-whois-privacy.shtml

Mark Jeftovic, owner is a great guy who's one of the old school netheads (cut
my teeth with him as co admins under an ISP owned by Osama Arafat who went on
to found Q9). Recommended.

/kc


On Wed, Sep 21, 2016 at 02:46:43PM -0400, Jim Mercer said:
  >On Wed, Sep 21, 2016 at 11:43:50AM -0700, james machado wrote:
  >> so who would you quantify as secure and reliable? who does not require
  >> additional "services" besides registration or spend all their time trying
  >> to upsell you?
  >
  >i'm good with easydns.com
  >
  >--jim
  >
  >> 
  >> james
  >> 
  >> On Wed, Sep 21, 2016 at 10:18 AM, Jim Mercer <j...@reptiles.org> wrote:
  >> 
  >> >
  >> > cheap, secure, reliable
  >> >
  >> > pick two.
  >> >
  >> > --jim
  >> >
  >> > On Mon, Sep 19, 2016 at 12:19 PM, Jeff Jones <jeff.jjo...@gmail.com>
  >> > wrote:
  >> > > Sorry if this is low level. But are people sick of registrars jacking 
up
  >> > > prices? Who is the cheapest and most reliable? I have been using
  >> > whois.com,
  >> > > networksolutions.com and am looking for input on who is cheap, secure,
  >> > > reliable registrar. Thanks for your input.
  >> >
  >> > --
  >> > Jim Mercer Reptilian Research  j...@reptiles.org+1 416 
410-5633
  >> >
  >> > Life should not be a journey to the grave with the intention of
  >> > arriving safely in a pretty and well preserved body, but rather
  >> > to skid in broadside in a cloud of smoke, thoroughly used up,
  >> > totally worn out, and loudly proclaiming "Wow! What a Ride!"
  >> >  -- Hunter S. Thompson
  >> >
  >
  >-- 
  >Jim Mercer Reptilian Research  j...@reptiles.org+1 416 410-5633
  >
  >Life should not be a journey to the grave with the intention of
  >arriving safely in a pretty and well preserved body, but rather
  >to skid in broadside in a cloud of smoke, thoroughly used up,
  >totally worn out, and loudly proclaiming "Wow! What a Ride!"
  > -- Hunter S. Thompson

-- 
Ken Chase - m...@sizone.org Toronto Canada

Re: One more thing to watch out for at data centers - fire drills

[Ken Chase]

All of these discussions sounds infinitely safe for humans.

Servers and network gear is replaceable. Sounds like the failure was not one of
DC mismanagement but human safety errors.

/kc


On Sat, Sep 17, 2016 at 09:27:26AM -0400, h...@netcases.net said:
  >On 2016-09-17 08:39, Suresh Ramasubramanian wrote:
  
>>http://motherboard.vice.com/read/a-loud-sound-just-shut-down-a-banks-data-center-for-10-hours?utm_source=bbcfb
  >>
  >>Releasing inert gas from fire suppression units that were over
  >>pressurized resulted in an extremely loud noise ??? causing cabinets
  >>full of hard drives to vibrate ??? which got transmitted to the read ???
  >>write heads of the drives.
  >>
  >>Amazing sort of outage + data loss, and this time the physical
  >>security plant chief gets to write up the RCA.
  >>
  >>--srs
  >
  >Another unexpected result when we had an all-out Halon test:  thick fog,
  >apparently from cold gas and somewhat humid air. I'm glad to have been
  >watching through windows. Visibility in the room dropped to zero.

-- 
Ken Chase - m...@sizone.org Guelph Canada