[gnutls-devel] [sr #108712] mutiple DTLS records in one UDP packet not handled correctly

[Andreas Schultz]

Follow-up Comment #10, sr #108712 (project gnutls):

> Interesting case. Here you are artificially setting the client's MTU to 400
bytes, and the server's to 1500. The certificate is 558 so the client cannot
receive it with the size of its buffers. In a real world case (when ICMP
packets are allowed) the server should have received GNUTLS_E_LARGE_PACKET and
should have adjusted its view of MTU size. 

Correction, I set the servers MTU to 400, the client's is left at 1500.
Artificial lowering the permitted MTU below the Path MTU is IMO a valid use
case and I have seen at least on real world server insisting on such a low MTU
(Cisco Virtual Wireless Controller)

> Is there some particular merit in addressing that? I mean are there real
scenarios where this case could occur?

Well, this sample is contrive to simulate a specific scenario that would not
occur with GNUTLS alone.

What the test does is to generate a payload that the client sees as one big
datagram containing multiple fragmented DTLS records. GNUTLS does not generate
this kind of datagram, but they are valid and OpenSSL does generate them. So
for the test to be reproducible without involving OpenSSL I had to come up
with some contrived code. Particularity, running DTLS over a streaming socket
that does not preserve the packet boundaries of sending side (this simulates
the "big datagram containing multiple DTLS records") and setting a low sender
side MTU to get the fragmentation.

So, to answer your question, yes there are real world scenarios where this
case will occur.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?108712>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/