In the absence of anything else, I'd implement TLS atop SCTP as follows:-
Have a 'pair' of unidirectional streams for each required 2-way communication; construct the pair by convention, preferably stream 0 out pairs stream 0 in, etc;
substitute alternative ssl_read / ssl_write function implementations if using OpenSSL that cal sctp_sendmsg / sctp_readmsg, and treat sctp as if it where a stream (TLS is record delimited, but that's too complex too map as openssl et al assume a stream)
use as a pair
So... this requires TLS set up for EVERY stream pair. Slow, inefficient, etc.
Raphael Cohn Chief Architect, stormmq Secretary, OASIS AMQP Standard
+44 7590 675 756
UK Office: Hamblethorpe Farm, Crag Lane, Bradley BD20 9DB, North Yorkshire, United Kingdom Telephone: +44 845 3712 567 Registered office: 16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom StormMQ Limited is Registered in England and Wales under Company Number 07175657 StormMQ.com
On 29 January 2013 15:38, John O'Hara <
> wrote:
TLS is more interesting - would you maintain a separate TLS session for each SCTP stream??? I know there's been some stuff written about this on the SCTP sites - would be interesting to see where that landed.
On 29 January 2013 14:41, Raphael Cohn <
> wrote:
> I'd hope not... by 'special stream' I just mean that one expects to receive
> SASL then connection open on SCTP stream 0 - which always exists. After
> that, it really doesn't matter, although it would be nice to have connection
> close on stream 0. In effect, stream 0 is what you get if you bind a socket
> to SCTP w/o doing anything special. One needs some sort of convention 'at
> start up' to know how to proceed. >
> Raphael Cohn
> Chief Architect, stormmq
> Secretary, OASIS AMQP Standard
>
> +44 7590 675 756
>
> UK Office:
> Hamblethorpe Farm, Crag Lane, Bradley BD20 9DB, North Yorkshire, United
> Kingdom
> Telephone: +44 845 3712 567
>
> Registered office:
> 16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom
> StormMQ Limited is Registered in England and Wales under Company Number
> 07175657
> StormMQ.com > >
> On 29 January 2013 14:29, Kritikos, Alex < >
> wrote: >> >> Hi all, >> >> Just a question to all… if we enforce a dedicated stream with some special >> meaning, would that not affect future bindings to other transports? Or will >> there be a registry / some sort of handshake to define the characteristics >> of a special stream? >> >> Thanks, >> >> Alex Kritikos >> Senior Director >> Software AG >> >> On Jan 29, 2013, at 4:21 PM, Raphael Cohn < > >> wrote: >> >> Andreas, >> >> Being stimulated by your questions. >> >> Connection Management >> I would prefer to have a dedicated stream for this. It's decidedly easier. >> It's also worth noting that we can send some out-of-band data with a >> message, such as an opaque 32-bit number. This could be an useful way to do >> the 'We're AMQPxxxx' equivalent in SCTP. Frankly, a client star >> >> Session >> Either. The choices we make in SCTP are whether we want to make it easy to >> take an existing implementation for TCP and make it work on SCTP (easy; just >> use one stream and multiplex, we can have a standard in a week that can be >> implemented in a day), or use multiple streams for multiple sessions (not >> too hard, but more work for everyone, but with other potential advantages). >> We might also want to consider if we ever want 'peel-off', where a stream >> can then become its own dedicated separate socket - useful for getting >> epoll, select, etc, to do per session events for high bandwidth sessions, >> rather than per connection, but rather hard to get one's head round. >> >> Regardless, I'm not in favour of mixing AMQP traffic on these streams with >> other protocols. Given the lack of first class support in most network >> eventing frameworks (epoll, etc) for per stream events, it would require >> some truly horrible server logic. >> >> Raph >> >> Raphael Cohn >> Chief Architect, stormmq >> Secretary, OASIS AMQP Standard >>
>> +44 7590 675 756
>> >> UK Office: >> Hamblethorpe Farm, Crag Lane, Bradley BD20 9DB, North Yorkshire, United >> Kingdom >> Telephone: +44 845 3712 567
>> >> Registered office: >> 16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom >> StormMQ Limited is Registered in England and Wales under Company Number >> 07175657 >> StormMQ.com >> >> >> On 29 January 2013 13:48, <
> wrote: >>> >>> >>> Without knowledge of SCTP usage for legacy amqp versions >>> (pre-OASIS-standard), >>> I have more general questions: >>> >>> - Connection management. >>> Need of dedicated management stream? >>> E.g., the first stream for protocol header, open, close >>> - Session. >>> Each session requires its own SCTP stream? >>> Or alternatively/additionally multiplexing like on a TCP connection? >>> - Ordering of operations. >>> Handling of pipelined open, simultaneous close and session end? >>> Maybe, pipelining has to be restricted or disallowed when using >>> multiple streams. E.g. session can only be begun after connection >>> "open" has been acked by the counterparty's "open" and >>> close may only be sent after ending the sessions has been acked >>> by the counterparty's "end" for all sessions. >>> >>> Andreas >>> >>> <
> wrote on 29.01.2013 13:22:41: >>> >>> >>>
> So I guess my open questions on the SCTP Binding are >>> > >>>
> 1) How do we mark initiation of the AMQP communication >>> > >>>
> In TCP we use a header AMQPxxxx ... which TCP guarantees will arrive >>>
> before any subsequent frames. In SCTP am I correct in believing >>>
> this guarantee would only hold true if all communication was on the >>>
> same SCTP stream. >>> > >>>
> The open frame similarly is defined as having to be sent before any >>>
> other AMQP traffic on the connection. >>> > >>>
> 2) Framing. I believe that we can do away with the need for AMQP >>>
> Framing when using SCTP. The SCTP message carries all information >>>
> that is currently held in an AMQP frame with the exception of the >>>
> unused extended header. Are others comfortable with this approach. >>> > >>>
> 3) Closing a connection. Similar issues to opening in that we don't >>>
> have the same total ordering guarantees. In the case of a clean >>>
> shutdown this is probably not a significant issue (all AMQP Sessions >>>
> will have been "end"ed prior to the close being issued... the peer >>>
> can take note of the close, and wait until all open sessions are >>>
> ended... or timeout after some waiting period). (There may be a >>>
> vanishingly small corner case where a sender asyncronously begins, >>>
> operates on, and ends a session... and this entire sequenec is >>> > "overtaken" by the close). >>> > >>>
> 4) Security... will we continue to use SASL... if so how does the >>>
> layering work. We also need to define the TLS equivalent layer. >>> > >>>
> What other areas have I ommitted? >>> > >>> >
--
Rob >>> >>> >>> >>>
-------------------------------------------------------------------------
>>> Deutsche Börse AG >>> Chairman of the Supervisory Board/ >>> Vorsitzender des Aufsichtsrats: >>> Dr. Joachim Faber >>> Executive Board/Vorstand: >>> Dr. Reto Francioni (Chief Executive Officer/Vorsitzender), >>> Andreas Preuss (Deputy Chief Executive Officer/ >>> stellv. Vorsitzender), Frank Gerstenschläger, >>> Gregor Pottmeyer, Hauke Stars, Jeffrey Tessler. >>> Aktiengesellschaft with registered seat in/mit Sitz in >>> Frankfurt am Main. >>> Commercial register/Handelsregister: >>> Local court/Amtsgericht Frankfurt am Main HRB 32232. >>> >>>
-----------------------------------------
>>> Diese E-Mail enthaelt vertrauliche oder rechtlich geschuetzte >>> Informationen. >>> Wenn Sie nicht der beabsichtigte Empfaenger sind, informieren Sie bitte >>> sofort den Absender und loeschen Sie diese E-Mail. Das unbefugte Kopieren >>> dieser E-Mail oder die unbefugte Weitergabe der enthaltenen Informationen >>> ist nicht gestattet. >>> >>> The information contained in this message is confidential or protected by >>> law. If you are not the intended recipient, please contact the sender and >>> delete this message. Any unauthorised copying of this message or >>> unauthorised distribution of the information contained herein is >>> prohibited. >>> >>> Legally required information for business correspondence/ >>> Gesetzliche Pflichtangaben fuer Geschaeftskorrespondenz: >>> http://deutsche-boerse.com/letterhead
>> >> >> >
