IETF Logo Mail Archive

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

Joe Touch <touch@isi.edu> Sat, 06 August 2016 03:23 UTC

Return-Path: <touch@isi.edu>
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 48FC912D59A for <tcpinc@ietfa.amsl.com>; Fri, 5 Aug 2016 20:23:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.247
X-Spam-Level:
X-Spam-Status: No, score=-6.247 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no
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 xWZWxK2P38oU for <tcpinc@ietfa.amsl.com>; Fri, 5 Aug 2016 20:23:16 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 E1C2212D636 for <tcpinc@ietf.org>; Fri, 5 Aug 2016 20:23:15 -0700 (PDT)
Received: from [10.194.132.236] (mobile-166-170-045-224.mycingular.net [166.170.45.224] (may be forged)) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u763Md4p010923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Aug 2016 20:22:50 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Joe Touch <touch@isi.edu>
X-Mailer: iPhone Mail (13G34)
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949362F62A8C7@MX307CL04.corp.emc.com>
Date: Fri, 05 Aug 2016 20:22:39 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <8448D86C-66DE-4E80-9F80-D0C1F6D3ABD7@isi.edu>
References: <CAJU8_nU1WzQNFFUn_2o1cACutB01iyQ_hC29PHoutr8TRDKGnA@mail.gmail.com> <579A4669.7030600@isi.edu> <87lh0lselg.fsf@ta.scs.stanford.edu> <CAJU8_nUPrm9JJMrrMbL5+FpP-9CKC6EkidCry9UuZA5ZfyJtoA@mail.gmail.com> <579A8223.8050308@isi.edu> <CAJU8_nXSxr7ykC1TwptBmyP8pNccz52ozq=hF7-EYiaMdDeLBQ@mail.gmail.com> <579BA470.3000405@isi.edu> <CAJU8_nXjhHH1eEXPA3hvhJ3YXsP_v2djGX=X2p9+wyn767Hm5A@mail.gmail.com> <adcaa33a-3bf5-e63a-bd19-fd165b16aa7d@wizmail.org> <87oa5fniu0.fsf@ta.scs.stanford.edu> <9ff12fb6-44f9-b1d0-2e9d-a67683679037@wizmail.org> <CAJU8_nVBem40i5Rqke37UBtOquF_mVBJHkjrtAmNN2qPdHqY=A@mail.gmail.com> <87d1lunvhn.fsf@ta.scs.stanford.edu> <579E9248.7050006@isi.edu> <87popt6nci.fsf@ta.scs.stanford.edu> <87k2g16mvb.fsf@ta.scs.stanford.edu> <579F7076.1080101@isi.edu> <CE03DB3D7B45C245BCA0D243277949362F623EDF@MX307CL04.corp.emc.com> <57A28E5C.7070304@isi.edu> <CE03DB3D7B45C245BCA0D243277949362F624017@MX307CL04.corp.emc.com> <87eg64dn8o.fsf@ta.scs.stanford.edu> <2fe90a4b-0a7c! -928c-45ae-aae8900fd710@isi.edu> <CE03DB3D7B45C245BCA0D243277949362F62A8C7@MX307CL04.corp.emc.com>
To: "Black, David" <david.black@emc.com>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/KL9OQisup5Y21SYrUQulfdptiiY>
Cc: tcpinc <tcpinc@ietf.org>, David Mazieres expires 2016-11-02 PDT <mazieres-576gyzdgbyb4wezn5yznvcya8i@temporary-address.scs.stanford.edu>
Subject: Re: [tcpinc] 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: Sat, 06 Aug 2016 03:23:17 -0000

Good catch.  I agree. 

Joe

> On Aug 5, 2016, at 3:52 PM, Black, David <david.black@emc.com> wrote:
> 
> This looks good, although I think this "SHOULD" requirement ought to be a "MUST":
> 
>>>   If a host sends a SYN-only SYN+ENO segment bearing data and
>>>   subsequently receives a SYN-ACK segment without an ENO option, that
>>>   host SHOULD reset the connection even if the SYN-ACK segment does not
>>>   acknowledge the SYN data.

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