Re: [Gen-art] [tram] Genart last call review of draft-ietf-tram-turnbis-25

[Vijay Gurbani <[e-mail]>]

Dear Tiru, thank you for your response.  Please see inline.

On Wed, Jun 5, 2019 at 7:21 AM Konda, Tirumaleswar Reddy <
[e-mail]> wrote:

> > - S 2.4, Figure 3: "To partly mitigate this attack ...", just to be
> explicit,  [...]
>
>
> If the attacker spoofs the TURN client IP address and sends bogus Send
> indication to the server to a peer based on the permission installed by the
> TURN client to the peer, this attack cannot be mitigated the server unless
> (D)TLS is used. However, if the attacker spoofs the TURN client IP address
> and sends bogus Send indication to the server to peer but the client has
> not installed permission to the peer, this attack can be mitigated by the
> server.  The above points are covered in
> https://tools.ietf.org/html/draft-ietf-tram-turnbis-25#section-20.1.4.
>
>
>
> I think a forward reference to Section 20.1.4 can easily be made in
> Section 2.4 so the reader is aware of the what mitigation properties are
> being provided by S2.4 and which section is providing the remaining
> properties.  It will make your document much more complete.
>
>
>
> [TR] Okay, added the following line:
>
> The techniques to fully mitigate the attack are discussed in Section
> 20.1.4.
>
>
Great, thanks.


> > - S5, second to last paragraph: "...a long sequence of invalid..."
> Here, how
> >   long is "long"?  2 messages?  3 messages?  4 messages?  I think an
> explicit
> >   guideline may help make the error handling more robust.
>
> The threshold for long sequence of invalid TURN messages looks
> implementation specific to me, it was not specified in the base TURN spec
> (see https://tools.ietf.org/html/rfc5766#section-4).
>
>
>
> If it was not specified in the base TURN specification, then it may make
> sense to tighten up the behaviour in the bis specification, no?  This would
> be our chance to add a behaviour that can be measured and test cases
> created against it for protocol resiliency, no?  Or am I missing something
> on why the bis specification does not want to tighten this behaviour?
>
>
>
> [TR] The threshold values for long sequence of invalid TURN messages is
> not discussed in the TRAM WG, and I don’t have information on the typical
> values used in the field. Anyways, not documenting the threshold values
> would not cause any interoperable issues for a really low probability
> scenario.
>
>
Since the WG has not addressed a threshold for invalid TURN messages, I
suspect that there is nothing more to be done here from a process point of
view.  However, despite this being a low probability scenario, it will be
encountered and I suspect that it has been already but just not
documented.  So from a completeness point of view, it may make sense to
bring this to the attention of the TRAM WG and if they have decided, for
good reasons, to punt on this, then the issue is closed.  I can send an
email to the TRAM WG chairs, just to close the loop.


> > - S7.3, third paragraph: "...before trying to request any more ..."
> Here, how
> >   many times should a client retry the request upon the receipt of a 508?
> >   Again, an explicit guideline will help interoperability; otherwise,
> some
> >   clients will retry only once, other more than once, and so on.
>
> The number of attempts the client would retry is implementation specific.
> For example, if other TURN servers are available, the client can try to get
> the relayed transport address from the other TURN servers and need not
> retry the request (see https://tools.ietf.org/html/rfc8445#section-5.1.1.2).
>
>
> Same feedback as above; if the number of attempts were not specified in
> rfc5766, could we not do better now?  Any reason not to?
>
>
>
> [TR] The number of attempts depends on the context, For instance (1) If
> other TURN servers are available, and the client gets the relayed transport
> address from at least one other TURN server, the client need not retry the
> request (2) if the client is using ICE (
> https://tools.ietf.org/html/rfc8445), the client can keep retrying till
> the candidate gathering phase expires (please note ICE specification does
> not specify the candidate gathering phase timeout).
>

Okay, sounds good.

Thank you for attending to my comments.  I appreciate it.

- vijay

>