netdev - Re: [PATCH RFC] Per route TCP options

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]

Date:	Wed, 21 Oct 2009 10:04:06 +0200
From:	Gilad Ben-Yossef <gilad@...efidence.com>
To:	Rick Jones <rick.jones2@...com>
CC:	netdev@...r.kernel.org, ori@...sleep.com
Subject: Re: [PATCH RFC] Per route TCP options

Rick Jones wrote:

> Gilad Ben-Yossef wrote:
>> Turn the global sysctls allowing disabling of TCP SACK, DSCAK,
>> time stamp and window scale into per route entry feature options,
>> laying the ground to future removal of the relevant global sysctls.
>>
>> You really only want to disable SACK, DSACK, time stamp or window
>> scale if you've got a piece of broken networking equipment somewhere 
>> as a stop gap until you can bring a big enough hammer to deal with
>> the broken network equipment. It doesn't make sense to "punish" the
>> entire connections going through the machine to destinations not 
>> related to the broken equipment.
>
> Is it really only the case that those options get disabled for broken 
> networking equipment?  Does this presage making all TCP options 
> per-route only?
Well, I assume it might be the case that there are situations where you 
are trying to communicate over some exotic link  where the networking 
equipment is not broken as such, but the unusual properties of the link 
makes one of the features not desirable. I can't think of such a 
situation right now off the top of my head, but maybe they exist.

The point is that even then you are more then likely to wish to turn off 
these options to specific destination and routes (that go over said 
exotic link) and keep using them over others - e.g. timestamp OK for 
local LAN, but for default route that goes over exotic TCP/IP over 
carrier penguins turn it off.

To sum it up, I think making these options per route is a win no matter 
the situation. The question I am less certain about if it is also 
desirable to have a global kill switch in addition to the per route 
options. My gut feeling is that this is not needed once you have a per 
route option.

Cheers,
Gilad

-- 
Gilad Ben-Yossef
Chief Coffee Drinker & CTO
Codefidence Ltd.

Web:   http://codefidence.com
Cell:  +972-52-8260388
Skype: gilad_codefidence
Tel:   +972-8-9316883 ext. 201
Fax:   +972-8-9316884
Email: gilad@...efidence.com

Check out our Open Source technology and training blog - http://tuxology.net

	"Sorry cannot parse this, its too long to be true  :)"
	  -- Eric Dumazet on netdev mailing list

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