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

["ma yc" <[e-mail]>]

Hi Parsi,

I would like to participate the following items.

[ECR] o  Using GRE "key" header field as IPsec traffic selector (possible
   starting point: draft-ma-softwire-ipsec-gre-demultiplexing-ps)
[ECR] o  Setting up GRE tunnels with IKE (possible starting point:
   draft-wu-l3vpn-ipsec-gre-00)
[R]  o  Non-EAP-based one-time password authentication (possible
   starting point: draft-sunabhi-otp-ikev2)
[R] o  IKEv2 session resumption / optimizing IKEv2 handshake when
    connecting again to same peer/cluster of peers (possible
    starting point: draft-sheffer-ipsec-failover)

Regards
Yuanchen

> On Wed, May 7, 2008 3:19 am, [e-mail] wrote:
> > 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.
> >
> > ---
> >
> > P.P.S. Acknowledgement: if you followed how Julien Laganier and
> > Marcelo Bagnulo handled the MEXT WG rechartering recently, you'll
> > notice I have stolen some ideas from them :-)
> > _______________________________________________
> > IPsec mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ipsec
> >
_______________________________________________
IPsec mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ipsec