[Swan-dev] aggressive mode

[D. Hugh Redelmeier]

| From: Paul Wouters <paul at nohats.ca>
| To: D. Hugh Redelmeier <hugh at mimosa.com>
| Cc: Libreswan Development List <swan-dev at lists.libreswan.org>
| Date: Sun, 21 Dec 2014 16:40:41 -0500 (EST)
| Subject: Re: [Swan-dev] aggressive mode
| 
| 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.

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?

| 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.

| > 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?

| > 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)

| > 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".

I don't understand in what way this makes sense.

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

Yeah.  It is sometimes hard to understand why tests fail.  In this
case, the failure has prompted me to find some problems.  But they may
not in fact be why the test failed.

| > 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 don't want to fix this yet: not until I work on the problems that
this has uncovered.

| > 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.

Good to know.

| > 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

The state machine is right.  After all, we're in
aggr_inI1_outR1_common because of the exchange type.

| > 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".

| > (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

Right.  That isn't what I was meaning by "policy".  Of course the word
is pretty debased by now so you'd have had to read my mind to know
that.

| > (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?

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.

And it seems to do so (using refine_host_connection) without benefit
of the policy constraints that find_host_connection has.  I hope that
isn't true -- I'll look more carefully.