Julien,
yes you are right. The Handshakers handle fragmented messages properly. Would you then suggest to make “DoS protection” configurable?
Kai
From: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Julien Vermillard
Sent: Tuesday, December 15, 2015 10:22 AM
To: Californium (Cf) developer discussions
Subject: Re: [cf-dev] 回复: question of californium.scandium project
Also I think if we bypass the anti DoS verify request (which is probably not needed for SMS) the handshaker will handle fragmented CLIENT_HELLO correctly?
On Tue, Dec 15, 2015 at 9:47 AM, Hudalla Kai (INST/ESY) <Kai.Hudalla@xxxxxxxxxxxx> wrote:
Hai,
Scandium currently expects the initial CLIENT_HELLO message to arrive as an unfragmented
message. This is not an unreasonable assumption to make since the CLIENT_HELLO message should usually be quite small anyways and we do not want to create any state for the client on the server unless we have validated that the client actually is in control
of the IP address the CLIENT_HELLO message has been received from.
That said, we might need to rethink this approach and at least be able to perform that
validation correctly even for fragmented CLIENT_HELLO messages. However, this will require some more complex re-factoring since it would involve relocation of responsibilities from the Handshakers to the DTLSConnector.
Maybe there is a way to reduce the size of the CLIENT_HELLO message you are sending?
Could you provide a log of the CLIENT_HELLO message sent to the server?
Kai
My name is RenHai, from China. I think you got what I meant. This project is to be used in SMS(short message server) of GSM network, and the MTU is
reduced to 140B because sms's max payload is 140 bytes. Thanks for your reply.
------------------ 原始邮件 ------------------
发送时间: 2015年12月14日(星期一)
下午3:58
主题: Re: [cf-dev] question of californium.scandium project
Hi there „unknown stranger“,
from your message I deduce that you are trying to make a DTLS connection over a network with an MTU of 140 bytes, right?
The log also indicates that the client has split up its CLIENT_HELLO message into two fragmented handshake messages which the server is not able to handle correctly, i.e. the server does not re-assemble the fragments into the original CLIENT_HELLO message.
We currently do not handle that case because, frankly spoken, I have not expected to ever receive a fragmented CLIENT_HELLO message (mainly because the CLIENT_HELLO message usually does not contain that much information).
May I ask what kind of networking infrastructure you are running on that has an MTU of 140 bytes?
BTW It would be nice of you to include your (first) name so that we know who we are talking to ;-)
Regards,
Kai
Project: scandium project
File: org.eclipse.californium.scandium.DTLSConnector.java
When I reduce the MTU ("
this.maximumTransmissionUnit = 140" at linenumber 298 in function "start"), I run ExampleDTLSServer.java and ExampleDTLSClient.java as application.
In ExampleDTLSServer console, there are
org.eclipse.californium.scandium.dtls.FragmentedHandshakeMessage cannot be cast to org.eclipse.californium.scandium.dtls.ClientHello exceptions. I put the output of DTLSClient and DTLSServer's console in DTLSClientLog.txt and
DTLSServerLog.txt.
When ExampleDTLSServer receive the second ClientHello there are cast exceptions in
processHandshakeRecordWithoutConnection function.
I catch two Records of second ClientHello in processClientHello function.
==[ DTLS Record ]==============================================
Content Type: Handshake (22)
Fragmented Handshake Message: 87 bytes
FE FD 56 6A 85 CF 63 FB E2 DA 7F D1 87 FD 78 82 50 E8 9B 5D 43 EF 4C 0A E1 57 4D 83 0F 3B BA CF CE 5C 00 20 BA 77 09 1D B0 66 4B 23 A2
6D 68 BB 16 E1 76 34 33 3D 9D 24 A8 33 82 B6 69 26 6B 21 5E CB C3 82 00 08 C0 AE C0 23 C0 A8 00 AE 01 00 00 20 00 0A 00 08 00
===============================================================
==[ DTLS Record ]==============================================
Content Type: Handshake (22)
Fragmented Handshake Message: 27 bytes
06 00 17 00 18 00 19 00 0B 00 02 01 00 00 13 00 03 02 02 00 00 14 00 03 02 00 02
===============================================================
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev
|