netdev - Re: [PATCH net-next] tcp: Add TCP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPh34mechU=aUS422OBFhHUt68Nk2PZBsMiLPw8eLwS_4PnRtw@mail.gmail.com>
Date:	Wed, 22 Oct 2014 21:50:14 +0200
From:	Hagen Paul Pfeifer <hagen@...u.net>
To:	Kristian Evensen <kristian.evensen@...il.com>
Cc:	David Miller <davem@...emloft.net>,
	Network Development <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] tcp: Add TCP_FREEZE socket option

On 22 October 2014 19:08, Kristian Evensen <kristian.evensen@...il.com> wrote:

> Another approach I designed was to have a separate TCP Freeze module
> and trigger the freeze/unfreeze through genetlink-messages. A user
> space application will be responsible for monitoring the devices and
> decide when to trigger the ZWAs. Would a design like that be
> acceptable?

At least better. But what userspace daemon would configure this?
Likely NetworkManager and friends. But at what conditions?

- When the WIFI signal strength is below some threshold?
- When switched to another AP?
- When switched from 802.11 to 802.3
- ...

In a NATed scenario there is no gain because IP addreses change and
the connection is lost anyway. For the signal strength thing there
might be an advantage but it has costs:

a) how long did you freeze the connection? What if NetworkManager
stops? The connection hang \infty
b) is it not better to inform the upper layer - the application - that
something happen with the link?

I mean when the application experience disruptions, the application
can decide what it do: reconnect, reconnect and resend or inform the
user. This possibility is now lost/hidden. Maybe it is no problem -
maybe it is for some applications.

I have no fundamental problems with TCP Freeze, but what is missing is
a complete story line. The use cases where it makes sense and if it is
save.

Do you have considered to bring this to the IETF (TCPM WG)?

Hagen
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html