Skip to content

Final proposal


SONAR represents the exchanges observed on the network as a flow matrix. Each entry corresponds to an aggregated flow, defined by the key attributes of the network packet (Ethernet → IP → Transport → Application).

This format follows the SFMS — SONAR Flow Matrix Standard, in its Core v0.2 version, designed to become an international standard for exchanging network flow matrices.


  • Alignment with the real structure of network frames (no ambiguous OSI/TCP-IP mixing)
  • Interoperability with other monitoring / SOC / IDS tools
  • Readability for network and cybersecurity analysts
  • Extensibility for future industrial and IoT protocols
  • Normativity to enable broad industry adoption

Source MACDestination MACEtherTypeSource IPSource IP TypeDestination IPDestination IP TypeTransport ProtocolSource PortDestination PortApplication ProtocolCumulative sizeOccurrences

Description:

  • Source / Destination MAC Layer-2 identifiers (link layer).
  • EtherType Type of encapsulated protocol (IPv4, IPv6, ARP, VLAN, PROFINET, etc.).
  • Source / Destination IP IP addresses if available, otherwise empty.
  • IP Type Classification (Unicast, Broadcast, Multicast, Unknown).
  • Transport Protocol TCP, UDP, ICMPv4, ICMPv6, None.
  • Ports Valid only for TCP/UDP → empty fields otherwise.
  • Application Protocol Inspected without decryption (DNS, HTTP, TLS, Modbus, Unknown…).
  • Cumulative size (bytes)
  • Occurrences (packets)

🧩 Temporality (optional SFMS-T extension)

Section titled “🧩 Temporality (optional SFMS-T extension)”
Last seen

Format: RFC3339 (2025-06-13T13:32:49Z) Lets you know whether the flow was recently active.

Temporality is not in the Core → it stays optional in SFMS v0.2. A future version may add first_seen, window.id, etc.


Source MACDestination MACEtherTypeSource IPSource IP TypeDestination IPDestination IP TypeTransportSrc PortDst PortAppSizeOccurrencesLast seen
00:11:22:33:44:55FF:FF:FF:FF:FF:FFARPNoneUnknown12832025-06-13T13:32:45Z
AA:BB:CC:DD:EE:FF11:22:33:44:55:66IPv4192.168.1.12Unicast192.168.1.1UnicastTCP44352428TLS1820072025-06-13T13:32:49Z

ElementReason
InterfaceDepends on the capture context, not the flow
OSI numbering (L3, L4…)Too ambiguous — replaced by explicit fields
Payload / TLS sessionOut of scope for passive capture without decryption
Internal references (VM/zone)Should be handled via extensions (SFMS-I)

Because it is extracted from the same “Protocol” field as TCP/UDP in IPv4/IPv6. → Same information source ⇒ same display level.

TLS encrypts application data. → SONAR displays the observable protocol, not the undecrypted internal session.


🔒 Cybersecurity alignment and interoperability

Section titled “🔒 Cybersecurity alignment and interoperability”

The model can be mapped to the Information Elements of the IPFIX standard used by NetFlow v9, sFlow, IDS/IPS, NDR, etc.

🎯 Goal: enable the universal exchange of network flow matrices.


The SONAR export follows SFMS Core v0.2 strictly. A validator and a JSON schema are provided to guarantee conformance.


  • Explicit support for industrial protocols (Modbus, Profinet)
  • Full temporal extension (first_seen, window.id)
  • IETF (Internet-Draft) standardization proposal

SONAR sets the normative foundation that can be adopted by the Cyber & OT community.


This format clarifies the network flow matrix and makes it:

✅ Standardized ✅ Interoperable ✅ Durable ✅ Context-independent ✅ Aligned with the network and cyber industry

The goal is for SONAR to become the reference for representing and exchanging network flow matrices.