[strongSwan] Configuration Payload for IP Address Assignment Error Cases

[Pisano, Stephen G (Stephen)]

Thanks Martin.  Some follow-ups below...

>By default, strongSwan keeps the IKE_SA up, unless the strongswan.conf
>option charon.close_ike_on_child_failure is set to yes.

Well, whether close_ike_on_child_failure = yes or = no, does strongSwan keep trying to start the connection?  Or is some manual intervention required?  We have auto=start, dpdaction=restart, keyingtries=%forever, rekey=yes, if that matters...


>I've pushed a patch [1] that improves the situation by just ignoring the
>virtual IP, changing the behavior to the description below.

We use install_virtual_ip = no and the up/down script/PLUTO_MY_SOURCEIP to learn of the assigned IP address.  So I assume before your patch, the up/down script would be called with PLUTO_MY_SOURCEIP set to 0.0.0.0, and I wonder what else would happen?  Would there be an IPSEC SA created?

With install_virtual_ip = no and your patch, I assume no IPSEC SA is created and no up/down script is called?  Is it true?


>> 3. the SeGW does not generates a configuration payload reply nor a
>> failure notification (e.g., it does not provide any support for
>> configuration payload)
>
>It depends on how the responder narrows the Traffic Selector for the
>client. If it gets narrowed to the physical IP (or something that
>contains it), the CHILD_SA will get established using this IP for the
>local IPsec policy.

Sorry, I don't follow what you mean by "the physical IP (or something that
contains it)".  I don't understand what IP could be used or assumed, if the SeGW can not fulfill the client's request for an IP address assignment.




>-----Original Message-----
>From: Martin Willi [mailto:martin at strongswan.org]
>Sent: Tuesday, June 26, 2012 12:04 PM
>To: Pisano, Stephen G (Stephen)
>Cc: users at lists.strongswan.org
>Subject: Re: [strongSwan] Configuration Payload for IP Address Assignment
>Error Cases
>
>Hi Stephen,
>
>> 2. the SeGW replies with an INTERNAL_ADDRESS_FAILURE notification
>
>This is how a responder should behave if it doesn't hand out internal
>addresses. As a client, strongSwan does not create an associated
>CHILD_SA, because the gateway usually does not include the SA/TS
>payloads with this error.
>
>By default, strongSwan keeps the IKE_SA up, unless the strongswan.conf
>option charon.close_ike_on_child_failure is set to yes.
>
>> 1. the SeGW replies with an configuration payload reply containing and
>> "empty" address (length = 0)
>
>strongSwan interprets this as a 0.0.0.0 address, but still tries to
>install it. This seems to be rather problematic with our netlink kernel
>interface. The kernel seems to ACK the installation, but does never
>confirm it by sending a notification. As we have to wait for this
>confirmation to go on with the CHILD_SA installation, the thread hangs.
>
>I've pushed a patch [1] that improves the situation by just ignoring the
>virtual IP, changing the behavior to the description below.
>
>> 3. the SeGW does not generates a configuration payload reply nor a
>> failure notification (e.g., it does not provide any support for
>> configuration payload)
>
>It depends on how the responder narrows the Traffic Selector for the
>client. If it gets narrowed to the physical IP (or something that
>contains it), the CHILD_SA will get established using this IP for the
>local IPsec policy.
>
>Regards
>Martin
>
>[1]http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=5def45b8