[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 [127.0.0.1]) 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-Level:
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 ([12.22.58.30]) by localhost (ietfa.amsl.com
[127.0.0.1]) (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 [130.104.5.67]) 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
[130.104.5.120]) (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
Richard, 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 everywhere... 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 mentionned. 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
- [tcpm] RFC1323 revision Olivier Bonaventure