[PULL][PATCH] Small buffering fixes, start of recv side cleanup
Jonathan Bastien-Filiatrault
joe at x2a.org
Wed Sep 8 15:42:43 CEST 2010
Nikos Mavrogiannopoulos wrote:
> On 09/01/2010 02:32 AM, Jonathan Bastien-Filiatrault wrote:
>
>>> Hi and thank you! My question would be how would you move on. That is
>>> what would be your next (planned) moves in adding DTLS?
>> My pleasure,
>>
>> I am currently working on getting GnuTLS to receive datagram-sized
>> chunks and adapting the record layer so that records cannot span
>> datagrams when using DTLS.
>>
>> Towards that goal, I have forward-ported my old (1 year+) patches to the
>> current master branch.
>> My current progress is here (broken code warning in full effect):
>> http://github.com/jothan/gnutls/commits/rebase%2Fdtls/
>> The handshake buffering code in those patches needs to be completely
>> redone.
>
> Pretty fair.
>
>> The next steps are the recv + record side work I mentionned above. After
>> that, I will need to add HelloVerifyRequest processing. At that point, I
>> should be very close to (drum roll...) achieving the first
>> inter-implementation Free Software DTLS handshake between OpenSSL and
>> GnuTLS.
>
> That would be nice :)
This has been accomplished in the latest patches. I will post that code
tonight to the mailing list, but I do not expect it to be merged as it
still has many loose ends.
>> Many issues regarding timeout and retransmission issues are yet to be
>> solved. The division of responsibilities between the application and the
>> library regarding those issues are pretty much still in the air.
>
> I'd suggest to move everything to the layer over gnutls. As far as I
> understand from DTLS is that it can be used over many unreliable layers
> with different characteristics. Maybe some sensible "defaults" exist for
> UDP, as we do now for TCP.
Ok, will do.
>> Regarding the patches, would it help you and Simon if I mail patches
>> series individually instead or in addition to requesting a git-pull ? It
>> might more accessible to others for comment and review.
>
> At least for me patches are easier reviewed by e-mail. However I think
> it might be better to send patches (at least for merging) once some
> milestones you set are completed (say once DTLS datagrams can be sent
> and received, handshake works etc). That way you'll be free to change
> anything in your previous work, without fearing touching already
> submitted code. The current master code that you are working on
> shouldn't change in this aspect. Looking forward for your patches! :)
My latest patches posted on github handshake fully with OpenSSL in DTLS
mode. Application data can be exchanged. I have only tried it on the
loopback interface, but it should work over the net as long as the
packets are short enough and not lost. I can also post the example
program I am using.
Still to do:
- Implement handshake reliability
- MTU/MSS handling
- Handshake fragmentation and reassembly.
- Bulk encryption parameter versionning.
I am currently working on bulk encryption parameter versionning (the
epoch field in DTLS). This involves decoupling the encryption parameters
from the rest of the session. The resulting code should be somewhat
cleaner and easier to understand (and shorter). I have mostly succeeded,
but many details remain. These patches will affect the internal api for TLS.
This is the biggest patch by far:
lib/ext_session_ticket.c | 56 +---
lib/gnutls_alert.c | 2 +-
lib/gnutls_buffers.c | 1 +
lib/gnutls_cipher.c | 74 +++---
lib/gnutls_cipher.h | 11 +-
lib/gnutls_compress.c | 13 +-
lib/gnutls_compress.h | 6 +-
lib/gnutls_constate.c | 717
++++++++++++++++++---------------------------
lib/gnutls_constate.h | 33 ++-
lib/gnutls_dtls.c | 2 +-
lib/gnutls_handshake.c | 12 +-
lib/gnutls_int.h | 97 ++++---
lib/gnutls_record.c | 65 +++--
lib/gnutls_record.h | 2 +-
lib/gnutls_session_pack.c | 55 +++-
lib/gnutls_state.c | 75 +++--
libextra/gnutls_ia.c | 2 +-
17 files changed, 565 insertions(+), 658 deletions(-)
I will post the buffering patches tonight, the diffstat is not nearly as
impressing.
>
> best regards,
> Nikos
More information about the Gnutls-devel
mailing list