your thoughts on a particualar ipfw action.

[Dr. Rolf Jansen]

> Am 11.08.2016 um 14:20 schrieb Ian Smith <smithi at nimnet.asn.au>:
> On Thu, 11 Aug 2016 10:09:24 -0300, Dr. Rolf Jansen wrote:
>>> Am 11.08.2016 um 08:06 schrieb Ian Smith <smithi at nimnet.asn.au>:
>>> On Wed, 10 Aug 2016 -0300, Dr. Rolf Jansen wrote:
>>> ...
>>> ...
>>>> I just submitted a PR asking to add the new port 'sysutils/ipdbtools'.
>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211744
>>> 
>>> Wonderful.
>> 
>> The port maintainers were really quick. The port has been accepted 
>> and has been already committed.
> 
> So it has, on refreshing the page.  Smooth and fast.
> 
> Re __uint128_t I _guess_ there may be macro/s to do that maths for i386?

Yeah, I am exploring the options. Comparisons, addition and subtraction are working already, multiplication, division and remainder operations are a tad more difficult, I must leave this for some weekend.

>>> ...
>>> A more tech-savvy article than ABC or other news media managed so far:
>>> https://www.theguardian.com/australia-news/2016/aug/10/computer-says-no-australian-census-shambles-explanation-depends-on-who-you-ask
>> 
>> Well, I tend to believe that this has nothing to do with DoS attacks, 
> 
> Some should have been expected, planned for, mitigation anticipated, as 
> well as expecting at least 5 times the legit connections/hr they tested 
> for, and as the guardian article pointed to, their DNS was screwed in 
> several ways: way too long TTL (can't move fast), hard-coded subdomain 
> in SSL cert (couldn't readily add load-sharing capacity?) and such.
> 
> But they admit the geo-blocking fell over - whether inline as firewall 
> or on another server fielding lookup requests not disclosed - but they 
> say that failure caused a/the/some router to fail (crash? explode? :)

Perhaps they did Geo-blocking in the way that I mentioned in the summary of the ipdbtool's manual to be a no-go:

...
Unfortunately, online database look-up is by far too slow for even think-
ing about being utilized on the firewall level, where IP packets need to
be processed in a microsecond time scale. Therefore, a locally maintained
IP Geo-location database is indispensable in the given respect.
...

> IBM, FFS! but they'll point to govt specs and disclaim hardware failure 
> but still it's not great product endorsement for their SoftLayer Cloud.

Natural but non-professional reaction. My mother always told us, if you point
with your index finger to others, three fingers are pointing back to you.
So IBM not only failed technically but also the PR devision did a bad job. 

>> I mean, of course it is DoS, but not caused by an attack. Exactly the 
>> same happens every year on 30th of April between 17:00 and 24:00 on 
>> the servers of the Federal Bureau of Finance here in Brazil. That is 
>> the deadline for the online-submission of the annual tax declaration 
>> of the Brazilian citizens. Seems that the bureaucrats all over the 
>> world share the same deficiency of creative problem solving.
> 
> Seems it's a requirement for the job, world wide.  Creativity is scary, 
> but you think they could guess that ~8 million households in the eastern 
> timezone were going to have dinner then do their census within ~2 hours.

Of course they could not guess this, because public servants are trained
to assume that the normal citizen does not meet her/his obligations, and
for sure they were (are) prepared to send out 8 million penalty notices
in 24 hours.

>> Who in the bureaucrats hell told them to go with one deadline for 
>> everybody? For the census in Australia, I would have told the 
>> citizens that everybody got an individual deadline which is his or 
>> her birthday in 2016 -- problem solved.
> 
> That'd be great load-balancing .. shall I let them know? :)

Doesn't cost anything giving it a try, however, you could as well slap an
ox on his horn - same effect.