Re: [lwip-devel] Packet processing stack hooks

[Bogad, Katharina]

Hi Eric,

> Question: why not leave LWIP_HOOK_IP4_INPUT as it is and 
> just add LWIP_HOOK_IP4_PREROUTING and your other hooks? 
> Just issue a warning saying not to use it if you use firewall code. 
> I think it's a good idea to leave existing code functioning as before.

My most glaring problem with the current placement of the hook is that is 
simply in the wrong place in the processing stack. Compared to other IP stacks, 
input always means "packets destined for local processing only". The current 
placement leads to a situation where the input hook receives more packets than 
I would expect. Maybe I am alone in this feeling; and I don't know the 
development history here, but I if I had to guess I'd suspect that the hook was 
there before forwarding was a thing.

Be that as it may, one possible solution is to gate all new hooks behind an 
#ifdef. Something like LWIP_ADVANCED_FILTER_HOOKS; which, if enabled would move 
the input hook and add all other hooks.
Perspectively, if consensus is that the hook should be moved, at some point in 
the future this flag could then default to on, and at an even later date, be 
removed again.

> Also, make sure to add an LWIP_FIREWALL option (or something 
> similar, I would prefer LWIP_NETFILTER myself since it's useful for
> things other than firewalls) and make sure that all firewall code is
> excluded when not defined.

My firewalling is actually very low-tech and consists of a grammar that parses 
a subset of nftables configuration which then generates C code that uses the 
hooks to filter [0]. I'm not sure if I can open source this, but in any case, 
it'd probably be a completely separate project---unless you'd want a bunch of 
python in the LwIP repo and my company agrees to do that [1]. 

All I need from LwIP are hooks to process chains from, and the runtime impact 
if the hooks are not set is exactly zero. This also means no dynamic firewall 
configuration (beyond enabling, disabling and swapping chains at runtime), but 
this is a concise design decision: any non-trivial dynamic firewalling 
inherently results in building a virtual machine for packet processing, which 
would not only be totally overkill for a stack that claims to be light weight 
but also probably won't fit on microcontrollers.

> Last but not least: any plans to add IPv6 support? 
> I myself would be very interested in that. I wouldn't 
> mind contributing as well, if needed.

I haven't looked into the IPv6 side of things as it is currently out of scope 
for my local project, but I will do that before sending patches. Obviously, if 
I add hooks to the IPv4 side of things, I'll also add filter hooks to the rest 
of LwIP. I have also now put "make sure that the filter hooks are consistent" 
on my to do list. I'd like to avoid a situation where e.g. LWIP_HOOK_IP6_INPUT 
has different semantics than the IP4 version.

I also have a packet flow diagram I'd like to contribute at some point 
detailing which hook lives where and how packets are flowing through the stack, 
but again, company red tape must be navigated first -- sorry.

In any case, IPv6 support then only depends on if the necessary grammar is 
implemented in the code generator. In my experience, this is doable in a day or 
so, depending on how much of the nftables grammar you choose to support.

I hope this answers your questions!

Regards,
Katharina

[0]: you could probably do the same with a bunch of macro magic and hand 
written C, but I wholeheartedly admit that I'm not 1337 enough to do that 
right; also there are other factors favoring the code generation solution I 
can't go into publicly.

[1]: I'm not even totally convinced that this should be part of LwIP. A few 
years ago I might have placed this in lwip-contrib, but since this has been 
merged into the base tree, I'm not sure where to put it. Possibly a new module 
lwip-firewall?

---
Katharina Bogad
Secure Operating Systems

Fraunhofer Institute AISEC
Lichtenbergstr. 11, 85748 Garching near Munich, Germany
tel:+49-89-3229986-1020
mailto:katharina.bogad@aisec.fraunhofer.de
https://www.aisec.fraunhofer.de

-----Ursprüngliche Nachricht-----
Von: Eric Koldeweij <eric@no-sense.net> 
Gesendet: Donnerstag, 30. Januar 2025 08:44
An: Bogad, Katharina <katharina.bogad@aisec.fraunhofer.de>
Betreff: Re: [lwip-devel] Packet processing stack hooks

Katharina,

I think it's a very good idea and it would be a very useful addition to LWIP. 
Just a few thoughts and questions:

Question: why not leave LWIP_HOOK_IP4_INPUT as it is and just add 
LWIP_HOOK_IP4_PREROUTING and your other hooks? Just issue a warning saying not 
to use it if you use firewall code. I think it's a good idea to leave existing 
code functioning as before.

Also, make sure to add an LWIP_FIREWALL option (or something similar, I would 
prefer LWIP_NETFILTER myself since it's useful for things other than firewalls) 
and make sure that all firewall code is excluded when not defined.

Last but not least: any plans to add IPv6 support? I myself would be very 
interested in that. I wouldn't mind contributing as well, if needed.

Regards,

Eric.


Just a question:

On 1/29/25 12:49, Bogad, Katharina wrote:
> Hi list,
>
> I am currently working on a stateless firewall implementation on top of LwIP.
>
> Similar to what is described in Task #16603 [0], I also found myself 
> needing to implement more hooks to do this, namely:
>
> LWIP_HOOK_IP4_FORWARD in the routing path of ipv4 in 
> src/core/ipv4/ip4.c LWIP_HOOK_IP4_OUTPUT  in the output path of ipv4 
> in src/core/ipv4/ip4.c LWIP_HOOK_ETH_FORWARD in src/netif/bridgeif.c
>
> While implementing these was essentially straight forward, I also 
> noticed that LWIP_HOOK_IP4_INPUT should probably be renamed to 
> LWIP_HOOK_IP4_PREROUTING.
> Currently, all packets, including those that will not end up being 
> processed by the host, will trigger LWIP_HOOK_IP4_INPUT which makes 
> the firewall code much more complicated in needing to distinguish between 
> whether a packet will end up being routed or not.
>
> If renamed, we could define a new LWIP_HOOK_IP4_INPUT that actually 
> lives in the input path, post routing decision. I'd probably place 
> this right before line 712 where the path into the upper layers starts.
>
> However, this would introduce a breaking change in semantics: some 
> packets that are currently passed to LWIP_HOOK_IP4_INPUT will not arrive 
> there post-change.
> As far as I understand this will include at least:
>
> - IGMP router alert messages if LWIP_IGMP is defined,
> - fragmented packets if IP_REASSEMBLY == 0,
> - packets with invalid source,
> - DHCP packets if IP_ACCEPT_LINK_LAYER_ADDRESSING is defined,
> - Packets with invalid checksum,
> - packets which fail to pass header checks.
>
> I plan to contribute my patches once I am finished and have 
> successfully navigated my company's red tape. Therefore, it'd be great 
> to have some feedback on this, and also whether you have alternative 
> ideas on how to name the conflicting hooks. Ideally, I would like to 
> not re-use the existing hook name (such that it can be either aliased or emit 
> a build error), but so far, I haven't managed to come up with a good name 
> replacement.
>
> Thank you in advance!
>
> Regards,
> Katharina Bogad
>
> [0]: https://savannah.nongnu.org/task/?16603
>
> ---
> Katharina Bogad
> Secure Operating Systems
>
> Fraunhofer Institute AISEC
> Lichtenbergstr. 11, 85748 Garching near Munich, Germany
> tel:+49-89-3229986-1020
> mailto:katharina.bogad@aisec.fraunhofer.de
> https://www.aisec.fraunhofer.de
>
>
> _______________________________________________
> lwip-devel mailing list
> lwip-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-devel