Change:
This LGTM and would address my concern.
I think this is good to go.
immediately reset the congestion controller and round-trip time estimator for the new path to initial values (see Sections A.3 and B.3 in {{QUIC-RECOVERY}}) unless it has knowledge that a previous send rate or round-trip time estimate is valid for the new path. For instance, an endpoint might infer that a change in only the client's port number is indicative of a NAT rebinding, meaning that the new path is likely to have similar bandwidth and round-trip time. This is kind of an odd formulation. What knowledge does the endpoint have in this case that we don't already have? Why not just make an explicit exception for port-only changes?
...because that would create an explicit endorsement of the practice. This text was somewhat carefully negotiated to avoid creating that sort of endorsement. That said, I expect people to ignore port. But I also expect some servers to be able to recognize the presence of a NAT that uses a pool of addresses and to treat all of those addresses as equivalent also. And in IPv6 there are many cases where parts of the address are not relevant (/64 per host means that you might as well not bother with the last half in a lot of cases now). So there is a risk in narrowly permitting port variations that certain types of address validation shortcuts are implicitly excluded.
I see what you mean, but I think that this kind of hinting at the user without explicitly stating it does a disservice to the implementor, who then needs to figure it out for themselves. IMO we should explicitly state the exceptions that the WG believes are permissible and then add this escape hatch text.
I'm not sure I have a better suggestion than the existing text for NAME concern, but I noticed a different small possible issue. The process of validating the path is very likely to give you a RTT measurement for the path, so it might be worth tweaking the MUST to say "MUST ... and discard any round trip estimates associated with the old path" or just "MUST not use round trip time measurements from the old path on the new one."? One could keep the estimates for the old path, as we've discussed, so I think saying you must reset or discard the information is a bit strong.
This isn't meant to be a disservice to the implementer -- to an unaware implementer, the requirement is clear: reset the RTT and the congestion controller. This is meant to provide an escape hatch for those experimenting or for those who have other sources of information. For example, it might be possible that address changes within a /24 are also NAT rebinding (and there's evidence of this), so we want to allow endpoints to use this knowledge, but we don't want to specify that behavior. I think a "MUST ... unless" captures that.
I agree that we should leave room for the implementor do do more. However, what I am saying is that we already know that port changes (and perhaps lower-64 changes for v6) are likely to be rebinding and so we should tell people that rather than asking them to figure it out for themselves.
I would be weary about a blanket statement that if a port (or address) change is merely rebinding, then transmission should go on with the previously estimated rate and window. The port or address change is a network event indicating that something changed. It used to be that NAT rebinding were strongly correlated with transmission hiatus -- the NAT would recycle bindings if it did not observe traffic for some time, typically about 30 seconds. It may also well be that the rebinding indicates a routing change on the path to the NAT. In both cases, the network condition did change and merely reusing the old estimates is a mistake.
I'm not sure I agree with this analysis, but if that's the group consensus then we should prohibit this behavior, not have a MUST NOT with an unclear exception. My point is that what goes in this document should be what the WG thinks that generic internet servers ought to do.
I agree resetting congestion state is better in this case. Since NAT rebinding only occurs on idle, resetting state seems in spirit of past recommendations around resetting congestion window on idle. I think we should remove the exception.
NAME it would be nice if congestion response allowed better choices than "continue as nothing happened" and "go back to start as if nothing was known about the path". I think the endpoints have some knowledge about the past of the path, and also an indication that this knowledge could be wrong. How wrong might depend on timing, e.g., time since past measurements. I could see applying some Bayesian logic there. But this is clearly research.
I'd like to point out that this is unilateral endpoint behavior, and removing the exception does not mean that deployments won't implement different things here. This is at a minimum something that implementations will play around with, and the exception allows room for it because we believe it's safe to allow some discretion here.
NAME we might debate how safe it is to keep sending as if nothing changed. There is some risk of creating a spike of congestion on the new path if the assessment was wrong. On the other hand, doing that when "just the port changed" will work most of the time, especially if the congestion controller already shrinks the window after the link goes idle, which many do. So in the hand I agree that we are probably better off just keeping the existing text.
I'm still happy with the existing text, FWIW. I think it captures the important points.
NAME pointed me to this text, which could add confustion on this point. URL My current reading is that you don't have to reset the congestion controller if you're pretty sure it's a NAT rebind, but you still need to perform path validation. Is that correct?
Follow-up Q: Do you need to wait for a PATH_RESPONSE before sending on the new path(which delays application data 1RTT), or can you concurrently validate the path while also starting to use it?
There is a security risk if a client could convince a server to send data to an arbitrary address. The challenge mitigates that risk.
Could an amplification attack limit be imposed to allow some usage of the new path before validating it?
We're in the process of implementing this, and as currently specified the draft adds a round trip delay compared to what we did in GoogleQUIC. Using a middle ground with an amplification limit as suggested by NAME might be required to ensure reasonable performance.
The amplification limit can probably be used, but it's likely going to not be good enough, since you probably just received a request after a long pause and not a full sized packet. NAME Does GQUIC have this amplification protection at the moment?
NAME currently Connection Migration on gQUIC does not use an amplification limit nor path validation. We haven't seen that kind of attack at scale. I think we should add those protections when we implement the IETF take on Connection Migration, but we'll need to make sure the performance hit isn't too high. If we go with the amplification factor then we can have the client send a bunch of padding to make it work.
It'd be great if clients could send a full-sized datagram after quiescence. But regardless, I'm not too worried about servers going above 3x in this case, because only an on-path attacker can use this behavior to mount a reflection attack.
In section 9.3 "Responding to Connection MIgration", we allow sending the initial window per estimated round-trip time. There's no mention of amplification limit I can see. URL An endpoint MAY send data to an unvalidated peer address, but it MUST protect against potential attacks as described in Section 9.3.1 and Section 9.3.2. In 9.3.1: Until a peer's address is deemed valid, an endpoint MUST limit the rate at which it sends data to this address. The endpoint MUST NOT send more than a minimum congestion window's worth of data per estimated round-trip time (kMinimumWindow, as defined in [QUIC-RECOVERY]). .... If an endpoint skips validation of a peer address as described in Section 9.3, it does not need to limit its sending rate.
Ah, yes, thank you for finding that text. I think we did that because of what Kazuho said -- that only an on-path attacker can mount this reflection attack. NAME NAME Given the text in 9.3, is there a problem anymore?
NAME we'll have to run experiments to confirm that. Since kMinimumWindow is defined as 10 packets, that might be enough for most requests. If it doesn't turn out to be enough, we may need to change the limit to - but we'll collect data before we propose a change like that
Proposed resolution is to close with no action, consensus to be confirmed
I think I'm ok with close with no action from a design perspective, but I find having this text in multiple locations and having similar, but different statements quite confusing. I'd rather you label this editorial and we try to make the text a bit clearer and/or better organized.
NAME and my read of the discussion was that a solution that was going to address the issue would have to be a design change. Hence it's a design issue, and the resolution is "no change". We can definitely spin out some related editorial changes into another issue though.
NAME -- what text organization do you think might help?
OK, I'll label this as ready, and you can spin a new editorial issue for any such changes.
NAME a state transition diagram would be very nice I think, similar to streams. And maybe some reorg, but I need to re-read the relevant sections at once to understand how that could work.
More discussion
FYI, I've written up Ted's suggestion from the mailing list as (with some word-smithing)
Due to the discussion during the consensus call, we'll run this through the Late-stage process again.
We should mark it proposal-ready though, right?
For clarity sake, the proposed resolution is .
Discussion on-list continues, but if this is the direction we choose... believe that the current text is appropriate. As I said, I don't have a strong opinion about the outcome, but we shouldn't just hint to people that they should ignore the port. -Ekr

Discussion:
On confirming a peer's ownership of its new address, an endpoint MUST immediately reset the congestion controller and round-trip time estimator for the new path to initial values (see Appendices A.3 and <del> B.3 in QUIC-RECOVERY) unless it has knowledge that a previous send rate or round-trip time estimate is valid for the new path.  For instance, an endpoint might infer that a change in only the client's port number is indicative of a NAT rebinding, meaning that the new path is likely to have similar bandwidth and round-trip time. However, this determination will be imperfect.  If the determination is incorrect, the congestion controller and the RTT estimator are expected to adapt to the new path.  Generally, implementations are advised to be cautious when using previous values on a new path. </del> <ins> B.3 in QUIC-RECOVERY) unless the only change in the peer's address is its port number.  Because port-only changes are commonly the result of NAT rebinding or other middlebox activity, the endpoint MAY instead retain its congestion control state and round-trip estimate in those cases instead of reverting to initial values.  In cases where congestion control state retained from an old path is used on a new path with substantially different characteristics, a sender may transmit too aggressively until the congestion controller and the RTT estimator have adapted.  Generally, implementations are advised to be cautious when using previous values on a new path. </ins> There may be apparent reordering at the receiver when an endpoint sends data and probes from/to multiple addresses during the migration