Return-Path: 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 AFE0212B319 for ; Tue, 6 Sep 2016 11:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508] 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 DSA03ZoXn3bQ for ; Tue, 6 Sep 2016 11:14:51 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 6325012B0B5 for ; Tue, 6 Sep 2016 11:14:51 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u86IERgh000602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 6 Sep 2016 11:14:27 -0700 (PDT) To: David Borman , Yoshifumi Nishida References: From: Joe Touch Message-ID: Date: Tue, 6 Sep 2016 11:14:27 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u86IERgh000602 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tcpm@ietf.org" , Sanjeev Ranot Subject: Re: [tcpm] (ref. RFC 7323) Increase of shift count from 14 to 15. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2016 18:14:53 -0000 Hi, all, On 9/6/2016 7:24 AM, David Borman wrote: > The biggest problem with changing the shift count midstream is that TCP has no reliable mechanism for doing option negotiation midstream. Agreed. > The only packets that are reliably delivered are packets that contain data or have the SYN or FIN bit set. AFAICT, this isn't strictly true. The data and connection state are reliably "delivered" (or synchronized), but not the packets per se. Options in those packets aren't reliably delivered any more than any other packet, esp. because TCP has no strict requirement that the options of retransmitted segments don't vary. TCP gets around this by confirming the options exchanged during the SYN, but no other time during the connection. You *can* build your own handshake on top of TCP, but it's complicated. We did this for TCP-AO to support key rollover - the sender offers a new key, which cannot be used until the receiver confirms it. The same happens in the opposite direction. As Dave pointed out, this takes up option space (one extra byte in AO, in addition to the confirmation being overloaded with the current keyID) and requires that the option "protocol" consider how to handle handshake failure, packet reordering, etc. Joe