netdev - Re: [PATCH 2/2] dccp: Do not let initial option overhead shrink the MPS

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] [day] [month] [year] [list]

Date:	Mon, 02 Mar 2009 03:08:10 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	gerrit@....abdn.ac.uk
Cc:	dccp@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 2/2] dccp: Do not let initial option overhead shrink
 the MPS

From: Gerrit Renker <gerrit@....abdn.ac.uk>
Date: Sat, 28 Feb 2009 09:38:29 +0100

> This fixes a problem caused by the overlap of the connection-setup and
> established-state phases of DCCP connections.
> 
> During connection setup, the client retransmits Confirm Feature-Negotiation
> options until a response from the server signals that it can move from the
> half-established PARTOPEN into the OPEN state, whereupon the connection is
> fully established on both ends (RFC 4340, 8.1.5).
> 
> However, since the client may already send data while it is in the PARTOPEN
> state, consequences arise for the Maximum Packet Size: the problem is that the
> initial option overhead is much higher than for the subsequent established
> phase, as it involves potentially many variable-length list-type options
> (server-priority options, RFC 4340, 6.4).
> 
> Applying the standard MPS is insufficient here: especially with larger
> payloads this can lead to annoying, counter-intuitive EMSGSIZE errors.
> 
> On the other hand, reducing the MPS available for the established phase by
> the added initial overhead is highly wasteful and inefficient.
> 
> The solution chosen therefore is a two-phase strategy:
> 
>    If the payload length of the DataAck in PARTOPEN is too large, an Ack is sent
>    to carry the options, and the feature-negotiation list is then flushed.
> 
>    This means that the server gets two Acks for one Response. If both Acks get
>    lost, it is probably better to restart the connection anyway and devising yet
>    another special-case does not seem worth the extra complexity.
> 
> The result is a higher utilisation of the available packet space for the data
> transmission phase (established state) of a connection.
> 
> The patch (over-)estimates the initial overhead to be 32*4 bytes -- commonly
> seen values were around 90 bytes for initial feature-negotiation options.
> 
> It uses sizeof(u32) to mean "aligned units of 4 bytes".
> For consistency, another use of 4-byte alignment is adapted.
> 
> Signed-off-by: Gerrit Renker <gerrit@....abdn.ac.uk>

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