Re: [IPsec] Adoption call for draft-hopps-ipsecme-iptfs

Tommy Pauly <tpauly@apple.com> Mon, 28 October 2019 16:44 UTC

Return-Path: <tpauly@apple.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC6F1200B4 for <ipsec@ietfa.amsl.com>; Mon, 28 Oct 2019 09:44:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.002
X-Spam-Level:
X-Spam-Status: No, score=-7.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 zmE09q2suEQ0 for <ipsec@ietfa.amsl.com>; Mon, 28 Oct 2019 09:44:35 -0700 (PDT)
Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 263A3120098 for <ipsec@ietf.org>; Mon, 28 Oct 2019 09:44:35 -0700 (PDT)
Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x9SGVNOt042783; Mon, 28 Oct 2019 09:44:33 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=ZHLhz+j879dnuxbxSP22rc+7ZRNFcRQkkbxfj4SxUuk=; b=r9EwABQwiFG8OLN4nnpfv9ABbydvBAc54nTGyd4q5iGe2hHPYTGuFJV1Z3qRWBsqDhVA 5G0V6xM6IxR18OLyi/nIOVerXvDSygnsO0H2O5rbodMLZ7wdoOf6ySgGpQcXblC7LiAu eTel+Fpltx6KrZhB3KheB2ecnGUpy0fXNlec3gG4v6Z6gQMw+/sU39wbrCJFsTFaYsA9 6BMUkXmTBvVaEhseFxMtz81zgz56qHedlatSwHjwTLhbosibjE2SOojbRCmW8ffIjk4R AWSNH1F6E2igpncxQmkRJotX1y8CXLcH6QXWUbEwKIFlXd3LwcR7H0MVBYDONf/fhGW8 6w==
Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2vvjttthb6-19 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 28 Oct 2019 09:44:33 -0700
Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q0300GQDFU6Y370@ma1-mtap-s02.corp.apple.com>; Mon, 28 Oct 2019 09:44:30 -0700 (PDT)
Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q0300G00FS25Y00@nwk-mmpp-sz11.apple.com>; Mon, 28 Oct 2019 09:44:30 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 7b7c4a48706c56c09df429cd423b7c05
X-Va-E-CD: 87da3a9bbaa3527eb114afd29701fe95
X-Va-R-CD: f45a1599ad82be1ed75eba480cd9a2d0
X-Va-CD: 0
X-Va-ID: 8908570f-df50-4e60-8219-1ce644056c1c
X-V-A:
X-V-T-CD: 7b7c4a48706c56c09df429cd423b7c05
X-V-E-CD: 87da3a9bbaa3527eb114afd29701fe95
X-V-R-CD: f45a1599ad82be1ed75eba480cd9a2d0
X-V-CD: 0
X-V-ID: d4cbc3cc-6a1a-4d14-a07b-0778890f61aa
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-10-28_06:,, signatures=0
Received: from [17.192.171.228] by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q0300BRBFU67B20@nwk-mmpp-sz11.apple.com>; Mon, 28 Oct 2019 09:44:30 -0700 (PDT)
Sender: tpauly@apple.com
Content-type: text/plain; charset="us-ascii"
MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\))
From: Tommy Pauly <tpauly@apple.com>
In-reply-to: <23988.25468.681313.594115@fireball.acr.fi>
Date: Mon, 28 Oct 2019 09:44:18 -0700
Cc: ipsec@ietf.org
Content-transfer-encoding: quoted-printable
Message-id: <175DBE4C-550F-4E5A-8594-8438CB37C25E@apple.com>
References: <23988.25468.681313.594115@fireball.acr.fi>
To: Tero Kivinen <kivinen@iki.fi>
X-Mailer: Apple Mail (2.3594.4.17)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-28_06:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/stP7PXNURT4GtGGwLX0eGJS6s7k>
Subject: Re: [IPsec] Adoption call for draft-hopps-ipsecme-iptfs
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Oct 2019 16:44:37 -0000

I've read the document and think this is good problem area to work on, and this document is a good starting place to adopt.

Going forward, I would like to see more discussion and review of the use IP fragmentation (how often is that really needed, and is it worth the concerns stated in https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-17), as well as the use of Congestion Control (considerations for how having multiple layers of CC works, and if we can make sure that the format of the payload is aligned with current work in QUIC, etc).

Thanks,
Tommy

> On Oct 26, 2019, at 8:17 AM, Tero Kivinen <kivinen@iki.fi> wrote:
> 
> So this is fast (one week) adoption call for the
> draft-hopps-ipsecme-iptfs draft to be accepted to the WG document. We
> did have quite positive feedback in last IETF meeting and the charter
> item is being worked on in parallel to this call.
> 
> If you support adopting this document as WG document and as a starting
> place for the charter item proposed for the WG, then send email
> indicating your support to the ipsec@ietf.org mailing-list. If you
> have any comments or reservations send them to list too.
> 
> This adoption call finishes at 2019-11-04.
> 
> ----------------------------------------------------------------------
> The demand for Traffic Flow Confidentiality has been increasing in the user
> community; however, the current method defined in RFC4303 (i.e., add null
> padding to each ESP payload) is very inefficient in it's use of network
> resources. The working group will develop an alternative TFC solution that
> provides for efficient use of network resources.
> -- 
> kivinen@iki.fi
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec