[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] How to limit the UDP Rx packet size to avoid big RAM al
From: |
R. Diez |
Subject: |
Re: [lwip-users] How to limit the UDP Rx packet size to avoid big RAM allocations |
Date: |
Wed, 27 Jun 2018 09:39:30 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 |
> 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