[IPsec] Additional charter items 1 thu 4

Michael Richardson <mcr+ietf@sandelman.ca> Sun, 25 February 2018 19:36 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 3B265126DFB for <ipsec@ietfa.amsl.com>; Sun, 25 Feb 2018 11:36:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ICmleCp0GNOR for <ipsec@ietfa.amsl.com>; Sun, 25 Feb 2018 11:36:09 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93C4D1241F8 for <ipsec@ietf.org>; Sun, 25 Feb 2018 11:36:09 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0161720090 for <ipsec@ietf.org>; Sun, 25 Feb 2018 14:43:44 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 18EF980D06 for <ipsec@ietf.org>; Sun, 25 Feb 2018 14:36:08 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: ipsec@ietf.org
In-Reply-To: <23175.7252.256625.885691@fireball.acr.fi>
References: <23175.7252.256625.885691@fireball.acr.fi>
X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Sun, 25 Feb 2018 14:36:08 -0500
Message-ID: <28247.1519587368@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/uOYuwLvBGmF5VvJucbru1wC4wrA>
Subject: [IPsec] Additional charter items 1 thu 4
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.22
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: Sun, 25 Feb 2018 19:36:11 -0000

Tero asked about:
1) Responder MOBIKE
2) Address Failure Errors
3) Labeled IPsec
4) Mitigating privacy concerns

I read through the discussion about them, and read some of the drafts.
I find that 1,2,3 are all well defined and bounded in time and space.

I found that #4 is not so well understood; in particular it seems to suggest
doing things not just defend against, but subvert government actors.
I don't really object to such work occuring, but I want to suggest that
this is a case of cat-and-mouse arms race.  I suggest that the IETF is
too slow a place to do this.  Do this in open source.

I would not object to seeing a a moderate number (~dozen) of types allocated
for experimental use.  i.e. details to be provided later.  Pretty much all of
our tables are Expert Review. Go out there and try some things with real
code, and then report back in two years which mechanisms scaled and did the
right thing.

I have a concern with #3: while I know that redhat delivers this to
government customers, are there any other vendors will also implement?
If not, then I'm worried we won't have enough interested parties to review,
unless some of the actual customers are brought to the table to review.

I'd like to prioritize #2 as highest.

I think that #1 (Responder MOBIKE) may suffer from lack of actual
implementers being involved today.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-