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

[Antony Antony]

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

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:)

-antony