Re: QUIC Address Discovery

[Tommy Pauly <[e-mail]>]

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