On Thu, Mar 29, 2018 at 08:39:40AM +0200, Phil Sutter wrote: > On Thu, Mar 29, 2018 at 06:56:08AM +0200, Florian Westphal wrote: > > Phil Sutter <phil@xxxxxx> wrote: > > > > is hard to read. So, lets just add icmp/icmpv6 to > > > > ip/ip6 protocol base so users can just go with > > > > > > > > icmp type destination-unreachable > > > > > > Does this then lead to generating protocol dependency in e.g. inet > > > table? > > > > Whats the expected behaviour there? > > I was just curious. :) > > > Currently you will get a dependency via > > payload_gen_special_dependency(), i.e. icmpv6 in inet will > > not match icmpv6-in-ipv4. > > Sounds good! I think the most intuitive behaviour would be: > > family | rule | effect > --------------------------------------------------------------- > ip | icmp type foo | icmp-in-ipv4 > | icmpv6 type foo | icmpv6-in-ipv4 > --------------------------------------------------------------- > ip6 | icmp type foo | icmp-in-ipv6 > | icmpv6 type foo | icmpv6-in-ipv6 These two above look good to me. > --------------------------------------------------------------- > inet | icmp type foo | icmp-in-ipv4 or icmp-in-ipv6 > | icmpv6 type foo | icmpv6-in-ipv4 or icmpv6-in-ipv4 So you mean, we just look at the transport protocol field? That would simplify things since we would not need dependencies at all. We discussed that we should actually enforce ipv4 if you ask for 'icmp type foo' from inet, otherwise we would just let things like a forged IPv6 header with ICMP go through, which may be a bit counterintuitive to users? I mean, for a tight ruleset from inet chains, users would need to do 'meta protocol ip icmp type foo' to make sure forged packets don't go through. > --------------------------------------------------------------- > > I guess this differs from the current state only in the 'or' part of > inet family, right? Or does nftables reject plain icmp/icmpv6 payload > matches in inet family if l3proto has not been specified? If l3proto is not specified, the idea is to infer it from icmp. We should still allow things like: meta protocol ip6 icmp type foo which is broken right now, since we should allow users to make any arbitrary matching, even if it will be unlikely to see this packet. So if we stick to this path, this needs to be fixed as it is broken right now. Makes sense to you? -- 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
