lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] Packet processing stack hooks


From: Bogad, Katharina
Subject: [lwip-devel] Packet processing stack hooks
Date: Wed, 29 Jan 2025 11:49:28 +0000

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]