[Swan-dev] regression newoe-02-klips rasie some questions.

[Antony Antony]

On Fri, Jun 23, 2017 at 10:00:23PM -0400, Andrew Cagney wrote:

> > http://swantest.libreswan.fi/results/blackswan/2017-06-23-swantest-3.21rc2-142-g4cb3a8b-master/newoe-02-klips/OUTPUT/road.pluto.log
> 
> I'm not sure that us proposing something we don't support is the root
> cause here; rather it is just the oddity that triggered the
> problematic code path.

true. I pushed a fix. I got confused because it worked netkey and crash on 
klips.

> For instance, when a responder replies with a bogus accepted proposal
> in the AUTH packet, ikev2_process_sa_payload() will reject it and
> return the same STF_FAIL + v2N_NO_PROPOSAL_CHOSEN.  Does that have the
> same end result?

AUTH payload failure is a different code path. This was AUTH payload success
and installing SA failed; ie AUTH exchange failure. So parent advanced and 
the child didn't.

> > Could it be KLIPS does not support ESP_AES_GCM_C? I am not sure yet. If
> > KLIPS suppors it this is something else.  Why pluto figure this out late in
> > the negotiation? Shouldn't pluto know as the initiator which ESP algorithms
> > are supported by kernel and send only those in the proposal to the
> > responder?
> >
> > Do we need another ESP default list based klips or netkey:)
> 
> It is a no win, we just need to be ready.  For instance with XFRM
> AES_CMAC, the only way to know if it is supported is to try creating a
> connection and using it.
> 
> However we can likely mitigate things.
> 
> What about calling check_kernel_encrypt_alg() from
> append_encrypt_transform() so stuff that gets past the parser gets
> dropped before (instead of after) it goes out.  Another option is to
> remove ikev2_proposal_to_proto_info()'s check and instead let the
> kernel reject it (as would happen for AES_CMAC). 

this could be an improvement I guess.
I wonder if all algorithms, if they are kernel modules, loaded at start? Or 
could a cryptp module get loaded when pluto install an SA? Or when ESP 
packet actually arrive xfrm/klips call that crypto function.

> It wouldn't help with IKEv2's hardwired ESP/AH defaults though, but
> for those I'd prefer to see them handled similar to IKEv1 IKE
> defaults, see ikev1_default_ike_info(void).  Besides, KLIPS is going
> away. 

:)