IETF Logo Mail Archive

Re: [tcpinc] [tcpm] TCP's treatment of data in SYN packets

Gavin McCullagh <gmccullagh@gmail.com> Tue, 02 August 2016 03:52 UTC

Return-Path: <gmccullagh@gmail.com>
X-Original-To: tcpinc@ietfa.amsl.com
Delivered-To: tcpinc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA5B12D10D; Mon, 1 Aug 2016 20:52:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IL8yV3clPIK8; Mon, 1 Aug 2016 20:52:45 -0700 (PDT)
Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A99712B05E; Mon, 1 Aug 2016 20:52:45 -0700 (PDT)
Received: by mail-it0-x233.google.com with SMTP id f6so189535835ith.0; Mon, 01 Aug 2016 20:52:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l8diwhjPT6Vy60supX6vWSw8wbNCziXJt9ISImwHa8Q=; b=XBUNeC3HafUl/MRO5SpBGiAeChTV6rkNAd8XPSv3WigX6PRzuFMx3XElsadqIFPSxB wxWgng+PoOzg4IqjJj4vr8o+r/gW5VhuYL8VCwUmaCBIiYA0AIzKh9TK5vz5vsV8sVBM SUOav3LyUM0MFMHGL0KH7d/OBpWnaXoCpYMj0j1SIGuiqF3k01SKs75s8/yKCjVu/k5P DtfCF4xEnLY8Y14cP0ZKGMMGeC7ijfZ7J15c2Khjg95gVnS1fdxCiKDGEg3ax+04syax Ea8OZgLZ1DyQOrEJVchrP332jtlzjthdYpZU+55SOcZawLum5DNHa6iHgqZTrRzF5LUX kpZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l8diwhjPT6Vy60supX6vWSw8wbNCziXJt9ISImwHa8Q=; b=YMK2SRqsIrdqBSo6RpcGMT0KD1anuvPnmUEuiGGTUCN8P+ySyt5v/AlUhVUWT8T6k0 AG5BkNjytFzyTJgbnN7Mph19WGrNjrYSYfg1988R84iTMhSYEH8KAu3FO9puXwLZg0E0 EOKKBBlB+qes7JnV96YVMVivQSV3uQyyelb0cCp9/ONQKd+M1XAcu+vt8sAjsskpUvX7 /WMyGly9dF1H2v0fsKiEOMQ0MIcMuIG7+9u6Kb+5JVpjLIK6rMVqpRkarO/UBW2fp1pM wAvT7w9MrDZL6HheD1GRb9YX/AhtmeVpg3pua8YvjPOeUwptQFhy2pg4ZTAY5MipI0JY WOMQ==
X-Gm-Message-State: AEkoouvyH7VchZCx9DL+rWovJFYRo6beCLqiDp0adwSeGoxyx49RR8htMtaac89ZnPBYO5yDSOWM8F/o+NTwaQ==
X-Received: by 10.36.155.213 with SMTP id o204mr45034067itd.96.1470109964454; Mon, 01 Aug 2016 20:52:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.14.16 with HTTP; Mon, 1 Aug 2016 20:52:43 -0700 (PDT)
In-Reply-To: <20160728063754.GA24657@cowbell.employees.org>
References: <CAJU8_nU1WzQNFFUn_2o1cACutB01iyQ_hC29PHoutr8TRDKGnA@mail.gmail.com> <CAK6E8=d3psZBS1yX56fRQ-SP7qCN_vem5tNB8O42zPyo0TKj7Q@mail.gmail.com> <CAJU8_nWMBbqLLsYQ3GhqRk8YkptqjCF40h_R7HNSOrqHwLbgxQ@mail.gmail.com> <87wpk7x9v6.fsf@ta.scs.stanford.edu> <CAJU8_nWni5wu2BJLT_j559RjRT=GgrkyurQi2uwE7v8Mo61NHA@mail.gmail.com> <877fc6ycuw.fsf@ta.scs.stanford.edu> <20160727232419.GA45841@cowbell.employees.org> <20160728063754.GA24657@cowbell.employees.org>
From: Gavin McCullagh <gmccullagh@gmail.com>
Date: Mon, 01 Aug 2016 20:52:43 -0700
Message-ID: <CAHQ5LGpOXj3ri92wvUMkDF9pUGmDHvsF5u+DTG0SkJOV6qaBCQ@mail.gmail.com>
To: Derek Fawcus <dfawcus+lists-tcpcrypt@employees.org>
Content-Type: multipart/alternative; boundary="94eb2c05fb2036513805390ea6d1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/TLDXzWShQDOIQloADfYqB9IYADY>
Cc: tcpinc <tcpinc@ietf.org>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>, "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>, Kyle Rose <krose@krose.org>, David Mazieres expires 2016-10-25 PDT <mazieres-5mehvxfqtr38mvjvf6tfwgcy62@temporary-address.scs.stanford.edu>
Subject: Re: [tcpinc] [tcpm] TCP's treatment of data in SYN packets
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussion list for adding encryption to TCP." <tcpinc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpinc/>
List-Post: <mailto:tcpinc@ietf.org>
List-Help: <mailto:tcpinc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2016 03:52:48 -0000

Just to satisfy my curiosity, how did this work (or did it?) with TCP SYN
Cookies?

I can imagine a tcp listener which was implementing SYN Cookies only ACKing
the initial SYN sequence number and not the data which it discarded, then
the application retransmitting that data either on the subsequent ACK or
the next data packet.  Does that generally just work with most/all tcp
implementations on the other side?  I suppose it ought to?

Gavin

On Wed, Jul 27, 2016 at 11:37 PM, Derek Fawcus <
dfawcus+lists-tcpcrypt@employees.org> wrote:

> On Thu, Jul 28, 2016 at 12:24:19am +0100, Derek Fawcus wrote:
> >
> > Implying that a passive opener which chose to ack such data bytes would
> > have to buffer such data until the handshake completes;  but I'm not
> > aware of any stack which actually works that way.
>
> Except the old KA9Q NOS,  which was tickling my memory...
>
> It did have the ability to send such SYN data.
>
> DF
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>

v2.35.0 | Report a Bug | By Email | System Status