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

"Brian Weis (bew)" <> Fri, 06 January 2017 16:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A65F3129B76; Fri, 6 Jan 2017 08:43:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.622
X-Spam-Status: No, score=-17.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B9AcdvpzhLlq; Fri, 6 Jan 2017 08:43:18 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 81771129B74; Fri, 6 Jan 2017 08:43:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2854; q=dns/txt; s=iport; t=1483720998; x=1484930598; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=begZ85Yh3aD5cYZldfBxQpVTa4Gkr0d+0HKu/Ao7nok=; b=L0xmAIWrwhZbPUGu/fa4FzFmXreQPzYf2YBql4HSkeNmjYZJctgQb904 OmLIX70BiDeclVbUPj9g7Ls/VhzVFKu2ybKT4q8+nZ5xFLHGVjBpY64mc lbYBehHEQVdvRwRuxRX04OR3uzKv/UJXgYPvMVoFfg0L9agbBSSUS5MmC 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.33,325,1477958400"; d="scan'208";a="369554791"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jan 2017 16:43:17 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v06GhHjT006939 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Jan 2017 16:43:17 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 6 Jan 2017 11:43:16 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Fri, 6 Jan 2017 11:43:16 -0500
From: "Brian Weis (bew)" <>
To: Paul Wouters <>
Thread-Topic: [IPsec] GDOI GROUPKEY-PUSH Acknowledgment Message
Thread-Index: AQHSZt5Pm+5bN/TfMkWEbIAgfGfqGaEq0duAgAEsLYA=
Date: Fri, 6 Jan 2017 16:43:16 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "" <>
Subject: Re: [MSEC] [IPsec] GDOI GROUPKEY-PUSH Acknowledgment Message
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multicast Security List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 Jan 2017 16:43:19 -0000

Hi Paul,

Thanks for your comments.

> On Jan 5, 2017, at 2:48 PM, Paul Wouters <> wrote:
> On Wed, 4 Jan 2017, Brian Weis (bew) wrote:
>> In Seoul there was a presentation on the GDOI GROUPKEY-PUSH Acknowledgment Message (, 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.

Correct, it’s based on IKEv1. We understand that IPSECME is focused on IKEv2, but were asked to make sure that the working group was not interested before taking another path.

> 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?).

The goal of the 6407 is to provide key management for IP multicast flows. The IKE1 protocol re-use for 6407 makes sense for the devices that supported IPsec protection for both unicast and multicast traffic.

> 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?

Kathleen has agreed to AD sponsor the draft if ipsecme is not interested.


> Paul

Brian Weis
Security, CSG, Cisco Systems
Telephone: +1 408 526 4796