| From: Paul Wouters <[email protected]> | To: D. Hugh Redelmeier <[email protected]> | Cc: Libreswan Development List <[email protected]> | 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. _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
