<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 29, 2021 at 6:31 PM jrzx <<a href="mailto:jrzx@protonmail.ch">jrzx@protonmail.ch</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div> On Friday, March 26, 2021 8:41 AM, Phillip Hallam-Baker <<a href="mailto:phill@hallambaker.com" target="_blank">phill@hallambaker.com</a>> wrote: <br></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><div style="font-size:small">A host accepts UDP requests from multiple clients which MAY change their Source IP address and port at any time because of NAT deployment. <br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div><div>Not at any time, not in the middle of active conversation, because that would break TCP and flow control</div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Yes, in the middle of a connection. TCP/IP is a separate protocol from UDP/IP. UDP doesn't have flow control. We are adding it at the application layer. </div><div class="gmail_default" style="font-size:small"><br></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>If your NAT has some ports dynamically mapped, to allow incoming packets, it is not going to move the ports it has mapped to a new network address.</div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Again, this happens frequently. Some NATs drop the connection after a few seconds of inactivity. The idea here is to be able to recover from that situation.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">We also want to deal with situations like Alice is connected to a video conference on her phone, she enters the house, she now has WiFi and it is fast. So seamlessly detect the fact that a faster connection became available and make use of it. Or make use of both.</div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>Which means that time your source address changes, you are going to be renegotiating flow control, in which case you should be negotiating a new shared secret from asymmetric secrets.</div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Not for these use cases. And some of the devices may not have public key available.</div><br></div><div><div class="gmail_default" style="font-size:small">In the longer term, I want to be able to keep a symmetric key session going Kerberos style forever if need be. It is highly likely that post quantum crypto will have performance or other drawbacks. The drawback might turn out to be not being delivered in a form we can use on time. So I do not want to rely on rekeying.</div><div class="gmail_default" style="font-size:small"></div></div><div class="gmail_default" style="font-size:small">QUIC is optimized to one particular use case. I am looking to optimize for subtly different use cases and take account of the traffic analysis considerations.</div></div></div>