[Swan-dev] aggressive mode

[Paul Wouters]

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

> | I prefer not to support 2) as such asymmetry leads to failures when
> | initiator/responder role switch on rekey.
>
> Makes sense.  But why are we supporting Aggressive Mode?  I think that
> it reflects a stupidity on the other side.  Is a stupid other side
> likely to be symmetrically stupid?

Interoperability, mostly with Cisco configurations.

> | 1) is the default (aggrmode=no) and 3) is aggrmode=yes. 2) is not
> | supported.
>
> OK.  I think that the documentation should be clearer on this matter.

>From ipsec.conf:

        aggrmode
            Use Aggressive Mode instead of Main Mode. Aggressive Mode is less
            secure, and vulnerable to Denial Of Service attacks. It is also
            vulnerable to brute force attacks with software such as ikecrack.
            It should not be used, and it should especially not be used with
            XAUTH and group secrets (PSK). If the remote system administrator
            insists on staying irresponsible, enable this option.

That's pretty harsh on the not using it part. I just added a note to
clarify this applies to IKEv1 only.

> | > I assume that if we accept IKEv1, we will accept Main Mode.
> |
> | or aggressive mode, depending on aggrmode= setting.
>
> Sorry, I wasn't clear.  I assume that if we accept IKEv1, we will
> always accept Main Mode.  This contrasts with Aggressive Mode which is
> only accepted if it has been explicitly enabled.  Is this correct?

No. we either accept either main or aggressive mode, but no either or
both.

> | > 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
>
> Typo: it should have read (there is NO way of requiring absence)

So should we fix that logic?

> | > POLICY_IKEV1_DISABLE must be replaced by its complement.

So POLICY_NOT_IKEV1 ?

> | It has ikev2=yes, so IKEv1 is allowed. It indeed should have ikev2=insist.
>
> I don't want to fix this yet: not until I work on the problems that
> this has uncovered.

Makes sense.

> | Didn't the state machine match on Exchange Type 4 ?
> | https://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml#ipsec-registry-17
>
> The state machine is right.  After all, we're in
> aggr_inI1_outR1_common because of the exchange type.

Yes, that was _my_ point :)

> | > 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.
>
> I wasn't clear.  The policy constraint I'm talking about is for the
> search for a suitable connection.  The policy constraint is the last
> argument to find_host_connection and the current code for
> aggr_inI1_outR1_common uses the unreasonable value LEMPTY meaning "no
> constraint".

Ahh.

> It turns out that ikev1_decode_peer_id does more than its name
> suggests.  It also changes st->st_connection, at least sometimes.
> Bad function name.

That is scary :/

We know the connection switching code has issues. I'm also looking into
a bug for this case:

conn port443
 	also=base
 	esp=aes256-sha1
 	leftprotoport=tcp/443
 	rightprotoport=tcp

conn port80
 	also=base
 	esp=aes128-sha1
 	leftprotoport=tcp/80
 	rightprotoport=tcp

Whether an incoming connection for port443 works now depends on loading
order. Note that this one seems to work regardless of loading order:


conn all
 	also=base
 	esp=aes256-sha1

conn port80
 	also=base
 	esp=aes128-sha1
 	leftprotoport=tcp/80
 	rightprotoport=tcp

Paul