[strongSwan] Regarding Installation issue in strongswan

[Andreas Steffen]

Hi Saravan,

RFC 4306 cannot be read as a stand-alone document but the
clarifications offered by

RFC 4718 IKEv2 Clarifications and Implementation Guidelines

must be considered as well. Actually the original goal of
RFC 5996 was to combine RFC 4306 and RFC 4718 into a single
document.

Section 4.3 Diffie-Hellman for First CHILD_SA clearly states:

    http://tools.ietf.org/html/rfc4718#section-4.3

    Section 1.2 [of RFC 4306] shows that IKE_AUTH messages do not
    contain KEi/KEr or Ni/Nr payloads.  This implies that the SA payload
    in IKE_AUTH exchange cannot contain Transform Type 4 (Diffie-Hellman
    Group) with any other value than NONE.  Implementations should
    probably leave the transform out entirely in this case.

    Thus if you include a DH-Transform in the IKE_AUTH request it must
    have the value NONE.

Best regards

Andreas

On 11/19/2012 06:26 PM, SaRaVanAn wrote:
> Hi Martin,
> Thanks for you reply.
> I just want to clarify the doubts on PFS group proposal in IKEv2.
>
> I guess, as per RFC 4306 , PFS group proposal will happen in CREATE_SA
> exchange (IKE_AUTH messages). Because its mentioned like "
>   A CHILD_SA is created by sending a CREATE_CHILD_SA request"
>
> But in RFC 5996 , its mentioned like
> "  The CREATE_CHILD_SA exchange is used to create new Child SAs and to
>     rekey both IKE SAs and Child SAs"
>
> As per new RFC 5996, CREATE_CHILD_SA is only meant to create New Child
> SA's (after a tunnel is formed).
> So its not possible to inter operate a software,  which supports RFC4306
> with Strongswan.
>
> Please correct me , If I am wrong. I m not clear about this point in RFC.
> I need experts guidance.
>
> Regards,
> Saravanan N
>
>
>
> On Mon, Nov 19, 2012 at 12:41 AM, Martin Willi <martin at strongswan.org
> <mailto:martin at strongswan.org>> wrote:
>
>     Hi,
>
>      > 13[CFG] received proposals:
>     ESP:AES_CBC_256/HMAC_SHA1_96/MODP_1536/NO_EXT_SEQ
>      > 13[IKE] no acceptable proposal found
>      > 13[ENC] generating IKE_AUTH response 1 [ IDr AUTH N(NO_PROP) ]
>
>     Your client sends a DH group in the CHILD_SA proposals in IKE_AUTH. This
>     seems wrong, as a DH exchange is never done in IKE_AUTH. The proposal
>     would match in a CREATE_CHILD_SA (as you can do a DH exchange there),
>     but not in IKE_AUTH.
>
>     Regards
>     Martin

======================================================================
Andreas Steffen                         andreas.steffen at strongswan.org
strongSwan - the Linux VPN Solution!                www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==