Subject: [tram] Suresh Krishnan's Discuss on draft-ietf-tram-stun-path-data-03: (with DISCUSS and COMMENT)

From: "Suresh Krishnan" <[email-masked]>
Date: Wed, 20 Apr 2016 15:58:43 -0700

Suresh Krishnan has entered the following ballot position for
draft-ietf-tram-stun-path-data-03: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tram-stun-path-data/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The RespTransCnt mechanism seems to be a bit fragile and error prone
possibly leading to wrong conclusions on the client (please see my
example below). If you agree with my assessment, it is probably useful to
evaluate whether the added complexity of this RespTransCnt mechanism is
worth it for the potentially unreliable results it produces. 

Consider the following two cases (copy paste with a monospace font for
better readability)

Case 1: Upstream loss of first "re"transmission

|  Upstream loss  |
|  Client  Server |
+-+-+-+-+-+-+-+-+-+
|  1         x    |
|                 |
|  2         2,1  |
|    2,1          |

Case 2: Downstream loss of response to first "re"transmission with
re-ordering

| Downstream loss |
|  Client  Server |
+-+-+-+-+-+-+-+-+-+
|  1         1,2  |
|    x            |
|  2         2,1  |
|    2,1          |

How does the client differentiate between these two cases?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 5: IANA Considerations

Shouldn't the range for this option be in the 0x8000-0xBFFF range instead
of the 0x8000-0xFFFF range as currently stated by the draft?

Section 6:

I think this requirement is backwards and needs to be reworded.

"Unauthenticated STUN message MUST NOT include the PATH-CHARACTERISTIC
attribute in order to prevent on-path attacker from influencing
decision-making."

Suggest rewording to.

"The PATH-CHARACTERISTIC attribute MUST NOT be included in
unauthenticated STUN messages in order to prevent an on-path attacker
from influencing decision-making."

I also agree with Alissa about the vagueness of the attribute name.

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Thu, 21 Apr 2016 07:16:04 +0000

> On 21 Apr 2016, at 00:58, Suresh Krishnan <[email-masked]> wrote:
> 
So the problem is that the first retransmit (second transmit) of the STUN request arrives before the initial transmit and the response to the initial request is lost downstream. 

This means not able to distinguish between upstream reordering and downstream loss. I do not think adding complexity to solve this is worth it. If ICE is using this, it is still valuable information. And once (s)RTP starts flowing the reordering will quickly be discovered by out of orer packets. 

The draft needs to clearly spell out this limitation.

My main worry now is the RTT calculation. Am I right if I assume that the packets usually are delayed when reorder, and not magically put in front of the queue? If that is the case the RTT measurement should still be ok

Yes. We want it to be part of the IETF Review comprehension-optional range.

> from influencing decision-making.”
> 

+1
> I also agree with Alissa about the vagueness of the attribute name.
+1

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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 21 Apr 2016 11:05:09 +0000

> -----Original Message-----
> From: Pal Martinsen (palmarti)
> Sent: Thursday, April 21, 2016 12:46 PM
> To: Suresh Krishnan
> Cc: The IESG; [email-masked]; Simon Perreault; tram
> mailing list; [email-masked]
> Subject: Re: [tram] Suresh Krishnan's Discuss on draft-ietf-tram-stun-path-
> data-03: (with DISCUSS and COMMENT)
> 
> 
> > email addresses included in the To and CC lines. (Feel free to cut
> > this introductory paragraph, however.)
> >
> >
> > Please refer to
> > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > example below). If you agree with my assessment, it is probably useful
> > to evaluate whether the added complexity of this RespTransCnt
> > mechanism is worth it for the potentially unreliable results it produces.
> >
> So the problem is that the first retransmit (second transmit) of the STUN
> request arrives before the initial transmit and the response to the initial
> request is lost downstream.
> 
> This means not able to distinguish between upstream reordering and
> downstream loss. I do not think adding complexity to solve this is worth it. 

STUN retransmissions are paced out using RTO value discussed in RFC5389 and doubled after each retransmission. It looks like a  corner case where the retransmitted packet reaches the server before the previous packet.

-Tiru

> If ICE is using this, it is still valuable information. And once (s)RTP starts flowing
> the reordering will quickly be discovered by out of orer packets.
> 
> My main worry now is the RTT calculation. Am I right if I assume that the
> packets usually are delayed when reorder, and not magically put in front of
> the queue? If that is the case the RTT measurement should still be ok
> 
> >
> > Shouldn't the range for this option be in the 0x8000-0xBFFF range
> > instead of the 0x8000-0xFFFF range as currently stated by the draft?
>