On Aug 10, 2009, at 11:21 AM, David Schwartz wrote:
Daniel Mentz wrote:
In my understanding DTLS should provide UDP semantics when run over
the
later.
That is correct.
That is if a user message is too large in terms of the PMTU it
should either be silently discarded or the sender should be
notified by
an error message similar to "Message too big".
No, it should be fragmented and reassembled, just like UDP does.
IP does the fragmentation/reassembly, not UDP.
In no event should the message be fragmented and delivered to the
receiving application in more than one piece.
Correct, and that never happens.
It might be acceptable
that only a prefix is delivered but other than that only the
message as
a whole or no message should be delivered.
Prefixes are unacceptable. DTLS guarantees that the datagram is either
received intact or not recieved at all.
But OpenSSL is doing exactly this: dtls1_write_app_data_bytes() in
d1_pkt.c fragments user messages if the (guessed) MTU is too small to
transmit the message in one piece. The receiving application has no
way
to figure out if a message received by using SSL_read() is a complete
message or only a fragment of a message.
The receiving application doesn't have to, the IP layer handles
fragmentation and reassembly.
Also, it's impossible to find
out which fragment was read and if all fragments needed for
reassembly
were transmitted.
Huh? IP packets have the necessary information to reassemble
fragments. This
is all handled below the UDP layer.
In my concrete setting I'm running OpenSSL on FreeBSD and try to
transmit a user message of say 2000 bytes. With no way of figuring
out
the correct PMTU on FreeBSD OpenSSL makes an educated (wrong) guess
of
1472 and uses it to slice the message into chunks of appropriate
size.
Since I'm using the loopback interface I can transmit datagrams
bigger
than this.
The receiving application gets only junk: The first fragment can
not be
processed because it was truncated. All remaining fragments can not
be
used as well because they do not form a legitimate message.
It's not clear what you're saying here. If the receiving application
ever
gets anything other than a datagram sent by the other end, that's a
serious
bug in OpenSSL. The whole point of DTLS is to ensure datagrams
cannot be
tampered with in flight. This likely has nothing to do with
segmentation of
MTU issues and everything to do with the message authentication code.
My suggestion is to return an error message in that case or just to
go
ahead and send the message anyway. The socket interface will
eventually
return a (correct) error message if OpenSSL tries to send a packet
too
big for the PMTU.
Why would that generate an error exactly? The IP layer should simply
split
the datagram into segments.
This would make debugging easier. It took me some time to figure
out why
I was receiving junk on the receiving end although DTLS provides HMAC
for integrity control.
You have yet to explain any reason why you would get junk on the
receiving
end. The HMAC code should prevent exactly this, and if the IP layer
can mess
it up, something is horribly and seriously wrong.
After careful consideration I even think that this is a protocol
violation because the integrity of the message is indeed corrupted
although DTLS aims to guarantee integrity.
You are correct, but it has nothing to do with segmentation.
The situation with SCTP is slightly different: It sets the MTU to an
artificial value of 16384 because SCTP provides fragmentation and
reassembly on the transport layer. But if you send messages bigger
than
that then your messages get fragmented again.
So does IP. Otherwise, UDP wouldn't work if you didn't know the path
MTU.
DTLS/SCTP supports user messages as large as they fit into a record
layer. If the user provides larger messages, the send call must fail.
Best regards
Michael
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
