[tcpm] RFC1323 revision

Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be> Fri, 27 July 2012 10:17 UTC

Return-Path: <olivier.bonaventure@uclouvain.be>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 657E821F863C for <tcpm@ietfa.amsl.com>; Fri, 27 Jul 2012 03:17:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id HkumjBLNQ1NC for <tcpm@ietfa.amsl.com>; Fri, 27 Jul 2012 03:17:09 -0700 (PDT)
Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be []) by ietfa.amsl.com (Postfix) with ESMTP id AEBA921F85FF for <tcpm@ietf.org>; Fri, 27 Jul 2012 03:17:09 -0700 (PDT)
Received: from mbpobo.dhcp.info.ucl.ac.be (haproxy2.sipr.ucl.ac.be []) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 29A6411EB7D; Fri, 27 Jul 2012 12:17:04 +0200 (CEST)
X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 29A6411EB7D
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1343384224; bh=zLXxdx9dtoTkSZjKn2vLi2r0RUVOxKWX2ALDnHoiA8s=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject: Content-Type:Content-Transfer-Encoding; b=UfSTXrfHzDG2zUfJDflZYD4dMa5Vhz2d9OaZ3CbfnFv5aPHoqYhxp8lt9Mk9THF0y fOpn/RzsdoubLmt/aM34j+ivXYSXlhxfXqYTRn2MrWaUqDAhU4bOr0B67fvtVmbCTM HnwSD1G3ev21D55Zx7xouMQpy6UN3vK3zcphHTXw=
Message-ID: <50126AA0.4050506@uclouvain.be>
Date: Fri, 27 Jul 2012 12:17:04 +0200
From: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: rs@netapp.com, tcpm@ietf.org
X-Enigmail-Version: 1.4.3
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.97.3-exp at smtp-5.sipr-dc.ucl.ac.be
X-Virus-Status: Clean
X-Sgsi-Spamcheck: SASL authenticated,
X-SGSI-MailScanner-ID: 29A6411EB7D.A1E70
X-SGSI-MailScanner: Found to be clean
X-SGSI-From: olivier.bonaventure@uclouvain.be
X-SGSI-Spam-Status: No
Subject: [tcpm] RFC1323 revision
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Olivier.Bonaventure@uclouvain.be
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Jul 2012 10:17:10 -0000


I won't be at IETF next week and I saw that you were responsible for a
new version of RFC1323. Since the first publication of RFC1323, the
Internet has changed and a revision of this RFC should at least detail
one problem that occurs in practice but was not anticipated by the
designers of TCP or the authors of RFC1323.

RFC1323 assumes that if the client receives the WScale option in the
SYN+ACK, then the window scale can be safely used during the entire
connection. This is unfortunately not true since a stateful firewall can
(and some still do -
http://www.cisco.com/application/pdf/paws/71602/pix-sa-tcp-scaling-ts.pdf )
accept the WSCALE option in the SYN and SYN+ACK segments while not
understanding them and they discard the packets that appear to be
outside the window.

I think that the RFC should at least document this problem and encourage
firewall developpers to either :
- remove WSCALE option in the SYN segment if they don't support RFC1323
- support RFC1323

We would expect that all firewalls support RFC1323, almost 20 years
after the initial publication, but this is probably still not the case

Note that the presence of middleboxes causes other types of failure
scenarios that can affect RFC1323 implementations. For example, consider
a firewall that removes the WSCALE option from the SYN+ACK segment but
not from the SYN segment (e.g. because the path is assymetrical and the
packets go through different firewalls). In this case, the server will
be using WSCALE while the client will not be using WSCALE. This is
another failure situation with middleboxes that should at least be

I'll be on holidays during the next two weeks, but if needed, I'd be
ready to contribute text on these issues.

Best regards,

Olivier Bonaventure

INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be