On 23 June 2017 at 16:11, Antony Antony <[email protected]> wrote: > my recent fixes to ikev2 retransmit exposed an issue. I am working on a fix > for the regression. However, I noticed it is only on klips. The root cause > is probably worth looking further. > > The test newoe-02-klips, road, is using klips stack. It is hitting passert > since merge commit 59b1d0. I think I can fix this soon. If I fix it the root > cause may go unnoticed. > > Switch the stack to netkey on road there is no crash. A further look > suggest klips does not support AES_GCM? Then why send AES_GCM in proposal as > the initiator to the responder. > > | check_kernel_encrypt_alg(20,256): alg not present in system > "private-or-clear#192.1.2.0/24"[1] ...192.1.2.23 #2: ESP algo > ESP_AES_GCM_C=20 with key_len 256 is not valid (encryption alg not present > in kernel) > "private-or-clear#192.1.2.0/24"[1] ...192.1.2.23 #2: ESP/AH responder AUTH > Child proposed/accepted a proposal we don't actually support! > > 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. 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? > 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). 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. _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
