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.

Sign up for GitHub

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

Jump to bottom

Proper L4 Tunneling should include IP + L4 headers #51

Open
t-lin opened this issue Jun 24, 2020 · 0 comments
Open

Proper L4 Tunneling should include IP + L4 headers #51

t-lin opened this issue Jun 24, 2020 · 0 comments
Labels
enhancement New feature or request Low Priority question Further information is requested

Comments

@t-lin
Copy link
Member

t-lin commented Jun 24, 2020

Right now the L4 proxy really only transfers the UDP/TCP payloads, and does not include the L4 headers. Thus it functions more like an application-level gateway.

Protocols that may include the original L3/L4 information in the application layer payload may fail. The obvious case is the authentication header in IPsec (see RFC 2402). RFC 3027 gives a pretty decent overview of some other problems when network addresses (and/or ports) are modified.

Will need to devise a better way to do the proxying in the future. For now, it seems to work with basic single-connection traffic that doesn't need a secondary channel/connection (e.g. works for SSH and HTTP, but difficult to get it to work with HTTPS).
@t-lin t-lin added enhancement New feature or request help wanted Extra attention is needed question Further information is requested labels Jun 24, 2020
@t-lin t-lin added Low Priority and removed help wanted Extra attention is needed labels Jun 24, 2020
t-lin added a commit that referenced this issue Jun 30, 2020
@t-lin
Implemented support for TCP service chaining
1daa427 
  - Like the UDP version, the traffic is passed back along the path of
    VNFs in reverse order, but does not re-enter the VNFs.
  - Barring other improvements (erroneous error messages, stateful
    close, passing of errors back through the chain, etc.), this
    should commit should resolve the TCP/UDP case for #50.
  - As noted in #51, however, we currently pass payloads without
    headers, and proper tunneling that includes headers should be
    addressed within that issue.
t-lin added a commit that referenced this issue Jun 30, 2020
@t-lin
Implemented support for TCP service chaining
6b8644b 
  - Like the UDP version, the traffic is passed back along the path of
    VNFs in reverse order, but does not re-enter the VNFs.
  - Barring other improvements (erroneous error messages, stateful
    close, passing of errors back through the chain, etc.), this
    should commit should resolve the TCP/UDP case for #50.
  - As noted in #51, however, we currently pass payloads without
    headers, and proper tunneling that includes headers should be
    addressed within that issue.
t-lin added a commit that referenced this issue Jul 1, 2020
@t-lin
Implemented support for TCP service chaining
9014007 
  - Like the UDP version, the traffic is passed back along the path of
    VNFs in reverse order, but does not re-enter the VNFs.
  - Barring other improvements (erroneous error messages, stateful
    close, passing of errors back through the chain, etc.), this
    should commit should resolve the TCP/UDP case for #50.
  - As noted in #51, however, we currently pass payloads without
    headers, and proper tunneling that includes headers should be
    addressed within that issue.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request Low Priority question Further information is requested
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@t-lin