[jira] [Commented] (PROTON-160) Allow open.hostname to be configured independently of network hostname

["Rafael H. Schloming (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/PROTON-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505199#comment-13505199 ] 

Rafael H. Schloming commented on PROTON-160:
--------------------------------------------

I think this issue is related to a couple of others: PROTON-161, PROTON-90, and PROTON-136, and to some extent PROTON-164 (specifically the portion pertaining to redirect).

The spec has the following language regarding the hostname field:

           "The name of the host (either fully qualified or relative) to which the sending peer
            is connecting. It is not mandatory to provide the hostname. If no hostname is provided
            the receiving peer SHOULD select a default based on its own configuration. This field
            can be used by AMQP proxies to determine the correct back-end service to connect
            the client to.

            This field MAY already have been specified by the <xref name="sasl-init"/> frame, if a
            SASL layer is used, or, the server name indication extension as described in
            RFC-4366, if a TLS layer is used, in which case this field SHOULD be null or contain
            the same value. It is undefined what a different value to that already specified
            means."

Note in particular the relationship between the TLS hostname and this field.

So PROTON-161/PROTON-90 have identified the need to somehow specify a name to match against the TLS certificate. I think there may be a requirement implicit in PROTON-136 to key the session cache off of something meaningful to the TLS layer, and of course we have this Jira. It sounds to me like these all fall under the general problem that the "TLS endpoint" needs to be able to be independent from the "TCP endpoint", although for obvious reasons it's desirable to make it easy (i.e. default them) to be the same.

>From what I can tell, it seems like the open.hostname field, the session key used for PROTON-136, and the name we match against the TLS certificate all should come from a single source. Right now that source is the message address. Assuming that is the right source for that info we need to specify exactly how to transform the address into this "TLS hostname" thing. This relates to PROTON-163, as that is pointing out a specific case where we are transforming incorrectly, but it would also be good to know how to handle other kinds of URLs as the URL syntax allows lots of random cruft in there and I don't know offhand what is supposed to be part of this canonical TLS hostname thingy and what isn't, e.g. if you do amqp://host:port/blah, is the port part of it or not? I'm guessing there's some possibly authoritative info out there we can crib from on what browsers do as this is essentially the same problem as transforming the typed-in URL into the HTTP "Host" header.

Now as for this JIRA in particular, I think we need to understand the overall resolution process that messenger goes through when resolving the TCP connection info for a given message address, and this needs to somehow account for redirects as mentioned in PROTON-164. Right now messenger will do a DNS lookup on the host portion of the message address in order to determine the TCP endpoint, however it only does this the first time it encounters a message to a given address. All subsequent messages to the same address will get sent down the same connection that was established by the first message for as long as that connection survives. Now assuming we transparently handle redirects as simply a further step in the resolution process, then I would expect this scenario to extend pretty well. On the first message we'd do the DNS lookup, connect to a redirector, and then establish a permanent connection and send all subsequent messages there. What's not clear to me though is how this would interact with option (1). If we're specifying a network address to connect to on a per message basis, then what happens if we have already have an existing connection for the address specified in this message, and this existing connection doesn't match the supplied network address? If we use the existing connection then I would say we aren't really specifying network connectivity on a per message basis, we're actually just short-circuiting/overriding the resolution process, i.e. this is equivalent to simply configuring a set of aliases for the messenger, e.g. when you see address "foo", make your TCP connection to "bar". On the other hand if we don't use the existing connection we could end up with some pathological behaviour if you point your message to a redirector since we would end up making a new connection for every single message we send.

Apologies for the long and rambling post, I probably shouldn't have tried to tackle this one so late. ;-) I guess I'll just wrap up by asking A) does any of the above make sense, and B) do you have any more info on the overall scenario you're trying to support, and C) is it worth investigating some kind of option (3) along the lines of the aliasing mentioned above?
                
> Allow open.hostname to be configured independently of network hostname
> ----------------------------------------------------------------------
>
>                 Key: PROTON-160
>                 URL: https://issues.apache.org/jira/browse/PROTON-160
>             Project: Qpid Proton
>          Issue Type: Improvement
>          Components: proton-c
>    Affects Versions: 0.1, 0.2
>            Reporter: David Ingham
>
> In a scaled-out, multi-tenant broker environment, the host on which the container is running is often different from the host to which a client is establishing the tcp connection. The 'hostname' field in the connection open performative was added to support this scenario. Currently there's no way to control this from the Messenger API.
> Options include:
> (1) (preferred) add a new 'networkhost' field to Message to allow the network address to be specified. If provided, this information would be used when establishing the network connection and the data in the 'address' field would be used in the connection open hostname field. This is somewhat in line with the way that connection redirect (amqp:connection:redirect) is specified.
> (2) extend the syntax of address with query string to supply hostname, e.g., username:password@tcpaddress:tcpport/entityname?hostname=foo where 'foo' would become the hostname used in the connection open frame. This is the approach used by the current Qpid AMQP 1.0 JMS client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira