ike: log attributes as objects - v1

[jasonish]

Ticket: https://redmine.openinfosecfoundation.org/issues/7902

SV_BRANCH=OISF/suricata-verify#2665

Also:

• Don't log empty "ike" server objects

[jasonish]

This is the proposed solution for Suricata 9, but its a breaking change so we don't want to backport it as-is.

For 8 and 7 (as currently invalid JSON can be produced), I'm recommending we default to something like:

       "encrypted_payloads": false,
       "client": {
         "proposals": [
           {
             "alg_enc": "EncAesCbc",
             "alg_enc_raw": 7,
             "sa_key_length": "Unknown",
             "sa_key_length_raw": 128,
             "alg_hash": "HashSha",
             "alg_hash_raw": 2,
             "sa_life_duration": "Unknown",
             "sa_life_duration_raw": 86400,
             "alg_dh": "GroupAlternate1024BitModpGroup",
             "alg_dh_raw": 2,
             "alg_auth": "AuthPreSharedKey",
             "alg_auth_raw": 1,
             "sa_life_type": "LifeTypeSeconds",
             "sa_life_type_raw": 1,
             "sa_life_duration_1": "Unknown",
             "sa_life_duration_1_raw": 65535
           }
         ]

With an opt-in to the new format:

types:
  - ike:
      # Logging attributes as an array of objects (Suricata 9.0 style)
      #object-attributes: true

I do feel its too early to declare an ike v2 logging style.

[suricata-qa]

WARNING:

field	baseline	test	%
	SURI_TLPR1_stats_chk
.uptime	652	629	96.47%

Pipeline = 27713

[victorjulien]

I do feel its too early to declare an ike v2 logging style.

I think we need to define some criteria for this. To me, a breaking change like this seems good reason to bump a version.

[jasonish]

I do feel its too early to declare an ike v2 logging style.

I think we need to define some criteria for this. To me, a breaking change like this seems good reason to bump a version.

We could bump it in 9 with the assumption v2 might change before 9 is final - without a complete holistic look at the ike logging, I think its a little early to declare v2 as final. And the priority here should be to fix the creation of invalid JSON, not necessarily define a new version of IKE logging we can lock down.

Scenario I want to avoid:

• Add v2 logging now. Backport a v2 toggle to 7 and 8.
• Identify enhancements or other changes in 9 that might be breaking
• Now we need to bump to v3 before Suricata 9 is released.

[jasonish]

Replaced by #13927