[Swan-commit] Changes to ref refs/heads/master

[Andrew Cagney]

New commits:
commit 17be5711151f18f5d9f48601601cb0d78dc825ac
Author: Andrew Cagney <cagney at gnu.org>
Date:   Tue Nov 29 14:05:41 2016 -0500

    pluto: when IKEv2 ESP/AH "fix" struct trans_attrs .encrypt setting it to an enum ipsec_cipher_alg
    
    For instance, when IKEv2 ESP/AH CAMELLIA, where the kernel backend expects
    the IKEv1 ESP_CAMELLIA(22) value, use struct encrypt_desc's .ikev1_esp_id
    to set struct trans_attr's .encryt field to the correct IKEv1 value.
    
    Here's some idle speculation as to how things went wrong.  initially:
    
    - esp_transform_name[] contained the IKEv2 value: 23
    
    - esp=camellia was converted to 23 by looking up esp_transform_name[]
    
    - IKEv2 proposals seemed to work
    
    - kernel backend and IKEv1 started to accumulate code to compensate
      for for kernels wanting the value 22.
    
    But then, to fix a problem with the kernel logs printing the wrong
    name for 22, esp_transform_name[] gained a second ESP_CAMELLIA entry
    at 22:
    
    - esp=camellia started being converted to 22 instead of 23 since that
      occures first in esp_transform_name[]
    
    - IKEv2 code was added to compensate, mapping 22(kernel)->23(IKEv2)
      when creating proposals.
    
    - However, IKEv2 code forget to do the reverse map (23->22) when
      converting the accepted proposal back to internal form expected by
      the kernel backend.  After all, earlier kernel/backend hacks meant
      this seemd to work.
    
    Real fix, short of deleting .encrypt, is to move it to backend specific
    structures.