[Openswan dev] [Patch] Multiple proposals in Aggressive mode...
Michael H. Warfield
mhw at WittsEnd.com
Fri Mar 12 00:02:37 EST 2010
Sorry for the duplicate post but I realized my patch may easily get lost
in the forest of replies I was replying to. So, I'm forwarding the
whole thing back in to make it stand out.
Mike
-------- Forwarded Message --------
From: Michael H. Warfield <mhw at wittsend.com>
Reply-to: mhw at wittsend.com
To: Michael Richardson <mcr at sandelman.ca>
Cc: dev at openswan.org, mhw at wittsend.com
Subject: Re: [Openswan dev] [Openswan Users] Trying to get Openswan
working Ubuntu to Cisco ASA 5510
Date: Thu, 11 Mar 2010 23:42:49 -0500
Michael, and Paul, et al...
Ok... So... Paul forwarded your message to the dev list so I'm cc'ing
the dev list on my reply to your original message...
On Thu, 2010-03-11 at 13:43 -0500, Michael Richardson wrote:
> The pick first proposal logic is at:
> spdb_v1_struct.c, in the function:
> bool
> init_am_st_oakley(struct state *st, lset_t policy)
>
> which is called in ikev1_aggr.c, in
>
> if(init_am_st_oakley(st, policy) == FALSE) {
> loglog(RC_AGGRALGO, "can not initiate aggressive mode, at most one algorithm may be provided");
> reset_globals();
> return STF_FAIL;
> }
> aggr_outI1().
> The purpose of this code is to restrict the policy down to one proposal.
> The work of sending it done by out_sa() called from either
> aggr_outI1_tail(), or from main_outI1().
> You may need to do *some* of the work from init_am_st_oakley() to make
> sure the DH group is setup correctly before you do the async operation
> to generat ethe DH exponent needed before you can initialize.
Ok... So you were sort of right but also very wrong on this. This is
not where (most of) the multi-proposal work needs to be done.
But it got me drilling down in there and I found it deeper in
oakley_alg_makedb and the maxtrans parameter. Seems to have been called
with only 3 values, -1, 0, and 1 from elsewhere. It only checks for ==
1 to limit to one proposal. No idea what the different between -1 and 0
was suppose to have been. So I added a value of 2 to mean multiple
proposals but only one DH group (and use the first DH group for that).
Then I changed the calls that called it with 1 to call it with 2. In
that case, the code then complains if it encounters a DH group that
differs from the initial group and skips that proposal and continues on.
That seems to have done the trick (once I disarmed one passert booby
trap in init_am_st_oakley). I can now specify 8 proposals (the only 8
from vpnc that match what OpenSWAN will support of the 24 that vpnc
supports) and it will issue 8 proposals and the server will select one
and all is right with the world. I preserved the case where maxtrans ==
1 even though there's no call with it, in case we do find a case where
that's needed. My code is all add on into the multi-proposal case to
limit it to 1 DH group.
Once you got me to really look at the code, it wasn't that intimidating
once I drilled in deep enough. I just needed to go deeper. Thanks.
So, I got that far.
Now for the bad news...
The code point you pointed to DOES fire if (and only if) there is NO
ike= specification provided. Ok... That's bad, but not that bad.
Particularly since the man pages even mentions an example of
ike=mod1024. Wow... That would do exactly what I want! Wild card
everything else and give me every combination with that single DH group.
Trouble is THAT doesn't work. The parser is not behaving as documented.
In fact, none of the remarks and examples of leaving something off and
defaulting works (other that the DH group). It spits all sorts of
errors about unexpected characters and incorrect values if I don't fully
specify an exact and complete proposal specification (with the exception
that I can leave of the DH group which is exactly what I want to
specify...). Sigh... So, if I explicitly specify all 8 proposals
individually, it works like a charm. Kind of a pain though. This is
what it looks like:
ike=aes256-sha1;modp1024,aes256-md5;modp1024,aes192-sha1;modp1024,aes192-md5;modp1024,aes128-sha1;modp1024,aes128-md5;modp1024,3des-sha1;modp1024,3des-md5;modp1024
Trace proves it Aggressive I1 contains 8 transform proposals and the
server responds with one it likes, just like what we want.
Works but not exactly what I was after. I'm going to look at main mode
and see how it handles the case of no ike specification but we really
could use the ike=mod1024 feature working. It will be ugly to let the
make_db weed out all the proposals with the alternate DH groups with no
ike specification... But, now, that's in an entirely DIFFERENT stretch
of code from all this. Now it's back in the parser...
That patch is attached here for this. This makes multiple proposals in
aggressive mode work for me, even if it does make the config a bit ugly.
Diff's are against 2.6.24 release code. I can rebase if desired.
I've got a separate patch to fix the trivial little off-by-one but in
id.c that I'll post shortly. I'll keep them in separate messages to
keep the confusion down.
Regards,
Mike
_______________________________________________
Dev mailing list
Dev at openswan.org
http://lists.openswan.org/mailman/listinfo/dev
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openswan-2.6.24.ag-multi-prop.diff
Type: text/x-patch
Size: 3806 bytes
Desc: not available
Url : http://lists.openswan.org/pipermail/dev/attachments/20100312/16ac37b5/attachment.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://lists.openswan.org/pipermail/dev/attachments/20100312/16ac37b5/attachment-0001.bin
More information about the Dev
mailing list