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 >
