Hi Vijay,
Please see inline [TR2]
From: Vijay Gurbani <vijay.gurbani@xxxxxxxxx>
Sent: Thursday, June 6, 2019 6:09 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@xxxxxxxxxx>
Cc: gen-art@xxxxxxxx; draft-ietf-tram-turnbis.all@xxxxxxxx; ietf@xxxxxxxx; tram@xxxxxxxx
Subject: Re: [tram] Genart last call review of draft-ietf-tram-turnbis-25
|
CAUTION: External email. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
|
Dear Tiru, thank you for your response. Please see inline.
> - 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.
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.
[TR2] Sure, go ahead. If members in the WG respond, I will update the draft accordingly.
Cheers,
> - 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).
Thank you for attending to my comments. I appreciate it.
|
