Hi Pablo, Could we make things clear about this discussion? I think we have some misunderstandings, and I am certainly unaware of some concerns you are trying to enforce. How about discussing them one by one? = Detect or specify address family in tproxy command = I submitted a patch to detect the address family in evaluate_addr in case the table is INET and print an error if table is not IPV4, IPV6 or INET. Do you disagree with this solution in general or only in case of tproxy? In general, I think it is better to have explicit checks here as the error message generated by the current solution may be misleading in a situation like mine (basically every time trying ot evaluate an ipv4 address to a rule in inet table). Regarding family detection, you say family should be specified in the rule in case the table is inet. Do you say this because of UX or technical reasons? I think, the technical part can easily be covered (as I do in stmt_evaluate_tproxy) with setting a family attribute after a successfull evaluation and sending it to the kernel. As a consequence the family of the rule match is not ambiguous technically. The UX part is more subjective by nature. In my opinion, if a user specifies an IPv4 address he/she expects that it will match IPv4 for packets and the same with IPv6. Therefor my intention is to leave explicit specification out. Do you think it is not this obvious? In tproxy case, the kernel will receive a family attribute with the value of IPV4 or IPV6 in case an address is specified so it will not be necessary to generate ip dependency to an ipv6 rule (although I don't think I generate any dependency explicitly) and this information is used for matching, so kernel has sufficient information of the family of the role. = Dependency = You mentioned some kind of dependency in some of your emails, but I don't know what you think of. Could you describe what a dependency is in this context? Is it in user- or kernelspace? For ip/ip6/inet tables isn't that default to process *only* packets with IPv4 or IPv6 header? If it is default, I don't understand why any other dependency should be generated, I can just check the family of the packet against the family of the, can't I? You bring bridge/netdev as examples, but tproxy is not supported in these tables (refused from nft_tproxy_init in the kernel), so I don't see why we should consider them. Regarding the address family detection, the evaluate_addr function only cares about L3 addresses so bridge/netdev seems to be irrelevant here, too. = Kernel, address family check = You had a comment in an email which I still don't really understand. I think your kernel patch is also lacking this, and a custom userspace program may add a tproxy expression to deal with IPV6 traffic, which may result in crashing the kernel. Do you mean that a program can add an expression with an IPv6 address with a family of NFPROTO_IPV4? Then I suppose the nft_validate_register_load should return error in the init function, shouldn't it? Do you mean that address may be specified whereas tproxy family is left on default? Yes, this was possible, I added a check for this in my v2 patch. Do you mean, that an IPv6 packet can be passed to the IPv4 evaluation function? Your code snippet seems to be related to this. It examined if the L3 header is IP header, but it really seems to be the same as what I do (at least in ip/ip6/inet tables). I compare the packet's family (from nft_pf()) and the tproxy family, and I pass the packet to the v4 or v6 eval function respectively. The L3 header should be present so this should work securely with such a strict init function. If none of these, could you please define the scenario with more details? In which point do you think my code is voulnerable and what is a scenario? I hope I grabbed the important points to make this situation clear. It would be nice if you could reply to all these notes and questions as I am confused about what we disagree on right now. Regards, Máté -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
