Re: [IPsec] Proposed wording for a revised charter

Daniel Migault <daniel.migault@ericsson.com> Mon, 07 March 2016 15:59 UTC

Return-Path: <mglt.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1B31B4354 for <ipsec@ietfa.amsl.com>; Mon, 7 Mar 2016 07:59:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 WX2U9Ok7WjVr for <ipsec@ietfa.amsl.com>; Mon, 7 Mar 2016 07:59:28 -0800 (PST)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41DD01B434F for <ipsec@ietf.org>; Mon, 7 Mar 2016 07:59:28 -0800 (PST)
Received: by mail-wm0-x22e.google.com with SMTP id p65so76030650wmp.0 for <ipsec@ietf.org>; Mon, 07 Mar 2016 07:59:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=RzcV8a3XNpdPPePWASwLT3ko0C6+DPjNW5JGzq8F+ss=; b=IAlJBNlE7736CW5urUTDC9At07j94nb6xX/DkgfWEp+D4zueAYKrf6sWBBYH7xyvZo vNTh/IZgiBTOTb1TKntgEQNj1U8pweRNW2aZWdpdMaI8zTpel6GO2Hp+s5BUD/94YNCs wyOU5r4nk6F4pQrS7NUKiZ5I10GCqIc7rNKntMaU8HntBWUv5VGGfIgvRfOHkQjsEUYd 8Edx2XetyQom20VQrBQ9PoNO2AuBj93tcdWxBEj2X+Gr0zpeyP1921KhLZhUK/+LTZ1l w79x1rqAt6aNDZcRXTUJZCWrCnsAmcnTbD7SJvd6f3fhqlvfM5CniKXzIp5Szr2oxQ1S wIog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=RzcV8a3XNpdPPePWASwLT3ko0C6+DPjNW5JGzq8F+ss=; b=PNaQaKGGVdGdueUY9TpTDOGZ0IPDZMCK2dnA+IddILyx5bjX6v97PgV/C3DA8zd+12 v6AowRqKUGXdE5ZKYx9OE3gg97BmRbLkCFoADN2m7fUQaaUSx/TCBfGnnWYx1NAtguiw eCkh+/QxzEv1EmfyW+ZfuY35qSnXX5LKgAurqpjb6kS2xEWE9N+teWPySV1lwXxinz7f uLckdyAREDAn24Xv8dFZ2GHGQu/FYiS45B5N7Y2I9vziZIteXZ01Ppi4MEH4xu3L9uc3 AzWfoFNRL8zvKTlwpmAgk3aAk0TZhTvh+IrvQ+3ADyAhRbBt8t43RTC6iNflDhTI4MBg Rpuw==
X-Gm-Message-State: AD7BkJLRF9BOUfMYOLeOGaVwER53q9ejcktbZJgwYhYdEufQy2kSCjpT2SeiJ/RrJ7OhY6U73nM9RScibelCKw==
MIME-Version: 1.0
X-Received: by 10.28.90.68 with SMTP id o65mr13254457wmb.70.1457366366798; Mon, 07 Mar 2016 07:59:26 -0800 (PST)
Sender: mglt.ietf@gmail.com
Received: by 10.194.78.199 with HTTP; Mon, 7 Mar 2016 07:59:26 -0800 (PST)
In-Reply-To: <82BDFE1B-EF80-49EA-BD47-4D77C5E812EA@vpnc.org>
References: <82BDFE1B-EF80-49EA-BD47-4D77C5E812EA@vpnc.org>
Date: Mon, 07 Mar 2016 15:59:26 +0000
X-Google-Sender-Auth: TTR6CxBXaz41Zghaq1OXqqw-2zA
Message-ID: <CADZyTknA1PHJpeBhwrCJSk1fdYxnNMmd+HjmuE3B9UXtNXb_=Q@mail.gmail.com>
From: Daniel Migault <daniel.migault@ericsson.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: multipart/alternative; boundary="001a1145239499cc34052d778c94"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipsec/X0lVZZyDbElEkKW0_hf-XZVNokQ>
Cc: IPsecME WG <ipsec@ietf.org>
Subject: Re: [IPsec] Proposed wording for a revised charter
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
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, 07 Mar 2016 15:59:30 -0000

Hi,

We would like to add the definition of YANG models for IKEv2 and IPsec as
items of the charter. The intent of such models is to be able to provide
configurations that are implementations independent. Of course IPsecme will
be expected to provide feed backs/comments on the data model which does not
require any YANG knowledge. YANG aspects will be validated by YANG
tools/community.

We will publish a draft that proposes a YANG model for IKEv2 by next week.
Future drafts on for IPsec will be provided later too.
BR,

Daniel

On Tue, Mar 1, 2016 at 4:18 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

> Greetings. We need to update our charter to reflect our current and
> expected work. Dave and I propose the following text. Please let us know
> within the next week if you have suggestions for changes.
>
> --Paul Hoffman and Dave Waltermire
>
>
> The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs),
> IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). IPsec is
> widely deployed in VPN gateways, VPN remote access clients, and as a
> substrate for host-to-host, host-to-network, and network-to-network
> security.
>
> The IPsec Maintenance and Extensions Working Group continues the work of
> the earlier IPsec Working Group which was concluded in 2005. Its purpose is
> to maintain the IPsec standard and to facilitate discussion of
> clarifications,
> improvements, and extensions to IPsec, mostly to IKEv2.
> The working group also serves as a focus point for other IETF Working
> Groups
> who use IPsec in their own protocols.
>
> The current work items include:
>
> IKEv2 contains the cookie mechanism to protect against denial of service
> attacks. However this mechanism cannot protect an IKE end-point (typically,
> a large gateway) from "distributed denial of service", a coordinated
> attack by
> a large number of "bots". The working group will analyze the problem and
> propose a solution, by offering best practices and potentially by extending
> the protocol.
>
> IKEv2 utilizes a number of cryptographic algorithms in order to provide
> security services. To support interoperability a number of mandatory-to-
> implement (MTI) algorithms are defined in RFC4307. There is interest in
> updating the MTIs in
> RFC4307 based on new algorithms, changes to the understood security
> strength of existing algorithms, and the degree of adoption of previously
> introduced algorithms. The group will revise RFC4307 proposing updates to
> the MIT algorithms used by IKEv2 to address these changes.
>
> There is interest in supporting Curve25519 and Curve448 for ephemeral key
> exchange in the IKEv2 protocol. The group will extend the
> IKEv2 protocol to support key agreement using these curves and their
> related functions.
>
> This charter will expire in August 2016. If the charter is not updated
> before
> that time, the WG will be closed and any remaining documents revert back to
> individual Internet-Drafts.
>
>
>
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>