Re: [lwip-users] How to limit the UDP Rx packet size to avoid big RAM allocations

[R. Diez]

> I found it awkward to answer, because I did not get
> any e-mails from the mailing list on this subject.
> I had to manually check the mailing list archive to see your messages.

Regarding my previous comment above, I wonder if you could change the 
way you send e-mails, so that I do get direct e-mails too, like on most 
other mailing lists.


> That's why we have IP_REASS_MAX_PBUFS.

That does not really help, because it is a counter, and not a limit on 
the number of allocated bytes. That distinction is important in my 
resource-constrained environment.


> Yes. The MTU has nothing to do with the size of
> the packets you want to receive. That's why we have
> fragmentation and reassembly.

There is a relation. Nobody sends huge UDP packets, because they tend to 
get dropped. Nobody will send TCP packets that are 10 times the size of 
the MTU, if only for performance reasons. My device advertises a much 
smaller MSS anyway (well, I hope lwIP does that according to TCP_MSS. I 
am no expert).

TCP/IP does not enforce hard limits on the packet sizes, but there are 
limits implemented everywhere on the Internet. A limit like 
MAX_REASSEMBLED_PACKET_SIZE is probably a reasonable thing to do for 
small device with fixed, defined protocols.

I was only suggesting that, if the MTU is set to 1500, it would not make 
sense in real life to allow packets 5 times that size, because such big 
packets would require at least 5 fragments, which is too high for my 
little device.


> ... however, it does *not* harden your system against
> the attack you described:
> [...]
> Maybe we could add the reassembly queues to this freeing hook...

With such a MAX_REASSEMBLED_PACKET_SIZE constant, we would cover one 
attack vector. With the improvement you suggested, we could cover 
another one. So both look applicable.

Is that right? Or do you think there are better ways? Or does nothing 
really help on small devices?

Regards,
  rdiez