[strongSwan] The reply of CREATE_CHILD_SA exchange with Notify Payload of type NO_ADDITIONAL_SAS
andreas.steffen at strongswan.org
Wed Nov 24 08:23:25 CET 2010
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?
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
>> 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
>> 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. [...]
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)
More information about the Users