Subject: [tram] STUNBIS: Retransmissions over TCP

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 26 Jul 2016 11:23:57 +0200

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.

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.

With sadness,
/O

---

From: Simon Perreault <[email-masked]>
Date: Tue, 26 Jul 2016 08:09:30 -0400

> retransmits over TCP to get around this.

I think this will be met with incredulity and responses along the lines
of "pcap or GTFO". :)

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?

> 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?

Simon

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 26 Jul 2016 14:24:54 +0200

> On 26 Jul 2016, at 14:09, Simon Perreault <[email-masked]> wrote:
> 
It has been documented:
https://www.cs.montana.edu/mwittie/publications/Goel16Detecting.pdf

> 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.

> *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

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Tue, 26 Jul 2016 18:20:16 +0530

The use cases I've heard are:
1. A (broken) middle box doing TCP<->UDP inter-working: If the message get
lost on the UDP side and the transmissions are handled by the TCP stack (in
the kernel), the middle box may not retransmit the message over UDP causing
problem for endpoints.
2. Mobility: If the IP address changes, TCP may not know whether the
message was sent or not.

These are what I've overheard, though I haven't come across the problem
myself..

Muthu

On Tue, Jul 26, 2016 at 5:39 PM, Simon Perreault <[email-masked]>
wrote:

> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 27 Jul 2016 09:23:16 +0200

> On 26 Jul 2016, at 14:50, Muthu Arul Mozhi Perumal <[email-masked]> wrote:
> 
> 1. A (broken) middle box doing TCP<->UDP inter-working: If the message get lost on the UDP side and the transmissions are handled by the TCP stack (in the kernel), the middle box may not retransmit the message over UDP causing problem for endpoints.
> 2. Mobility: If the IP address changes, TCP may not know whether the message was sent or not.
> 
> These are what I've overheard, though I haven't come across the problem myself..
THank you for your feedback!

I think there is something here to explore for STUN and the various usages, but we may not
be ready to open up StunBIS for it. It is a middlebox problem we need to handle, and I think
that STUN is a tool developed to discover middleboxes - NAT was the first one. The STUN RTT
measurement come in handy here, as the report I referred to clearly sees different latencies
depending on direction indicating that a TCP proxy was in the path. Maybe the RTT draft needs
to consider one-way too in order to assist detection?

/O
> 
> Muthu
> 
> On Tue, Jul 26, 2016 at 5:39 PM, Simon Perreault <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tram <https://www.ietf.org/mailman/listinfo/tram>
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 27 Jul 2016 07:21:42 -0500

Dear All,

This conversation is starting out in the right place (thank you, Olle), and
what TRAM needs to do with STUNbis NOW should stay in TRAM, but I would
appreciate someone summarizing what folks are seeing, with appropriate
references, to TSVAREA.

The larger conversation is something TSV needs to know about.

Thank you all.

Spencer, as TRAM AD

On Jul 27, 2016 02:23, "Olle E. Johansson" <[email-masked]> wrote:
>> 1. A (broken) middle box doing TCP<->UDP inter-working: If the message
get lost on the UDP side and the transmissions are handled by the TCP stack
(in the kernel), the middle box may not retransmit the message over UDP
causing problem for endpoints.
message was sent or not.
myself..