Re: [IPsec] IPsec maintenance/extensions WG, summary so far

"Peng Yang" <peng.yang.chn@gmail.com> Mon, 26 May 2008 08:31 UTC

Return-Path: <ipsec-bounces@ietf.org>
X-Original-To: ipsec-archive@megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1EB028C152; Mon, 26 May 2008 01:31:07 -0700 (PDT)
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BA7F3A6B82 for <ipsec@core3.amsl.com>; Mon, 26 May 2008 01:31:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 L3wlwzEuP10y for <ipsec@core3.amsl.com>; Mon, 26 May 2008 01:31:05 -0700 (PDT)
Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.187]) by core3.amsl.com (Postfix) with ESMTP id 71AFF3A6B81 for <ipsec@ietf.org>; Mon, 26 May 2008 01:31:04 -0700 (PDT)
Received: by gv-out-0910.google.com with SMTP id e6so504072gvc.15 for <ipsec@ietf.org>; Mon, 26 May 2008 01:31:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=0vT7c11lcDZ/ZtPQi4XPGoUfP4WxWmrAwVjrvXAqvnQ=; b=XGF58euLd3iOv50u+7fPEw8SheIaAB1hqgC2gXy1Rvq2sReDEsRbmPo49pC1TnnNHOyCqo4p0YbIihe1tca0KJMLl94nRVZp8+JEacTGcDUA827gy6fgwO5iirJ1XCAhrNQkieI9JkpRujPWRk06p6Zi9tKydpyArTUn+JaiByg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uRB8Qpkq4ZJxdUPN9pdoIrXEsS3bQSAOCgkZj4QXPTfsGg8rO2hf0WLSZmqc4OoqG0iRCWfwMHsqK5F+EoJvIvHptO7Xfc86/4j5dmbp22kwnW21RWkgApKBzI8GRq5rg7BkBoOOHz/damgwWlP8+mmojaLmhFTJ9zQFYG04rNs=
Received: by 10.142.98.18 with SMTP id v18mr1894251wfb.61.1211790663846; Mon, 26 May 2008 01:31:03 -0700 (PDT)
Received: by 10.142.211.11 with HTTP; Mon, 26 May 2008 01:31:03 -0700 (PDT)
Message-ID: <4c5c7a6d0805260131j7218f64byb139ded878d3103d@mail.gmail.com>
Date: Mon, 26 May 2008 16:31:03 +0800
From: Peng Yang <peng.yang.chn@gmail.com>
To: ipsec@ietf.org, Pasi.Eronen@nokia.com
In-Reply-To: <4c5c7a6d0805252341r84994d3tf66505ee9ee1fdf9@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
References: <4c5c7a6d0805252341r84994d3tf66505ee9ee1fdf9@mail.gmail.com>
Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

Hi, Pasi and all:

 Sorry for late post. And sorry for Pasi if you received multiple copy
of this mail.

My interest list has following items.

 [ECR] IKEv2 session resumption / optimizing IKEv2 handshake when
         connecting again to same peer/cluster of peers (possible
         starting point: draft-sheffer-ipsec-failover)
 [ECR] MEXT: interaction between IPsec and Mobile IP, Mobile IP
          specific extensions to IPsec
 [ECR] Using GRE "key" header field as IPsec traffic selector (possible
          starting point: draft-ma-softwire-ipsec-gre-demultiplexing-ps)

 Thanks a lot
 Cheers,

 Peny

> >>So far, we've had ~20 people who've expressed some form of support
> >>for creating a WG. This is good -- many current WGs have less than 20
> >>people who regularly post to the WG mailing list.
>
> >>However, by my count, we've also had ~20 proposals for work items.
> >>That obviously does not add up.
>
> >>I agree with Paul's comment about the WG scope: the WG should work
> >>on things where having a WG is really needed, and we actually have a
> >>*group* of people interested on participating.
>
> >>Having a WG should not encourage people to develop extensions that
> >>would not have happened in the absence of a WG (this usually indicates
> >>they're not widely needed). For some work items that have been
> >>proposed, an individual draft is IMHO a more appropriate process
> >>mechanism, and forming a WG would not automatically prevent
> >>publication of non-WG documents the WG decided not to take.
>
> >>To get some idea on what work items we have most interest in, I've
> >>collected those proposed so far (with some things vendors are known to
> >>do in proprietary ways thrown in).
>
> Please select the items you think the WG should work on (less than
> ten, please), order them most important first, and for each item,
> indicate what you're willing to do:
>
>  [E]dit: you're willing to edit the draft corresponding to the work
>  item (note: even if we use an individual draft as a starting point,
>  this does not automatically determine the editor of the WG item)
>
>  [C]ontribute: you're willing to propose non-trivial amounts of
>  text for the document during its development
>
>  [R]eview: you're willing to review new revisions of the draft
>  regularly (not just during WGLC)
>
> For example,
>
>  [CR] AEAD algorithms in IKEv2
>  [R] IPsec document roadmap update
>
> would mean that AEAD algorithms is your first priority, and you
> volunteer to contribute and review; and IPsec document roadmap is
> your second priority, and you volunteer to review.
>
> You can also propose a work item that isn't on my list.
> However, for the time being, I think PF_KEY work does not fit
> within the scope of the possible WG charter.
>
> List follows:
>
> o  Update to IKEv2 base specification (possible starting point:
>   draft-hoffman-ikev2bis)
>
> o  IPsec document roadmap update (possible starting point: RFC 2411)
>
> o  Using AEAD algorithms in IKEv2 (possible starting point:
>   draft-black-ipsec-ikev2-aead-modes)
>
> o  Redirecting a VPN client from one gateway to another
>   (in a cluster of gateways)
>
> o  IPsec "secure beacon", or detecting whether you need VPN or
>   not (possible starting point: draft-sheffer-ipsec-secure-beacon)
>
> o  Detecting crashed peers faster (possible starting point:
>   draft-nir-ike-qcd)
>
> o  IKEv2 session resumption / optimizing IKEv2 handshake when
>   connecting again to same peer/cluster of peers (possible
>   starting point: draft-sheffer-ipsec-failover)
>
> o  Authentication-only IPsec that simplifies packet inspection
>   (possible starting points: draft-hoffman-esp-null-protocol,
>   draft-grewal-ipsec-traffic-visibility)
>
> o  Better IPv6 configuration payloads (possible starting point:
>   draft-eronen-ipsec-ikev2-ipv6-config)
>
> o  Other work for making sure IKEv1 and IKEv2 work as well as
>   possible with IPv6, both from standards and operations standpoint
>   (please specify more details if you select this one)
>
> o  Running IPsec over TCP (so your VPN works even if the coffee
>   shop Wi-Fi has stupid packet filtering)
>
> o  GSS-API (or Kerberos) authentication for IKEv2
>
> o  Non-EAP-based one-time password authentication (possible
>   starting point: draft-sunabhi-otp-ikev2)
>
> o  Using GRE "key" header field as IPsec traffic selector (possible
>   starting point: draft-ma-softwire-ipsec-gre-demultiplexing-ps)
>
> o  Authentication with Cryptographically Generated Addresses (CGA)
>   (possible starting point: draft-laganier-ike-ipv6-cga)
>
> o  Guidelines for Mandating the Use of IPsec, for RFC430x IPsec
>   (possible starting point: draft-bellovin-useipsec)
>
> o  Labeled IPsec for RFC 430x IPsec
>
> o  IKEv1/IKEv2 co-existence and transition (please specify more
>   details if you select this one)
>
> o  Setting up GRE tunnels with IKE (possible starting point:
>   draft-wu-l3vpn-ipsec-gre-00)
>
> o  Connecting IKEv2 peers behind NATs via a "mediation server"
>   (possible starting point: draft-brunner-ikev2-mediation)
>
> o  Anything that may be needed from IKE/IPsec with respect to
>   routing protocol security (please specify more details if
>   you select this one)
>
> o  Documenting differences in IPsec usage in IETF vs. 3GPP vs.
>   3GPP2 vs. WiMAX vs. vendors etc. (please specify more details
>   if you select this one)
>
> o  IKEv2 CAPTCHA
>   (possible starting point: draft-mutaf-spikev2-01.txt)
>
> Please reply (on the mailing list) within a week or so -- I will
> then summarize what we have.
>
> Best regards,
> Pasi
>
> ---
>
> P.S. It's good to note that we currently have several other WGs
> working on IPsec:
>
> o  BMWG: benchmarking IPsec devices
>
> o  BTNS: unauthenticated or leap-of-faith IPsec, channel bindings,
>   IPsec APIs for applications (not key management daemons like
>   PF_KEY)
>
> o  MEXT: interaction between IPsec and Mobile IP, Mobile IP
>   specific extensions to IPsec
>
> o  MSEC: multicast IPsec
>
> o  ROHC: header compression in IPsec tunnel mode SAs
>
> o  SOFTWIRE: IPsec tunnels as a softwire, setting those up
>   based on BGP etc.
>
> These WGs will continue as-is, and e.g. any changes to their charters
> are not in the scope of this discussion. Future work items could be
> considered case-by-case, but the intent is *not* to collect all
> IPsec-related work to one WG.
>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec