2023年10月25日(水) 10:40 Ian Swett <[email protected]>:
> 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. > FWIW my complaint against the original approach was that it needs yet another mechanism to limit concurrency (as without one there would be concern of state exhaustion) and that I do not like it. Igor's approach to let endpoints unilaterally advertise peer addresses fixes the problem, at the same time providing the ability to announce addresses for each path at the correct moment (than using a request-response protocol). My +1 goes to taking that route and I have no reason to object. > 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 >>> >> >> -- Kazuho Oku
