Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt

Pasi Sarolahti <pasi.sarolahti@iki.fi> Mon, 27 May 2013 20:41 UTC

Return-Path: <pasi.sarolahti@iki.fi>
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 83A2621F8B04 for <tcpm@ietfa.amsl.com>; Mon, 27 May 2013 13:41:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 y02e4SF9KfBg for <tcpm@ietfa.amsl.com>; Mon, 27 May 2013 13:41:06 -0700 (PDT)
Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 60DC121F8A7B for <tcpm@ietf.org>; Mon, 27 May 2013 13:41:04 -0700 (PDT)
Received: from [192.168.1.70] (80.223.92.46) by jenni2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 5163F0F203156B11; Mon, 27 May 2013 23:40:45 +0300
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Pasi Sarolahti <pasi.sarolahti@iki.fi>
In-Reply-To: <51A3A684.5020400@isi.edu>
Date: Mon, 27 May 2013 23:40:52 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <B3F294F6-8866-4155-98F6-0927B90346E4@iki.fi>
References: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> <CAK6E8=d_LTZgnGAncdWDAi+7ebd3Lo5aevPeGG0=KSbBMeBhcg@mail.gmail.com> <519A8322.6030405@isi.edu> <26034_1369382276_519F1D83_26034_1735_1_519F1D68.604@uclouvain.be> <E220F4B0-EE27-431C-BCBE-0A0C01C8B0EF@iki.fi> <51A38F9F.4000407@isi.edu> <39EDB63B-7FCB-43F5-9355-474D50976005@iki.fi> <51A3A684.5020400@isi.edu>
To: Joe Touch <touch@ISI.EDU>
X-Mailer: Apple Mail (2.1503)
Cc: "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Mon, 27 May 2013 20:41:12 -0000

On May 27, 2013, at 9:31 PM, Joe Touch <touch@ISI.EDU> wrote:

> Regarding handling of non-RSTs lacking TSopt, we did discuss this on the list; you even cited this within the past day or so:
> 
> ---
>> Always including TSopt seems to represent the rough consensus of the
>> WG, even if it might not be a uniform agreement. This was discussed
>> quite extensively some time ago. (Though judging rough consensus from
>> Emails is difficult... we'd need some sort of electronic hum tool
> ---

My recollection is that this discussion concerned sender-side behavior, but there have been tens of Emails during the past weeks, so I might have missed something.

> Once you indicate a sender-side MUST, you need to describe how the receiver handles exceptions. IMO, there's little point to claiming PAWS protection if you're going to react *in any way* to a non-RST segment lacking TSopt.
> 
> I.e., a sender MUST include implies - IMO - a receiver MUST silently discard when the 'must' isn't there.

My reading of the original robustness principle is that TCP receiver should have minimal required validation checks for segments, so I don't think sender-side "MUST include" automatically implies receiver-side "MUST ignore if missing", unless we can point out a clear problem in accepting the segment. Perhaps the possible unreliability of PAWS is such, then.

But there are possible deployment implications in additional receiver check, too. In a perfect world this might work, but RFC 1323 did not have as strict MUST requirement about including TSopt in all segments after handshake, and there are possible middlebox issues as Olivier mentioned. So I think it would be worthwhile addition to the middlebox section, then, to say if a middlebox removes TSopt option, or a resegmenting middlebox does not include it in all segments, that breaks the TCP connection entirely, if this version of spec is followed.

As a mere data point, I did a quick check on Linux that currently seems to first check if timestamp option was in incoming segment, and only then do PAWS check. It does not reject segments because of lack of TSopt, at least based on my quick reading.

- Pasi