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
Re: IPsec Proposal: Invalid Key Length When Using GCM [SOLVED]
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.
Re: IPsec Proposal: Invalid Key Length When Using GCM
Current firmware still affected.
MT side:
Other side (strongswan's log):
This two: AES_CTR_288 and AES_GCM_16_288 are incorrect. It should be AES_CTR_256 and AES_GCM_16_256.
MT side:
Code: Select all
version: 6.41.2 (stable)
build-time: Feb/06/2018 12:29:02
Code: Select all
routerboard: yes
board-name: OmniTIK 5 ac
model: RouterBOARD OmniTIK G-5HacD
firmware-type: qca9550L
current-firmware: 6.41.2
Code: Select all
/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
Code: Select all
... 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
Re: IPsec Proposal: Invalid Key Length When Using GCM
After more than 6 years still this issue/bug hasn't been fixed :/
I don't know what they are doing in Mikrotik headquarters.
I don't know what they are doing in Mikrotik headquarters.