Re: [strongSwan] FW: strongSwan installs SPs?

2009-07-27 Thread Stephen Pisano 
Hi Andreas, 

That is just the kind of solution I had in mind.

Are you aware of any other SPD dependencies?

I think I found one, which I wanted to get your view on.

The area of functionality is SA establishment via a kernel ACQUIRE.

In ike_sa.c:acquire(), there is the following snippet:

/* find CHILD_SA */
iterator = this-child_sas-create_iterator(this-child_sas, TRUE);
while (iterator-iterate(iterator, (void**)current))
{
if (current-get_reqid(current) == reqid)
{
child_sa = current;
break;
}
}
iterator-destroy(iterator);
if (!child_sa)
{
DBG1(DBG_IKE, acquiring CHILD_SA {reqid %d} failed: 
 CHILD_SA not found, reqid);
return FAILED;
}

I interpret this to mean that you can only initiate an SA establishment via
a kernel ACQUIRE if there is an existing SA (which was generated with a
policy in the SPD, having a certain reqid).

Is this a correct interpretation?  

Thanks,
Stephen



-Original Message-
From: Andreas Steffen [mailto:andreas.stef...@strongswan.org]
Sent: Wednesday, July 22, 2009 7:20 AM
To: Stephen Pisano
Cc: users@lists.strongswan.org
Subject: Re: [strongSwan] FW: strongSwan installs SPs?

Hi Stephen,

we could introduce e.g. a new charon.no_spd_available configuration
option in /etc/strongswan.conf that would redefine the
child_sa_t.get_usetime() method:

http://wiki.strongswan.org/repositories/entry/strongswan/src/charon/sa/chil
d_sa.c#L357

Instead of using the kernel_interface-query_policy() method
a new kernel_interface-query_sa() method that we wanted to
implement anyway in one of the next releases, would retrieve
the current number of packets/bytes and compare it with the
previously retrieved value cached in the child_sa_t object.
I think I even implemented such an approach in pluto's KLIPS
kernel interface many years ago.

Best regards

Andreas

Stephen Pisano wrote:
 Thanks Andreas, please see my comment below.


 -Original Message-
 From: Andreas Steffen [mailto:andreas.stef...@strongswan.org]
 Sent: Wednesday, July 22, 2009 2:12 AM
 To: Stephen Pisano
 Cc: users@lists.strongswan.org
 Subject: Re: [strongSwan] FW: strongSwan installs SPs?

 Hello Stephen,

 installpolicy=no just means the the IKEv2 charon daemon does not
 use the add_policy() and del_policy() methods of the kernel interface
 to actively manage the IPsec policies but delegates these tasks to
 another process on the same host. charon still uses the query_policy()
 method to get the use_time status information for liveliness checks.

 [pisano] Ah, yes, I understand what you're saying, but consider an
 application where the SPD is not used and the IKE daemon is to be used
for
 SA management alone.  With the current behavior, this places a dependency
 between the IKE daemon and the presence of a policy in the SPD.

 Concerning your question why we don't query the SA's use_time instead,
 you are not the only wondering about this. The problem with the Linux
 kernel's NETLINK IPsec implementation is that the SA's use_time stores
 the time of *first* use but unfortunately not the *latest* use whereas
 only the associated IPsec policy keeps track of the desired information.

 [pisano] Yes, I see the issue with using SA use_time.

 The attached status output of ip xfrm state and ip xfrm policy shows
 that both the SA and policy where added at 2009-07-22 06:45:45 and
 the SA was first used five minutes later at 2009-07-22 06:50:06.
 Shortly before generating this output I sent data over the IPsec
 tunnel, so the policies show 07:31:30 and 07:33:09 for the outbound and
 inbound direction, respectively. Strangely enough, if you want to gather
 information about the number of bytes / packets send over a tunnel you
 can retrieve this data from the SA's only.

 [pisano] Perhaps the use of the SA's byte or packets counts would be a
 better choice to indicate activity liveness?

 Best regards

 Andreas

 Stephen Pisano wrote:
 A follow-up to Mugur's question...

 It appears that the SA activity portion of the peer liveness
algorithm
 uses a GETPOLICY operation to retrieve the policy use_time.  So, I
figure
 with installpolicy=no, this would essentially disable the SA activity
 portion of the liveness check.  Is that correct?  If so, this makes me
 wonder why policy use_time is used rather than SA use_time?

 Thanks,
 Stephen

 -Original Message-
 From: Andreas Steffen [mailto:andreas.stef...@strongswan.org]
 Sent: lundi 20 juillet 2009 19:57
 To: ABULIUS MUGUR
 Cc: users@lists.strongswan.org
 Subject: Re: [strongSwan] strongSwan installs SPs?

 Hi Mugur,

 by default strongSwan installs IPsec security policies in the kernel.
 With auto=route the policies are installed at the very beginning, so
 that matching plaintext packets trigger an XFRM_ACQUIRE message.
 With auto=add or auto

Re: [strongSwan] FW: strongSwan installs SPs?

2009-07-27 Thread Andreas Steffen 
Hi Stephen,

strongSwan can assign a preliminary IPsec SA and a corresponding
reqid using auto=route without installing an SPD in the kernel
(installpolicy=no). This is used in our Mobile IPv6 scenario:

http://wiki.strongswan.org/wiki/strongswan/MobileNodeSetup

The current disadvantage is that the XFRM_ACQUIRE message which
will trigger the actual IKE negotiation must use the correct reqid.
This is not a problem if only one tunnel is managed but might be tricky
with multiple tunnel definitions pre-started with auto=route. As an
alternative we could create the SA definition on demand applying a
closest match on the traffic selectors that are received via the
XFRM_ACQUIRE message.

Best regards

Andreas

Stephen Pisano wrote:
 Hi Andreas, 
 
 That is just the kind of solution I had in mind.
 
 Are you aware of any other SPD dependencies?
 
 I think I found one, which I wanted to get your view on.
 
 The area of functionality is SA establishment via a kernel ACQUIRE.
 
 In ike_sa.c:acquire(), there is the following snippet:
 
 /* find CHILD_SA */
 iterator = this-child_sas-create_iterator(this-child_sas, TRUE);
 while (iterator-iterate(iterator, (void**)current))
 {
 if (current-get_reqid(current) == reqid)
 {
 child_sa = current;
 break;
 }
 }
 iterator-destroy(iterator);
 if (!child_sa)
 {
 DBG1(DBG_IKE, acquiring CHILD_SA {reqid %d} failed: 
  CHILD_SA not found, reqid);
 return FAILED;
 }
 
 I interpret this to mean that you can only initiate an SA establishment via
 a kernel ACQUIRE if there is an existing SA (which was generated with a
 policy in the SPD, having a certain reqid).
 
 Is this a correct interpretation?  
 
 Thanks,
 Stephen
 
 
 
 -Original Message-
 From: Andreas Steffen [mailto:andreas.stef...@strongswan.org]
 Sent: Wednesday, July 22, 2009 7:20 AM
 To: Stephen Pisano
 Cc: users@lists.strongswan.org
 Subject: Re: [strongSwan] FW: strongSwan installs SPs?

 Hi Stephen,

 we could introduce e.g. a new charon.no_spd_available configuration
 option in /etc/strongswan.conf that would redefine the
 child_sa_t.get_usetime() method:

 http://wiki.strongswan.org/repositories/entry/strongswan/src/charon/sa/chil
 d_sa.c#L357

 Instead of using the kernel_interface-query_policy() method
 a new kernel_interface-query_sa() method that we wanted to
 implement anyway in one of the next releases, would retrieve
 the current number of packets/bytes and compare it with the
 previously retrieved value cached in the child_sa_t object.
 I think I even implemented such an approach in pluto's KLIPS
 kernel interface many years ago.

 Best regards

 Andreas

 Stephen Pisano wrote:
 Thanks Andreas, please see my comment below.


 -Original Message-
 From: Andreas Steffen [mailto:andreas.stef...@strongswan.org]
 Sent: Wednesday, July 22, 2009 2:12 AM
 To: Stephen Pisano
 Cc: users@lists.strongswan.org
 Subject: Re: [strongSwan] FW: strongSwan installs SPs?

 Hello Stephen,

 installpolicy=no just means the the IKEv2 charon daemon does not
 use the add_policy() and del_policy() methods of the kernel interface
 to actively manage the IPsec policies but delegates these tasks to
 another process on the same host. charon still uses the query_policy()
 method to get the use_time status information for liveliness checks.
 [pisano] Ah, yes, I understand what you're saying, but consider an
 application where the SPD is not used and the IKE daemon is to be used
 for
 SA management alone.  With the current behavior, this places a dependency
 between the IKE daemon and the presence of a policy in the SPD.

 Concerning your question why we don't query the SA's use_time instead,
 you are not the only wondering about this. The problem with the Linux
 kernel's NETLINK IPsec implementation is that the SA's use_time stores
 the time of *first* use but unfortunately not the *latest* use whereas
 only the associated IPsec policy keeps track of the desired information.
 [pisano] Yes, I see the issue with using SA use_time.

 The attached status output of ip xfrm state and ip xfrm policy shows
 that both the SA and policy where added at 2009-07-22 06:45:45 and
 the SA was first used five minutes later at 2009-07-22 06:50:06.
 Shortly before generating this output I sent data over the IPsec
 tunnel, so the policies show 07:31:30 and 07:33:09 for the outbound and
 inbound direction, respectively. Strangely enough, if you want to gather
 information about the number of bytes / packets send over a tunnel you
 can retrieve this data from the SA's only.
 [pisano] Perhaps the use of the SA's byte or packets counts would be a
 better choice to indicate activity liveness?

 Best regards

 Andreas

 Stephen Pisano wrote:
 A follow-up to Mugur's question...

 It appears that the SA activity portion

Re: [strongSwan] FW: strongSwan installs SPs?

2009-07-22 Thread Andreas Steffen 
Hello Stephen,

installpolicy=no just means the the IKEv2 charon daemon does not
use the add_policy() and del_policy() methods of the kernel interface
to actively manage the IPsec policies but delegates these tasks to
another process on the same host. charon still uses the query_policy()
method to get the use_time status information for liveliness checks.

Concerning your question why we don't query the SA's use_time instead,
you are not the only wondering about this. The problem with the Linux
kernel's NETLINK IPsec implementation is that the SA's use_time stores
the time of *first* use but unfortunately not the *latest* use whereas
only the associated IPsec policy keeps track of the desired information.

The attached status output of ip xfrm state and ip xfrm policy shows
that both the SA and policy where added at 2009-07-22 06:45:45 and
the SA was first used five minutes later at 2009-07-22 06:50:06.
Shortly before generating this output I sent data over the IPsec
tunnel, so the policies show 07:31:30 and 07:33:09 for the outbound and
inbound direction, respectively. Strangely enough, if you want to gather
information about the number of bytes / packets send over a tunnel you
can retrieve this data from the SA's only.

Best regards

Andreas

Stephen Pisano wrote:
 A follow-up to Mugur's question...
 
 It appears that the SA activity portion of the peer liveness algorithm
 uses a GETPOLICY operation to retrieve the policy use_time.  So, I figure
 with installpolicy=no, this would essentially disable the SA activity
 portion of the liveness check.  Is that correct?  If so, this makes me
 wonder why policy use_time is used rather than SA use_time?
 
 Thanks,
 Stephen
 
 -Original Message-
 From: Andreas Steffen [mailto:andreas.stef...@strongswan.org] 
 Sent: lundi 20 juillet 2009 19:57
 To: ABULIUS MUGUR
 Cc: users@lists.strongswan.org
 Subject: Re: [strongSwan] strongSwan installs SPs?
 
 Hi Mugur,
 
 by default strongSwan installs IPsec security policies in the kernel.
 With auto=route the policies are installed at the very beginning, so
 that matching plaintext packets trigger an XFRM_ACQUIRE message.
 With auto=add or auto=start, the policies are installed only after both
 inbound and outbound IPsec SAs have been created.
 
 For the IKEv2 daemon there is an *installpolicy=no* option, though,
 which I originally created for Mobile IPv6 connections where the mip6d
 daemon installs the IPsec policies and then alerts the IKEv2 daemon via
 an XFRM_MSG_MIGRATE message. See my Mobile IPv6 HOWTO:
 
   http://wiki.strongswan.org/wiki/strongswan/MobileIPv6
 
 So if you have another process which manages the policies you can just
 set installpolicy=no for that connection in ipsec.conf.
 
 Best regards
 
 Andreas
 
 ABULIUS MUGUR wrote:
 StrongSwan doc says that 'auto=route' installs kernel traps. Can 
 somebody confirm that strongSwan installs a SP (Security Policy) for 
 this connection? There are any other circumstances for which 
 strongSwan handles (get/set) SP in kernel's SPD? We want to avoid any 
 kernel's SPD set/get for our specific IPsec implementation.

 Thanks
 Mugur

==
Andreas Steffen andreas.stef...@strongswan.org
strongSwan - the Linux VPN Solution!www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===[ITA-HSR]==
[r...@strongswan stats]# ip -s xfrm state

src 84.74.95.23 dst 152.96.52.150
proto esp spi 0xc7f7a5ed(3354895853) reqid 7(0x0007) mode tunnel
lifetime current:
  36575(bytes), 418(packets)
  add 2009-07-22 06:45:45 use 2009-07-22 06:50:06

src 152.96.52.150 dst 84.74.95.23
proto esp spi 0xc31c720e(3273421326) reqid 7(0x0007) mode tunnel
lifetime current:
  229360(bytes), 368(packets)
  add 2009-07-22 06:45:45 use 2009-07-22 06:50:06

[r...@strongswan stats]# ip -s xfrm policy

src 10.10.0.0/23 dst 152.96.52.150/32 uid 0
dir in action allow index 1256 priority 1770 share any flag 0x
lifetime current:
  0(bytes), 0(packets)
  add 2009-07-22 06:45:45 use 2009-07-22 07:33:09
tmplsrc 84.74.95.23 dst 152.96.52.150
proto esp spi 0x(0) reqid 7(0x0007) mode tunnel

src 152.96.52.150/32 dst 10.10.0.0/23 uid 0
dir out action allow index 1249 priority 1680 share any flag 0x
lifetime current:
  0(bytes), 0(packets)
  add 2009-07-22 06:45:45 use 2009-07-22 07:31:30
tmplsrc 152.96.52.150 dst 84.74.95.23
proto esp spi 0x(0) reqid 7(0x0007) mode tunnel

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] FW: strongSwan installs SPs?

2009-07-21 Thread Stephen Pisano 

A follow-up to Mugur's question...

It appears that the SA activity portion of the peer liveness algorithm
uses a GETPOLICY operation to retrieve the policy use_time.  So, I figure
with installpolicy=no, this would essentially disable the SA activity
portion of the liveness check.  Is that correct?  If so, this makes me
wonder why policy use_time is used rather than SA use_time?

Thanks,
Stephen




-Original Message-
From: Andreas Steffen [mailto:andreas.stef...@strongswan.org] 
Sent: lundi 20 juillet 2009 19:57
To: ABULIUS MUGUR
Cc: users@lists.strongswan.org
Subject: Re: [strongSwan] strongSwan installs SPs?

Hi Mugur,

by default strongSwan installs IPsec security policies in the kernel.
With auto=route the policies are installed at the very beginning, so
that matching plaintext packets trigger an XFRM_ACQUIRE message.
With auto=add or auto=start, the policies are installed only after both
inbound and outbound IPsec SAs have been created.

For the IKEv2 daemon there is an *installpolicy=no* option, though,
which I originally created for Mobile IPv6 connections where the mip6d
daemon installs the IPsec policies and then alerts the IKEv2 daemon via
an XFRM_MSG_MIGRATE message. See my Mobile IPv6 HOWTO:

  http://wiki.strongswan.org/wiki/strongswan/MobileIPv6

So if you have another process which manages the policies you can just
set installpolicy=no for that connection in ipsec.conf.

Best regards

Andreas

ABULIUS MUGUR wrote:
 StrongSwan doc says that 'auto=route' installs kernel traps. Can 
 somebody confirm that strongSwan installs a SP (Security Policy) for 
 this connection? There are any other circumstances for which 
 strongSwan handles (get/set) SP in kernel's SPD? We want to avoid any 
 kernel's SPD set/get for our specific IPsec implementation.
 
 Thanks
 Mugur

==
Andreas Steffen andreas.stef...@strongswan.org
strongSwan - the Linux VPN Solution!www.strongswan.org
Institute for Internet Technologies and Applications University of
Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland)
===[ITA-HSR]==

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users