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. ThanksMichalle > Subject: Re: [strongSwan] The reply of CREATE_CHILD_SA exchange with Notify > Payload of type NO_ADDITIONAL_SAS > From: [email protected] > To: [email protected] > CC: [email protected] > 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 >
_______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
