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

Add MPTCP support #2068

Open
1 of 4 tasks
cdelzotti opened this issue Aug 14, 2022 · 4 comments
Open
1 of 4 tasks

Add MPTCP support #2068

cdelzotti opened this issue Aug 14, 2022 · 4 comments

Comments

@cdelzotti
Copy link
Contributor

cdelzotti commented Aug 14, 2022

Prerequisites

  • This issue is an EPIC issue (add label: EPIC).
  • This issue is an EPIC TASK (add issue to EPIC description).

Select one OR another:

  • I'll create a PR to implement this feature (assign to yourself).
  • Someone else should implement this (describe it well).

Feature description

When tracing net_packet events, Tracee already parses a bunch of metadata (IP source/destination, TCP ports, etc). I thought Tracee could also parse Multipath TCP information (DSS, Data Sequence, etc) as MPTCP is a part of the Linux Kernel since version 5.6.

If you think it's a good idea, I can take care of the implementation.

Additional Information (feature drawings, files, logs, etc)

For further details about MPTCP : https://www.rfc-editor.org/rfc/rfc8684

@rafaeldtinoco
Copy link
Contributor

Hello @cdelzotti, we're changing the way we capture network packages/events in tracee (very soon) and I believe we won't need to deal with physical layer details such as bonding/mptcp. I'll have this opened to make sure and close it once we get the code merged.

@cdelzotti
Copy link
Contributor Author

Hm, what do you mean by physical layer details ? From what I understood Multipath TCP is now implemented within the Linux Kernel to provide MPTCP directly from network edges, isn't it ?

@rafaeldtinoco
Copy link
Contributor

rafaeldtinoco commented Aug 16, 2022

@cdelzotti Sorry, I mixed concepts (bonding/ether-channel) with MPTCP (multiple flows/windows same socket). We're current replacing our network/capturing code and things will be more clear once we have finished it.

By a quick read of THIS and THIS, I would say, as long as the different TCP flows contexts are obtainable from the places we're tracing (eBPF program attachpoints), I would be okay as long as we had a very good usecase for it.

Isn't MPTCP still a corner case nowadays ? I would love to know if MPTCP adoption is higher than using RoCE + IB, for example (and things like that).

Still, lets wait for the new netcode to be merged (0.9.0 release) and then we can check if this is something we want to do (and discuss how if it is).

@cdelzotti
Copy link
Contributor Author

For the usecase matter, they're currently implementing MPTCP within basic tools such as curl or openssh : https://github.com/mptcp-apps . And iperf might have MPTCP support some day (Even if this PR seems to be hanging there for a while now) : esnet/iperf#1166 . But anyway, as it seems that MPTCP can be used with a simple socket configuration (https://lwn.net/Articles/791376/), I thought it might be relevant to have Tracee parsing MPTCP metadata too.

@rafaeldtinoco rafaeldtinoco added this to the v0.9.0-rc1 milestone Sep 6, 2022
@rafaeldtinoco rafaeldtinoco self-assigned this Sep 6, 2022
@yanivagman yanivagman modified the milestones: v0.9.0-rc1, v.0.10.0 Sep 20, 2022
@yanivagman yanivagman removed this from the v0.10.0 milestone Nov 3, 2022
@yanivagman yanivagman changed the title [FEAT] Add MPTCP support Add MPTCP support Jan 31, 2023
@rafaeldtinoco rafaeldtinoco removed their assignment Feb 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants