Hi Andreas,<br> Thanks a lot for your detailed explanation.<br><br>Regards,<br>Saravanan N<br><br><div class="gmail_quote">On Tue, Nov 20, 2012 at 1:25 AM, Andreas Steffen <span dir="ltr"><<a href="mailto:andreas.steffen@strongswan.org" target="_blank">andreas.steffen@strongswan.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Saravan,<br>
<br>
RFC 4306 cannot be read as a stand-alone document but the<br>
clarifications offered by<br>
<br>
RFC 4718 IKEv2 Clarifications and Implementation Guidelines<br>
<br>
must be considered as well. Actually the original goal of<br>
RFC 5996 was to combine RFC 4306 and RFC 4718 into a single<br>
document.<br>
<br>
Section 4.3 Diffie-Hellman for First CHILD_SA clearly states:<br>
<br>
<a href="http://tools.ietf.org/html/rfc4718#section-4.3" target="_blank">http://tools.ietf.org/html/<u></u>rfc4718#section-4.3</a><br>
<br>
Section 1.2 [of RFC 4306] shows that IKE_AUTH messages do not<br>
contain KEi/KEr or Ni/Nr payloads. This implies that the SA payload<br>
in IKE_AUTH exchange cannot contain Transform Type 4 (Diffie-Hellman<br>
Group) with any other value than NONE. Implementations should<br>
probably leave the transform out entirely in this case.<br>
<br>
Thus if you include a DH-Transform in the IKE_AUTH request it must<br>
have the value NONE.<br>
<br>
Best regards<br>
<br>
Andreas<div class="im"><br>
<br>
On 11/19/2012 06:26 PM, SaRaVanAn wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
Hi Martin,<br>
Thanks for you reply.<br>
I just want to clarify the doubts on PFS group proposal in IKEv2.<br>
<br>
I guess, as per RFC 4306 , PFS group proposal will happen in CREATE_SA<br>
exchange (IKE_AUTH messages). Because its mentioned like "<br>
A CHILD_SA is created by sending a CREATE_CHILD_SA request"<br>
<br>
But in RFC 5996 , its mentioned like<br>
" The CREATE_CHILD_SA exchange is used to create new Child SAs and to<br>
rekey both IKE SAs and Child SAs"<br>
<br>
As per new RFC 5996, CREATE_CHILD_SA is only meant to create New Child<br>
SA's (after a tunnel is formed).<br>
So its not possible to inter operate a software, which supports RFC4306<br>
with Strongswan.<br>
<br>
Please correct me , If I am wrong. I m not clear about this point in RFC.<br>
I need experts guidance.<br>
<br>
Regards,<br>
Saravanan N<br>
<br>
<br>
<br>
On Mon, Nov 19, 2012 at 12:41 AM, Martin Willi <<a href="mailto:martin@strongswan.org" target="_blank">martin@strongswan.org</a><br></div><div class="im">
<mailto:<a href="mailto:martin@strongswan.org" target="_blank">martin@strongswan.org</a>><u></u>> wrote:<br>
<br>
Hi,<br>
<br>
> 13[CFG] received proposals:<br>
ESP:AES_CBC_256/HMAC_SHA1_96/<u></u>MODP_1536/NO_EXT_SEQ<br>
> 13[IKE] no acceptable proposal found<br>
> 13[ENC] generating IKE_AUTH response 1 [ IDr AUTH N(NO_PROP) ]<br>
<br>
Your client sends a DH group in the CHILD_SA proposals in IKE_AUTH. This<br>
seems wrong, as a DH exchange is never done in IKE_AUTH. The proposal<br>
would match in a CREATE_CHILD_SA (as you can do a DH exchange there),<br>
but not in IKE_AUTH.<br>
<br>
Regards<br>
Martin<br>
</div></blockquote>
<br>
==============================<u></u>==============================<u></u>==========<br>
Andreas Steffen <a href="mailto:andreas.steffen@strongswan.org" target="_blank">andreas.steffen@strongswan.org</a><br>
strongSwan - the Linux VPN Solution! <a href="http://www.strongswan.org" target="_blank">www.strongswan.org</a><br>
Institute for Internet Technologies and Applications<br>
University of Applied Sciences Rapperswil<br>
CH-8640 Rapperswil (Switzerland)<br>
==============================<u></u>=============================[<u></u>ITA-HSR]==<br>
</blockquote></div><br>