First charter draft

Thanks to everyone who replied to the poll!

Based on the responses, I've put together a first draft 
of charter text, which has IMHO quite reasonable balance 
between maintenance (ikev2bis, roadmap, ipv6) and the 
extensions with widest interest (session resumption and redirect).

I also tried to come up with some text describing the 
work items, to make it clear what's in scope and what is not.
(Comments on that text are welcome!)

This list doesn't include draft-black-ipsec-ikev2-aead-modes,
since it's basically read to be published now, and might be out
before the WG gets created.

Please send comments (either privately or on the list) 
as soon as possible -- to have the first WG meeting in Dublin,
we need to converge on charter text soon (since there are
several process steps it needs to go through before the WG
is officially approved).

Best regards,
Pasi

==========

IP Security Maintenance and Extensions (ipsecme)
DRAFT 2008-06-01

Chair(s): TBD

Re: First charter draft

Hello, Pasi,

Thanks for your hard work to collect these information.

Based on mailing list discussion, what we find is GRE key traffic selector
is No.6 popularity, there are several different parties from different places
interesting in this work, and there are one mobile operator having
this requirement.
and two experts had reviewed the draft and had deep discussion already.

Current charter only list top 5 popular work items, here
may I suggest that shall we take the GRE key traffic selector in this phase.
It will be appreciate if you could kindly help to consider it,

Best regards,

-Hui

2008/6/2  <Pasi.Eronen <at> nokia.com>:
> Thanks to everyone who replied to the poll!
>
> Based on the responses, I've put together a first draft
> of charter text, which has IMHO quite reasonable balance
> between maintenance (ikev2bis, roadmap, ipv6) and the
> extensions with widest interest (session resumption and redirect).
>
> I also tried to come up with some text describing the
> work items, to make it clear what's in scope and what is not.
> (Comments on that text are welcome!)
>

Re: First charter draft

Hi Pasi, All, 
Although I agree with pursuing these items, I would like the group to
also consider extensions for IPsec traffic visibility. There are two
drafts that are proposing some of these extensions and I am working with
some colleagues on submitting an update to one of these shortly. These
are:

http://www.ietf.org/internet-drafts/draft-hoffman-esp-null-protocol-00.t
xt.

and

http://www.ietf.org/internet-drafts/draft-grewal-ipsec-traffic-visibilit
y-00.txt

In your draft charter, there are two items related to IPsec VPNs.
Although VPN is the predominant use of IPsec today for remote access /
site-to-site, I believe one of the reasons that IPsec end-to-end is not
widely employed today is due to the lack of traffic visibility in
managed environments such as Enterprises. AH is not practical and ESP
does not offer enough flexibility. 

I would like the group to consider a small modification to the charter
and include text on using IPsec in real world, end-to-end solutions
where practical considerations such as network management tools /
intrusion detection / malware scanning tools are unable to operate when
the data is encrypted. Having IPsec extensions to accommodate these
tools will greatly increase the viability of using IPsec beyond just VPN
and remote access.

Re: First charter draft

_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

ipsec rekey issue

Hi all,

I have a rekey problem reference from
http://www.kame.net/racoon/racoon-ml/msg00874.html
I use 2.6.21.7 kernel with ipsec-tools 0.6.5 as the server, and Windows
XP as the client.

Setup a road warrior mode

Windows XP <---------------> VPN server <-----------> Internet
VPN Tunnel

The problem is when the tunnel is built, Windows XP try to download a
big file about 200MB.
When download progress reached about 120~130MB, Windows XP can not
access internet anymore.
After about 5 minutes, the tunnel seems work, Windows can access
internet again.
Any advice will be appreciated

Re: First charter draft

I do agree that the current extensions (session resumption and
redirect) are mostly targeted to "remote access VPN" use, and 
having a broader base could be useful.

However, we also need to prioritize -- not everything that is 
useful can be in the *first* charter -- and make sure every work 
item has sufficient interest (so it actually gets used) and people 
willing to work on it (so it gets done).

If we decide to take more than five items, "GRE key traffic selector"
and "ESP NULL traffic visibility" would be the ones with most support.

Both also look reasonably simple technically (the actual technical
details an implementor would need are probably less than five pages
each -- with additional text explaining the motivation, security
considerations, etc.), so this could be feasible.

However, I'd like to get some more opinions about these work
items, especially from people who participated in the discussions
about "ESP NULL traffic visibility" earlier.

Here's a short summary about these proposed work items:

o  A standards-track extension to IKEv2 to support using the "Key" 
   field of Generic Routing Encapsulation (GRE) packets, specified 
   in RFC 2890, as a traffic selector (in similar fashion as TCP/UDP 
   port number or ICMP type/code fields). This allows different GRE 
   traffic flows to be mapped to different IPsec SAs.  Any further 
   extensions related to the use of IPsec with GRE are beyond the 
   scope of this work item.

o  A standards-track mechanism that allows an intermediary device,
   such as a firewall or intrusion detection system, to easily and
   reliably determine whether an ESP packet is encrypted with the 
   NULL cipher; and if it is, determine the location of the actual 
   payload data inside the packet. The starting points for this work 
   item are draft-grewal-ipsec-traffic-visibility and draft-hoffman-
   esp-null-protocol.

Best regards,
Pasi 

> -----Original Message-----
> From: ext Grewal, Ken [mailto:ken.grewal <at> intel.com] 
> Sent: 04 June, 2008 20:42
> To: Eronen Pasi (Nokia-NRC/Helsinki); ipsec <at> ietf.org
> Subject: RE: [IPsec] First charter draft
> 
> Hi Pasi, All, 
> Although I agree with pursuing these items, I would like the group to
> also consider extensions for IPsec traffic visibility. There are two
> drafts that are proposing some of these extensions and I am 
> working with
> some colleagues on submitting an update to one of these shortly. These
> are:
> 
> http://www.ietf.org/internet-drafts/draft-hoffman-esp-null-pro
tocol-00.t
> xt.
> 
> and
> 
> http://www.ietf.org/internet-drafts/draft-grewal-ipsec-traffic
-visibilit
> y-00.txt
> 
> In your draft charter, there are two items related to IPsec VPNs.
> Although VPN is the predominant use of IPsec today for remote access /
> site-to-site, I believe one of the reasons that IPsec 
> end-to-end is not
> widely employed today is due to the lack of traffic visibility in
> managed environments such as Enterprises. AH is not practical and ESP
> does not offer enough flexibility. 
> 
> I would like the group to consider a small modification to the charter
> and include text on using IPsec in real world, end-to-end solutions
> where practical considerations such as network management tools /
> intrusion detection / malware scanning tools are unable to 
> operate when
> the data is encrypted. Having IPsec extensions to accommodate these
> tools will greatly increase the viability of using IPsec 
> beyond just VPN
> and remote access.
> 
> I will be happy to present some of these findings / ideas at the next
> IETF.
> 
> Thanks for your consideration... 
> 
> Thanks, 
> - Ken
>  
> 
> -----Original Message-----
> From: ipsec-bounces <at> ietf.org [mailto:ipsec-bounces <at> ietf.org] On Behalf
> Of Pasi.Eronen <at> nokia.com
> Sent: Sunday, June 01, 2008 11:13 AM
> To: ipsec <at> ietf.org
> Subject: [IPsec] First charter draft
> 
> Thanks to everyone who replied to the poll!
> 
> Based on the responses, I've put together a first draft 
> of charter text, which has IMHO quite reasonable balance 
> between maintenance (ikev2bis, roadmap, ipv6) and the 
> extensions with widest interest (session resumption and redirect).
> 
> I also tried to come up with some text describing the 
> work items, to make it clear what's in scope and what is not.
> (Comments on that text are welcome!)
> 
> This list doesn't include draft-black-ipsec-ikev2-aead-modes,
> since it's basically read to be published now, and might be out
> before the WG gets created.
> 
> Please send comments (either privately or on the list) 
> as soon as possible -- to have the first WG meeting in Dublin,
> we need to converge on charter text soon (since there are
> several process steps it needs to go through before the WG
> is officially approved).
> 
> Best regards,
> Pasi
> 
> ==========
> 
> IP Security Maintenance and Extensions (ipsecme)
> DRAFT 2008-06-01
> 
> Chair(s): TBD
> 
> Security Area Director(s): TBD
> 
> Mailing Lists:
> 
> General Discussion: ipsec <at> ietf.org
> To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec
> Archive: http://www.ietf.org/mail-archive/web/ipsec/
> 
> Description of Working Group:
> 
> The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated
> RFCs), IKEv2 (RFC 4106, RFC 4718, and associated RFCs), and the IPsec
> security architecture (RFC 4301). IPsec is widely deployed in VPN
> gateways, VPN remote access clients, and as a substrate for
> host-to-host, host-to-network, and network-to-network security.
> 
> The IPsec Maintenance and Extensions Working Group will continue the
> work of the earlier IPsec Working Group which was concluded in
> 2005. Its purpose is to maintain the IPsec standard and to facilitate
> discussion of clarifications, improvements, and extensions and
> improvements to IPsec, mostly to IKEv2. The working group will also 
> be a focus point for other IETF Working Groups who use IPsec in their 
> own protocols.
> 
> The initial set of work items is:
> 
> o  A revision to IKEv2 (RFC 4306) that incorporates the
>    clarifications from RFC 4718, and otherwise improves the quality
>    of the specification, taking into account implementation and
>    interoperability experience.  In some cases, the revision may
>    include small technical corrections; however, impact on existing
>    implementations must be considered. Major changes and adding new
>    features is beyond the scope of this work item. The starting
>    point for this work is draft-hoffman-ikev2bis. 
> 
> o  An IPsec document roadmap that describes the various RFC 
>    documents covering IPsec, including both the core RFC 240x 
>    and RFC 430x versions of IPsec, and extensions specified in 
>    other documents. Sections 2 and 3 of RFC 2411 can provide  
>    useful material, but the expected scope is slightly different 
>    from RFC 2411. This document will be informational.
> 
> o  A standards-track extension to IKEv2 that provides full IPv6
>    support for IPsec remote access clients that use configuration
>    payloads. This work will be based on
>    draft-eronen-ipsec-ikev2-ipv6-config.
> 
> o  A standards-track extension that allows an IPsec remote access
>    client to "resume" a session with a gateway; that is, to skip 
>    certain parts of IKE negotation when connecting again to the 
>    same gateway (or possibly a cluster of closely cooperating 
> gateways).
> 
>    The idea is similar to TLS session resumption without
>    server-side state, specified in RFC 5077.
> 
>    The main goals for this extension are to avoid public-key
>    computations (to reduce VPN gateway load when a large number of
>    clients reconnect to the geteway within a short period of time,
>    such as following a network outage), and remove the need for
>    user interaction for authentication (which may be required by
>    some authentication mechanisms). The extension shall not have 
>    negative impact on IKEv2 security features.
> 
>    Failover from one gateway to another, mechanisms for detecting
>    when a session should be resumed, and specifying communication
>    mechanisms between gateways are beyond the scope of this work
>    item.  Specifying the detailed contents of the "session ticket"
>    is also beyond the scope of this document; if there is sufficient 
>    interest, this could be specified later in a separate document.
> 
>    To the degree its content falls within the scope of this work
>    item, text and ideas from draft-sheffer-ipsec-failover will be
>    used as a starting point.
> 
> o  A standards-track extension to IPsec that allows an IPsec remote
>    access gateway to redirect VPN clients to another gateway. This
>    extension should be aligned with the session resumption extension,
>    (the previous work item), and if so decided by the WG, could be
>    specified in the same document. The starting point will be
>    draft-devarapalli-ipsec-ikev2-redirect.
> 
> The initial scope of the WG is restricted to the work items listed
> above. The WG shall not consider adding new work items until one or
> more of its documents progress to IESG evaluation. At that time, the
> WG can propose rechartering.
> 
> Chartering this WG is not intended to have effect on documents that
> beyond the initial scope. In particular, work on IPsec extensions that
> are not included in this charter can happen as usual in other WGs (and
> there are currently several other WGs working on IPsec extensions; for
> example, BTNS and ROHC), or as individual submissions.
> 
> This charter will expire in June 2010 (24 months from approval).  If
> the charter is not updated before that time, the WG will be closed and
> any remaining documents revert back to individual Internet-Drafts.
> 
> Goals and Milestones:
> 
> Dec 2008  WG last call on IPv6 configuration payloads
> Dec 2008  WG last call on IPsec roadmap
> Mar 2009  WG last call on IKEv2bis
> Jan 2009  WG last call on session resumption
> Feb 2009  WG last call on redirect
> 
> ================
> 
> _______________________________________________
> IPsec mailing list
> IPsec <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
> 

Re: First charter draft

Hi Pasi,
Since these are relatively simple techniques, including those shouldn't
impact the work group schedule.
I fully support including the "GRE key traffic selector" in the work group
charter.

Thanks,
Yingzhe

-----Original Message-----
From: ipsec-bounces <at> ietf.org [mailto:ipsec-bounces <at> ietf.org] On Behalf Of
Pasi.Eronen <at> nokia.com
Sent: Thursday, June 05, 2008 12:42 PM
To: ken.grewal <at> intel.com; ipsec <at> ietf.org
Subject: Re: [IPsec] First charter draft

I do agree that the current extensions (session resumption and
redirect) are mostly targeted to "remote access VPN" use, and 
having a broader base could be useful.

However, we also need to prioritize -- not everything that is 
useful can be in the *first* charter -- and make sure every work 
item has sufficient interest (so it actually gets used) and people 
willing to work on it (so it gets done).

If we decide to take more than five items, "GRE key traffic selector"
and "ESP NULL traffic visibility" would be the ones with most support.

Both also look reasonably simple technically (the actual technical
details an implementor would need are probably less than five pages
each -- with additional text explaining the motivation, security
considerations, etc.), so this could be feasible.

However, I'd like to get some more opinions about these work
items, especially from people who participated in the discussions
about "ESP NULL traffic visibility" earlier.

Here's a short summary about these proposed work items:

o  A standards-track extension to IKEv2 to support using the "Key" 
   field of Generic Routing Encapsulation (GRE) packets, specified 
   in RFC 2890, as a traffic selector (in similar fashion as TCP/UDP 
   port number or ICMP type/code fields). This allows different GRE 
   traffic flows to be mapped to different IPsec SAs.  Any further 
   extensions related to the use of IPsec with GRE are beyond the 
   scope of this work item.

o  A standards-track mechanism that allows an intermediary device,
   such as a firewall or intrusion detection system, to easily and
   reliably determine whether an ESP packet is encrypted with the 
   NULL cipher; and if it is, determine the location of the actual 
   payload data inside the packet. The starting points for this work 
   item are draft-grewal-ipsec-traffic-visibility and draft-hoffman-
   esp-null-protocol.

Best regards,
Pasi 

> -----Original Message-----
> From: ext Grewal, Ken [mailto:ken.grewal <at> intel.com] 
> Sent: 04 June, 2008 20:42
> To: Eronen Pasi (Nokia-NRC/Helsinki); ipsec <at> ietf.org
> Subject: RE: [IPsec] First charter draft
> 
> Hi Pasi, All, 
> Although I agree with pursuing these items, I would like the group to
> also consider extensions for IPsec traffic visibility. There are two
> drafts that are proposing some of these extensions and I am 
> working with
> some colleagues on submitting an update to one of these shortly. These
> are:
> 
> http://www.ietf.org/internet-drafts/draft-hoffman-esp-null-pro
tocol-00.t
> xt.
> 
> and
> 
> http://www.ietf.org/internet-drafts/draft-grewal-ipsec-traffic
-visibilit
> y-00.txt
> 
> In your draft charter, there are two items related to IPsec VPNs.
> Although VPN is the predominant use of IPsec today for remote access /
> site-to-site, I believe one of the reasons that IPsec 
> end-to-end is not
> widely employed today is due to the lack of traffic visibility in
> managed environments such as Enterprises. AH is not practical and ESP
> does not offer enough flexibility. 
> 
> I would like the group to consider a small modification to the charter
> and include text on using IPsec in real world, end-to-end solutions
> where practical considerations such as network management tools /
> intrusion detection / malware scanning tools are unable to 
> operate when
> the data is encrypted. Having IPsec extensions to accommodate these
> tools will greatly increase the viability of using IPsec 
> beyond just VPN
> and remote access.
> 
> I will be happy to present some of these findings / ideas at the next
> IETF.
> 
> Thanks for your consideration... 
> 
> Thanks, 
> - Ken
>  
> 
> -----Original Message-----
> From: ipsec-bounces <at> ietf.org [mailto:ipsec-bounces <at> ietf.org] On Behalf
> Of Pasi.Eronen <at> nokia.com
> Sent: Sunday, June 01, 2008 11:13 AM
> To: ipsec <at> ietf.org
> Subject: [IPsec] First charter draft
> 
> Thanks to everyone who replied to the poll!
> 
> Based on the responses, I've put together a first draft 
> of charter text, which has IMHO quite reasonable balance 
> between maintenance (ikev2bis, roadmap, ipv6) and the 
> extensions with widest interest (session resumption and redirect).
> 
> I also tried to come up with some text describing the 
> work items, to make it clear what's in scope and what is not.
> (Comments on that text are welcome!)
> 
> This list doesn't include draft-black-ipsec-ikev2-aead-modes,
> since it's basically read to be published now, and might be out
> before the WG gets created.
> 
> Please send comments (either privately or on the list) 
> as soon as possible -- to have the first WG meeting in Dublin,
> we need to converge on charter text soon (since there are
> several process steps it needs to go through before the WG
> is officially approved).
> 
> Best regards,
> Pasi
> 
> ==========
> 
> IP Security Maintenance and Extensions (ipsecme)
> DRAFT 2008-06-01
> 
> Chair(s): TBD
> 
> Security Area Director(s): TBD
> 
> Mailing Lists:
> 
> General Discussion: ipsec <at> ietf.org
> To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec
> Archive: http://www.ietf.org/mail-archive/web/ipsec/
> 
> Description of Working Group:
> 
> The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated
> RFCs), IKEv2 (RFC 4106, RFC 4718, and associated RFCs), and the IPsec
> security architecture (RFC 4301). IPsec is widely deployed in VPN
> gateways, VPN remote access clients, and as a substrate for
> host-to-host, host-to-network, and network-to-network security.
> 
> The IPsec Maintenance and Extensions Working Group will continue the
> work of the earlier IPsec Working Group which was concluded in
> 2005. Its purpose is to maintain the IPsec standard and to facilitate
> discussion of clarifications, improvements, and extensions and
> improvements to IPsec, mostly to IKEv2. The working group will also 
> be a focus point for other IETF Working Groups who use IPsec in their 
> own protocols.
> 
> The initial set of work items is:
> 
> o  A revision to IKEv2 (RFC 4306) that incorporates the
>    clarifications from RFC 4718, and otherwise improves the quality
>    of the specification, taking into account implementation and
>    interoperability experience.  In some cases, the revision may
>    include small technical corrections; however, impact on existing
>    implementations must be considered. Major changes and adding new
>    features is beyond the scope of this work item. The starting
>    point for this work is draft-hoffman-ikev2bis. 
> 
> o  An IPsec document roadmap that describes the various RFC 
>    documents covering IPsec, including both the core RFC 240x 
>    and RFC 430x versions of IPsec, and extensions specified in 
>    other documents. Sections 2 and 3 of RFC 2411 can provide  
>    useful material, but the expected scope is slightly different 
>    from RFC 2411. This document will be informational.
> 
> o  A standards-track extension to IKEv2 that provides full IPv6
>    support for IPsec remote access clients that use configuration
>    payloads. This work will be based on
>    draft-eronen-ipsec-ikev2-ipv6-config.
> 
> o  A standards-track extension that allows an IPsec remote access
>    client to "resume" a session with a gateway; that is, to skip 
>    certain parts of IKE negotation when connecting again to the 
>    same gateway (or possibly a cluster of closely cooperating 
> gateways).
> 
>    The idea is similar to TLS session resumption without
>    server-side state, specified in RFC 5077.
> 
>    The main goals for this extension are to avoid public-key
>    computations (to reduce VPN gateway load when a large number of
>    clients reconnect to the geteway within a short period of time,
>    such as following a network outage), and remove the need for
>    user interaction for authentication (which may be required by
>    some authentication mechanisms). The extension shall not have 
>    negative impact on IKEv2 security features.
> 
>    Failover from one gateway to another, mechanisms for detecting
>    when a session should be resumed, and specifying communication
>    mechanisms between gateways are beyond the scope of this work
>    item.  Specifying the detailed contents of the "session ticket"
>    is also beyond the scope of this document; if there is sufficient 
>    interest, this could be specified later in a separate document.
> 
>    To the degree its content falls within the scope of this work
>    item, text and ideas from draft-sheffer-ipsec-failover will be
>    used as a starting point.
> 
> o  A standards-track extension to IPsec that allows an IPsec remote
>    access gateway to redirect VPN clients to another gateway. This
>    extension should be aligned with the session resumption extension,
>    (the previous work item), and if so decided by the WG, could be
>    specified in the same document. The starting point will be
>    draft-devarapalli-ipsec-ikev2-redirect.
> 
> The initial scope of the WG is restricted to the work items listed
> above. The WG shall not consider adding new work items until one or
> more of its documents progress to IESG evaluation. At that time, the
> WG can propose rechartering.
> 
> Chartering this WG is not intended to have effect on documents that
> beyond the initial scope. In particular, work on IPsec extensions that
> are not included in this charter can happen as usual in other WGs (and
> there are currently several other WGs working on IPsec extensions; for
> example, BTNS and ROHC), or as individual submissions.
> 
> This charter will expire in June 2010 (24 months from approval).  If
> the charter is not updated before that time, the WG will be closed and
> any remaining documents revert back to individual Internet-Drafts.
> 
> Goals and Milestones:
> 
> Dec 2008  WG last call on IPv6 configuration payloads
> Dec 2008  WG last call on IPsec roadmap
> Mar 2009  WG last call on IKEv2bis
> Jan 2009  WG last call on session resumption
> Feb 2009  WG last call on redirect
> 
> ================
> 
> _______________________________________________
> IPsec mailing list
> IPsec <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
> 
_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: First charter draft

_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: First charter draft

Pasi.Eronen <at> nokia.com writes:
> If we decide to take more than five items, "GRE key traffic selector"
> and "ESP NULL traffic visibility" would be the ones with most support.

I think both of these need more discussion before they should be
accepted as charter items, and I am not sure we should be doing that
now, as it might delay the creation of the WG. I think we can start
discussing whether those should be added as working item after we get
at least one of the original items out from the WG.

The GRE key traffic selector itself is not that hard thing, but there
is all kind of other things related to it. When we added the protocol
selectors on the IPsec architecture we didn't really realize that
there is problems with fragments, and I think the gre key field has
same problem, thus it might require stateful fragment checking and
so on. Also I am not sure why different gre key values needs to be put
on the separate SA. I have not really seen good reason why this is
needed.

For the ESP NULL traffic visibility there is the problem that
firewalls cannot really trust the bit saying "I am nice, I am
authenticated only packet, there is no need to block me", meaning the
firewalls needs to inspect the packet inside the ESP packet anyways,
so I am not sure if that is right way to do that thing either. 
--

-- 
kivinen <at> safenet-inc.com

Re: ipsec rekey issue

On Thu, Jun 05, 2008 at 02:52:27PM +0800, mix wrote:
> Hi all,

Hi.

> I have a rekey problem reference from
> http://www.kame.net/racoon/racoon-ml/msg00874.html
> I use 2.6.21.7 kernel with ipsec-tools 0.6.5 as the server, and Windows
> XP as the client.
> 
> Setup a road warrior mode
> 
> Windows XP <---------------> VPN server <-----------> Internet
> VPN Tunnel
> 
> The problem is when the tunnel is built, Windows XP try to download a
> big file about 200MB.
> When download progress reached about 120~130MB, Windows XP can not
> access internet anymore.
> After about 5 minutes, the tunnel seems work, Windows can access
> internet again.
> Any advice will be appreciated

If your problem occurs when you try to download a big file, you should
better have a look at your client's MTU / TCPMSS.

If your problems occurs every 80% of IPSec-SA's lifetime, you're
probably experiencing a problem similar to the one explained in the
link you provided, which have been fixed in most recents kernels (I
don't know exactly in which version).

You may also consider posting to ipsec-tools-users mailing list, which
is probably more appropriate for such request.

Yvan.

--

-- 
NETASQ
http://www.netasq.com

_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec