[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openwireless-tech
Subject:    Re: [OpenWireless Tech] Low Bandwidth HTTPS Open WiFi
From:       Erik Soderquist <ErikSoderquist () gmail ! com>
Date:       2014-12-19 14:41:49
Message-ID: CACoZoo2vAide02NhDt-QMLeYgbsHK6Ma7xP=kZR8EmqJOjVNHQ () mail ! gmail ! com
[Download RAW message or body]

That sounds like a lot of complicated code/overhead for home grade
routers, and I've already trivially bypassed it before to maintain
near-continuous "full speed" access.

Nice idea in theory, but I've never found it to be worth it in
practice, mostly due to the overhead it involved on the router to keep
track and dynamically throttle connections.

-- Erik

On Thu, Dec 18, 2014 at 9:49 PM, Tom Hanan
<tom.hanan@switchcomputing.com> wrote:
> I personally favor a staged bandwidth limiting approach where each ip / mac
> devices bandwidth starts at <512kbps and drops in half for each 25M Bytes
> that are transferred within an hour. So a device that had already
> transferred 100M bytes in a given hr would be limited to 32kbps for the next
> hr. That should be no problem for an "internet of things" device even when
> performing an update. In fact it encourages the more professional staggered
> live verified updates vs the hackers favorite of forced reset with online
> boot loader and restart.
>
> Emerging security standards and testing for internet of things devices will
> make those poor update practices obsolete by exposing all the devices on a
> net work with those behaviors.
>
> Devices that need bandwidth limits higher than those described above are NOT
> low bandwidth! Note that 32kbps will handle all the VOIP and texting the
> average person needs even after they used up their 100MB burst allocation!
>
>
>
> My mottos for low band with open wireless are"
>
> "Trust But Verify"
> "Open but Limited"
>
> -T
>
>
> On 12/17/2014 9:21 AM, Erik Soderquist wrote:
>>>
>>> On 20:05 Tue 16 Dec     , Erik Soderquist wrote:
>>> ...
>>>>
>>>> As to encrypting the connection, privacy alone is a good enough
>>>> reason.  I don't necessarily want anyone with a sniffer being able to
>>>> see clear text of the fitness/health details.
>>>
>>> I guess my text wasn't really clear: Instead of HTTPS I would suggest
>>> "raw"
>>> TLS (not HTTP). At least it should be allowed so polling and other
>>> overhead
>>> can be avoided if implemented.
>>
>> I'll certainly agree that 'raw' TLS rather than HTTP over TLS is more
>> efficient, but that is outside the scope of the open wireless
>> projects, and is up to the device/application programmers for things
>> like the example pedometer to handle.  I'm (personally at least) also
>> against attempting to specifically block unencrypted connections, as
>> that gets into either picking and choosing which ports to allow/deny,
>> and not every encrypted application uses the standard ports, nor does
>> every application using a standard encrypted port use encryption (yes,
>> I've found unencrypted traffic on 443 many times), or trying to look
>> inside the packets to test if the payload is encrypted, which means
>> lots more overhead, and having to be able to identify every variant of
>> every encryption tat might be used. Either I think would be a
>> nightmare to support, and again, is outside the scope of the open
>> wireless projects.
>>
>> Rate limiting, on the other hand, I can see being a very useful
>> feature.  For example, a rate limit of 128-256 Kb/s (still several
>> times faster than the dial up most of us have used) per IP address
>> with a 512 Kb/s cap on the open segment would allow the example
>> devices ample bandwidth to update, while very effectively discouraging
>> warez downloaders from using the open connection, and greatly limiting
>> the impact to home users if someone does download huge files at that
>> slow rate anyway.
>>
>> -- Erik
>> _______________________________________________
>> Tech mailing list
>> Tech@openwireless.org
>> https://srv1.openwireless.org/mailman/listinfo/tech
>>
>>
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> http://www.avast.com
>
_______________________________________________
Tech mailing list
Tech@openwireless.org
https://srv1.openwireless.org/mailman/listinfo/tech
[prev in list] [next in list] [prev in thread] [next in thread]