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

On Tue, Jun 16, 2015 at 8:30 AM John Fallows <john.fallows@kaazing.com> wrote:

Okay, getting closer... :-)

More responses inline.

On Tue, Jun 16, 2015 at 2:24 AM Godfrey, Robert X <robert.godfrey@jpmorgan.com> wrote:

> Is it legitimate to enhance the structure of the info map in AMQP 1.0 when used over WebSockets?

> For example, could we add a path and perhaps a scheme? Or would that be deemed non-compliant with

> the AMQP 1.0 protocol specification as it stands today?

The info map on the error is deliberately open-ended. We can define the semantics associated with a new entry in the websockets binding and this would be compliant with the existing AMQP 1.0 specification. Obviously we can’t mandate its use, but we can recommend it is provided where possible.
Understood.

So, one possibility then would be to define some additional fields for both the amqp:connection:redirect and amqp:link:redirect types, mostly useful for our WebSockets case but potentially generic for any URL-based AMQP 1.0 transport.
scheme : interpreted as "tcp" if unspecified
path : interpreted as empty if unspecified
In combination with existing fields in those types...
hostname : the hostname of the container
network-host : DNS hostname or IP address of machine hosting the container
port : the port number on the machine hosting the container
address : the address of the terminus at the container (amqp:link:redirect only)
...we can construct a URL to follow the AMQP 1.0 redirect as follows:
scheme://hostname:port[path], e.g. ws://example.com:80/amqp10
...and then initiate network connectivity to "network-host" to begin the handshake.

However, browser environments do not allow such direct access to the network for sandboxed security reasons. The network-host would have no meaning in that environment because the physical connectivity would typically be determined by resolving the "hostname" in the WebSocket URL via DNS (in other scenarios a proxy may be the first physical hop).

Note: using the term "scheme" here rather than protocol since "wss" is not really a protocol, it is a scheme that unpacks to ws protocol over http protocol (during-handshake) over tls protocol, etc. The URL Wikipedia article makes the same point stating that the "mailto" URL scheme is not a protocol.

Perhaps we should also consider using "network-host" in the constructed WebSocket URL for redirect?
scheme://network-host:port[path], e.g. ws://example.com:80/amqp10
This may be more consistent with the TCP approach, given that there appears to be no requirement for the DNS name of the machine hosting the container to match the logical AMQP 1.0 hostname used in OPEN.
tcp://network-host:port, e.g. tcp://amqp.internal.net:5672
This distinction between hostname and network-host is a key point that will potentially influence how we proceed on the OPEN frame.

> Yes, this is a definite possibility, similar in spirit to the HTTP Host header that travels across any number of TCP intermediaries

> before arriving at the target server HTTP endpoint.

> Perhaps something like "location" with value equivalent to "ws://example.com/amqp10" would be a reasonable connection property to add in the OPEN frame from the client?

AMQP already carries a “host” in the open frame which sort of fulfils this purpose, however it does not carry the protocol being used to connect (i.e. it would say only “example.com” or maybe “example.com/amqp10”) – actually do we talk in the binding document about what value should be placed in the open frame here? My suggestion is that we additionally carry some property which conveys the protocol over which the initial connection was made.
That's a good point.

In the binding document, we currently specify that the HTTP Host header in the WebSocket handshake should identify the hostname of the AMQP 1.0 container and should match the hostname in the OPEN frame sent later over the same connection after the WebSocket handshake is completed.

IMHO, the (optional) hostname concept in the OPEN frame is part of the AMQP 1.0 domain, whereas the HTTP hostname in a WebSockets URL is part of the AMQP 1.0 transport and is not always required to match.

This interpretation seems consistent with the existing TCP semantics. For example, after following an amqp:connection:redirect using TCP transport, the OPEN hostname may no longer match the DNS name of the physical connection to network-host.

IMHO, there is an issue with the binding document in section 2.1 Opening a WebSocket Connection, specifically regarding the interpretation of the HTTP Host header.

Host HTTP header : Identifies the hostname of the AMQP container. The value provided here SHOULD match that provided later in the hostname field of the open frame, and during SASL negotiation (if used).

The AMQP 1.0 OPEN frame should own identification of the AMQP 1.0 hostname when clients connect over WebSockets just as for TCP, but the current wording of the binding specification seems to imply that the HTTP Host header dominates when the HTTP Host header and AMQP 1.0 OPEN hostname field differ.

For example, if the AMQP 1.0 OPEN hostname is omitted from a WebSockets client, the same semantics as TCP should be followed, namely "if no hostname is provided, the receiving peer SHOULD select a default based on its own configuration" (AMQP 1.0 specification, section 2.7.1). Otherwise, there appears to be no natural way to pick up the AMQP 1.0 broker default hostname when accessed by clients over WebSockets.

If we intend to have the AMQP OPEN frame hostname field dominate, then perhaps we just need to modify the wording:

Host HTTP header : this value MAY be used to identify the hostname of the AMQP container if the hostname field is omitted from the open frame during the AMQP handshake.

...or words to that effect. :-)
> One thing that is still not quite clear to me in this approach is how an AMQP 1.0 broker would discover the appropriate target

> WebSocket URL to redirect the client if the AMQP 1.0 broker is not directly already aware of WebSocket-based connectivity.

Yes – this could only work if the broker was aware that there is the possibility of intermediaries, or in general allows full configuration of the properties that get put in the error map for redirect. At some level all values in the redirect map must have come from user configuration – what we are implying here is that broker vendors should allow for the addition of properties to this configuration that they themselves do not understand.
Agreed.

An AMQP 1.0 broker configured for direct client access over WebSockets (without any tcp-to-websockets intermediaries) would already be in a position to issue amqp:connection:redirect and amqp:link:redirect frames modified as discussed above.

An AMQP 1.0 broker configured for direct client access over TCP, with WebSocket access via tcp-to-websockets intermediaries, would require additional configuration to be in a position to issue amqp:connection:redirect and amqp:link:redirect frames modified as discussed above.

Such brokers would also need to determine that a client could (only?) follow such a WebSocket-based redirect.

An AMQP 1.0 broker configured for direct client access over TCP, with WebSocket access via tcp-to-websockets intermediaries that also understand AMQP 1.0 protocol, would not require additional configuration because the intermediary could re-write amqp:connection:redirect and amqp:link:redirect frames modified accordingly as discussed above.

Btw, what is the expected behavior of an AMQP 1.0 TCP client that receives a redirect after connecting via SASL? Should the client use SASL for the redirected connection or not? Similar question for how to know whether to use TLS when following the redirect.

cheers,
John

-- Rob

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

From: John Fallows [mailto:john.fallows@kaazing.com]
Sent: 16 June 2015 01:41
To: Godfrey, Robert X; amqp-bindmap@lists.oasis-open.org
Subject: Re: [amqp-bindmap] AMQP 1.0 Redirect with WebSockets

Thanks for responding, Rob!

Please see comments inline below.

On Fri, Jun 12, 2015 at 5:41 AM Godfrey, Robert X <robert.godfrey@jpmorgan.com> wrote:

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

That's an excellent point.

Initially we had been focused on how to deal with an intermediary relaying tcp-to-websockets traffic. However, as you implicitly point out, an AMQP 1.0 broker may very well terminate WebSocket connections directly from clients, with no intermediary.

In that scenario, the logical redirect is very much required, for the same reasons that it would be required when servicing connections using AMQP 1.0 directly over TCP.

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

Agreed.

Is it legitimate to enhance the structure of the info map in AMQP 1.0 when used over WebSockets? For example, could we add a path and perhaps a scheme? Or would that be deemed non-compliant with the AMQP 1.0 protocol specification as it stands today?

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.

Yes, this is a definite possibility, similar in spirit to the HTTP Host header that travels across any number of TCP intermediaries before arriving at the target server HTTP endpoint.

Perhaps something like "location" with value equivalent to "ws://example.com/amqp10" would be a reasonable connection property to add in the OPEN frame from the client?

Alternatively, the client could offer a capability to follow a WebSocket-based redirect (with current WebSocket location) in the OPEN frame sent from client to server, and in parallel the server could send a desired capability for the client to follow a WebSocket-based redirect in the OPEN frame sent from server to client.

Having determined how to negotiate the ability for the server to issue and for the client follow a WebSocket-based AMQP 1.0 redirect (for both connection and links) we would still need to determine how best to describe the redirect frame as it relates to standard AMQP 1.0 frame syntax - thats the previous discussion above about item #2: Enhance the AMQP 1.0 redirect frame to describe a URL.

One thing that is still not quite clear to me in this approach is how an AMQP 1.0 broker would discover the appropriate target WebSocket URL to redirect the client if the AMQP 1.0 broker is not directly already aware of WebSocket-based connectivity.

Looking forward to more discussion on the call tomorrow. :-)

cheers,

-john.

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

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

amqp-bindmap message