RE: [amqp-bindmap] AMQP 1.0 Redirect with WebSockets

[Steve Huston <shuston@riverace.com>]

Thanks very much for sending this explanation, John. I have read it a few times hoping to come up with a sensible approach. I haven’t, but didn’t want to leave you hanging as if no one had read it.

 

How about you other websocket-knowledgeable folks – any ideas?

 

Thanks,

-Steve

 

From: amqp-bindmap@lists.oasis-open.org [mailto:amqp-bindmap@lists.oasis-open.org] On Behalf Of John Fallows
Sent: Tuesday, June 09, 2015 8:46 PM
To: amqp-bindmap@lists.oasis-open.org
Subject: [amqp-bindmap] AMQP 1.0 Redirect with WebSockets

 

Hi Folks,

 

Here's the conundrum with AMQP 1.0 redirect semantics when using WebSockets as a transport:

• AMQP 1.0 redirect frame(s) assume physical characteristics of the transport layer, such as network-host and port (AMQP 1.0 specification, section 2.8.16)
• AMQP 1.0 redirect connection error and AMQP 1.0 redirect link error frames can be received at any time during the AMQP 1.0 connection
• WebSockets endpoints are described by a URL such as ws://websocket.org/amqp10, not just network-host and port.
• WebSockets have no standard way to redirect after successful handshake, prior to successful handshake HTTP 30x can be used to redirect WebSocket client
• Intermediary blindly forwarding AMQP 1.0 traffic from TCP to and from WebSockets will expose physical address information for internal AMQP 1.0 server behind WebSocket endpoint (security issue)
• Intermediaries seeking to prevent such exposure need to inspect frames and avoid propagation of redirect frames over WebSocket
• In fact for strict correctness, intermediaries would seemingly need to either follow the physical TCP redirects themselves, while maintaining the same WebSocket entry point for WebSocket clients, or else convey to the client that a WebSocket-style redirect is necessary instead.

 

I believe our choices are limited as follows:

1. Make it illegal to send an AMQP 1.0 redirect frame over WebSockets

1. Define a way to require that an AMQP 1.0 connection disables redirects and then tcp-to-websockets intermediaries propagate blindly
2. Inspect frames at tcp-to-websockets intermediaries and require the intermediary to follow the physical TCP redirect on behalf of the WebSocket client

2. Enhance the AMQP 1.0 redirect frame to describe a URL, such as ws://websocket.org/amqp10 or tcp://example.com:5672 instead of just a pre-parsed network-host and port

1. Define a way to require that an AMQP 1.0 connection disables redirects and then tcp-to-websockets intermediaries propagate blindly
2. Inspect frames at tcp-to-websockets intermediaries and require the intermediary to convert the redirect frame to a WebSocket-style redirect instead

3. Leave behavior unspecified

1. Risks exposure of internal server information to WebSockets based clients for naive tcp-to-websockets intermediary implementations
2. Make a recommendation to avoid sending redirects to such tcp-to-websockets intermediaries, then the AMQP 1.0 server would be configured not to send redirects, without requiring any AMQP 1.0 protocol changes or AMQP 1.0 extensions.

At this point, I'm just trying to capture where we are rather than reaching a specific conclusion just yet.  Please respond with your thoughts, especially if there are other scenarios not included above that might help to further guide our thought process.

 

cheers,

-john.