Re: [RFC net-next 3/6] net: Introduce VRF device driver - v2

[David Ahern <dsa@cumulusnetworks.com>]

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