MikroTik

Posted: **Mon Oct 09, 2017 3:41 pm**

Hi all,

I have a few RouterBoards in use that connect remote branches over IPsec with our main office, where we use strongSwan as the IKE daemon. This works fine so far, using the cipher suite AES_CBC_128/HMAC_SHA2_256_128/MODP_2048 for the IPsec SAs. RouterOS version is v6.40.4.

I'm currently tinkering with the ciphers and noticed something peculiar about the CGM algorithms: it appears that RouterOS adds 32 to the actually configured cipher strength when it sends the proposal to the remote peer.

As an example, if I configure a proposal using enc-algorithms=aes-256-gcm, then the actual proposal that is sent is AES_GCM_16_288/(0)/MODP_2048. This indicates AES GCM with a 128 bit IV and a key length of 288 bits.

However, according to the relevant RFC (https://tools.ietf.org/html/rfc4106), section 8.4.: "The Key Length attribute MUST have a value of 128, 192, or 256.". This results in strongSwan rejecting the proposal.

To me it seems like a bug, but maybe I misunderstand something. Any thoughts?

Thanks & best regards

Posted: **Tue Oct 10, 2017 1:34 pm**

Thank you very much for the detailed report. Looks like you are right - there seems to be a bug in RouterOS. We will try to fix this issue in upcoming versions or RouterOS.

Posted: **Mon Feb 12, 2018 9:21 pm**

Current firmware still affected.
MT side:

version: 6.41.2 (stable)
build-time: Feb/06/2018 12:29:02

routerboard: yes
board-name: OmniTIK 5 ac
model: RouterBOARD OmniTIK G-5HacD
firmware-type: qca9550L
current-firmware: 6.41.2

/ip ipsec proposal
add auth-algorithms=sha512 enc-algorithms=aes-256-cbc,aes-256-ctr,aes-256-gcm lifetime=1h name=proposal1 pfs-group=ecp521

Other side (strongswan's log):

... received proposals: ESP:AES_CBC_256/AES_CTR_288/AES_GCM_16_288/HMAC_SHA2_512_256/ECP_521/NO_EXT_SEQ
... configured proposals: ESP:AES_CBC_256/AES_CTR_256/HMAC_SHA2_512_256/ECP_521/NO_EXT_SEQ, ESP:AES_GCM_16_256/ECP_521/NO_EXT_SEQ
... selected proposal: ESP:AES_CBC_256/HMAC_SHA2_512_256/ECP_521/NO_EXT_SEQ

This two: AES_CTR_288 and AES_GCM_16_288 are incorrect. It should be AES_CTR_256 and AES_GCM_16_256.

Posted: **Sun Jun 09, 2024 2:44 pm**

After more than 6 years still this issue/bug hasn't been fixed :/
I don't know what they are doing in Mikrotik headquarters.

MikroTik

IPsec Proposal: Invalid Key Length When Using GCM

IPsec Proposal: Invalid Key Length When Using GCM

Re: IPsec Proposal: Invalid Key Length When Using GCM [SOLVED]

Re: IPsec Proposal: Invalid Key Length When Using GCM

Re: IPsec Proposal: Invalid Key Length When Using GCM