netstack: allow defaultHandler respond ICMPv4Echo in promiscuous mode #11609
+15
−2
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
The gVisor network stack is extensively employed in user-space tunneling software, often operating in promiscuous mode. In this configuration, the stack directly responds to all ICMPv4 Echo Request packets, irrespective of whether a transport defaultHandler has already processed them. This behavior is often unintended in certain scenarios, as evidenced by issues such as:
In these scenarios, users may prefer to utilize SetTransportProtocolHandler to configure a custom
defaultHandler
for tailored processing of ICMPv4 Echo packets.In issue #8657, @kevinGC proposed a potential solution:
However, this approach appears somewhat aggressive, as it could impair applications that depend on the existing gVisor stack behavior with ICMPv4 protocol handlers, such as runsc itself. These programs would require code adjustments to accommodate this change, as shown below:
This patch introduces an alternative by enabling the stack to refrain from directly responding to ICMPv4 Echo packets delivered locally due to promiscuous mode, thereby allowing the defaultHandler to handle them independently.
This proposal is presented as an initial step for discussion, and insights from experts on potential refinements or superior alternatives are warmly welcomed.
Testing and adjustments for ICMPv6 will be addressed once the approach is finalized.
Patch Details
In ipv4.go:handleValidatedPacket, the packet is evaluated based on
AcquireAssignedAddress
to determine local delivery or forwarding:In promiscuous mode, packets destined for unknown addresses are assigned a temporary address and delivered locally:
By leveraging the
Temporary
field in AddressProperties, we can identify packets delivered locally due to promiscuous mode. A new field,LocalAddressTemporary
, is added toNetworkPacketInfo
to record this status:Finally, in icmp.go:handleICMP, direct replies to such packets are skipped:
Quick Testing
To validate this patch, a simple test program and procedure are provided below:
Test procedure: