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