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] > <mailto:[email protected]>> wrote: >> >> >> 2023年10月20日(金) 14:27 Kazuho Oku <[email protected] >> <mailto:[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] >>> <mailto:[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
