From: Timo Teräs <timo.teras@ik...> - 2009-03-03 17:53:06
I just refreshed my patch of the "multiple anonymous remotes" at:
I updated remoteconf dumping and documentation. It should be usable
now, and I'll probably commit it next week or so unless something
serious is found. So please take a look at it as it's pretty intrusive
and touches the code all over the place as the diffstat summary
29 files changed, 1647 insertions(+), 1686 deletions(-)
I probably should have split it to multiple commits. But I really
don't like quilt (I always forget to "quilt add" before editing
a file). And CVS cannot help here much either.
Maybe I should start to maintain a public git tree with my
development stuff in it?
On Tue, Mar 03, 2009 at 07:52:54PM +0200, Timo Ters wrote:
> Hi all,
> I just refreshed my patch of the "multiple anonymous remotes" at:
Sounds good, I hope I'll have time to have a look on it within the
next few days.
I asked myself a question a few days ago related to that dev: how do
you select the good remote anonymous section ?
In aggressive mode, you can of course use peer's identity, but we do
know that aggressive mode is bad because it has a weaker security
So, in main mode, what can be used to select the good certificate,
except an IP address ???
From: Timo Teräs <timo.teras@ik...> - 2009-03-04 09:29:41
VANHULLEBUS Yvan wrote:
> So, in main mode, what can be used to select the good certificate,
> except an IP address ???
It's documented in the man page.
Basically, in main mode the first proposal that has one or more
candidate remote confs is selected. Then in further exchanges, when
rest of the info is exchanged (cert request, identities, etc.) those
are enforced to match a valid remote conf.
So in theory if you have a lot of options the negotiation can fail
if initiator proposes multiple sa:s / authentications, but the
first proposal matches someone elses remoteconf and later on we
cannot change our ISAKMP approval to what should have been used
with the remote. So better configure the initiator always right;
there's no way to make responder work properly in the above case.