<div dir="ltr"><div class="gmail_default" style="font-size:small">So, a little curlicue just popped up.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">One of the problems I am going to need to solve at some point is to rebind a connection after the source IP address/port change. This can be caused by a NAT reconfiguration, a DHCP event or the user simply changes from one network to another. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The idea here is that Alice is going to establish a connection between her device and her Mesh Service Provider Hosts that is persistent and survives changes to the configuration on either end. We can assume the Host end will be on a static IP address and port[1]. But the client end is going to vary a great deal. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So in the ordinary state of affairs, the host recognizes packets from Alice by their source address+port and this is used to obtain the shared secret used to decrypt the remainder of the message.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">If the client source address+port change, the host is going to respond with a packet saying 'unrecognized connection' and bounce the source address and port back to the client. The client then realizes that its outbound connection config has changed and we need to rebind.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">One option would be a packet 'claiming' the prior source address+ip but that seems ugly. I would like to have as little connecting one packet to another  as possible 

enclair.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So the next thing would be to have an encrypted connection ID as follows:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">When connecting, Host specifies rebinding key and the connection ID.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">To rebind, the client takes the current time in ticks and creates a packet {time, connectionID} and encrypts it under the rebinding key. This is then accepted by the host if the 

time value is close enough to the host idea of UTC/PHBT.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">This works a bit better but we still have something of an issue because the rebinding key is the same for every connection to that host.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">One possibility that is relatively cheap is to use a collection of n pairs of encryption keys and issue a different set of pairs to each connection. So if there are a maximum of 64K connections to a host, we have 16 pairs of keys. Connections 0 and 1 will share the first 15 keys, only the last will be different. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The client encrypts the value {nonce, time} under each of their keys, the nonce value is different each time, the time changes. The nonce values are then fed into a KDF to generate the session key to decrypt {time, connectionID}.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">To verify the rebinding claim, the host attempts decryption under each of the possible keys, discarding the values whose time values don't match.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The nice thing about this approach is that we could even extend it to TOR/Mixmaster/etc. type applications in which nobody knows who is talking to whom. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">[1] The Host port/address should only change when Alice service provision is transitioned to a different host. And this should (usually) be a planned event that is properly managed. </div></div>