[Swan-dev] regression newoe-02-klips rasie some questions.
andrew.cagney at gmail.com
Sat Jun 24 02:00:23 UTC 2017
On 23 June 2017 at 16:11, Antony Antony <antony at phenome.org> 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#220.127.116.11/24" ...18.104.22.168 #2: ESP algo
> ESP_AES_GCM_C=20 with key_len 256 is not valid (encryption alg not present
> in kernel)
> "private-or-clear#22.214.171.124/24" ...126.96.36.199 #2: ESP/AH responder AUTH
> Child proposed/accepted a proposal we don't actually support!
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
> 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
More information about the Swan-dev