[Swan-dev] aggressive mode

[Paul Wouters]

On Sun, 21 Dec 2014, D. Hugh Redelmeier wrote:

> The ipsec.conf(5) manpage says "aggrmode" means "Use Aggressive Mode instead
> of Main Mode".
>
> This does not seem nuanced enough.
>
> There seem to be three reasonably policies:
> 1) forbid aggressive mode
> 2) accept aggressive mode but don't propose it
> 3) accept and propose aggressive mode
> We should support all of these.

I prefer not to support 2) as such asymmetry leads to failures when
initiator/responder role switch on rekey.

> What is the current state?  I guess (2) without "aggremode" in the
> conn and (3) if it is there.  I want (1) as the default because
> aggressive mode is problematic from a security standpoint.

1) is the default (aggrmode=no) and 3) is aggrmode=yes. 2) is not
supported.

> I assume that if we accept IKEv1, we will accept Main Mode.

or aggressive mode, depending on aggrmode= setting.

>  It is
> quite unfortunate the the policy about IKEv1 is represented negatively
> (POLICY_IKEV1_DISABLE).  This does not work with the selection logic
> for policies.  A conn is considered to have suitable policy if it has
> all the required policy bits on (there is way of requiring absence).  So
> POLICY_IKEV1_DISABLE must be replaced by its complement.

Note that from a code point of view it does make sense, as IKEv2,
IKEv1-main and IKEv1-agg are different "Exchange Types".

> Why does this come up?  The test netkey-audit-01 is failing
> for me.

Odd.

> When I look at the log, I see something that seems awfully
> odd:
>
> - east receives an initial aggressive mode packet
>
> - it decides to use a connection called "ikev2".
>
> That sounds misguided.  Why would "ikev2" allow for aggressive mode?

It has ikev2=yes, so IKEv1 is allowed. It indeed should have ikev2=insist.

> I haven't looked at that conn -- it might actually allow v1 aggressive
> mode, but nonetheless there is a problem in the code.

It does not allow aggressive mode, because aggrmode=yes is not set.

> aggr_inI1_outR1_common looks for a suitable connection and does not
> express any policy constraints.

Didn't the state machine match on Exchange Type 4 ?
https://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml#ipsec-registry-17

>  Yet there certainly are constraints:
> (1) ikev1 must be allowed by the connection,
> (2) aggressive mode must be allowed by the connection

both codified with matching Exchange Type 4.

> (3) the authentication mode (which we already know from the initial
>    packet) must be allowed.

Actually, we also get an ID we can match in the first packet, see

http://tools.ietf.org/html/rfc2408#section-4.7

> (Oh, and there is another mystery with this test run.  The
>        pexpect(c == st->st_connection); /* ??? how would this have changed? */
> fires, and I cannot see how.  I'll figure that one out when my test
> machine becomes available.)

That might be because of hostpair? The test users 3 connections to the
same hostpair, but specifying different IDs. Note that specifying
different IDs was probably done to work around other issues with the
find host connection code.

Paul