[strongSwan] The reply of CREATE_CHILD_SA exchange with Notify Payload of type NO_ADDITIONAL_SAS

[Andreas Steffen]

Hello Michalle,

you are using strongSwan 4.2.4 which is rather old. As far as I
remember we fixed the NO_ADDITIONAL_SAS behaviour in later versions.
Could you please try 4.5.0?

Kind regards

Andreas

On 24.11.2010 06:50, michalle OY wrote:
> hi, Martin
> Thanks for your help. The reply Packet with NO_ADDITIONAL_SAS
> notification has been passed the verification by Strongswan. 
> But why Strongswan still retransmit the CREATE_CHILD_SA request.  Does
> that conflict with  RFC?
> in FRC 5996 chapter4:
> 
> When an SA expires (based on locally configured values of either lifetime or
>    octets passed), and implementation MAY either try to renew it with a
>    CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and
>    create a new one.  If the responder rejects the CREATE_CHILD_SA
>    request with a NO_ADDITIONAL_SAS notification, the implementation
>    MUST be capable of instead deleting the old SA and creating a new
>    one.
> 
>  
> 
> Thanks
> 
> Michalle
> 
>> Subject: Re: [strongSwan] The reply of CREATE_CHILD_SA exchange with
> Notify Payload of type NO_ADDITIONAL_SAS
>> From: martin at strongswan.org
>> To: michalle_oy at hotmail.com
>> CC: users at lists.strongswan.org
>> Date: Tue, 23 Nov 2010 08:24:50 +0100
>>
>> Hi,
>>
>> The next-payload field in your encryption payload is 46 (encrypted):
>>
>> > parsing ENCRYPTED payload, 48 bytes left
>> > parsing payload from => 48 bytes @ 0xb8d826ec
>> > 0: 2E 00 00 30 4B E5 2C 09 72 61 D6 DE 87 AC ED EC ...0K.,.ra......
>> > 16: B5 85 67 85 00 A3 53 78 8E 47 89 CD EB 13 CA B5 ..g...Sx.G......
>> > 32: C0 87 F0 1D A1 C3 7E 2C 55 88 1E 4B B3 F0 89 E2 ......~,U..K....
>> > parsing rule 0 U_INT_8
>> > => 46
>>
>> But it should have the type of the first payload encrypted, 41 (notify)
>> in your case. RFC 5996 3.14:
>>
>> > Next Payload - The payload type of the first embedded payload.
>> > Note that this is an exception in the standard header format,
>> > since the Encrypted payload is the last payload in the message and
>> > therefore the Next Payload field would normally be zero. [...]
>>
>> Regards
>> Martin

======================================================================
Andreas Steffen                         andreas.steffen at 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]==