[Swan] Ike v2 negotiation

[Andrew Cagney]

On 26 October 2016 at 11:02, Paul Wouters <paul at nohats.ca> wrote:
> On Tue, 18 Oct 2016, Renzo Dani wrote:
>
>>         ike=aes256-sha2_512;modp2048
>>         phase2alg=aes256-sha2_512;modp2048
>
>
>> If we start the tunnel everything works and the tunnel is correctly
>> established:
>>
>> Oct 18 10:46:16 lofw pluto[1411]:  #579: initiating v2 parent SA
>> Oct 18 10:46:16 lofw pluto[1411]:  #579: myName IKE proposals:
>> 1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2-512;INTEG=HMAC_SHA2_512_256;DH=MODP2048
>> Oct 18 10:46:16 lofw pluto[1411]:  #579: STATE_PARENT_I1: sent v2I1,
>> expected v2R1
>> Oct 18 10:46:16 lofw pluto[1411]:  #579: myName ESP/AH proposals:
>> 1:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_512_256;ESN=DISABLED
>> Oct 18 10:46:16 lofw pluto[1411]:  #580: STATE_PARENT_I2: sent v2I2,
>> expected v2R2 {auth=IKEv2 cipher=aes_256 integ=sha512_256
>> prf=OAKLEY_SHA2_512 group=MODP2048}
>> Oct 18 10:46:16 lofw pluto[1411]:  #580: IKEv2 mode peer ID is
>> ID_IPV4_ADDR: 'a.a.a.a'
>> Oct 18 10:46:16 lofw pluto[1411]:  #580: negotiated connection [......] ->
>> [....]
>> Oct 18 10:46:16 lofw pluto[1411]:  #580: STATE_PARENT_I3: PARENT SA
>> established tunnel mode {ESP.....
>>
>>
>> Instead if the process is started from the other side they send us
>> different proposals:

Does a line like:

packet from 192.1.2.45:500: westnet-eastnet-ipv4-psk-ikev2 IKE
proposals for initial responder: 1:IKE:ENCR=AES_GCM_C_256;...

or similar (the exact format has evolved so it might be the below)
showing the local (libreswan) proposal list appear in the logs
somewhere?

myName IKE proposals:
 1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2-512;INTEG=HMAC_SHA2_512_256;DH=MODP2048

>> Oct 18 10:45:24 lofw pluto[1411]: packet from a.a.a.a:500: proposal
>> 2:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2-256;INTEG=HMAC_SHA2_256_128;DH=MODP2048
>>   chosen from:
>>
>> 1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2-512;INTEG=HMAC_SHA2_512_256;DH=MODP2048
>> 2:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2-256;INTEG=HMAC_SHA2_256_128;DH=MODP2048[first-match]
>> 3:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA1;INTEG=HMAC_SHA1_96;DH=MODP2048
>>
>> and we end up choosing the option 2 instead of option 1 and the tunnel is
>> not working.
>
>
> If they send you a proposal list, and you pick one, they MUST honour
> that proposal. The fact that they are rejecting your proposal is a bug
> in their code. Can you tell me the vendor/model/type of device that is
> used, so I can relay this back to that vendor?
>
> But perhaps the bug is on our end, since we should never have picked up
> HMAC_SHA2_256_128 as we do not have that configured. Andrew, did this
> code get changed/fixed recently?

It was rewritten a while back.

I'm not sure where the problem is - it should have matched the first
IKE proposal.
In both cases, the same code is used to construct a local proposal.

All I've noticed is:

- ike=...-sha2_256 would result in the IKEv2 proposal
PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128

- our default accepts AES_256 with either SHA2_256 or SHA2_512 but we
should prefer SHA2_512 given the option

>
> Perhaps what is happening is that we pick the wrong proposal and send
> that back, but actually use the one we have configured?
>
> I know we changed the order recently to prefer sha2_512 over sha2_256,
> so I assume this is an older version of libreswan? But we should double
> check this scenario cannot happen anymore with the latest code.
>
>> I think option 1 is the only matching the configuration or I think it
>> wrong?
>
>
> Yes you are right. Can you tell us which version of libreswan this was?
>
> Paul
>