[strongSwan] The reply of CREATE_CHILD_SA exchange with Notify Payload of type NO_ADDITIONAL_SAS
michalle_oy at hotmail.com
Wed Nov 24 06:50:48 CET 2010
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. [...]
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users