IETF Logo Mail Archive

Re: [tcpinc] Revised version of TCP-ENO

Kyle Rose <krose@krose.org> Fri, 14 August 2015 00:54 UTC

Return-Path: <krose@krose.org>
X-Original-To: tcpinc@ietfa.amsl.com
Delivered-To: tcpinc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE021AD0D3 for <tcpinc@ietfa.amsl.com>; Thu, 13 Aug 2015 17:54:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=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 OvoaUkQj4WB0 for <tcpinc@ietfa.amsl.com>; Thu, 13 Aug 2015 17:54:30 -0700 (PDT)
Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (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 2D83F1AD0D6 for <tcpinc@ietf.org>; Thu, 13 Aug 2015 17:54:30 -0700 (PDT)
Received: by igui7 with SMTP id i7so2725268igu.1 for <tcpinc@ietf.org>; Thu, 13 Aug 2015 17:54:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9f/0KIt+x6O97RhfBZQdliqitFN8rPVzDWM2rPNwU6w=; b=eNUP4xYOA44KzNhecLLaiYc1EVZJP/BCRF+3L1CA3wkr3zzzYBzDyBiCGLYikpbVEm WBH4pY2qTXsJld2f/1FJeoNkuEYjlplP29vpjDeG9JPhE3cS2aOWJa6dXToJTqQOipXG YUnRxARMrywgWCIdqC/pU7OLXUNui7atwUr2c=
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:date :message-id:subject:from:to:cc:content-type; bh=9f/0KIt+x6O97RhfBZQdliqitFN8rPVzDWM2rPNwU6w=; b=D+Yyf6QzDDWK8j14coj13AbSRlMNLPk2smrlm/0dHesBHc0SgtYhYhyou5RS8Wnt62 UiZseh0K2FFBqdXvupxs5tKNDGxehgpgHnke54Sl0xOGcnmrO/BB6KZaYZ38FKldNr+i 76B/6NwgRPlXJLJlJSYNfZYyBvzSR759beKMSmW+05O7agbOswzjaE7qrK8rv5zgYFmI MOTlGPS+JeerjiB3wzsY6thrDsaHch6RJLC7FqOtpyXj0YjB4HzqyMKNnvLAUT7W5XAV uROlbKM2H/KeA6qieMDjSekPW4xKHqewiaygfBx9YXozC4JI9zk6Cq+lfOfC2FsEd2KW lm9g==
X-Gm-Message-State: ALoCoQn7IPMJYrwGLLJmzqbyHxtdX/eRiBrFQ+KXQka/j3wIH+O11paO4XTPOB5YKgNN26lwbzkI
MIME-Version: 1.0
X-Received: by 10.50.30.196 with SMTP id u4mr188410igh.11.1439513669400; Thu, 13 Aug 2015 17:54:29 -0700 (PDT)
Received: by 10.79.31.197 with HTTP; Thu, 13 Aug 2015 17:54:29 -0700 (PDT)
X-Originating-IP: [207.172.212.184]
In-Reply-To: <87h9o4rqwz.fsf@ta.scs.stanford.edu>
References: <87pp2vqplu.fsf@ta.scs.stanford.edu> <CAJU8_nXAHhf6dqqs0gUEGz49bG7YUO1qaGwaLm04+vstPTyfWg@mail.gmail.com> <87h9o4rqwz.fsf@ta.scs.stanford.edu>
Date: Thu, 13 Aug 2015 20:54:29 -0400
Message-ID: <CAJU8_nVCo3+6BwWn-ikdHXbhiOE-Yo+35H5o4mYf0iLi_2eHzA@mail.gmail.com>
From: Kyle Rose <krose@krose.org>
To: David Mazieres <dm-list-tcpcrypt@scs.stanford.edu>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tcpinc/Xts4O7l-daq0aqk-4w1Dfr5EOQw>
Cc: tcpinc@ietf.org
Subject: Re: [tcpinc] Revised version of TCP-ENO
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 14 Aug 2015 00:54:32 -0000

>> What is the meaning of "first valid spec identifier"? This allowance
>> for multiple spec identifiers sent by host B makes sense if the chosen
>> spec is "the first spec identifier also among those spec identifiers
>> that host A sent",
>
> That is the intent.  In other words, if A and B have multiple compatible
> spec identifiers, the negotiated spec is the one at the lowest byte
> offset in B's SYN segment.

I missed the definition for "valid" in 3.2. That resolves my confusion.

>>> A TCP segment MUST
>>> include at most one suboption whose high nibble is 0.
>>
>> Does this mean "A TCP SYN segment including the TCP-ENO option MUST..."?
>
> Yes.  Would the following wording help:  "A TCP segment MUST include at
> most one ENO suboption whose high nibble is 0."

Yes, that is more precise.

Kyle

v2.23.0 | Report a Bug | By Email