gnutls-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

TLS over SCTP


From: Sebastien Decugis
Subject: TLS over SCTP
Date: Fri, 01 Aug 2008 14:26:17 +0900
User-agent: Thunderbird 2.0.0.12 (Windows/20080213)

Hello, [sorry to reposting on the same topic as in help-gnutls, but the content is slightly different]

I am wanting to use the gnutls library to achieve TLS over a multi-stream SCTP connection, as detailed in RFC 3436. Unfortunately it seems that the current support in gnutls for providing custom transport functions is not sufficient to achieve this.

For people who are not familiar with SCTP, I'll now give a short introduction on this protocol. SCTP is a reliable transport protocol (as TCP), message-oriented (as UDP), which provides the capability to create multiple streams inside one connection. The messages in one stream are ordered, but each stream is independent from the others. This allows (in some applications) to avoid head-of-the-line blocking problem that occurs in TCP when some data is lost during a transmission. SCTP also provides other interesting features such as support for multihoming. On an API point of view, one socket object is created, and the number of streams is negotiated between the endpoints. sendmsg() function is used to send a message on this socket, with some options available to specify the stream on which the message is sent. recvmsg() function receives a message from any stream, and the message contains the stream id on which it was received in its meta-data. RFC3436 specifies how TLS should be used to secure SCTP connections. In a row, independent pairs of streams (bi-directional) are used as independent TLS channels. For example, if an SCTP connection between two peers negotiates 4 outbound streams and 6 inbound streams, then 4 TLS handshakes will occur on streams 0 to 3, and the two remaining inbound streams are not protected by TLS.

In its current state, the gnutls library misses the ability to have several gnutls_session_t associated to a single connection object. It is a problem on message reception, because we can determine the session to which a message belongs only *after* we receive it. This demultiplexing operation is not currently allowed in gnutls, AFAIU.

I am considering to implement such support in the gnutls library, either as a new session object ("gnutls_session_multistream_t") or as an extension of the current session object (adding new fields to it). Basically, the differences are: -> ability to define a number of independent communication channels (bi-directional streams) in the object. -> storage for this same number of sessions states (the current gnutls_session_t) -> different prototype of the push and pull transport callbacks, that take an additional parameter (the stream id on which to send / on which the message was received)

The functions such as gnutls_handshake would also need a new version, either as gnutls_handshake_multistream or merged in the same function, to provide the ability to negociate the TLS sessions on all streams.

I have no knowledge of the gnutls code so far, so I'd like to hear comments from the experienced developpers on this topic, before I start. More specifically, would such feature be considered for inclusion in a future release when it is stable? Would you give me advices and hints for implementing this cleanly?

Thank you in advance,
Sebastien.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]