Re: QUIC Address Discovery

[David Schinazi <[e-mail]>]

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 <[e-mail]> wrote:

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