[Swan] Ike v2 negotiation
Paul Wouters
paul at nohats.ca
Wed Oct 26 15:02:13 UTC 2016
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:
>
> 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?
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
More information about the Swan
mailing list