Re: [IPsec] ikev1-graveyard

Benjamin Kaduk <kaduk@mit.edu> Mon, 08 April 2019 20:54 UTC

Return-Path: <kaduk@mit.edu>
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 E4173120104 for <ipsec@ietfa.amsl.com>; Mon, 8 Apr 2019 13:54:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 J_WUGBVLGu_m for <ipsec@ietfa.amsl.com>; Mon, 8 Apr 2019 13:54:35 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 6C42F120013 for <ipsec@ietf.org>; Mon, 8 Apr 2019 13:54:34 -0700 (PDT)
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x38KsU38018237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 8 Apr 2019 16:54:32 -0400
Date: Mon, 08 Apr 2019 15:54:29 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: ipsec@ietf.org
Message-ID: <20190408205429.GU70202@kduck.mit.edu>
References: <14997.1554660673@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <14997.1554660673@localhost>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/a7wyyg4OrPV1oBqB3Y0PW7EjdHE>
Subject: Re: [IPsec] ikev1-graveyard
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, 08 Apr 2019 20:54:37 -0000

On Sun, Apr 07, 2019 at 02:11:13PM -0400, Michael Richardson wrote:
> 
> I have read draft-pwouters-ikev1-ipsec-graveyard-00.
> 
> I think that the actual words and organization of the document could use a
> bit of polish, but fundamentally it does the right thing, and sends the right message.
> 
> I would like to ask the WG to adopt this document, we can sort out the
> wording afterwards, and spend (priority) WG time on this document.
> 
> I would very much like to point to a clear statement when I see IKEv1 being
> used in the field for no good reason (except that nobody thought about IKEv2).
> If it has to be in the form of an RFC, so be it: I'd like to be able to say
> to a manager, "You are not RFCZZYY compliant", and I'd like this to get
> into a variety of security audit lists.
> 
> The document likely has likely little technical impact, and I think we should
> acknowledge that this is a policy statement.
> That's okay with me, if it it is okay with the IESG.
> If there is another way to get the same impact, I'm open to hearing it.
> 
> The datatracker page for RFC2409 already says:
>    Type		RFC - Proposed Standard (November 1998; No errata)
>    Obsoleted by RFC 4306
>    Updated by RFC 4109
> 
> But, I think that the goal is to mark these documents as Historic as well.
> I didn't see that action in the document specifically (maybe I missed it).
> Many updates to the IANA registries, which we could do in other ways, I think.
> 
> As I understand it, marking something as Historic is something the IESG can
> do without publishing a document.  The changes to the IANA registries I'm
> less clear about, but I believe it could also be done without a document.

To move to historic, there should be some form of document (per
https://www.ietf.org/blog/iesg-statement-designating-rfcs-historic/) but it
need not be published as an RFC.  The past few times we've done this
everyone involved had to think for a while to remember what the right way
to wrangle the wording in the published RFC should be, but we can worry
about that later if we need to.

-Ben