On 20 January 2016 at 22:59, Paul Wouters <[email protected]> wrote: > 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.
That, fortunately, is beyond the scope of what I'm changing. >> 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 Yes. For instance, given: - initiator proposes KE=1500 MODP=1500 2000 - responder has MODP=4000,2000 then if tje responder sends back INVALID_KE(4000) (its default), instead of INVALID_KE(2000) (from matching proposal), then the initiator is going to drop that response on the floor and an interop that should work won't. > 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
