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

[michalle OY]

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: 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
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20101124/b6155cd3/attachment.html>