Suricata

Just noticed this ticket; in general having these MPLS info would be interesting for us as well. I have prepared a first shot of MPLS logging support by using VLAN support as an inspiration (see https://github.com/satta/suricata/tree/mpls) but I am not sure about some of the details like

• is it expected (or common) to see multiple sets of labels in the same flow, and/or
• would it be expected to be able to separate flows based on MPLS labels (like it is done for VLAN tags via "vlan.use-for-tracking")?

I do not have much experience with how this technology is actually used out there and publicly available pcaps are pretty simplistic and do not go beyond the basics. Any comments or input? The current implementation assumes that all packets in a flow share a set of labels.

Also, I have currently limited the number of labels parsed to 3, and if there are more than 3 an event is raised. If anyone can come up with a realistic estimate of how many labels are typically used in common use cases, it would help set a better constraint.

For instance, the current code would produce the following EVE (among others):

{
  "timestamp": "2000-03-03T22:27:46.896814+0100",
  "flow_id": 755564368240102,
  "pcap_cnt": 21,
  "event_type": "alert",
  "mpls": [
    18,
    16
  ],
  "src_ip": "10.31.0.1",
  "src_port": 11001,
  "dest_ip": "10.34.0.1",
  "dest_port": 23,
  "proto": "TCP",
  "pkt_src": "wire/pcap",
  "alert": {
    "action": "allowed",
    "gid": 1,
    "signature_id": 1,
    "rev": 1,
    "signature": "TEST Telnet Activity",
    "category": "",
    "severity": 3
  },
  "direction": "to_server",
  "flow": {
    "pkts_toserver": 1,
    "pkts_toclient": 0,
    "bytes_toserver": 66,
    "bytes_toclient": 0,
    "start": "2000-03-03T22:27:46.896814+0100",
    "src_ip": "10.31.0.1",
    "dest_ip": "10.34.0.1",
    "src_port": 11001,
    "dest_port": 23
  }
}
{
  "timestamp": "2000-03-03T22:27:41.942807+0100",
  "flow_id": 755564368240102,
  "event_type": "flow",
  "mpls": [
    18,
    16
  ],
  "src_ip": "10.31.0.1",
  "src_port": 11001,
  "dest_ip": "10.34.0.1",
  "dest_port": 23,
  "proto": "TCP",
  "app_proto": "telnet",
  "flow": {
    "pkts_toserver": 10,
    "pkts_toclient": 6,
    "bytes_toserver": 648,
    "bytes_toclient": 397,
    "start": "2000-03-03T22:27:46.896814+0100",
    "end": "2000-03-03T22:27:48.998503+0100",
    "age": 2,
    "state": "closed",
    "reason": "shutdown",
    "alerted": true
  },
  "tcp": {
    "tcp_flags": "1b",
    "tcp_flags_ts": "1b",
    "tcp_flags_tc": "1b",
    "syn": true,
    "fin": true,
    "psh": true,
    "ack": true,
    "state": "closed",
    "ts_max_regions": 1,
    "tc_max_regions": 1
  }
}

suricata -v -S mplstest.rules -v -k none -r mpls-twolevel.cap -c suricata.yaml -l .

alert tcp any any -> any 23 (msg:"TEST Telnet Activity"; classtype:policy-violation; rev: 1; gid: 1; sid: 1;)

with this pcap: https://wiki.wireshark.org/uploads/__moin_import__/attachments/SampleCaptures/mpls-twolevel.cap

I also noticed that there are already https://github.com/OISF/suricata/pull/4311 (which is by Wesley who this ticket is assigned to) and https://github.com/OISF/suricata/pull/4977 (which introduces a useful data structure to implement this) but they seem to have stalled a bit.
Any news on that front?

Also, unfortunately, the broader questions about how label gathering and logging generalizes to flows are not addressed there either...

Any comments here? Is there anything anybody is waiting for that I might be able to help with to get this feature going?

Trying to sum up Sascha at Suricon 2023 :
Also, would same IP with different MPLS labels need to be unified ?

Suricon 2023 :
- Make Packet structure more compact
- Make it easier to extend decoders without having to update the Packet structure (not only vlan, but mols and other)
see PR quoted above