On Sun, 13 Mar 2022 at 09:25, Andrew Cagney <[email protected]> wrote: > > On Sun, 13 Mar 2022 at 08:42, Paul Wouters <[email protected]> wrote: > > > > Begin forwarded message: > > > > > commit f20a3dba83b77dc615057cac1ec7f498987f7963 > > > Author: Andrew Cagney <[email protected]> > > > Date: Sat Mar 12 14:34:38 2022 -0500 > > > > > > ikev2: when responding to bad IKE_SA_INIT, record error and return > > > STF_FATAL > > > > Why is there an STF value here? Since there is no state yet l, there can’t > > really be an state change ? So no STF ? > > It's after the connection's been instantiated and state created. > > Things breakdown roughly as: > > - process_v2_IKE_SA_INIT() case MESSAGE_REQUEST (mumble something > about splitting it into two functions) > -- sanity cheks > -- cookie > -- redirect > -- find transition (sniff check needed payloads) > -- instantiate connection(grrr) > -- create state > - v2_dispatch() which calls process_v2_IKE_SA_INIT_request() and has > the code your asking about > -- match proposals against connection > -- cross check KE > -- dispatch crypto > > to your point we could probably shuffle the middle. For instance, > delay instantiating the connection until after the proposal and ke > matching.
BTW, one other thing to consider is what IKE_SA_INIT events should be logged against the state. For instance, if the connection instantiation and state are delayed then, presumably, a rejected proposal would be logged against the connection template. Not wrong, just different to now. _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
