Re: [lwip-users] altcp_tls_mbedtls

[Giuseppe Modugno]

Il 26/02/2019 09:58, Simon Goldschmidt ha scritto:
> Giuseppe Modugno wrote:
> > An: address@hidden
> > Betreff: Re: [lwip-users] altcp_tls_mbedtls
> >
> > Il 25/02/2019 20:19, address@hidden ha scritto:
> > > Am 22.02.2019 um 10:24 schrieb Giuseppe Modugno:
> > > > Il 22/02/2019 09:43, Simon Goldschmidt ha scritto:
> > > [snip]
> > >
> > > > > > Is this warning correct? I think TCP_WND should be compared with
> > > > > > MBEDTLS_SSL_IN_CONTENT_LEN or MBEDTLS_SSL_OUT_CONTENT_LEN or the
> > > > > > maximum
> > > > > > of them (of course, I hope to compare it with OUT buffer only, because
> > > > > > it is smaller).
> > > > > I think you're right: this should compare to the IN buffer. No that it
> > > > > would help you here... :-)
> > > > I'm not an expert here, so my question could be very stupid. TCP_WND is
> > > > the TCP window that is used to avoid continuous ack for small data. The
> > > > transmitter sends data filling the window and then waits for the ack.
> > > TCP_WND is what we announce to the remote host to be able to buffer
> > > for RX.
> > >
> > > For TX, what we buffer is the minimum of what the remote host tells us
> > > to be able to buffer and the memory we have/allow (both available heap
> > > memory and the limitation defines SND_BUF and SND_QUEUE_LEN).
> > Ok, but I couldn't understand the relation between lwip receiving window
> > and TLS incoming buffer. If MBEDTLS_SSL_IN_CONTENT_LEN is 16kB, should I
> > need a TCP_WND at least 16kB, for a total of 32kB of memory only to
> > handle incoming TLS traffic?
> No. TCP_WND is not something you have allocated. It's the amount of data
> the remote host can send before we reopen the window.
>
> In the altcp TLS case, the data is received and ACKed, then the TLS
> adaption layer passes it into mbedtls and frees the buffer. However, the
> window update is sent by the application code that is TLS-agnostic. So
> the window update is only sent after the block has been decrypted.

Could you point me to the code that reopen the window after the block 
has been decrypted? I couldn't find it, my shame.

Isn't possible to reopen the window (call tcp_recved) even when a 
partial TLS block is received? I couldn't understand why lwip needs to 
reopen the window only when an entire block is received (and decrypted 
by mbedTLS).
Suppose 1kB of a 16kB encrypted block is received, altcp_tls_mbedtls 
pass the data to the application mbedTLS that copy them in its buffer, 
then frees the received pbufs. Now we can reopen the window. What's 
wrong with this approach that can keep TCP_WND small?

> And
> since such a block may be up to 16 kByte, the tcp window has to be at
> least that big, too, or you can get a deadlock.
>
> > Suppose I have a TCP_WND of only 2kB and incoming TLS buffer of 16kB.
> > The TLS transmitter could send maximum 2kB of data that are buffered in
> > the lwip receiving window. lwip calls altcp_recv(), so
> > altcp_mbedtls_lower_recv() with received data (2kB maybe segmented in
> > small pbufs and pbuf chains).
> >
> > I can't follow the code, but I expect those data are immediately passed
> > to mbedTLS library that should copy those data to its 16kB incoming
> > buffer, freeing receiving window. I think the lwip TCP receiving window
> > could be smaller than mbedTLS incoming data buffer.
> To make the receiving window smaller, you'd have to change the code.
> However, you would gain nothing: TCP_WND is *not* a buffer. The actual
> buffer is in mbedtls and you can't shrink that. TCP_WND just describes
> this behaviour.

TCP_WND isn't a buffer, however I need to reserve a sufficiently sized 
memory pools (I'm using memory pools for pbufs with MEMP_MEM_MALLOC=0). 
And memory pools are statically allocated memory, so I end up with 16kB 
allocated buffer for mbedTLS and 16kB memory pools for storing at least 
TCP_WND bytes.

In core/init.c there's an error:

#if !MEMP_MEM_MALLOC && PBUF_POOL_SIZE && (TCP_WND > (PBUF_POOL_SIZE * 
(PBUF_POOL_BUFSIZE - (PBUF_LINK_ENCAPSULATION_HLEN + PBUF_LINK_HLEN + 
PBUF_IP_HLEN + PBUF_TRANSPORT_HLEN))))
#error "lwip_sanity_check: WARNING: TCP_WND is larger than space 
provided by PBUF_POOL_SIZE * (PBUF_POOL_BUFSIZE - protocol headers). If 
you know what you are doing, define LWIP_DISABLE_TCP_SANITY_CHECKS to 1 
to disable this error."
#endif

I understand pbuf pool should be sized at least TCP_WND that is 16kB... 
and pools are statically allocated. Am I wrong?

> The only downside I see is that this way, all other non-TLS applications
> get a bigger TCP_WND too. That's why we want to add code to control TCP_WND
> at runtime per pcb.
Yes, this is another useful thing.