Re: [tcpinc] [tcpm] WGLC for draft-ietf-tcpinc-tcpeno

Joe Touch <touch@isi.edu> Mon, 06 February 2017 16:35 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 50AEF12943A; Mon, 6 Feb 2017 08:35:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] 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 TpxUOemyrLPQ; Mon, 6 Feb 2017 08:35:16 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 E90DA129417; Mon, 6 Feb 2017 08:35:15 -0800 (PST)
Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v16GYW5v000331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 6 Feb 2017 08:34:34 -0800 (PST)
To: David Mazieres expires 2017-05-06 PDT <mazieres-pkmdzkf62nfmb5xbagc254xup6@temporary-address.scs.stanford.edu>, "Scharf, Michael (Nokia - DE)" <michael.scharf@nokia.com>, "Holland, Jake" <jholland@akamai.com>, "tcpinc@ietf.org" <tcpinc@ietf.org>
References: <D668D28F-42BB-40A4-81D1-1FF2D3D95ECB@akamai.com> <87fujvonza.fsf@ta.scs.stanford.edu> <1FD85C9B-BE52-4E9F-A6D9-54BAD0425C8A@akamai.com> <655C07320163294895BBADA28372AF5D48D1DE65@FR712WXCHMBA15.zeu.alcatel-lucent.com> <87zii0ydil.fsf@ta.scs.stanford.edu>
From: Joe Touch <touch@isi.edu>
Message-ID: <ca32a70e-a7fe-5ce2-aaa4-781effa479cf@isi.edu>
Date: Mon, 06 Feb 2017 08:34:33 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <87zii0ydil.fsf@ta.scs.stanford.edu>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
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/j7e9icHKYWKRCzfKjgILTB3pOco>
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpinc] [tcpm] WGLC for draft-ietf-tcpinc-tcpeno
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Working group mailing list for TCP Increased Security \(tcpinc\)" <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: Mon, 06 Feb 2017 16:35:17 -0000

FWIW:


On 2/5/2017 5:26 AM, David Mazieres wrote:
> "Scharf, Michael (Nokia - DE)" <michael.scharf@nokia.com> writes:
>
>> While TCPM discusses large SYN options (for a long time already), all
>> known solutions have downsides. I do not believe that a non-TCPM
>> document should speculate on the feasibility solutions.
> Michael, what do you think of the new proposed wording?
>
>    Various proposals exist to increase the maximum space for options in
>    the TCP header.  Though these proposals are highly experimental--
The non-SYN extension is currently a WG document and intended for
standards-track.
>    particularly those that apply to SYN segments
The SYN extension proposals all have significant known issues and are
both highly experimental and difficult to deploy.

> --TCP-layer encryption
>    could significantly benefit from the availability of increased SYN
>    option space.
It might be useful to differentiate between the potential use of non-SYN
vs. SYN space.

You should be more explicit that "Although this protocol could benefit
from extended SYN space, e.g., to support in-band key coordination,
future TEPs should expect to use only the currently available space."

IMO, the following is speculative and not useful:

>   In particular, if future TEPs can perform key
>    agreement by embedding public keys or Diffie-Hellman parameters
>    within suboption data, it will simplify protocols and reduce the
>    number of round trips required for connection setup.  With large
>    options, the 32-byte limit on length bytes could prove insufficient.
>    This draft intentionally aborts TCP-ENO if a length byte is followed
>    by an octet in the range 0x00-0x9f.
The following appears to direct TCPM docs to update this doc, which is
not appropriate. If there is a SYN extension, it is much more likely to
be a stand-alone doc to update RFC793 and other docs would individually
update protocols that might benefit from that space.

>   Any document updating TCP's
>    option size limit can also define the format of larger suboptions by
>    updating this draft to assign meaning to such currently undefined
>    byte sequences.

...
>
> Our goal is not to second-guess TCPM, but rather to provide TCPM with a
> data point that they have a "customer" for large SYN options in the
> unlikely event that some proposal is ever deemed realistic.  I could
> make the wording even stronger, as in:
>
>    These proposals are highly experimental--with those that apply to SYN
>    segments particularly unlikely to be adopted any time soon--but
>    TCP-layer encryption could significantly benefit from the
>    availability of increased SYN option space.
Actually, the above is much more useful (IMO), but most of the rest of
the paragraph can be omitted.

Joe

>
> But that could be seen as second-guessing TCPM in the other
> direction--telling TCPM we *don't* expect them to standardize large SYN
> options anytime soon.  (Of course, it's true that I don't expect them to
> do that, but it might not be my place to say so in an RFC unless you
> sign off on the language...)
>
> As always, concrete suggestions on wording are appreciated.
>
> Thanks,
> David
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm