On 7/28/2016 12:33 AM, Toerless Eckert wrote: > You may want to move this discussion to the spud mailing list. Thats IMHO the > "improve STUN" solution. If this were a situation SPUD or STUN could improve, I might agree.
I don't think that's the goal of either system, though - there is no system that can interact with something that does everything possible to NOT interact. Joe > On Thu, Jul 28, 2016 at 09:20:32AM +0200, Olle E. Johansson wrote: >>> On 27 Jul 2016, at 17:18, Joe Touch <[email protected]> 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
