-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
base: master
Are you sure you want to change the base?
Conversation
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
Codecov ReportAttention: Patch coverage is
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
Flags with carried forward coverage won't be shown. Click here to find out more. |
Lots of failing jobs. Any idea what is going on? |
Yes, CI is failing because I changed the json schema for the field 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. |
There was a problem hiding this 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.
@glongo if you change |
I accidentally used the wrong SV_BRANCH and likely changed it after the CI had already started. |
It's green now |
Make sure these boxes are checked accordingly before submitting your Pull Request -- thank you.
Contribution style:
https://docs.suricata.io/en/latest/devguide/contributing/contribution-process.html
Our Contribution agreements:
https://suricata.io/about/contribution-agreement/ (note: this is only required once)
Changes (if applicable):
(including schema descriptions)
https://redmine.openinfosecfoundation.org/projects/suricata/issues
Link to ticket: https://redmine.openinfosecfoundation.org/issues/
Describe changes:
sdp.media.bandwidth
andsdp.media.attribute
sticky buffers have not been implemented yet because the media field is a vector ofMediaDescription
, and both thebandwidth
andattribute
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:
time
andrepeat_time
fields are now parsed correctlyPersonal considerations:
sdp.media.*
sticky buffers were initially meant to be namedsdp.media_descriptions.*
, but I realized the names were too long. I wonder if I should rename themedia_description
field tomedia
for consistency.sdp.media.media
; I would prefer to rename it tosdp.media.name
, or justsdp.media
, and adjust the logged field name if necessary.SV_BRANCH=OISF/suricata-verify#2092