On Wed, 20 Jan 2016, Andrew Cagney wrote:
Um, what is "connection switching"?
We answer IKE_INIT, they come back with IKE_AUTH. We then check if there
is a better matching connection to switch to.
In IKEv2, the only way the initiator is going to encrypt and the
responder decrypt that IKE_AUTH packet is by using the KE and proposal
agreed to during IKE_INIT.
All of that information is stored on the state, not the connection. So
it can still switch connection and update st->st_connection
This is why later in the IKE negotiation we can find out the KE payload
we had is actually not valid (because we had to switch connection)
I suspect there's something else I'm missing.
conn one
also=base
authby=secret
ike=aes-sha1;modp2048
conn two
also=base
authby=rsasig
ike=aes-sha1;modp1536
When we receive IKE_INIT, both connections can match. Say it picks "one"
and the KE payload is modp2048. Then it replies and received IKE_AUTH.
Now the AUTH payload has RSASIG as method. It means we need to switch to
conn "two". But now suddenly our replied modp2048 group is invalid and
we need to return NO_PROPOSAL_CHOSEN.
Ah, you'd like to play nice :-)
It's hard enough to get an idea of what's going wrong to begin with :)
I believe:
- sends back INVALID_KE(default)
causing remote end to come back with a KE we might consider, and then either:
- sends-back (I hope) INVALID_KE(correct ke); causing the remote end
to come back with KE we'll hopefully agree to
- or, no proposal chosen
It is tricky to return the right KE based on only information in
IKE_INIT. Administrators are encourages to use the same modp groups
where possible :P
You cannot really send INVALID_KE back in IKE_AUTH.
Paul
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
