Subject: Re: [quicwg/base-drafts] Path Challenge Padding and Amplification Protection (#4257)

From: Jana Iyengar <[email-masked]>
Date: Tue, 03 Nov 2020 17:14:14 -0800

This is a response to the the discussion in #4264 on the potential performance cost of applying this limit on quiescence.

This roundtrip isn't the only perf issue on NAT rebinding:
- a server could reset the congestion controller
- the server infrastructure could send a GOAWAY since incoming packets are having to be redirected between servers, forcing a new connection for subsequent requests.

Despite the fact that we want to have continuity across NAT rebinding, we did not design for it to be seamless in terms of performance. I don't think we should start now.

Let's remember that NAT rebinding is the _uncommon case_, and typically occurs after quiescence of 30 or 60 seconds. A client app that wants to improve performance because this quiescence is a common pattern for it can always use one of many methods, including sending PINGs.

I'd strongly argue against making any recommendations. This is a question where I believe more experience is necessary to learn best practices.

-- 
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/4257#issuecomment-721457465

---

From: Martin Thomson <[email-masked]>
Date: Tue, 03 Nov 2020 18:26:13 -0800

I would also point out that we suggest that [path validation can be performed when using a path that hasn't been used for some time](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-8.2-4).  This isn't three datagrams, but it's now a fully padded datagram, which will allow for three packets.  That's pretty good relative to a full handshake, if an implementation chooses to do that.

-- 
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/4257#issuecomment-721475992

---

From: Nick Banks <[email-masked]>
Date: Wed, 04 Nov 2020 07:45:11 -0800

I agree with the sentiment that NAT rebinding is an edge case and it likely to have all sorts of performance related issues, and we don't really need to try to optimize for them. I personally think mentioning the known problems an possible solutions would be nice though.

The only real problem I left is that is seems there is some confusion (as seen from my discussion with Kazuho on the PR) about amplification protection and its relation to port-only NAT rebinding. Is it an exception to the rule or not? I didn't see any specific text on this one way or the other in the latest PR last I look, and I think it might be worth while to have some.

-- 
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/4257#issuecomment-721809411

---

From: Mike Bishop <[email-masked]>
Date: Wed, 04 Nov 2020 08:20:56 -0800

> If the client IP address has changed, the server MUST adhere to the anti-amplification limit; see {{address-validation}}.  Note that in the presence of NAT, this requirement might be insufficient to protect other hosts that share the NAT from amplification attack.

My reading of this text is that for a port-only change, you're not mandated to, but a cautious implementation could certainly choose to apply the limit to that case as well.

-- 
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/4257#issuecomment-721830189

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 04 Nov 2020 17:46:19 -0800

One point that seems to have been lost is the addition of an error code -- see discussion [here](https://github.com/quicwg/base-drafts/pull/4264#discussion_r514029543). I think adding an error code for NO_VIABLE_PATH is a good idea.

-- 
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/4257#issuecomment-722072681

---

From: Martin Thomson <[email-masked]>
Date: Wed, 04 Nov 2020 18:47:07 -0800

Let's do that as a separate PR, which I will write up now, so that I don't forget...

-- 
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/4257#issuecomment-722102990