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

["Vijay Devarapallli" <[e-mail]>]

Hi Pasi,

I have one more. Sorry for not posting this earlier.

There was a proposal coming out of the former MIP6 WG to use IKEv2 to
re-direct a mobile node to another home agent. The Binding
Update/Binding Acknowledgement exchange between the mobile node and
the home agent is always preceded by an IKEv2 exchange for mutual
authentication, home address configuration and setting up the required
security associations for protecting Mobile IPv6 signaling messages.
It was felt that it would be desirable for the home agent to tell the
mobile node to go another home agent before the IKEv2 exchange
completes. Otherwise the mobile node would have do the IKEv2 exchange
with the new home agent all over.

This proposal for re-directing the mobile node to another home agent
during the IKE_SA_INIT exchange was in a ex-MIP6 WG document. There
were some issues raised during the IESG review for the IKEv2 re-direct
mechanism. So the mechanism was taken out and the rest of the document
was published as RFC 5026. One of the concerns expressed was that it
could be generic extension to IKEv2 rather than being something
specific to Mobile IPv6.

So I would like to propose to add another work item to the new IPsec
WG charter to work on a IKEv2 re-direct mechanism during the
IKE_SA_INIT exchange. Much of the details have already been worked out
(by the ex-MIP6 WG and then some discussions offline), it is just a
matter of writing up a draft. I am in the process of writing up this
draft. This is coming a bit late. I hope it can be included in the
IPsec re-chartering process.

Regards,
Vijay

On Wed, May 7, 2008 at 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