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

"Scharf, Michael (Nokia - DE)" <michael.scharf@nokia.com> Tue, 07 February 2017 06:53 UTC

Return-Path: <michael.scharf@nokia.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 7ADEF1293FD; Mon, 6 Feb 2017 22:53:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 Z_UBBovdSoHT; Mon, 6 Feb 2017 22:53:39 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0123.outbound.protection.outlook.com [104.47.0.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC1BD12009C; Mon, 6 Feb 2017 22:53:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6HssaODc2deMfDAafEeuvtg4F9f960hPHfMihwgV4is=; b=HKkA99lVCqT2OhFZvtO1kcNFa/VXqehV2XUu7geqrNw97CBA9kxHl7pQHRNxrS/hcDd8jYFTsp0aoQcqAhE3d4MJUyGLaisX8E6lLe6BW28GhD2SwdRl2+Kv6XSR9SW0ENY5GVMie3uWwDreZ1lJm1OY4g6+kTEfR3BndKzyO80=
Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Tue, 7 Feb 2017 06:53:36 +0000
Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) with mapi id 15.01.0888.025; Tue, 7 Feb 2017 06:53:36 +0000
From: "Scharf, Michael (Nokia - DE)" <michael.scharf@nokia.com>
To: Joe Touch <touch@isi.edu>, David Mazieres expires 2017-05-06 PDT <mazieres-pkmdzkf62nfmb5xbagc254xup6@temporary-address.scs.stanford.edu>, "Holland, Jake" <jholland@akamai.com>, "tcpinc@ietf.org" <tcpinc@ietf.org>
Thread-Topic: [tcpm] [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno
Thread-Index: AQHSfaH8bHX24B8Ba06t1pm3vEt1naFWrKGAgAE+RACAAg8N8IAAYQAAgAHG0YCAAP1Ouw==
Date: Tue, 07 Feb 2017 06:53:35 +0000
Message-ID: <AM5PR0701MB254723F1F442D3533DF15C9C93430@AM5PR0701MB2547.eurprd07.prod.outlook.com>
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>, <ca32a70e-a7fe-5ce2-aaa4-781effa479cf@isi.edu>
In-Reply-To: <ca32a70e-a7fe-5ce2-aaa4-781effa479cf@isi.edu>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=michael.scharf@nokia.com;
x-originating-ip: [135.245.48.254]
x-ms-office365-filtering-correlation-id: e4c583c4-3264-4074-951c-08d44f2609f5
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:AM5PR0701MB2547;
x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2547; 7:uQZIfVbbd2yO/5isdlkgb6Qc0kidKUj8Vz7Fb6WpwfuCYRIc8RfadwoTdqqdiqMDJetFSwwFU8xRhRPylGsakw0DXGeOY07qZzHrmTKJKdgPUkN5gJIT69AvD4pR/g0wc0bzEkrgcMP1nKBOghJkLt9f885A87HpXa46YIi0/mCZORT4iqwTaD4eZsboYDFVeUwZYDwCPlK3npkrpaicZELvpTtf/jFppDN/9ggpfKTEGe6dN5FPLiBNINnDddSGfHq/uExZGNh7IBKS8vIBu9Mh4NqEA7zrKXQVXKRLoT0+fzWDt2jhxPgNt6ASuT8tBKFWETIN5mDMrMfQKq0Z7KaNLUHJgySZb3o2Tg5nIhEAgMCZEMb4pvIl+wNlyTX/L5rAGAc2yogzruRN56NJj4fYMgiLeQwN28/p39ELp/4CwVziKqfPcrxIEng11Y6cGQVtgsBRmPY0Cc+4X257r5QA6UacIMddXQmsaRAL/UKFSZwCgWf8k9Bzq2MqY1FdOAQ9WTzix7fV4hVILsmOkA==
x-microsoft-antispam-prvs: <AM5PR0701MB2547356D2CA1F1FF3A410FF293430@AM5PR0701MB2547.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(244540007438412)(82608151540597);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(20170203043)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(20161123558025)(6072148); SRVR:AM5PR0701MB2547; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2547;
x-forefront-prvs: 0211965D06
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39840400002)(39850400002)(39450400003)(39410400002)(24454002)(199003)(377424004)(76104003)(377454003)(189002)(99286003)(53936002)(3280700002)(92566002)(101416001)(55016002)(6246003)(53546003)(93886004)(2906002)(230783001)(6436002)(25786008)(54356999)(50986999)(76176999)(33656002)(9686003)(8936002)(66066001)(102836003)(6116002)(189998001)(3846002)(81156014)(81166006)(8676002)(2900100001)(561944003)(4326007)(6506006)(122556002)(68736007)(97736004)(6306002)(7736002)(305945005)(74316002)(7696004)(2950100002)(2171002)(86362001)(5660300001)(229853002)(77096006)(3660700001)(38730400002)(106116001)(105586002)(106356001)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2547; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2017 06:53:35.8772 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2547
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/mIyeRaP18JeKPq99tazOGBavmq4>
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: Tue, 07 Feb 2017 06:53:41 -0000

I'd agree to Joe's proposal "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."

Michael (chair hat off)

________________________________________
From: Joe Touch <touch@isi.edu>
Sent: Monday, February 6, 2017 17:34
To: David Mazieres expires 2017-05-06 PDT; Scharf, Michael (Nokia - DE); Holland, Jake; tcpinc@ietf.org
Cc: tcpm@ietf.org
Subject: Re: [tcpm] [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno

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