Project

General

Profile

Actions

Feature #8517

open
SD CT

ikev2: new buffers and keywords

Feature #8517: ikev2: new buffers and keywords

Added by Stuart DC 23 days ago. Updated 22 days ago.

Status:
Triaged
Priority:
Normal
Target version:
Effort:
Difficulty:
Label:

Description

Recently reviewed and attempted to create coverage on Windows IKEv2 vulnerability which lead me to find that Suricata only carves buffers for nonce and key exchange payloads but here having access to a buffer for the Encrypted Payload would have been convenient.

https://www.zerodayinitiative.com/blog/2026/4/22/cve-2026-33824-remote-code-execution-in-windows-ikev2

It would great to have the rest of the IKE payloads given keyword buffers.
RFC: https://datatracker.ietf.org/doc/html/rfc4306


Additionally, it'd be great to have a keyword for Next Payload which contains all `next payload` values (in sequence) or for each payload a keyword (ike.encrypt_payload_next).


Related issues 1 (1 open0 closed)

Related to Suricata - Task #4772: tracking: parity between fields logged and fields available for detectionAssignedVictor JulienActions

VJ Updated by Victor Julien 23 days ago Actions #1

  • Subject changed from New IKEv2 Payloads Buffers and Keywords to ikev2: new buffers and keywords

Could you provide a more specific lists of which buffers and keywords you'd expect, suggest naming and syntax and ideally also describe what the usecase per keyword is?

VJ Updated by Victor Julien 23 days ago Actions #2

  • Related to Task #4772: tracking: parity between fields logged and fields available for detection added

PA Updated by Philippe Antoine 23 days ago Actions #3

  • Status changed from New to Assigned
  • Assignee set to Community Ticket

SD Updated by Stuart DC 23 days ago ยท Edited Actions #4

current ikev2 payloads as buffers/keywords

nonce -> already exists as ike.nonce_payload
key exchange -> already exists as ike.key_exchange_payload

new ikev2 payloads would be implemented similarly as the above.

security association -> ike.security_assoc_payload
identification -> ike.identification_payload
certificate -> ike.certificate_payload
certificate request -> ike.certificate_req_payload
authentication -> ike.auth_payload
notify -> ike.notify_payload
delete -> ike.delete_payload
traffic selector -> ike.traffic_selector_payload
encrypted -> ike.encrypted_payload
configuration -> ike.config_payload
extension authentication protocol (eap) -> ike.eap_payload

unfortunately I can't speculate to the use case per keyword. the discovery of this vulnerability does warrant a need to easily navigate IKEv2 payloads in order to test values within the desired IKE payload.

current implementation only allows a rule to blindly match with an assumption on which payloads exists within the IKE packet.

PA Updated by Philippe Antoine 22 days ago Actions #5

  • Status changed from Assigned to Triaged

Thanks

Are these fields already logged by Suricata ?

assumption on which payloads exists within the IKE packet.

Should we have a ike.payload_type keyword ? (is it relevant for the protocol ?)

Actions

Also available in: PDF Atom