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, 01 Sep 2010 09:05:23 +0200
From:	Alexander Zimmermann <alexander.zimmermann@...sys.rwth-aachen.de>
To:	Gerrit Renker <gerrit@....abdn.ac.uk>
Cc:	Ilpo J?rvinen <ilpo.jarvinen@...sinki.fi>,
	David Miller <davem@...emloft.net>, dccp@...r.kernel.org,
	Netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH 3/5] tcp/dccp: Consolidate common code for RFC 3390
	conversion

Hi Gerrit,

Am 01.09.2010 um 07:23 schrieb Gerrit Renker:

> | > This patch consolidates initial-window code common to TCP and CCID-2:
> | >  * TCP uses RFC 3390 in a packet-oriented manner (tcp_input.c) and
> | >  * CCID-2 uses RFC 3390 in packet-oriented manner (RFC 4341).
> ...
> | > +static inline u32 rfc3390_bytes_to_packets(const u32 smss)
> | > +{
> | > +	return smss <= 1095 ? 4 : (smss > 1460 ? 2 : 3);
> | > +}
> | > +
> ...
> | 
> | What is spelled out in tcp_select_initial_window might also need to follow 
> | the same logic?
> | 
> Thank you for paying attention, can you please have a look at the subsequent
> patch. I went through this yesterday and found that in 4 different places 
> there are 4 different interpretations of what RFC 3390 means.
> 
> Having asked someone more familiar with IETF issues, it seems that the RFC 5681
> interpretation of RFC 3390 is now the 'official' one.
> 
> +------------+--------------------+--------------------+--------------------+--------------------+
> | Condition  |     RFC 2414       |        Linux       |       Linux        |     RFC 5681       |
> |            |     RFC 3390       |      tcp_input     |     tcp_output     |                    |
> +------------+--------------------+--------------------+--------------------+--------------------+
> | 2 segments | 2190 < MSS         | 1460 < MSS         | 4380 < MSS         | 2190 < MSS         |
> | 3 segments | 1095 < MSS <= 1460 | 1095 < MSS <= 1460 | 1460 < MSS <= 4380 | 1095 < MSS <= 2190 |

                              ^^^^^

Are you sure about this?

RFC3390 says (page 2):
 If (1095 bytes < MSS < 2190 bytes) then win <= 4380;

So, IMO it should be 1095 < MSS < 2190 for 3 segments, and 2190 <= MSS for 2 segments
in the "RFC 3390" column.

BTW: I think that we should not reference RFC2414, since RFC3390 obsoletes it.

Alex


> | 4 segments |        MSS <= 1095 |        MSS <= 1095 |        MSS <= 1460 |        MSS <= 1095 |
> +------------+--------------------+--------------------+--------------------+--------------------+
> --
> 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

//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: (49-241) 80-22221
// email: zimmermann@...rwth-aachen.de
// web: http://www.umic-mesh.net
//


Download attachment "PGP.sig" of type "application/pgp-signature" (196 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ