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

[Question] Pcap-analyzer for Voip and VoLTE pcaps #1

Open
Jgerardopine opened this issue May 28, 2020 · 4 comments
Open

[Question] Pcap-analyzer for Voip and VoLTE pcaps #1

Jgerardopine opened this issue May 28, 2020 · 4 comments

Comments

@Jgerardopine
Copy link

Hi,
Based on the answer on Can't build pcap-parser #5 " Depending on what you want to do, I can provide some hints on what is better to choose": I am looking to work on pcaps contianing protocols such as GTP, RTP, RTCP, SIP, S1AP, DIAMETER and parse specific attributes within the applicaiton layer, some attributes from FRAME and Transport layers as well but mainly on application layers.
Is this something currenlty possible? Any hint or recommendation on how to use it for Application layers?

@chifflier
Copy link
Member

Hi,

I do not know all these protocols well, so my answer may miss some elements.

From what I understand, it may not very very easy. The main reasons are:

  • These protocols are currently not supported, and we'll need parsers (though I have a diameter parser somewhere on my disk that I have not yet published) to add them. I have not checked if such parsers already exist
  • Passing info from a layer to another is currently not standardized

In the current state, what can be done is add a plugin to the network or transport layers (or both), and call decoding functions recursively. You'll be able to call libpcap-analyzer functions if you need to decode known protocols like UDP or TCP, and would also benefit from all the infrastructure of decoding/plugins/etc.

To keep information from different layers is a different thing. Currently, plugins store hashmaps of whatever they want, the key usually being the identifier of the flow. I'm still trying to think of a global/easier solution, but Rust makes it quite hard due to borrowing/ownership issues :/

@chifflier
Copy link
Member

Additional thoughts:
Applications layers can be added in their own plugin (see the tls plugin for a standaline example), or in the rusticata plugin.

Having a standalone plugin is better if you'll use your own parsers, and already know how to identify / track the protocol. Rusticata is useful if you want to use the existing probing mechanisms, so I think it would not be the case here. You only have to link your plugin (like the explugin-example crate) in pcap-analyzer.

Note that even if you add them in the rusticata plugin, it is not mandatory to have them in the rusticata crate, they only have to share the same interface.

@Jgerardopine
Copy link
Author

Not sure what do you mean by existing probing systems? We extract this informaiton from Telco grade probes and the dissectors exist on tshark/wireshark so there is no problem on supporting decding them.
I'll check the plugins and give it a shot.

Thanks for the help, I'll let you know the outcome.

@chifflier
Copy link
Member

What is called probing in PAL is the protocol identification functions and logic, to be able to recognize for ex. TLS independently of the port number. I'm not sure you need it here.

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

No branches or pull requests

2 participants