DTLS does seem to be the “right” answer... though I am unfamiliar with the extent of its support (e.g. I’m not aware of support directly from Java).
Setting up individual TLS sessions on each SCTP stream seems particularly unattractive.
-- Rob
From: amqp-bindmap@lists.oasis-open.org [mailto:amqp-bindmap@lists.oasis-open.org]
On Behalf Of Raphael Cohn
Sent: Tuesday, January 29, 2013 3:56 PM
To: John O'Hara
Cc: Kritikos, Alex; amqp-bindmap@lists.oasis-open.org
Subject: Re: [amqp-bindmap] [SCTP Binding]
The other option is DTLS... which is supported in newer versions of OpenSSL and GnuTLS. I know very little about it.
Raphael Cohn
Chief Architect, stormmq
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:54, Raphael Cohn <raphael.cohn@stormmq.com> wrote:
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)
So... this requires TLS set up for EVERY stream pair. Slow, inefficient, etc.
Raphael Cohn
Chief Architect, stormmq
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 <john@rjohara.com> 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 <raphael.cohn@stormmq.com> 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
> raphael.cohn@stormmq.com
> +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 <Alex.Kritikos@softwareag.com>
> 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 <raphael.cohn@stormmq.com>
>> 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
>> raphael.cohn@stormmq.com
>> +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, <Andreas.Moravec@deutsche-boerse.com> 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
>>>
>>> <robert.godfrey@jpmorgan.com> 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
>>
>>
>>
>
This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.
|