[Openswan Users] ike and esp proposals

[Paul Wouters]

On Wed, 4 Jan 2006, Matthias Haas wrote:

> I am currently testing around with the current snapshot. I also wanted to
> test he proposals that can now be defined for phase 1 and 2. Is it correct,
> that you can define the propsal only if you are the initiator of an
> connection?

No. Both ends can force a proposal by setting an ike= and/or esp= line. Once you
set such an option, it is interpreted as 'strict', eg all other proposals are
rejected. This is independant on whether you are initiating or responding.

Additionally, using aggressive mode, the first packet of the initiator must
always contain the valid proposal, since aggressive mode does not allow for
further negotiation. Therefor, openswan-2 forces you to set ike= for an
aggressive mode connection.

> As soon as your are recepient of a connection requests your propsal settings
> do not have any influence on the connection.

No, setting an ike= line on the responder forces the initiator to agree to that
proposal or the conenction will fail.

> great to get connection not established if you define the propsal i.e. to use
> aes but the other side is only capable of 3des. This could be related to
> security concerns about 3des.

There are security concerns with 3des?

The use of strict mode will make migration in case of an algorithm breakage easier.
Imagine 3des is compromised. You only need to add ike=aes and esp=aes on the VPN
gateway to enforce all clients to switch to aes. Those who don't support aes, will
not be able to connect. From a security point of view this is the correct behaviour.
If management insists of allowing 3des, then you can allow both proposals, but give
aes some preference, eg: ike=aes,3des. Though in that case, the initiator which
supports both could still decide on 3des in such a case (though that's arguably a
bug in the initiator, not the responder).

Paul