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

[<[e-mail]>]

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