Bug #980
iv-gen issue...
Description
Hi,
It seems, that commit d0ed1079103334680b1b775b5217709cd26d6ab6 (iv-gen: Ensure external sequential IVs are actually sequential) breaks
CHILD_SA rekey?
I am using it on openwrt (86_x64 arch.) and 'aes128gcm16-prfsha256-ecp256' as ike cipher suite.
Here are the logs from the responder (with some additional debugging info)
First IKE authentication response (ok):
charon: 16[ENC] <to_bob|1> generating IKE_AUTH response 1 [ IDr CERT AUTH SA TSi TSr ] charon: 16[ENC] <to_bob|1> encrypting encrypted payload mid = 0000000000000001 charon: 16[ENC] <to_bob|1> get_iv prev=FFFFFFFFFFFFFFFF seq = 0000000100000000 charon: 16[ENC] <to_bob|1> encrypting encrypted payload get_iv rc=1
First rekey (not ok):
charon: 07[IKE] <to_bob|1> establishing CHILD_SA to_bob{1}
charon: 07[ENC] <to_bob|1> generating CREATE_CHILD_SA request 0 [ N(REKEY_SA) SA No TSi TSr ]
charon: 07[ENC] <to_bob|1> encrypting encrypted payload mid = 0000000000000000
charon: 07[ENC] <to_bob|1> get_iv prev=0000000100000000 seq=0000000000000000
charon: 07[ENC] <to_bob|1> !!! seq <= this->prev !!!
charon: 07[ENC] <to_bob|1> encrypting encrypted payload get_iv rc=0
Furthermore after the failure the updown script gets called which deletes the relevant firewall rules (that's ok),
but next successfull ike negotiation doesn't call updown script which leaves the system without firewall rules set - an unusable state.
Regards
Luka
Related issues
Associated revisions
History
#1 Updated by Martin Willi over 5 years ago
Hi Luka,
It seems, that commit d0ed1079103334680b1b775b5217709cd26d6ab6 (iv-gen: Ensure external sequential IVs are actually sequential) breaks CHILD_SA rekey?
Yes, I can confirm the issue. It does not only affect rekeying, but any original-responder initiated exchange. This is because it reuses the same message ID the original-initiator already used, and therefore the same sequential IV.
The mentioned commit is actually fine, as it just ensures that IVs don't get reused. As a work-around you'll have to switch to a non-counter cipher (everything else than gcm/ccm/ctr).
I think we have two options here:- Include the original-initiator or the request flag in the sequential IV; this requires that we adopt the check in the mentioned commit, as IVs can't be strictly sequential then. We could even handle that completely in iv_gen.
- Use an external sequential IV counter; We prefer to avoid that, as we'd need to synchronize that counter when using HA failover.
Regards
Martin
#2 Updated by Martin Willi over 5 years ago
This commit goes the first approach, and is a fix simple to implement. I didn't test it extensively yet, though.
#3 Updated by Martin Willi over 5 years ago
- Category set to libstrongswan
- Status changed from New to Feedback
- Assignee set to Martin Willi
#4 Updated by Luka Logar over 5 years ago
Unfortunately the fix isn't working (or perhaps isn't working all the time?)
Here's the relevant (one of several) log fragment (see "encrypting encrypted payload failed, no IV or padding" error at 22:06:22.657678
2015-06-02T22:06:22.655969 charon: 10[KNL] creating rekey job for CHILD_SA ESP/0xc4095110/10.200.0.209
2015-06-02T22:06:22.656187 charon: 10[IKE] <to_bob|14> establishing CHILD_SA to_bob{10}
2015-06-02T22:06:22.656252 charon: 10[ENC] <to_bob|14> generating CREATE_CHILD_SA request 0 [ N(REKEY_SA) SA No TSi TSr ]
2015-06-02T22:06:22.656301 charon: 10[NET] <to_bob|14> sending packet: from 10.200.0.208[500] to 10.200.0.209[500] (205 bytes)
2015-06-02T22:06:22.657328 charon: 08[NET] <to_bob|14> received packet: from 10.200.0.209[500] to 10.200.0.208[500] (193 bytes)
2015-06-02T22:06:22.657366 charon: 08[ENC] <to_bob|14> parsed CREATE_CHILD_SA response 0 [ SA No TSi TSr ]
2015-06-02T22:06:22.657598 charon: 08[IKE] <to_bob|14> CHILD_SA to_bob{39} established with SPIs ca2a36f4_i c4784ccb_o and TS 10.0.0.0/24 10.208.0.0/24 === 10.209.0.0/24
2015-06-02T22:06:22.657634 charon: 08[IKE] <to_bob|14> closing CHILD_SA to_bob{38} with SPIs cce6bfec_i (52513 bytes) c4095110_o (48502 bytes) and TS 10.0.0.0/24 10.208.0.0/24 === 10.209.0.0/24
2015-06-02T22:06:22.657646 charon: 08[IKE] <to_bob|14> sending DELETE for ESP CHILD_SA with SPI cce6bfec
2015-06-02T22:06:22.657662 charon: 08[ENC] <to_bob|14> generating INFORMATIONAL request 1 [ D ]
2015-06-02T22:06:22.657678 charon: 08[ENC] <to_bob|14> encrypting encrypted payload failed, no IV or padding
2015-06-02T22:06:22.663108 vpn: - 10.200.0.209 10.209.0.0/24 == 10.200.0.209 -- 10.200.0.208 == 10.0.0.0/24
2015-06-02T22:06:22.668813 vpn: - 10.200.0.209 10.209.0.0/24 == 10.200.0.209 -- 10.200.0.208 == 10.208.0.0/24
2015-06-02T22:06:22.671807 charon: 08[CHD] <to_bob|14> updown: iptables: Bad rule (does a matching rule exist in that chain?).
2015-06-02T22:06:22.672573 charon: 08[CHD] <to_bob|14> updown: iptables: Bad rule (does a matching rule exist in that chain?).
2015-06-02T22:06:22.673311 charon: 08[CHD] <to_bob|14> updown: iptables: Bad rule (does a matching rule exist in that chain?).
2015-06-02T22:06:22.674040 charon: 08[CHD] <to_bob|14> updown: iptables: Bad rule (does a matching rule exist in that chain?).
2015-06-02T22:06:22.674438 vpn: - 10.200.0.209 10.209.0.0/24 == 10.200.0.209 -- 10.200.0.208 == 10.0.0.0/24
2015-06-02T22:06:22.677369 charon: 08[CHD] <to_bob|14> updown: iptables: Bad rule (does a matching rule exist in that chain?).
2015-06-02T22:06:22.677949 charon: 08[CHD] <to_bob|14> updown: iptables: Bad rule (does a matching rule exist in that chain?).
2015-06-02T22:06:22.678513 charon: 08[CHD] <to_bob|14> updown: iptables: Bad rule (does a matching rule exist in that chain?).
2015-06-02T22:06:22.679061 charon: 08[CHD] <to_bob|14> updown: iptables: Bad rule (does a matching rule exist in that chain?).
2015-06-02T22:06:22.679348 vpn: - 10.200.0.209 10.209.0.0/24 == 10.200.0.209 -- 10.200.0.208 == 10.208.0.0/24
2015-06-02T22:11:08.137083 charon: 14[NET] <15> received packet: from 10.200.0.209[500] to 10.200.0.208[500] (264 bytes)
2015-06-02T22:11:08.137122 charon: 14[ENC] <15> parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) V ]
2015-06-02T22:11:08.137153 charon: 14[IKE] <15> received strongSwan vendor ID
2015-06-02T22:11:08.137162 charon: 14[IKE] <15> 10.200.0.209 is initiating an IKE_SA
2015-06-02T22:11:08.138998 charon: 14[IKE] <15> sending cert request for "C=XX, ST=XXXXXX, O=XXXXXX, OU=XX, CN=ca"
2015-06-02T22:11:08.139035 charon: 14[ENC] <15> generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(HASH_ALG) N(MULT_AUTH) V ]
2015-06-02T22:11:08.139071 charon: 14[NET] <15> sending packet: from 10.200.0.208[500] to 10.200.0.209[500] (297 bytes)
2015-06-02T22:11:08.291359 charon: 15[NET] <15> received packet: from 10.200.0.209[500] to 10.200.0.208[500] (1016 bytes)
2015-06-02T22:11:08.291398 charon: 15[ENC] <15> parsed IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ IDr AUTH SA TSi TSr N(MULT_AUTH) N(EAP_ONLY) ]
2015-06-02T22:11:08.291413 charon: 15[IKE] <15> received cert request for "C=XX, ST=XXXXXX, O=XXXXXX, OU=XX, CN=ca"
2015-06-02T22:11:08.291546 charon: 15[IKE] <15> received end entity cert "C=XX, ST=XXXXXX, O=XXXXXX, OU=XX, CN=bob"
2015-06-02T22:11:08.291557 charon: 15[CFG] <15> looking for peer configs matching 10.200.0.208[10.200.0.208]...10.200.0.209[10.200.0.209]
Regards
Luka
#5 Updated by Luka Logar over 5 years ago
And here are seq and prevX values:
2015-06-03T10:22:01.095747 charon: 12[ENC] <to_bob|2> generating INFORMATIONAL request 1 [ D ] 2015-06-03T10:22:01.095759 charon: 12[ENC] <to_bob|2> get_iv seq=0000000100000000 prevl=0000000100000000 prevh=8000000000000000 2015-06-03T10:22:01.095764 charon: 12[ENC] <to_bob|2> encrypting encrypted payload failed, no IV or padding
#6 Updated by Tobias Brunner over 5 years ago
Yes, the patch has a small bug. Comparing the previous high sequence number to the passed sequence number seq obviously won't work as it will always be smaller. Moving seq |= SEQ_IV_HIGH_MASK; before the comparison should fix this (another option would be to store seq without SEQ_IV_HIGH_MASK in prevh).
I pushed an updated commit to the iv-reuse branch.
#7 Updated by Luka Logar over 5 years ago
Yes, patch is working. Thank you for your prompt response.
Could you please comment on the log entries after the failure? Why is the updown script called twice?
Best regards
Luka
#8 Updated by Tobias Brunner over 5 years ago
- Tracker changed from Issue to Bug
- Status changed from Feedback to Closed
- Target version set to 5.3.2
- Resolution set to Fixed
Thanks for testing the patch.
Could you please comment on the log entries after the failure? Why is the updown script called twice?
The failure happened right after a CHILD_SA rekeying, when the daemon attempted to delete the old CHILD_SA. At that point two CHILD_SAs were established so when the IKE_SA was destroyed due to the fatal failure a child_updown() event was triggered for both of them (in a normal rekeying this event is not triggered for the the old SA). I think we could fix that by marking rekeyed CHILD_SAs with CHILD_REKEYED (as we do with IKEv1 SAs) after the child_rekey() event has been triggered and then check for that state when deciding whether to trigger the child_updown() event. Since there are other issues open regarding similar problems (e.g. #853) we will probably need to have a closer look at this.
#9 Updated by Tobias Brunner over 5 years ago
- Affected version changed from dr|rc|master to 5.3.1
#10 Updated by Tobias Brunner over 5 years ago
- Has duplicate Bug #983: Rekeying failure in 5.3.1 added
ivgen: Allow reusing the same message ID twice in sequential IV gen
We use the message ID and fragment number as IV generator. As IKEv2 uses
distinct message ID counters for actively and passively initiated exchanges,
each IV would be used twice. As we explicitly reject such message IDs since
d0ed1079, original-responder initiated exchanges fail with counter mode ciphers.
This commit separates IV space in two halves for sequential IVs, and
automatically assigns once reused sequence numbers to the second half.
Fixes #980.