quic: add frames support

[catenacyber]

Link to redmine ticket: https://redmine.openinfosecfoundation.org/issues/4985

Describe changes:

• quic: add frames support

I still do not understand the benefit of frames for protocols over UDP... What am I missing ?

What is the point of having a frame for sip.request_line compared to the sticky buffer ?

[codecov[bot]]

Codecov Report

Merging #7832 (5517ef7) into master (bb2e111) will decrease coverage by 0.09%. The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #7832      +/-   ##
==========================================
- Coverage   76.10%   76.00%   -0.10%     
==========================================
  Files         663      663              
  Lines      185889   185887       -2     
==========================================
- Hits       141467   141289     -178     
- Misses      44422    44598     +176     

Flag	Coverage Δ
fuzzcorpus	60.88% <ø> (-0.14%)	:arrow_down:
suricata-verify	52.48% <ø> (-0.11%)	:arrow_down:
unittests	60.70% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

[victorjulien]

What is the point of having a frame for sip.request_line compared to the sticky buffer ?

For simple text protocols it will avoid overhead of allocating a buffer in the state. It's also just a new and simpler way to declare buffers that then automatically become available to the rule lang.

[victorjulien]

• quic: add frames support

I still do not understand the benefit of frames for protocols over UDP... What am I missing ?

Currently there are a few things that make it different:

1. frames can be only about a part of the data, e.g. tls.hdr, tls.data.
2. due to suricata pattern matching internals alert dns ... content... and alert ... frame:dns.pdu will work differently, with the latter being more efficient.
3. it can be used to "normalize" in some cases, like in dns.pdu this is the whole packet payload for UDP, but for TCP it exludes the TCP specific length field so that inspection of UDP and TCP would be the same.

Generally I think it can make sense to do a pdu, hdr and data frame for protocols. However I don't know if it makes sense for quic as there is encryption everywhere?

[suricata-qa]

WARNING:

field	baseline	test	%
	tlpw1_stats_chk
.tcp.rst	103033	126112	122.4%

Pipeline 9026

[catenacyber]

Thanks very much Victor.

I thought frames as PDUs, but they seem rather improved buffers

Generally I think it can make sense to do a pdu, hdr and data frame for protocols. However I don't know if it makes sense for quic as there is encryption everywhere?

So for quic, I think it does not make sense as we want to match on the decrypted data that is not cleartext in the StreamSlice. Do you want to make quic.decrypted_data available to the rule lang ? But then the allocated buffer needs to live after the parsing has been done...

[catenacyber]

Closing as irrelevant