Re: [MSEC] [IPsec] GDOI GROUPKEY-PUSH Acknowledgment Message

Paul Wouters <paul@nohats.ca> Thu, 05 January 2017 22:49 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: msec@ietfa.amsl.com
Delivered-To: msec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9301296EC; Thu, 5 Jan 2017 14:49:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.1
X-Spam-Level:
X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 7hDt7IMGCaqp; Thu, 5 Jan 2017 14:49:02 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.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 00EAB129460; Thu, 5 Jan 2017 14:49:01 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3tvjXV6dmqz3DG; Thu, 5 Jan 2017 23:48:58 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1483656538; bh=GMgsydjBh3ujhiaO2CfYvhkIMgEFaqpBbjMES/CDRsk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=AZwlD0HacvHsh/TjgCKZnXLzkxorWk4ES31kUxIML1mKWuoEgRaT5nCarDNuqubhD Pf405LMqM4oVIRdPS+WnihJpZVsBQXfFw1JKM/ZNoZGTaaXP5BENiw9Tv85BdpZlHG IpI448znMYW8qUkPzgRvDGRIMbc8u8qSbAbnyRiE=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id gbRJoV5RYS1k; Thu, 5 Jan 2017 23:48:56 +0100 (CET)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 5 Jan 2017 23:48:56 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id E89C161A45; Thu, 5 Jan 2017 17:48:53 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca E89C161A45
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D107B4942C65; Thu, 5 Jan 2017 17:48:53 -0500 (EST)
Date: Thu, 5 Jan 2017 17:48:53 -0500 (EST)
From: Paul Wouters <paul@nohats.ca>
To: "Brian Weis (bew)" <bew@cisco.com>
In-Reply-To: <7D8F64E3-7B45-4141-95ED-87E2F503EB71@cisco.com>
Message-ID: <alpine.LRH.2.20.1701051741570.16157@bofh.nohats.ca>
References: <7D8F64E3-7B45-4141-95ED-87E2F503EB71@cisco.com>
User-Agent: Alpine 2.20 (LRH 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT
Archived-At: <https://mailarchive.ietf.org/arch/msg/msec/zZ0U0WPKuAR4mB-lt5pFKjSEtRY>
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, "msec@ietf.org" <msec@ietf.org>
Subject: Re: [MSEC] [IPsec] GDOI GROUPKEY-PUSH Acknowledgment Message
X-BeenThere: msec@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multicast Security List <msec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/msec>, <mailto:msec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/msec/>
List-Post: <mailto:msec@ietf.org>
List-Help: <mailto:msec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/msec>, <mailto:msec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jan 2017 22:49:03 -0000

On Wed, 4 Jan 2017, Brian Weis (bew) wrote:

>
> In Seoul there was a presentation on the GDOI GROUPKEY-PUSH Acknowledgment Message (https://datatracker.ietf.org/doc/draft-weis-gdoi-rekey-ack/), an update to RFC 6407 (GDOI) — a group key management protocol using IKEv1. GDOI was originally managed by the MSEC WG, which is no longer active. The question was asked as to whether there was any interest in the IPSECME working group in this work, and the authors were asked to take the question to this list. Please respond if you believe the draft should be managed within IPSECME, rather than as an AD sponsored draft (which is the alternative plan).

Is 6407 actually implemented for IKEv2? It really reads as an IKEv1
plugin. Similarly, this also seems like an IKEv1 plugin for that
plugin. I'm a little surprised 6407 is Standards Track.

I wasn't around when 6407 happened. It seems like a very complicated
keying protocol that just happens to be run inside IKE (although on
a different port?). I'm not sure how many people within ipsecme
are familiar with this and would want to work on this document. As
it seems to not affect IKEv2 on port (4)500, I feel it is probably
best done without adoption by the WG. Although it currently says
Standards Track, so I'm not sure if it can be that and AD sponsored?

Paul