New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why MUST a server use the same port for HTTP/QUIC? #929

Closed
LPardue opened this Issue Nov 14, 2017 · 7 comments

Comments

Projects
None yet
4 participants
@LPardue
Copy link
Contributor

LPardue commented Nov 14, 2017

Section 3 on QUIC advertisement finishes with the following paragraph

Servers MAY serve HTTP/QUIC on any UDP port. Servers MUST use the same port across all IP addresses that serve a single domain, and SHOULD NOT change this port.

I have a few questions:

  1. Where does the requirement to use the same port come from?
    a) Does this lock server owners into a single port for eternity? (per-user port advertisement seems unlikely to me)
    b) What happens if a server does listen on different ports? Is it a connection error?
    c) I can see some hypothetical problems, e.g. where Alt-Svc is used for load shedding to a different origin that resolves to an anycast IP, leading to violation. Similar to what has been discussed on #560 and #253.
  2. Should clients pro-actively ignore non-compliant servers?
  3. Why are port changes recommended against?
  4. What should clients do if they see an Alt-Svc within the a HTTP/QUIC connection that changes the port.?

I appreciate the connection of this paragraph to QUIC advertisement. However, it actually seems quite fundamental guidance for HTTP/QUIC server deployments on how they should approach domain, IP and port usage. This makes me wonder if it should be broken out into a separate (sub)section or that it would pay to pull this information out into the manageability document.

@mikkelfj

This comment has been minimized.

Copy link
Contributor

mikkelfj commented Nov 14, 2017

What does it even mean to place servers on specific ports? That a front load balancer ensures that this happens?

In docker based cloud environments such as SWARM and Kubernetes each server instance would be running a random port outside the container and typically some specific port internally, such as port 8080, but often unrelated to the public port number.

@MikeBishop

This comment has been minimized.

Copy link
Contributor

MikeBishop commented Nov 14, 2017

Basically, it's saying that when the client receives an Alt-Svc advertisement that example.com can be reached at port x and hostname foo.bar, that should (and almost certainly SHOULD, but perhaps not MUST) mean a client can successfully receive example.com's content by connecting on port x to any IP address to which foo.bar resolves. That you're allowed to pick ports arbitrarily, but you can't effectively expose different ports from multiple endpoints for the same hostname.

There are ways around this -- publish multiple hostnames with multiple Alt-Svc records, for example. If you want to change ports, you would ideally have a transition period the duration of your Alt-Svc record lifetime in which both ports are accepted, though if you don't, a client that tries to connect could fail back to the origin and get the new record.

I could see an argument for putting this in the manageability draft, but it's almost more about the manageability of Alt-Svc than it is about QUIC or even HTTP/QUIC. It's pertinent to HTTP/QUIC because Alt-Svc is the only defined way to discover an HTTP/QUIC endpoint, so we want to help implementers get it right.

@MikeBishop MikeBishop added the -http label Nov 14, 2017

@LPardue

This comment has been minimized.

Copy link
Contributor

LPardue commented Nov 15, 2017

Ok, I can buy into the justification to keep it in the HTTP mapping document. I think the section could be tightened up a bit; there seems some fuzziness between advertising servers and providing servers. It's not a burning issue and I could prepare some text to improve things (as I see it).

I think this general topic is exacerbated by the implicit dependence on TCP as a fallback, I don't see any text in core documents that clearly state that.

I welcome guidance and would highlight that, with my naive QUIC-enabled server deployment hat on, it isn't immediately clear how I should design my Alt-Svc advertisement strategy to be compliant. Or what the failure conditions are if I fail to comply.

Does the case you describe uniquely apply to UDP ports or to TCP too? Is it acceptable to share the number but only across TCP/UDP (I'd say yes because they are distinct spaces)?

That you're allowed to pick ports arbitrarily, but you can't effectively expose different ports from multiple endpoints for the same hostname.

I'm not sure I see why this is a problem only for HTTP/QUIC, yet I have not seen similar requirements being expressed for other Alt-Svc advertisements.

To replay what I think you're saying, in example form:

Origin Alternative Prohibited Comment
https://example.com:443 h2=":443" No Conventional h2 case, alternative has same hostname and same port
https://example.com:443 h2=":12345" Yes? Conventional h2 case, alternative has same hostname and different port
https://example.com:443 h2="foo.example.com:443" No Conventional h2 case, alternative has different hostname and same port
https://example.com:443 h2="foo.example.com:1234" No Conventional h2 case, alternative has different hostname and different port
https://example.com:443 h2="foo.example.com:12345", h2="foo.example.com:12346" Yes? Two h2 alternatives that share the same hostname but different ports.
https://example.com:443 hq=":443" No Simple hq case, alternative has same hostname and same port number but vary by TCP/UDP
https://example.com:443 hq=":12345" No Simple hq case, alternative has same hostname and different port, permitted by TCP/UDP
https://example.com:433 hq="foo.example.com:443" No Simple hq case, alternative has different hostname and same port number, permitted by TCP/UDP and different host
https://example.com:433 hq="foo.example.com:12345" No Simple hq case, alternative has different hostname and different port, permitted by TCP/UDP and different host
https://example.com:443 hq="foo.example.com:12345", hq="foo.example.com:12346" Yes Two hq alternatives that share the same hostname but different port on UDP
https://example.com:12345 (a hq endpoint) hq=":12346" Yes A hq origin is advertising its own hostname with a different port
https://example.com:12345 (a hq endpoint talking quic version 0xff00000C) hq=":12346"; quic=D Yes A hq origin talking version C is advertising its own hostname with a different port and the different version D

I'm tired so may be completely misunderstanding things.

@MikeBishop

This comment has been minimized.

Copy link
Contributor

MikeBishop commented Nov 15, 2017

@LPardue

This comment has been minimized.

Copy link
Contributor

LPardue commented Nov 15, 2017

I need to think some more on this as things still seem a bit unclear.

The test points I've given are analogous to some cases we've tried out. There, the hostnames all resolve to the same set of IP addresses - with a single server process listening on different ports and configured with different vHosts.

@LPardue

This comment has been minimized.

Copy link
Contributor

LPardue commented Nov 20, 2017

So I've discussed this with a colleague and thought about this some more.

Firstly, the genesis for the text we've got now was not obvious to someone less familiar with the document development. In other words, the randomisation of port number is implicit in the text rather than explicit. For reference sake, the applicable GH items are #424 and #495.

However, meanwhile on #428 the WG has pursued the allocation of UDP port 443 to the IESG. This was recently closed off as completed.

So I'd say at this point, the paragraph in question is the victim of a higher-level tension that is yet to be resolved. I'd like to keep this ticket open in order for us track the issue such that it can be resolved once the other dependencies have been.

@mnot mnot added the design label Dec 12, 2017

@MikeBishop MikeBishop self-assigned this Mar 14, 2018

@MikeBishop

This comment has been minimized.

Copy link
Contributor

MikeBishop commented Mar 14, 2018

Need text to clarify what I'm talking about, because it's obviously unclear. PR to come soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment