Re: [SPAM] Re: TLS over SCTP

[Sebastien Decugis]

Hello Nikos,

Thank you for your answer. Please see my comments below.

> A layer that would demultiplex the streams before should be needed.
> That's correct.
>   
Ok
> > 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)
> >     
>
> Can't this be achieved by having a layer of demultiplexing before gnutls
> that will use separate pull/push functions and a custom transport
> pointer? That we could include in gnutls as helper functions for SCTP.
>   

I understand your point. My first attempt was to come up with such 
intermediate layer that would provide these two functions:
send_to_stream(message, length, streamid);
recv_from_stream(message, length, streamid);
It would be quite straight-forward to use the user pointer from the 
session, or the connection object, to retrieve the stream id of a session.

Unfortunately, whereas the send function can be written quite easily, I 
cannot figure out how to write the recv function. Using the SCTP socket 
API [1], we do not specify the stream on which we are listening for a 
new message. Instead, we are listening for the next message from any 
stream, and when we receive it we can also get its stream id. That is a 
fundamental difference between a multistream SCTP association, and many 
separated connections.

That is the reason for my previous proposal. An alternate approach would 
be to be able to change the current TLS session from inside the 
transport handler, but I don't think this is a good approach, if 
possible at all.

What do you think, is there another possibility to solve the problem 
that I cannot see?

Thank you in advance,
Best regards,
Sebastien.

[1] http://www3.tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-17