Project

General

Profile

Bug #3198

VICI child-updown event of the IKEv1 termination doesn't show the byte data correctly

Added by Sung Kim 6 days ago. Updated 5 days ago.

Status:
Feedback
Priority:
Normal
Category:
vici
Target version:
Start date:
Due date:
Estimated time:
Affected version:
5.8.0
Resolution:
Fixed

Description

Hi,
I have a question about the byte data in the VICI child-updown event ('down') from the IKEv1 termination. When the VPN connection is terminated, the child-updown event doesn't provide the byte data ("bytes-in" and "bytes-out"). They are just zeros and the child state is "DELETED". Is this the correct behavior?
However, the updown event ("down") of the IKEv2 termination shows the byte data correctly (the child state is "ESTABLISHED").

History

#1 Updated by Tobias Brunner 6 days ago

  • Category changed from vici to ikev1
  • Status changed from New to Feedback

<usualdisclaimer> You shouldn't be using IKEv1 anymore. </usualdisclaimer>

When the VPN connection is terminated, the child-updown event doesn't provide the byte data ("bytes-in" and "bytes-out"). They are just zeros and the child state is "DELETED". Is this the correct behavior?
However, the updown event ("down") of the IKEv2 termination shows the byte data correctly (the child state is "ESTABLISHED").

If you are referring to closing the complete IKE_SA then the different states are to be expected. For IKEv2, the individual CHILD_SAs are not deleted, an updown event is just triggered for them without changing the state first or logging anything about them etc. However, for IKEv1, each individual CHILD_SA is deleted separately because there is no strict relation between IKE and CHILD_SAs there, so the behavior is the same as manually terminating the CHILD_SAs (which changes the state and logs status information about the closed CHILD_SAs).

That the usage numbers are zero shouldn't be the case though. Unless the CHILD_SA actually never was used, or it already expired (the latter should produce errors in the log about querying a non-existent SA in the kernel). As mentioned above, status information is logged about closed IKEv1 CHILD_SAs, which includes usage numbers. Check what numbers are logged there.

#2 Updated by Sung Kim 6 days ago

If you are referring to closing the complete IKE_SA then the different states are to be expected.

Yes, the termination was executed by the "vici.Session().terminate({"ike": ike_sa_name})"

That the usage numbers are zero shouldn't be the case though. Unless the CHILD_SA actually never was used, or it already expired (the latter should produce errors in the log about querying a non-existent SA in the kernel). As mentioned above, status information is logged about closed IKEv1 CHILD_SAs, which includes usage numbers. Check what numbers are logged there.

I was confused about the numbers. The child SA ("DELETED") in the child-updown event didn't have the byte data at all (I've made some traffic though). Should it have the data?

"ike_sa_name": {
    "uniqueid": "2",
    "version": "1",
    "state": "ESTABLISHED",
    "local-host": "X.X.X.X",
    "local-port": "4500",
    "local-id": "XXXXXXXX",
    "remote-host": "X.X.X.X",
    "remote-port": "4500",
    "remote-id": "XXXXXXX",
    "initiator": "yes",
    "initiator-spi": "22dc527080c9c22d",
    "responder-spi": "6a01fa1d04097f10",
    "nat-local": "yes",
    "nat-remote": "yes",
    "nat-any": "yes",
    "encr-alg": "AES_CBC",
    "encr-keysize": "256",
    "integ-alg": "HMAC_SHA2_384_192",
    "prf-alg": "PRF_HMAC_SHA2_384",
    "dh-group": "ECP_384",
    "established": "15",
    "rekey-time": "14034",
    "local-vips": [
        "X.X.X.X" 
    ],
    "tasks-queued": [
        "ISAKMP_DELETE" 
    ],
    "tasks-active": [
        "QUICK_DELETE" 
    ],
    "child-sas": {
        "child_sa_name": {
            "name": "child_sa_name",
            "uniqueid": "2",
            "reqid": "2",
            "state": "DELETED",
            "mode": "TUNNEL",
            "local-ts": [
                "x.x.x.x/x" 
            ],
            "remote-ts": [
                "0.0.0.0/0" 
            ]
        }
    }
}

#3 Updated by Tobias Brunner 6 days ago

  • Category changed from ikev1 to vici

I was confused about the numbers. The child SA ("DELETED") in the child-updown event didn't have the byte data at all (I've made some traffic though). Should it have the data?

Ah, I see. The vici plugin only returns some details about a CHILD_SA if it is in an "active" state (INSTALLED, REKEYING, REKEYED, see source:src/libcharon/plugins/vici/vici_query.c#L169). So neither DELETED, nor DELETING is included there and if the CHILD_SA is in either of these states you won't get usage numbers or other advanced info (like protocol, SPIs, marks, algorithms, lifetimes). That affects IKEv2 too if CHILD_SAs are terminated individually, as the state is set to DELETED before the event is triggered. But, as mentioned, not if the IKE_SA is deleted completely as the state just remains as is then.

I guess we could return some of the additional info for SAs in state DELETING/DELETED (but e.g. lifetimes don't really make sense). I'll have a look at this tomorrow.

#4 Updated by Tobias Brunner 5 days ago

  • Tracker changed from Issue to Bug
  • Assignee set to Tobias Brunner
  • Target version set to 5.8.2
  • Resolution set to Fixed

I pushed a fix for this to the 3198-vici-child-updown branch (since lifetimes are reported as signed numbers, I left them in the message even for potentially expired or rekeyed SAs).

#5 Updated by Sung Kim 5 days ago

Thank you for the quick response. I'll let my server admin know this fix.
However, I have another question about the byte numbers in the child-updown event caused by dpd timeout during the child rekeying but I'll create a new issue for that.

#6 Updated by Sung Kim 5 days ago

However, I have another question about the byte numbers in the child-updown event caused by dpd timeout the retransmission timeout during the child rekeying but I'll create a new issue for that.

Just for correcting my comment above

#7 Updated by Tobias Brunner 5 days ago

However, I have another question about the byte numbers in the child-updown event caused by dpd timeout the retransmission timeout during the child rekeying but I'll create a new issue for that.

As mentioned, usage numbers are only provided if the CHILD_SA is still installed in the kernel. So if the CHILD_SA expires while retransmits of the rekeying request are sent, there won't be any numbers if the IKE_SA is later terminated due to DPD.

Also available in: Atom PDF