| Re: [cf-dev] 回复： question of californium.scandium project |
|
Guys, I have looked into the Internet Draft for DTLS over GSM SMS [1] which a)
Seems to be expired with no successor version and b)
explicitly advises against disabling cookie exchange in section 5 Anyway, I wonder what the “expired” status of the draft is supposed to indicate. Does this mean that nobody (apart from you, Hai, and the authors)
seems to be really interested in running DTLS over SMS? [1]
https://datatracker.ietf.org/doc/draft-fossati-dtls-over-gsm-sms/ Kai From: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Julien Vermillard Exactly :)
-- On Tue, Dec 15, 2015 at 12:33 PM, Hudalla Kai (INST/ESY) <Kai.Hudalla@xxxxxxxxxxxx> wrote: 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 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 From:
cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx]
On Behalf Of ???? Hi, 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. Regards, Hai ------------------ 原始邮件 ------------------
发件人: "Hudalla Kai (INST/ESY)";<Kai.Hudalla@xxxxxxxxxxxx>;
发送时间: 2015年12月14日(星期一)
下午3:58
收件人: "Californium (Cf) developer discussions"<cf-dev@xxxxxxxxxxx>;
主题: 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 From:
cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx]
On Behalf Of ???? Project: scandium project File: org.eclipse.californium.scandium.DTLSConnector.java Question: 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) Peer address: /127.0.0.1:63430 Version: 254, 253 Epoch: 0 Sequence Number: 5 Length: 99 Fragment: Handshake Protocol Type: CLIENT_HELLO (1) Peer: /127.0.0.1:63430 Message Sequence No: 1 Fragment Offset: 0 Fragment Length: 87 Length: 114 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) Peer address: /127.0.0.1:63430 Version: 254, 253 Epoch: 0 Sequence Number: 6 Length: 39 Fragment: Handshake Protocol Type: CLIENT_HELLO (1) Peer: /127.0.0.1:63430 Message Sequence No: 1 Fragment Offset: 87 Fragment Length: 27 Length: 114 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 ===============================================================
|
