[strongSwan] Regarding Installation issue in strongswan

SaRaVanAn saravanan.nagarajan87 at gmail.com
Tue Nov 20 07:12:21 CET 2012


Hi Andreas,
    Thanks a lot for your detailed explanation.

Regards,
Saravanan N

On Tue, Nov 20, 2012 at 1:25 AM, Andreas Steffen <
andreas.steffen at strongswan.org> wrote:

> 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<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]==
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20121120/00143e79/attachment.html>


More information about the Users mailing list