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

["Pal Martinsen (palmarti)" <[e-mail]>]

> On 21 Apr 2016, at 00:58, Suresh Krishnan <[e-mail]> wrote:
> 
> 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?
> 
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

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

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

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

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

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