Subject: [quicwg/base-drafts] Erik Kline's Transport Comment 6 (#4518)

From: Lucas Pardue <[email-masked]>
Date: Tue, 05 Jan 2021 19:36:35 -0800

Erik Kline said:

> [ section 19.18 ]
> 
> * I'm idly wondering if there would be any debugging value in the response
>   including the IP & port to which the response is being sent (i.e. from
>   which the path challenge was received) ... assuming the packet with the
>   PATH_RESPONSE frame is protected.
> 
>   Not important though, and perhaps it was already discussed and rejected.
>   (or maybe it's better as some future, entirely separate PATH_INFO frame)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4518

---

From: Erik Kline <[email-masked]>
Date: Tue, 05 Jan 2021 21:40:20 -0800

I don't know that this needs any more consideration that might have already been given such ideas during development, if it warrants any consideration at all.

To be slightly more clear:

  1. obviously I'm **not** suggesting features that would enable a full STUN/TURN set of functionality
  2. I was just thinking of the "IP:port reflection" functionality (without the bit flipping), by which I mean the "reflexive transport address" vis. [RFC 8489](https://tools.ietf.org/html/rfc8489) section [14.1](https://tools.ietf.org/html/rfc8489#section-14.1) MAPPED-ADDRESS and **not** the [14.2](https://tools.ietf.org/html/rfc8489#section-14.2) XOR-MAPPED-ADDRESS

Also, I don't think this necessarily improves the security situation so much as it helps the endpoint discover whether NAT games are afoot.  And at this point I can't recall what protection level applies to packets that can carry these frames.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4518#issuecomment-755092385

---

From: Martin Thomson <[email-masked]>
Date: Wed, 06 Jan 2021 01:37:14 -0800

It's probably a bit late to consider additions of this nature.  This is probably a good candidate for extension, but as I don't think that we have any direct use for a reflexive address reporting utility in the protocol, I don't think we need to add one.

To elaborate a little more: QUIC doesn't attempt to play the same sorts of NAT-guessing games that STUN does.  QUIC generally isn't looking to create new flows to different destinations, we're happy with the one flow and most NATs know how to get return packets back in that configuration.  Maybe if a server was behind a NAT in a p2p environment, this might have value, but some of the deployments suggestions I've seen for that just use STUN alongside QUIC (which is possible) to get that done.

(This might be the first time that this particular idea has been suggested, though it probably came up once or twice in our many migration discussions.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4518#issuecomment-755191787

---

From: ianswett <[email-masked]>
Date: Wed, 06 Jan 2021 08:03:43 -0800

I agree with @martinthomson that it's late for additions like this an it's not necessary for any functionality in QUIC v1, but I can definitely see it being useful as an extension or a future version of QUIC.

I don't recall this ever being discussed at length or there being an issue for it, presumably because it wasn't particularly useful for HTTP/3.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4518#issuecomment-755388710

---

From: Erik Kline <[email-masked]>
Date: Thu, 07 Jan 2021 07:12:16 -0800

Fair enough!

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4518#issuecomment-756175707

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 08 Jan 2021 08:37:21 -0800

I think we can close this with no action. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4518#issuecomment-756858592

---

From: Martin Thomson <[email-masked]>
Date: Fri, 08 Jan 2021 20:22:25 -0800

Closed #4518.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4518#event-4186711202