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). 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
