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

["Godfrey, Robert X" <robert.godfrey@jpmorgan.com>]

> 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

I don’t think it really makes sense to say it is "illegal".  The redirect is basically saying "the resource you are looking for is not present at this location" - that fact cannot be changed.  The "redirect" is merely information that may be helpful to the client in finding the resource's new home.  Obviously without change, the information isn't terribly helpful to a websockets client, as it cannot use it - but it is in no worse a position than simply closing the connection/link with no additional information.

> 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

I think it's clear that we should define an additional property that can be put in the info map which can contain the URL for the connection to the remote container.  Obviously this can only be populated by the issuing broker if it knows the actual corresponding websocket endpoint - however this information is likely user driven configuration at the broker, so if the user owns the whole system (including the websocket tunneling) then this would not seem an issue.  Only if the websocket tunneling is not known about by the owner of the broker do we then have a problem which can only be solved by the intermediary - which would have to deep inspect the data flowing through it in order to enhance and redirect error conditions.

One action that *may* be useful is if websocket clients add a property/capability in the open frame which will indicate to the broker that the client is speaing over Websockets.  A naïve intermediary will simply pass this information on to the ultimate broker endpoint - the broker will then at least be aware that the ultimate client cannot use TCP connection information and therefore could generate a different error message which could be used to alert the broker owners that they need to add more (websocket URL) information for the redirect.

-- Rob

>     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.


Legally required information for business correspondence/Gesetzliche Pflichtangaben für Geschäftskorrespondenz: 
http://www.jpmorgan.com/pages/international/germany/email

From: amqp-bindmap@lists.oasis-open.org [mailto:amqp-bindmap@lists.oasis-open.org] On Behalf Of John Fallows
Sent: 10 June 2015 01:46
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.

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