[sctp-dev] Basic Questions

[Christopher Hegarty - Sun Microsystems Ireland]

comments inline...


On 23/06/2009 01:25, David Ryan wrote:
> Hi Chris,
> 
> Sorry, I forgot SCTP_DISABLE_FRAGMENTS was not supported on Solaris.
>> However, messages are fragmented by default. I added this option to ensure
>> that fragmentation was possible on platforms where it was not the default.
> 
> 
> I was surprised that quite a few of the options were not supported.  I guess
> this means that for now I'll have to rely on what Solaris currently provides
> and keep things simple (which is probably a good thing).
> 
> 
>> The main motivation behind this was to support TLS/SSL over SCTP, see
>> http://tools.ietf.org/html/rfc3436.
>>
> 
> I found RFC3436 last week and have started to explore  TLS/SSL over SCTP.
> I've got hold of the SSLEngineSimpleDemo and started to explore how best to
> implement this over the SCTP interface.  Has anyone in Sun has already done
> this?
Sorry, not that I am aware of. You are now leading this effort ;-)

>>From initial investigations there's two fundamental design issues I'm
> assuming.
> 
> The first is that SctpChannel.receive call does not allow filtering on
> specific streams, so all data will need to be received by a single thread.
Yes, only one thread can be receiving at any time, but the same thread 
does not necessarily need to receive all the messages. You can use a 
selector to determine if there is a message/notification available, and 
then hand off the channel to a thread from a thread pool to do the 
receive/processing.

> The second is that this will require separate SSLEngine objects for each
> bi-directional stream. 
Only if you want separate SSL sessions per stream. You could have a 
single SSL session, that is one SSLEngine, per association/channel. 
Therefore, all streams would use the same SSLEngine. You would need to 
ensure that each message is read completely before a message on another 
stream is received, this is the default behavior on Solaris.

  Also, if each secure stream is to be presented as
> different objects to the application it puts specific requirements on how
> that is done.  The application will need to either register a call back that
> can be called when data arrives for that stream, or a queue will need to be
> used.  In either case a separate thread will need to receive all data from
> the SctpChannel and decide if that data needs to be passed to a specific
> SSLEngine instance or to an application callback/queue.
> 
> A related issue is that I haven't worked out how an SSLEngine can be
> initiated with a session id of another SSLEngine to allow the abreviated
> handshake as specified in RFC3436.
I'm not sure either. Let me see if I can find out.

> These aren't really SCTP specific questions I know, but thought you might be
> interested in how the API will be used.
Yes, very much so.

>If/when I get some example code
> running I'll post it here.  I'm attempting to build a secure daytime server
> based on your example as a starting point.
That would be great. I am very interested in how this works out. Please 
keep me in the loop.

>> Another thing I noticed was that InvalidStreamException is an undeclared
>>> exception.  It would be nice if this extended from IOException and could be
>>> caught in the declared catch block.
>>>
>> InvalidStreamException is a RuntimeException (more specifically an
>> IllegalArgumentException) and as such is not required to be caught. It is
>> listed in the list of exceptions thrown by send, but not declared in the
>> method description so you are not required to provide a catch block. Does
>> this make sense or answer you question?
>>
> 
> Yes and No. :)  I realised it was a RuntimeException.  I was really
> questioning if this is the right design.  I can imagine that getting this
> parameter wrong could be quite easy to do which would create a bug that
> could easily slip through testing.  If it extended IOException the developer
> is more likely to have code to handle IOExceptions already and the
> consequence wouldn't be as bad.  Just a thought.
Yes, this is certainly true. Let me think about this.

-Chris.

>> I would personally leave it to SCTP to provide the message framing. I don't
>> see any issues with allowing SCTP do the framing unless you require very
>> large messages that the platform does not support.
> 
> 
> Yes, I think this line of questions was showing my naivety of SCTP framing.
> I went back and reviewed some of the SCTP introduction web sites and think I
> have a better understanding now.
> 
> Please let me know your comments. Have I answers some of your questions or
>> just confused things more? ;-)
> 
> 
> Your comments have been really helpful!
> 
> Thanks,
> David.
>