[Swan-dev] Thanks for state cleanups, one Q, was Fwd: [Swan-commit] Changes to ref refs/heads/main

[Andrew Cagney]

On Sun, 13 Mar 2022 at 09:25, Andrew Cagney <andrew.cagney at gmail.com> wrote:
>
> On Sun, 13 Mar 2022 at 08:42, Paul Wouters <paul at nohats.ca> wrote:
> >
> > Begin forwarded message:
> >
> > > commit f20a3dba83b77dc615057cac1ec7f498987f7963
> > > Author: Andrew Cagney <cagney at gnu.org>
> > > 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.