[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
TLS over SCTP
TLS over SCTP
Fri, 01 Aug 2008 14:26:17 +0900
Thunderbird 188.8.131.52 (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
-> 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,
- TLS over SCTP,
Sebastien Decugis <=
- Re: TLS over SCTP, Nikos Mavrogiannopoulos, 2008/08/02
- Re: [SPAM] Re: TLS over SCTP, Sebastien Decugis, 2008/08/03
- Re: [SPAM] Re: TLS over SCTP, Nikos Mavrogiannopoulos, 2008/08/09
- Re: [SPAM] Re: TLS over SCTP, Sebastien Decugis, 2008/08/10
- TLS over multi-stream SCTP, a wrapper..., Sebastien Decugis, 2008/08/15
- Re: TLS over multi-stream SCTP, a wrapper..., Nikos Mavrogiannopoulos, 2008/08/16
- Re: TLS over multi-stream SCTP, a wrapper..., Sebastien Decugis, 2008/08/17