Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-httpssvc-02.txt

[Paul Vixie <[e-mail]>]

On Tuesday, 10 March 2020 02:42:01 UTC Erik Nygren wrote:
> On Mon, Mar 9, 2020 at 10:32 PM Paul Vixie <[e-mail]> 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