Peace, On Sat, Jul 17, 2021, 3:28 AM Mark Nottingham <[email protected]> wrote:
> I appreciate the enthusiasm for the tangential here :) but to return the > original topic -- I realised that this is obliquely discussed in the > applicability draft: > > https://quicwg.org/ops-drafts/draft-ietf-quic-applicability.html#name-port-selection-and-applicat > > So at a minimum, it seems like we should expand upon that text to make > this issue more clear. I'll try to start a PR. > > If I read the thread correctly, people seem to think (somewhat > pessimistically, but realistically) that protocols susceptible to > reflection will continue to be created, so hardcoding a list into the RFC > isn't workable. > > Instead, I'm currently thinking the best approach will be to: > > 1. Expand the applicability document as per above, using examples from the > list I gave, since they're already pervasive > 2. Start a discussion in the TSVWG about the possibility of adding a new > column to the port registry to capture this information > What if we add a new key to the DNS SVCB record so that an HTTP/3-enabled service could indicate the source port ranges it does [not] want or is [not] able to see? The HTTP/3 servers would probably be using SVCB anyway for a number of applications. -- Töma
