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 ARP spoofing guard for host gateway port #210

Merged
merged 1 commit into from
Dec 12, 2019

Conversation

wenyingd
Copy link
Contributor

@wenyingd wenyingd commented Dec 9, 2019

Add ARP spoof guard flow entry after host gateway interface is created.

Fixes #200

@antrea-bot
Copy link
Collaborator

Thanks for your PR.
Unit tests and code linters are run automatically every time the PR is updated.
E2e tests can only be triggered by a member of the vmware-tanzu organization. Regular contributors to the project should join the org.

The following commands are available:

  • /test-e2e: to trigger e2e tests. This command can only be run by members of the vmware-tanzu organization
  • /skip-e2e: to skip e2e tests. This command can only be run by members of the vmware-tanzu organization

Add ARP spoof guard flow entry after host gateway interface is created.
@wenyingd
Copy link
Contributor Author

wenyingd commented Dec 9, 2019

/test-e2e

@jianjuns
Copy link
Contributor

jianjuns commented Dec 9, 2019

I personally feel no need to restrict the default namespace traffic. Anyway, you could not control all interfaces on the node.

@wenyingd
Copy link
Contributor Author

@antoninbas and I have an offline discussion about it, and we thought if the ARP reply sent from gw0 is using a fake MAC, later Openflow entries might not work, especially for the traffic that needs to be forwarded by host gateway. Technically, the MAC/IP address could be changed when the packets enters OVS from gw0 interface.

@jianjuns
Copy link
Contributor

You see if a Pod could send raw packets from a host interface, it could do many attacks, like it could even send VXLAN packets from a physical interface. And such containers should not be viewed as an application container, but more like a local daemon like antrea-agent.

@antoninbas
Copy link
Contributor

@jianjuns I agree about your statement. However, ARP spoofing is pretty bad IMO since it can mess up the networking for other Pods and that change actually prevents that it seems. So unless there is a downside to this change I am not seeing, I suggest we merge it.

@jianjuns
Copy link
Contributor

@antoninbas @wenyingd : I just do not like to add unnecessary flows and do not like to restrict host interface/traffic. But for this one I do not have a strong opinion. As you said there is no hard either (not sure if there could be cases that we want to manually bind another IP to the gateway interface though, of course for testing purposes only).

@wenyingd wenyingd merged commit ff39871 into antrea-io:master Dec 12, 2019
@wenyingd wenyingd deleted the issue200 branch December 12, 2019 02:21
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

Successfully merging this pull request may close these issues.

No ARP spoof guard for packets from host gateway
5 participants