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...