Re: QUIC Address Discovery

[Ian Swett <[e-mail]>]

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.

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