Hi Daniel,
I talked to Robin yesterday and based on that discussion Robin
provided a
patch. But thinking a bit more about this, I think we'll have to
change the
patch...
DTLS should not care about its lower layer. It can be UDP/IPv4, UDP/
IPv6,
DCCP/IPv4, DCCP/IPv6, SCTP/IPv4, SCTP/IPv6, and even tunneling protocols
can be involved.
So dtls should store internally (and that is what it actually needs)
the maximum packet size it can actually use. This should be stored
in d1->mtu.
If the upper layer explicitly sets the MTU, it should already account
for it. I think this is just a matter of what you provide in the
SSL_set_mtu() call.
Please note that the notion of MTU has different meanings at different
layers. At the DTLS layer, it is link layer MTU - IP header size - UDP
header size, for example...
I'm not sure if the stuff also works for IPv6 and so on...
So I think we need to update the patch Robin provided yesterday...
Best regards
Michael
On May 13, 2009, at 2:28 PM, Daniel Mentz wrote:
Hi Michael,
thank you for taking care of this. I'm happy to test any patch you
provide.
I'd suggest a different approach, though. I would stick to the
correct definition of MTU. Otherwise people who look at the code in
the future might get confused. d1->mtu should contain the real MTU
in my opinion. The 20+8 bytes overhead should be subtracted at a
different place. I'm not as familiar with the DTLS code as you are
so I can't tell where changes have to be made.
Also, I would appreciate if there were a function that I can use as
an application developer to find out the maximum number of bytes I
can pass to SSL_write() without the resulting IP packet exceeding
the MTU. I know that I could just take the MTU and subtract the
overhead for the IP, UDP and DTLS Record Header but I think that's a
violation of the layering principle. I - as an application developer
- don't want to be concerned with the DTLS Record Layer.
Best regards,
Daniel
Michael Tüxen wrote:
Hi Daniel,
yes, you are right. The command line arg is passed to
SSL_set_mtu() which just sets d1->mtu.
The rest of the code assumes that d1->mtu does
only covers the UDP payload. So we need to fix
the handling of SSL_CTRL_SET_MTU to reduce the
value by 20+8.
Regarding path MTU discovery there seems to be a similar
problem, since we have
case BIO_CTRL_DGRAM_QUERY_MTU:
sockopt_len = sizeof(sockopt_val);
if ((ret = getsockopt(b->num, IPPROTO_IP, IP_MTU, (void
*)&sockopt_val,
&sockopt_len)) < 0 || sockopt_val < 0)
{ ret = 0; }
else
{
data->mtu = sockopt_val;
ret = data->mtu;
}
break;
So I guess this also needs a reduction.
Robin, can you provide a patch?
Daniel, can you test the patch when it is available? The path MTU
discovery might be platform specific...
Best regards
Michael
On May 12, 2009, at 8:24 PM, Daniel Mentz wrote:
I've got the impression that the DTLS part of OpenSSL is based on
an incorrect understanding of the term MTU (Maximum Transmission
Unit).
My understanding is that the MTU refers to the size of the IP
packet including the IP header (usually 20 bytes) and the UDP
header (usually 8 bytes) in case UDP is used. This means that I
can transfer 1472 bytes of payload if the MTU is 1500 bytes.
Now, if I start openssl s_server with the following command line
./openssl s_server -dtls1 -no_ecdhe -timeout -cert large.pem -mtu
1400
and monitor packets with wireshark I can see IP packets with a
total length of 1428 bytes.
From looking at this I infere that OpenSSL interprets the MTU as
the maximum payload size of an UDP packet.
If I get rid of the -mtu parameter, rely on Path MTU discovery and
set the MTU of the outgoing interface to 1400 I don't get any
communication going. But I do see an avalanche of "Destination
unreachable (Fragmentation needed)" ICMP messages. I guess that
this is due to the incorrect understanding of the MTU. OpenSSL
appears to try sending larger packets than allowed by the PMTU.
Can anyone confirm this problem?
Thanks
-Daniel
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
______________________________________________________________________
OpenSSL Project http://
www.openssl.org
User Support Mailing List openssl-
us...@openssl.org
Automated List Manager
majord...@openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
