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
