On Tuesday, 10 March 2020 02:42:01 UTC Erik Nygren wrote: > On Mon, Mar 9, 2020 at 10:32 PM Paul Vixie <p...@redbarn.org> wrote: > > On Monday, 9 March 2020 20:56:39 UTC Ben Schwartz wrote: > > > ... > > > > i propose that section 6.2 for "port", and all references to same, be > > removed. > > We discussed this some on one of our authors' calls following > my seeing you allude to this a few weeks ago. > > The rationale for keeping port is that HTTPS is not just about the "web" > use-case. > While for Web use-cases it is common for most things to always tcp/443, > there > are plenty of non-"Web" use-cases (such as API calls in data centers, > service meshes, etc.) > where non-standard ports are commonly used. I know that Tim keeps > highlighting > a desire to make sure we consider these use-cases.
that seems fair, but still somewhat risky. many times in the last year i've been told by people younger than me that accessing the internet from beyond the horizon of the far end is old-think and should die. somehow we have to avoid that culture war, because family, corporate, and sensitive/military networks will always exist, and with them, NAT, ALG, and firewalls. > There's a default when port is left out (perhaps that should be clarified > better?) > but there are cases when being able to switch to an alternate port has > value. > Another case where this applies is QUIC/UDP where udp/443 is commonly > used but where operators may wish to situationally use different ports. how can we properly inform those operators that if their audience is broader than their own cloud or data center, that is, including distant edge networks which are managed and private, that anything they offer on a non-default port will be unreachable, and often silently so? i can't defend and won't try to defend authoritarian public networks nor surveillance capitalism in internet service providers. that's not my concern. rather, it's the managed private edge network whose utility i'd like to preserve, without a generation of finger-pointing from what won't work in HTTP/3 because of differing basic assumptions. > Adding a warning that the use of non-default ports could have > operational challenges might be warranted. (...) > > A closely related issue is this one: > > https://github.com/MikeBishop/dns-alt-svc/issues/111 > > (regarding clarifying the default port.) > > Does this help address the concern? > It's helpful to know the historical context. issue 111 seems unrelated. what i'm trying to avoid is service operators trying to be reachable on port numbers that managed private networks at the remote edge won't recognize and so won't build flow-state for. so, warnings as to possible unreachability of non-default ports sound like a good starting point. but i think we need to do more. i am extremely worried about QUIC manageability, as described here: https://tools.ietf.org/html/draft-ietf-quic-manageability-06#section-3 this draft carefully enumerates, and eliminates, every potential method by which a remote-edge managed private network operator might be able to recognize a permitted (in-policy) flow. i feel like this is our last opportunity to set expectations about unrecognizable traffic, and to agree on some norm by which service operators can act willfully to be reachable. if i'm addressing the wrong audience, or you'd like to follow up 1x1, let me know and i'll adapt my signal pattern for these concerns. -- Paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
