Death of the Internet, Film at 11

Sat Oct 22 13:41:08 UTC 2016

On 10/22/2016 05:34 AM, Mike Hammett wrote:
> "taken all necessary steps to insure that none of the numerous specific types of CCVT thingies that Krebs and others identified" 
> 
> Serious question... how? 
> 

Network operators can only do so much.  By the time traffic enters into
an ISP's traffic aggregation point, any flow monitoring and throttling
would have a minimal effect.  Not saying that it shouldn't be
considered.  The correct answer includes throttling the traffic much
closer to the source.

The obvious answer is that the device that bridges IoT to the upstream
link in the home or office have the capability of rate-limiting upstream
traffic.  Perhaps on a per-MAC basis.  When does a thermostat, light
bulb, or refrigerator need 1-megabyte/s uplink channels?  For that
matter, how many computers -- especially laptops -- need that kind of
upstream capacity?

(Yes, yes, YouTube publishers and VLAN links to the office, to name two,
will need that kind of channel; see below.  Gamers need small,
low-latency channels, so the throttling can't be too aggressive.
Public-access storage, web and mail servers, obviously.  IP-connected
Web cameras need some upstream capacity, but not a full-bore one.  The
uplink throttle can take into consideration "reasonable" upstream rates
for cameras.)

For wireless access points, the place to start would be with the OpenWRT
package, to serve as a model for what *can* be done.  Once we have a
proof of concept, it would raise the bar for "commercial"
implementations.  THAT would then provide an opportunity for the
three-letter Federal agencies to specify reasonable regulations, should
Congress so decide this is necessary.  It's much easier for regulatory
bodies to say "this software does it, why can't yours?" instead of
saying "you [manufacturer] go figure it out".

The ripple effect throughout the world would go a long way to curbing
the problem.  Especially if other regulatory administrations follow
suit, so that the enabling crap routers are weeded out.

What about the exceptions?  For those rare cases where one needs a
high-rate upstream channel for a node on the wireless network (or wired
network, for that matter), the firmware in the traffic aggregating
device can allow for specific exceptions to the rate-limit rules.  One
method is to tie exceptions to the device MAC address, or range of MAC
addresses.  Another is to tie exceptions to ports, with WiFi being a
single "port" in this context.  Generators of high-speed upstream
traffic would, for example, need a wired connection in order to do this.
 This would *not* affect most WiFi-connected peripherals, like printers,
because the AP would limit upstream traffic, not downstream.

The ISP would then have something to sell to the customer, to replace
the local POS router/WAP that the customer is currently using.

Hmmm...something to thing about as I build the Linux IPTABLES Firewall
Rule Generator Mk III...