Constraints on nft expressions and statements in inet ingress chains

Constraints on nft expressions and statements in inet ingress chains

[Frank Myhr]

Hi,

Since nftables 0.9.7 and kernel 5.10 we have inet ingress chains. It's 
great to now be able to share sets and maps among ingress and other inet 
chains!

I'm wondering about constraints on nft expressions and statements that 
can be used in inet ingress chains?

Some clearly make no sense, like:
- anything involving an output interface
- anything related to conntrack (I think)
- packet mark (I think)

Not sure about:
- reject statement (pretty sure not)
- ah & esp header expressions?
- raw payload expression?
- extension header expressions?

Seem to work, but are they a good idea this early in processing?:
- tcp header & udp header expressions? If IP datagrams are fragmented, 
these matches will miss all but first fragment, correct? (Since 
defragmentation doesn't happen until prerouting?)

My general impression is that inet ingress filtering on L3 IPv4 and IPv6 
header expressions like ip saddr, ip daddr is okay, but trying to reach 
into L4 so early will be problematic...

Thanks for your comments / correction / clarification!

Thanks,
Frank

Re: Constraints on nft expressions and statements in inet ingress chains

[Florian Westphal]

Frank Myhr <fmyhr@fhmtech.com> wrote:
> 
> Some clearly make no sense, like:
> - anything involving an output interface

yes.

> - anything related to conntrack (I think)

Depends, conntrack info may be present for loopback case.

> - packet mark (I think)

Will be present for loopback and it can be set/assigned.

> Not sure about:
> - reject statement (pretty sure not)

Should work in recent kernels.

> - ah & esp header expressions?

Why would that not worl?  This is just like tcp/udp header access.

> - raw payload expression?

Same.

> - extension header expressions?

Same.

> Seem to work, but are they a good idea this early in processing?:
> - tcp header & udp header expressions? If IP datagrams are fragmented, these
> matches will miss all but first fragment, correct? (Since defragmentation
> doesn't happen until prerouting?)

Yes, access to l4 header will not work for subsequent fragments.

> My general impression is that inet ingress filtering on L3 IPv4 and IPv6
> header expressions like ip saddr, ip daddr is okay, but trying to reach into
> L4 so early will be problematic...

Yes, it might not work in fragmentation case.

Re: Constraints on nft expressions and statements in inet ingress chains

[Frank Myhr]

On 2021/02/08 11:32, Florian Westphal wrote:
>> - reject statement
> Should work in recent kernels.
 >
> ... >> - packet mark
> Will be present for loopback and it can be set/assigned.
 >
 > ...
> conntrack info may be present for loopback case.
> 
 > ...
> access to l4 header will not work for subsequent fragments.

Thanks, Florian! The above is very good to know while working on my 
rulesets.

Best regards,
Frank