Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SDP: implements sticky buffers v2 #11961

Open
wants to merge 20 commits into
base: master
Choose a base branch
from

Conversation

glongo
Copy link
Contributor

@glongo glongo commented Oct 15, 2024

Make sure these boxes are checked accordingly before submitting your Pull Request -- thank you.

Contribution style:

Our Contribution agreements:

Changes (if applicable):

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

Describe changes:

  • Sticky buffers for SDP have been implemented.
    • The empty check within sticky buffer for optional fields has been removed
  • sdp.media.bandwidth and sdp.media.attribute sticky buffers have not been implemented yet because the media field is a vector of MediaDescription, and both the bandwidth and attribute fields are vectors as well.
    I believe the multi-buffer API cannot handle such a situation.
    If I'm not mistaken, a simple solution could be to "stringify" these fields like this:
"media_description": {
    "bandwidth": "AS:64,AS:65,AS:66",
    "attribute": "sendonly,recvonly"
}
  • Media's encryption key is logged now.
  • Multiple time and repeat_time fields are now parsed correctly

Personal considerations:

  • The sdp.media.* sticky buffers were initially meant to be named sdp.media_descriptions.*, but I realized the names were too long. I wonder if I should rename the media_description field to media for consistency.
  • I don't like the name sdp.media.media; I would prefer to rename it to sdp.media.name, or just sdp.media, and adjust the logged field name if necessary.
  • CI will probably fail due to the changes made to the way the time and repeat_time fields are logged.

SV_BRANCH=OISF/suricata-verify#2092

The encryption key subfield of the media description field is not
logged when it should be.

Ticket OISF#7305
The current parser implementations take a field, such as connection data, and
split it into subfields for a specific structure (e.g., struct ConnectionData).
However, following this approach requires several sticky buffers to match the
whole field, which can make a rule a bit verbose and doesn't offer any advantage
for matching specific parts of a field.

With this patch, a single line is still split into pieces if it makes sense for
parsing purposes, but these pieces are then reassembled into a single string.
This way, only one sticky buffer is needed to match the entire field.

Ticket OISF#7291
As defined in RFC4566, the time and repeat_time fields can be present
multiple times but they are currently parsed only once.

Ticket OISF#7325
This adds a sticky buffer to match the "Session name" field in both
requests and responses.

Ticket OISF#7291
This adds a sticky buffer to match the "Session information" field in
both requests and responses.

Ticket OISF#7291
This adds a sticky buffer to match the "Origin" field in both requests
and responses.

Ticket OISF#7291
This adds a sticky buffer to match the "Uri" field in both requests and
responses.

Ticket OISF#7291
This adds a sticky buffer to match the "Email" field in both requests
and responses.

Ticket OISF#7291
This adds a sticky buffer to match the "Phone number" field in both
requests and responses.

Ticket OISF#7291
This adds a sticky buffer to match the "Connection data" field in both
requests and responses.

Ticket OISF#7291
This adds a sticky (multi) buffer to match the "Bandwidth" field in both
requests and responses.

Ticket OISF#7291
This adds a sticky buffer to match the "Time" field in both requests and
responses.

Ticket OISF#7291
This adds a sticky buffer to match the "Repeat time" field in both
requests and responses.

Ticket OISF#7291
This adds a sticky bufffer to match the "Timezone" field in both
requests and responses.

Ticket OISF#7291
This adds a sticky buffer to match the "Encryption key" field in both
requests and responses.

Ticket OISF#7291
This adds a sticky (multi) buffer to match the "Attribute" field in both
requests and responses.

Ticket OISF#7291
This adds a sticky (multi) buffer to match the "Media" subfield of the
"Media description" field in both requests and responses.

Ticket OISF#7291
This adds a stick (multi) buffer to match the "Session information"
subfield of the "Media description" field in both requests and
responses.

Ticket OISF#7291
This adds a sticky (multi) buffer to match the "Connection data"
subfield of the "Media description" field in both requests and
responses.

Ticket OISF#7291
This adds a sticky (multi) buffer to match the "Encryption key" subfield
of the "Media description" field in both requests and responses.

Ticket OISF#7291
Copy link

codecov bot commented Oct 15, 2024

Codecov Report

Attention: Patch coverage is 92.09756% with 81 lines in your changes missing coverage. Please review.

Project coverage is 82.80%. Comparing base (378f678) to head (b6fe4e7).
Report is 8 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master   #11961      +/-   ##
==========================================
+ Coverage   82.76%   82.80%   +0.03%     
==========================================
  Files         910      911       +1     
  Lines      249014   249922     +908     
==========================================
+ Hits       206105   206942     +837     
- Misses      42909    42980      +71     
Flag Coverage Δ
fuzzcorpus 60.59% <35.95%> (-0.18%) ⬇️
livemode 18.80% <31.43%> (+0.09%) ⬆️
pcap 44.06% <36.14%> (+0.21%) ⬆️
suricata-verify 62.35% <91.74%> (+0.18%) ⬆️
unittests 58.90% <34.73%> (-0.11%) ⬇️

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

@victorjulien
Copy link
Member

Lots of failing jobs. Any idea what is going on?

@glongo
Copy link
Contributor Author

glongo commented Oct 15, 2024

Lots of failing jobs. Any idea what is going on?

Yes, CI is failing because I changed the json schema for the field time and repeat_time and SV test needs to be updated (which I did in OISF/suricata-verify#2092)

See 2b3e0cb

@victorjulien
Copy link
Member

Lots of failing jobs. Any idea what is going on?

Yes, CI is failing because I changed the json schema for the field time and repeat_time and SV test needs to be updated (which I did in OISF/suricata-verify#2092)

See 2b3e0cb

I don't understand. The CI for the PR should pass. If the SV PR is needed for it to pass, we should see a green CI. But we don't, so something is off.

Copy link
Member

@victorjulien victorjulien left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CI is very red.

@inashivb
Copy link
Member

@glongo if you change SV_BRANCH, please tag a team member to rerun the CI checks as they are not auto run.

@glongo
Copy link
Contributor Author

glongo commented Oct 16, 2024

Lots of failing jobs. Any idea what is going on?

Yes, CI is failing because I changed the json schema for the field time and repeat_time and SV test needs to be updated (which I did in OISF/suricata-verify#2092)
See 2b3e0cb

I don't understand. The CI for the PR should pass. If the SV PR is needed for it to pass, we should see a green CI. But we don't, so something is off.

I accidentally used the wrong SV_BRANCH and likely changed it after the CI had already started.

@glongo
Copy link
Contributor Author

glongo commented Oct 16, 2024

CI is very red.

It's green now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants