This feels like a problem worth addressing. :) Given peer addresses can change during the connection in QUIC, I would lean away from a TLS extension. Also, it's unclear to me if there's any value for TCP. If not, that makes a QUIC specific solution even more compelling.
I'll let you figure out who the authors should be, but thanks for initiating the work. Ian On Tue, Oct 24, 2023 at 8:16 PM Tommy Pauly <tpauly= [email protected]> wrote: > Indeed, very much deja-vu to see this coming up! > > I do think this is still a good idea to be handled, at some layer. The > older draft did use random values for the request ID, not a sequence number. > > At the same time as that older draft, we had published a proposal to > handle this in TLS extensions: > https://datatracker.ietf.org/doc/html/draft-kinnear-tls-client-net-address-00 > > Thanks, > Tommy > > On Oct 24, 2023, at 4:19 PM, David Schinazi <[email protected]> > wrote: > > This sounds very similar to this draft: > https://datatracker.ietf.org/doc/html/draft-pauly-quic-address-extension > Might be worth chatting with the authors to see if they're still > interested in this topic. > > David > > On Fri, Oct 20, 2023 at 11:29 AM Kazuho Oku <[email protected]> wrote: > >> >> >> 2023年10月20日(金) 14:27 Kazuho Oku <[email protected]>: >> >>> Thank you for the draft. >>> >>> I do not have enough knowledge to comment on the use-case, but I have >>> one concern regarding the design. >>> >>> It seems to me that the credit (i.e., permitted sequence number space) >>> for sending REQUEST_ADDRESS frames is not bounded. >>> >>> Doesn't that mean that an attacker can issue an arbitrary number of >>> REQUEST_ADDRESS requests without sending acks, thereby causing state >>> exhaustion at the receiver? >>> >>> That leads me to wonder if it is the best way to implement this sort of >>> request-response protocol directly on top of QUIC frames. What is the >>> rationale for defining this protocol not on top of QUIC streams, as part of >>> the application protocol? >>> >>> FWIW, if use of QUIC streams is undesirable, one alternative would be to >>> use TLS post handshake messages (i.e., the CRYPTO stream at the application >>> packet number space). The benefit of such a design would be that the >>> address discovery mechanism would then work on any protocol built on top of >>> TLS (e.g., TLS-over-TCP, DTLS, QUIC). >>> >> >> PS. Or, if we are seeing an emerging pattern of using one QUIC connection >> for conveying multiple application protocols (looks at WebTransport), is >> there a need to agree on (if not standardize) how QUIC streams are shared >> among the application protocols? >> >> >>> >>> 2023年10月20日(金) 3:39 Marten Seemann <[email protected]>: >>> >>>> I just published an I-D that defines a mechanism for QUIC endpoints to >>>> discover their (public) IP address and helps them determine their position >>>> in the network (e.g. if they're behind a NAT): >>>> https://datatracker.ietf.org/doc/draft-seemann-quic-address-discovery/ >>>> This is especially helpful for QUIC nodes running in a p2p setting. >>>> >>>> A similar result could be achieved by using STUN on the same UDP >>>> socket, but there are several advantages of doing it inside of QUIC. See >>>> the draft for details. >>>> >>>> >>> >>> -- >>> Kazuho Oku >>> >> >> >> -- >> Kazuho Oku >> > >
