FW: WG Review: IP Security Maintenance and Extensions (ipsecme)

<Pasi.Eronen@nokia.com> Wed, 25 June 2008 07:26 UTC

Return-Path: <ipv6-bounces@ietf.org>
X-Original-To: ipv6-archive@megatron.ietf.org
Delivered-To: ietfarch-ipv6-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 713E33A6893; Wed, 25 Jun 2008 00:26:46 -0700 (PDT)
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ACBB3A6893 for <ipv6@core3.amsl.com>; Wed, 25 Jun 2008 00:26:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89R+uhZD0gOX for <ipv6@core3.amsl.com>; Wed, 25 Jun 2008 00:26:43 -0700 (PDT)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 64E5A3A677E for <ipv6@ietf.org>; Wed, 25 Jun 2008 00:26:43 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5P7QbDG007348 for <ipv6@ietf.org>; Wed, 25 Jun 2008 10:26:42 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jun 2008 10:26:05 +0300
Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jun 2008 10:26:05 +0300
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: FW: WG Review: IP Security Maintenance and Extensions (ipsecme)
Date: Wed, 25 Jun 2008 10:26:04 +0300
Message-ID: <1696498986EFEC4D9153717DA325CB72FD369E@vaebe104.NOE.Nokia.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: WG Review: IP Security Maintenance and Extensions (ipsecme)
Thread-Index: AcjWF57d/96p82bISCmdmbuVhjd7DgAfLYgA
From: <Pasi.Eronen@nokia.com>
To: <ipv6@ietf.org>
X-OriginalArrivalTime: 25 Jun 2008 07:26:05.0457 (UTC) FILETIME=[BA9F6010:01C8D694]
X-Nokia-AV: Clean
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

FYI (in case you don't follow ietf-announce:) One of the proposed
work items is about IPv6, and the charter text calls for
cooperation/coordination between 6MAN WG and the new WG. -Pasi

-----Original Message-----
From: IESG Secretary
Sent: 24 June, 2008 19:30
To: ietf-announce@ietf.org
Cc: ipsec@ietf.org
Subject: WG Review: IP Security Maintenance and Extensions (ipsecme) 

A new IETF working group has been proposed in the Security Area.  The IESG
has not made any determination as yet.  The following draft charter was
submitted, and is provided for informational purposes only.  Please send
your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, July 1,
2008.


IP Security Maintenance and Extensions (ipsecme)
------------------------------------------------
Last Modified: June 19, 2008

Current Status: Proposed Working Group

Chair(s): TBD

Mailing Lists:

General Discussion: ipsec@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec
Archive: http://www.ietf.org/mail-archive/web/ipsec/

The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated
RFCs), IKEv2 (RFC 4106, RFC 4718, and associated RFCs), 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 will continue 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 and improvements to
IPsec, mostly to IKEv2. The working group will also be a focus point for
other IETF Working Groups who use IPsec in their own protocols.

The initial set of work items is:

- A revision to IKEv2 (RFC 4306) that incorporates the clarifications
from RFC 4718, and otherwise improves the quality of the specification,
taking into account implementation and interoperability experience. In
some cases, the revision may include small technical corrections;
however, impact on existing implementations must be considered. Major
changes and adding new features is beyond the scope of this work
item. The starting point for this work is draft-hoffman-ikev2bis.

- An IPsec document roadmap that describes the various RFC documents
covering IPsec, including both the core RFC 240x and RFC 430x versions
of IPsec, and extensions specified in other documents. Sections 2 and 3
of RFC 2411 can provide useful material, but the expected scope is
slightly different from RFC 2411. This document will be informational.

- A standards-track extension to IKEv2 that provides full IPv6 support
for IPsec remote access clients that use configuration payloads. This
work will be based on draft-eronen-ipsec-ikev2-ipv6-config. The WG shall
solicit help and reviews from the 6MAN WG to ensure that all aspects of
IPv6 are properly considered.

- A standards-track extension that allows an IPsec remote access client
to "resume" a session with a gateway; that is, to skip certain parts of
IKE negotation when connecting again to the same gateway (or possibly a
cluster of closely cooperating gateways). The idea is similar to TLS
session resumption without server-side state, specified in RFC 5077.

The main goals for this extension are to avoid public-key computations
(to reduce VPN gateway load when a large number of clients reconnect to
the geteway within a short period of time, such as following a network
outage), and remove the need for user interaction for authentication
(which may be required by some authentication mechanisms). The extension
shall not have negative impact on IKEv2 security features.

Failover from one gateway to another, mechanisms for detecting when a
session should be resumed, and specifying communication mechanisms
between gateways are beyond the scope of this work item. Specifying the
detailed contents of the "session ticket" is also beyond the scope of
this document; if there is sufficient interest, this could be specified
later in a separate document.

To the degree its content falls within the scope of this work item, text
and ideas from draft-sheffer-ipsec-failover will be used as a starting
point.

- A standards-track extension to IPsec that allows an IPsec remote
access gateway to redirect VPN clients to another gateway. This
extension should be aligned with the session resumption extension,
(the previous work item), and if so decided by the WG, could be
specified in the same document. The starting point will be
draft-devarapalli-ipsec-ikev2-redirect.

- A standards-track mechanism that allows an intermediary device, such
as a firewall or intrusion detection system, to easily and reliably
determine whether an ESP packet is encrypted with the NULL cipher; and
if it is, determine the location of the actual payload data inside the
packet. The starting points for this work item are
draft-grewal-ipsec-traffic-visibility and draft-hoffman-
esp-null-protocol.

The initial scope of the WG is restricted to the work items listed
above. The WG shall not consider adding new work items until one or more
of its documents progress to IESG evaluation. At that time, the WG can
propose rechartering.

Chartering this WG is not intended to have effect on documents that
beyond the initial scope. In particular, work on IPsec extensions that
are not included in this charter can happen as usual in other WGs (and
there are currently several other WGs working on IPsec extensions; for
example, BTNS and ROHC), or as individual submissions.

This charter will expire in July 2010 (24 months from approval). If
the charter is not updated before that time, the WG will be closed and
any remaining documents revert back to individual Internet-Drafts.

Milestones:

Dec 2008 WG last call on IPv6 configuration payloads
Dec 2008 WG last call on IPsec roadmap
Jan 2009 WG last call on session resumption
Feb 2009 WG last call on redirect
Mar 2009 WG last call on IKEv2bis
Apr 2009 WG last call on ESP NULL traffic visibility

-
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------