<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
hi, Martin<BR>
Thanks for your help. The reply Packet with NO_ADDITIONAL_SAS notification has been passed the verification by Strongswan. <BR>
But why Strongswan still retransmit the CREATE_CHILD_SA request. Does that conflict with RFC? <BR>
in FRC 5996 chapter4:<BR><SPAN class=Apple-style-span style="WORD-SPACING: 0px; FONT: medium 'Times New Roman'; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate; webkit-text-size-adjust: auto; orphans: 2; widows: 2; webkit-border-horizontal-spacing: 0px; webkit-border-vertical-spacing: 0px; webkit-text-decorations-in-effect: none; webkit-text-stroke-width: 0px"><SPAN class=Apple-style-span style="FONT-SIZE: 16px"><PRE class=newpage style="MARGIN-TOP: 0px; FONT-SIZE: 1em; MARGIN-BOTTOM: 0px; PAGE-BREAK-BEFORE: always">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.</PRE><PRE class=newpage style="MARGIN-TOP: 0px; FONT-SIZE: 1em; MARGIN-BOTTOM: 0px; PAGE-BREAK-BEFORE: always"> </PRE><PRE class=newpage style="MARGIN-TOP: 0px; FONT-SIZE: 1em; MARGIN-BOTTOM: 0px; PAGE-BREAK-BEFORE: always"><FONT face=Arial>Thanks</FONT></PRE><PRE class=newpage style="MARGIN-TOP: 0px; FONT-SIZE: 1em; MARGIN-BOTTOM: 0px; PAGE-BREAK-BEFORE: always"><FONT face=Arial>Michalle</FONT></PRE></SPAN></SPAN>
> Subject: Re: [strongSwan] The reply of CREATE_CHILD_SA exchange with Notify Payload of type NO_ADDITIONAL_SAS<BR>> From: martin@strongswan.org<BR>> To: michalle_oy@hotmail.com<BR>> CC: users@lists.strongswan.org<BR>> Date: Tue, 23 Nov 2010 08:24:50 +0100<BR>> <BR>> Hi,<BR>> <BR>> The next-payload field in your encryption payload is 46 (encrypted):<BR>> <BR>> > parsing ENCRYPTED payload, 48 bytes left <BR>> > parsing payload from => 48 bytes @ 0xb8d826ec <BR>> > 0: 2E 00 00 30 4B E5 2C 09 72 61 D6 DE 87 AC ED EC ...0K.,.ra...... <BR>> > 16: B5 85 67 85 00 A3 53 78 8E 47 89 CD EB 13 CA B5 ..g...Sx.G...... <BR>> > 32: C0 87 F0 1D A1 C3 7E 2C 55 88 1E 4B B3 F0 89 E2 ......~,U..K.... <BR>> > parsing rule 0 U_INT_8 <BR>> > => 46 <BR>> <BR>> But it should have the type of the first payload encrypted, 41 (notify)<BR>> in your case. RFC 5996 3.14:<BR>> <BR>> > Next Payload - The payload type of the first embedded payload.<BR>> > Note that this is an exception in the standard header format,<BR>> > since the Encrypted payload is the last payload in the message and<BR>> > therefore the Next Payload field would normally be zero. [...]<BR>> <BR>> Regards<BR>> Martin<BR>> <BR> </body>
</html>