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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 22 Oct 2014 22:33:39 +0200 From: Kristian Evensen <kristian.evensen@...il.com> To: Hagen Paul Pfeifer <hagen@...u.net> Cc: David Miller <davem@...emloft.net>, Network Development <netdev@...r.kernel.org> Subject: Re: [PATCH net-next] tcp: Add TCP_FREEZE socket option Hi, I am very sorry for not explaining the scenario/use-case properly. Freeze-TCP is mostly targeted at TCP connections established through mobile broadband networks. One example scenario is that of when a user moves outside of an area with LTE coverage. The mobile broadband connection will then be downgraded to 2G/3G and this process takes 10-15 seconds in the networks I have been able to measure. During this handover, the modem/device will in most cases report that it is still connected to LTE. So just looking at the state of the link is not good enough, as it will appear to be working fine (except for no data coming through it). The device does not change IP address, so TCP connections will resume normal operation as soon as the network connection is re-established and packet is retransmitted. However, because of the large "idle" period, this can take another 10-15 seconds. On Wed, Oct 22, 2014 at 9:50 PM, Hagen Paul Pfeifer <hagen@...u.net> wrote: > At least better. But what userspace daemon would configure this? > Likely NetworkManager and friends. But at what conditions? Yes, that would be my suggestion for tools too. The conditions would depend on the kind of network, available information and so on. > 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. This is the main reason why I went with a socket option. While I worked on this patch I wrote a small daemon for testing purposes. This daemon analyses data exported from a mobile broadband modem (QMI), looks at total interface throughput and then multicasts a netlink message when it determines that a handover might happen. This message is only a hint and then it is up to the application developer to decide what to do. Another solution would be a hybrid, the module will works as I described and the socket option will be used as an opt-in for Freeze-TCP. > > Do you have considered to bring this to the IETF (TCPM WG)? > Yes, I am currently considering it, or if I should look into different solutions before bringing it up for discussion. The ideal solution would be if there was a way to force a retransmit when the handover period is over, but that opens a whole net set of problems, potential security problems and changes TCP semantics a bit. An advantage of Freeze-TCP is that it works fine with what we have today. Thanks for your detailed comments! Kristian -- 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
Powered by blists - more mailing lists