On 7/9/15 10:56 PM, Eric W. Biederman wrote:
I have given specific areas of concern, and explained myself and you are
blowing me off.
You have not had answered my question with any additional details or
code references -- ie., a specific example. Asking you for clarification
and details is not blowing you off.
To recap:
Eric: "With respect to sockets there is also the issue that ip addresses
are not per vrf."
David: "IP addresses are per interface and interfaces are uniquely
assigned to a VRF so why do you think IP addresses are not per VRF?"
Eric: "I have read large swaths of the linux networking code over the
years. Further I was thinking more about non-local addresses ip
addresses, but I would not be surprised if there are also issues with
local addresses."
David: "Well, if someone has a specific example I'll take a look."
So, let me try this again: All of the IPv4 and IPv6 addresses I am aware
of are held in structs linked to a specific netdevice. Can you give me a
specific example of what you mean here? I can't respond to your feedback
based on the little information you have given me.
Besides the fragment reassembly and xfrm there are things like the
ineetpeer cache.
noted.
Which means things like packet fragmentation reassembly
can easily do the wrong thing. Similarly things like the xfrm for ipsec
tunnels are not hooked into this mix.
So I really do not see how this VRF/MRF thing as designed can support
general purpose sockets. I am not certain it can correctly support any
kind of socket except perhaps SOCK_RAW.
Sockets bound to the VRF device work properly. Why do you think they won't?
Because there are many locations in the network stack (like fragment
reassembly) that make the assumption that ip addresses are unique and
do not bother looking at network device or anything else. If fragments
manage to come into play I don't expect it would be hard to poision a
connections with fragments from another routing domain with overlapping
ip addresses.
If that is true it is a problem with the networking stack today and is
completely independent of this VRF proposal.
Not at all. It is required functionality for reassembly of ip fragments
when the packets come in via different paths. This is required to
support multi-path ip reception.
This only becomes a bug in the scenario you have proposed.
Can you please point to a specific line in one of these patches that
impacts fragmentation?
This patch -- patch 3 -- adds a VRF driver. It has not mucked with
packets at all.
Patch 4 (again I have a better split in a forthcoming revision) tweaks a
few places in the IPv4 stack with respect to socket lookups (dif
modified) and FIB table lookups (specifying a table to use or tweaking
oif/iif).
Since the VRF device has not touched the packet and does not introduce a
tunnel how has its use/existence impacted fragmentation?
I do plan tests to include ipsec for example and fragmentation; it's a
matter of time. If you have suggestions on a setup/test case I should
include please let me know.
David
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
