Noel Kuntze <noel@xxxxxxxxxxxxxxxxx> wrote: > On 18.10.2016 10:59, Florian Westphal wrote: > > Noel Kuntze <noel@xxxxxxxxxxxxxxxxx> wrote: > >> > On 17.10.2016 22:27, Pablo Neira Ayuso wrote: > > [..] > > > >>> > > Allowing to match if the packet is protected/unprotected in a > >>> > > true/false fashion. > >> > > >> > Well, I am active in the strongSwan community, so I believe I've seen all the > >> > use cases there are and I've seen uses of every option, except "--next" and "--strict". > >> > But I think there are probably use cases where they are used as well. > > Ok. I still believe that 'meta secpath' makes sense as a more simple > > alternative, I think most users are just interested in 'was this packet > > ipsec protected' rather than doing the full policy option dance. > > > > Wrt. -m policy in nftables, we have two different cases: > > > > 1. Check if a given daddr/saddr/spi etc is listed in *any* of the policies. > > 2. Check if a given policy contains the exact spi/daddr/saddr. > > > > As first rfc, what about the below syntax? > > > > It adds one expression (to load a given policy element into a register) > > and one statement (to search policies for a given number/address). > > > > add rule filter input xfrm policy direction original 0 spi eq 1 > > > > would take input policies, grab first one (policy[0]), get its spi and > > place it into a register (i.e., the 'eq 1' is not part of the xfrm > > expression, only 'spi' is passed as key so we know what to look for). > > > > Chaining these would allow the strict mode matching, but as you might > > imagine it would be quite bloated to do exact matching :-/ > > > > Statement would look like this: > > add rule filter input xfrm policy direction original spi 1 > > > > ... it would search all input policies for spi 1. > > (i.e., 1 is passed as immediate value to the xfrm expression). > > > > Thoughts? > > Does anyone see a -m policy case that we could not cover with this? > > [SNIP] > > *if* we can have all the options and data we can get with -m policy > (except --strict and --next, obviously) in nftables, then yes, > I think all use cases would be covered. > > > 1. Check if a given daddr/saddr/spi etc is listed in *any* of the policies. > Any in the SPD or any that matched? Policies in the secpath or xfrm dst entry. http://lxr.free-electrons.com/source/net/netfilter/xt_policy.c#L55 Searching SPD doesn't seem useful to me unless we want to do xfrm encap/decap from nft itself. > > 2. Check if a given policy contains the exact spi/daddr/saddr. > The exact SPI/daddr/saddr of what? Of a set policy match (whatever that might be) > in nftables? Same as above, except that it would check sp->xvec[X], for a fixed (user defined) value of X, rather then searching all of sp->xvec[]. Or, putting it differently, in 1) user providides data (ip address, spi, ...) and sp->xvec is the haystack we will search in. I expect most users and use cases are covered by this, rather than 2). For 2), user gives a policy index and tells us if they want saddr, daddr, spi or reqid and we will then copy it to a register. (Where another nft expression, e.g. cmp, can evaluate it) So 2) is only needed when exact matching of the entire policies is requested (--strict) mode. If you think we can go without strict, then only 1) is needed. The drawback is that 1) is very un-nftables like, but alas, I don't think we can avoid it. -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
