Re: Netfilter: match "tcp option" with the same type present multiple times

[Matthieu Baerts <matttbe@kernel.org>]

Hi Pablo,

Thank you for your reply!

On 07/10/2026 01:29, Pablo Neira Ayuso wrote:
> On Wed, Sep 30, 2026 at 08:33:36PM +0200, Matthieu Baerts wrote:
>> On 29/09/2026 14:03, Pablo Neira Ayuso wrote:
>>> On Tue, Sep 29, 2026 at 12:40:47PM +0200, Matthieu Baerts wrote:
>>>> On 29/09/2026 12:00, Pablo Neira Ayuso wrote:
>>>>> On Tue, Sep 29, 2026 at 11:21:15AM +0200, Matthieu Baerts wrote:

(...)

>> If someone gives ...
>>
>>   tcp option mptcp subtype { mp-capable, mp-join, remove-addr } drop
>>
>> ... a bitmap could be used, but then that's specific to MPTCP I suppose.
> 
> I think this makes sense from user perspective.
> 
> The nft_exthdr expression needs iterate over the whole list of tcp
> options, then if type is 30, make a set lookup to check if the subtype
> value is in the set.
> 
> Something like:
> 
>  - loop
>  |  r1 <- exthdr     [ if no more tcp options, break loop ]
>  |  r2 <- lookup(r1) [ if found, break loop ]
> 
> but exthdr need to be taugh to resume from the last visited tcp
> option. A new loop expression would wrap these two exthdr and lookup
> expression (similar to nft_inner) and store the iteration context (ie.
> last visited tcp option to continue from there).
> 
> exthdr tcp option support needs advertise a new NFT_EXPR_LOOP flag, so
> it can be used with within this new nft_loop expression.

Yes, this or Fernando's idea (BTW, thank you for looking at that!). Both
will need to expose a new capability to the userspace from what I
understand, so any of them are fine for me.

> Another question: Would you still like to validate that DSS comes
> before REMOVE_ADDR?

I don't think that's needed: the RFC doesn't impose an order nor a
specific combination. When multiple MPTCP options are used, they are
notifying two different things.

If people are interested in validating that option A comes before option
B, that's certainly because they are trying to find a specific pattern
-- e.g. to identify a specific stack or kernel version -- not to
identify packets of a certain protocol. For them, they can use other
techniques, but I don't think we need to increase the complexity to
support that case. (At least for MPTCP.)

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.