TLS over SCTP

Sebastien Decugis sdecugis at nict.go.jp
Fri Aug 1 07:26:17 CEST 2008


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.






More information about the Gnutls-devel mailing list