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

["fan zhao" <[e-mail]>]

Hi Vijay,

I also support this work item.

Sincerely,
fan


On Wed, May 7, 2008 at 11:33 AM, Vijay Devarapallli <[e-mail]> wrote:
> oops.. I just noticed that you did have the following in the list.
>
> o  Redirecting a VPN client from one gateway to another
>  (in a cluster of gateways)
>
> Is this the same? Or did someone else propose this?
>
> Vijay
>
> On Wed, May 7, 2008 at 11:30 AM, Vijay Devarapallli <[e-mail]> wrote:
>> 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
>
_______________________________________________
IPsec mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ipsec