You may want to move this discussion to the spud mailing list. Thats IMHO the "improve STUN" solution.
On Thu, Jul 28, 2016 at 09:20:32AM +0200, Olle E. Johansson wrote: > > > On 27 Jul 2016, at 17:18, Joe Touch <to...@isi.edu> wrote: > > > > Olle, > > > > On 7/27/2016 5:41 AM, Olle E. Johansson wrote: > >> ... > >> > >> This mess caused me sadly to suggest that we need to discuss breaking the > >> assumption that TCP delivery is always reliable > >> and implement retransmits even over TCP in the STUN protocol. STUN was > >> designed to discover middleboxes > >> with a focus on NAT. This is just another middle box to discover. > > None of this is news. One of the "features" of middleboxes is > > "transparent" TCP relaying. That device always destroys TCP reliable > > delivery semantics. > Even more sad - I just discovered them. > > > > This has been known since the mid 90s'. > > > > The challenge with STUN has always been that many middleboxes *do not > > want to be found*. > Which is one reason to improve STUN - right? > > > > >> The bigger picture is even more scary - what happens if our reliable > >> transport suddenly no longer is reliable? > >> > >> One developer from a well known mobile system vendor said ???well, I guess > >> that using TLS may help?????? > > > > Ask them *how* they think TLS helps. TLS relies on TCP semantics. > I asked the very same question, got no answer. Will get back to them. > > /O -- --- Toerless Eckert, eck...@cisco.com
