<div dir="ltr"><div dir="ltr"><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 Wed, Apr 14, 2021 at 2:50 PM Christian Huitema <<a href="mailto:huitema@huitema.net">huitema@huitema.net</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"><br>
<br>
I have personally done  work on that topic, including the implementation <br>
of randomized MAC addresses in Windows 10, and the specification of a <br>
privacy preserving version of DHCP (RFC 7844). These specifications hide <br>
the "fixed" MAC address of the client, but do not hide the address and <br>
SSID of the server. There are indeed scenarios in which you want to hide <br>
the identity of both parties -- mobile servers, personal area networks, <br>
meeting in airport lounges, etc. RFC 8882 provides a list of <br>
requirements in these scenarios, but I don't know of any deployed <br>
protocol that meets these requirements.<span class="gmail_default" style="font-size:small"></span> Anonymous rendezvous is a vexing <br>
problem.<br>
<br>
-- Christian Huitema<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">I have been working on this very problem. and come up with a protocol:</div></div><div><br></div><div><div class="gmail_default" style="font-size:small"><a href="https://www.ietf.org/id/draft-hallambaker-mesh-rdp-00.html">Mathematical Mesh 3.0 Part VI: Reliable Datagram Protocol (ietf.org)</a></div><br></div><div><div class="gmail_default" style="font-size:small">I concur with Christian, <span class="gmail_default"></span> Anonymous rendezvous is a vexing problem. And it is not a problem I think worth solving.</div></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">If Alice's phone wants to talk to Alice's tablet via a direct, peer to peer connection, this is not a symmetric problem. The interaction MUST be initiated by one device or the other. And that means that the initiating device has to discover what IP address etc the other is currently sitting on. And that is not simple when we consider constraints such as NAT etc.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So the rule I have is that every connection is established by an initiator talking to a responder and the responder has to be permanently available via a static IP address that is either on the same LAN as the initiator or is on the public Internet (i.e. not behind a NAT).</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Since neither Alice's phone nor her tablet meet that criteria, we need an intermediary to broker that type of connection. This is a presence problem and both devices need to have a connection to at least one presence service.</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">For IoT devices that only connect to a LAN owned by Alice, the presence service should probably be on the LAN side of the NAT scope so they still work when the house loses its external Internet connection. For the mobile and tablet, they probably need a presence service on the Internet and a NAT tunnelling strategy.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I have taken a very different approach to maintaining connections to the traditional crypto approach precisely so that I can support these use cases fluently.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">* Datagrams can span packets and be up to at least 64KB of data</div><div class="gmail_default" style="font-size:small">* Connections are essentially permanent once created unless one party decides it isn't.</div><div class="gmail_default" style="font-size:small">* AES keys are constant for the lifetime of a stream.</div><div class="gmail_default" style="font-size:small">* I rekey AES for every Datagram</div><div class="gmail_default" style="font-size:small">* The only reason to renegotiate the shared secret is for forward secrecy, this results in a new stream being created.</div><div class="gmail_default" style="font-size:small">* A device can issue a 'connection ticket' consisting of a network endpoint, shared secret and stream ID that is issued to a broker such as a presence service.</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">This approach allows me to do things like perform a one time 'device binding' to a digital camera and then configure it so that the user just snaps photographs wherever, whenever they are and those image files automatically end up on their home file server (or one in the cloud). The image files are only deleted off the device after it is confirmed that they have been fully and correctly backed up according to the user's specified policy.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Establishing a complete separation between RDP streams and the network endpoints across which they are realized allows for some really interesting and useful approaches. </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"><br></div><div><br></div><div><br></div><div> </div></div></div></div></div>