IETF Logo Mail Archive

Re: [tram] STUNBIS: Retransmissions over TCP

"Olle E. Johansson" <oej@edvina.net> Tue, 26 July 2016 12:25 UTC

Return-Path: <oej@edvina.net>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A3B12D775 for <tram@ietfa.amsl.com>; Tue, 26 Jul 2016 05:25:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKOJHVjgW7uF for <tram@ietfa.amsl.com>; Tue, 26 Jul 2016 05:24:58 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 346AB12D770 for <tram@ietf.org>; Tue, 26 Jul 2016 05:24:57 -0700 (PDT)
Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 8AE1F426A; Tue, 26 Jul 2016 14:24:54 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: "Olle E. Johansson" <oej@edvina.net>
In-Reply-To: <c5dae3ae-e661-f5df-9add-d8174248bd30@jive.com>
Date: Tue, 26 Jul 2016 14:24:54 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <6F618695-A2C3-4224-8392-A69C2EAE2D5D@edvina.net>
References: <A088130D-4E99-4D04-9645-461BD40BCC54@edvina.net> <c5dae3ae-e661-f5df-9add-d8174248bd30@jive.com>
To: Simon Perreault <sperreault@jive.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/B00DXyVf2iGf99S-0ToJp46fFic>
Cc: Olle E Johansson <oej@edvina.net>, tram@ietf.org
Subject: Re: [tram] STUNBIS: Retransmissions over TCP
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jul 2016 12:25:01 -0000

> On 26 Jul 2016, at 14:09, Simon Perreault <sperreault@jive.com> wrote:
> 
> Le 2016-07-26 à 05:23, Olle E. Johansson a écrit :
>> Section 6.2.2:
>> 
>> "Reliability of STUN over TCP and TLS-over-TCP is handled by TCP
>>   itself, and there are no retransmissions at the STUN protocol level.”
>> 
>> When using STUN over mobile networks, I think this is a bad assumption.
>> We’ve seen many times that TCP proxys cause TCP to fail and they don’t follow
>> the original intention of TCP. The SIP message fails, even though TCP confirmed
>> delivery. I’ve got confirmation from a few developers that they started to send UDP-style
>> retransmits over TCP to get around this.
> 
> I think this will be met with incredulity and responses along the lines
> of "pcap or GTFO". :)
> 
It has been documented:
https://www.cs.montana.edu/mwittie/publications/Goel16Detecting.pdf

> I admit I'd like to see a more detailed description of the problem
> before we mandate such a profound change in the protocol. Would you be
> able to get one of those developers to come talk to us?
He is doing some research for me, but I hope to get him out of the closet.
The research paper is a good start though. Clearly shows that the TCP
is confirmed by a middle box in the path, not by the other end point.

> 
>> As a discovery protocol, I think we need STUN to discover situations like this.
>> I know it’s not religiously correct, but retransmits over TCP unfortunately makes sense 
>> in today’s broken network, especially for a protocol designed to discover middle boxes.
> 
> To be clear: you actually mean sending a second Binding request on the
> *same* TCP connection, right? Not opening a new one?

I think so, yes. 

Maybe these needs to go in another revision, but I wanted to open this
can of worms for discussion. 

/O

v2.23.0 | Report a Bug | By Email