Hi Vijay, Please see inline [TR]
From: Vijay Gurbani <[email protected]> Sent: Tuesday, June 4, 2019 7:45 PM To: Konda, Tirumaleswar Reddy <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] 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. ________________________________ Tiru: Thank you for attending to my comments. Please see inline for some more questions based on your comments. Thank you for your time! On Tue, Jun 4, 2019 at 4:46 AM Konda, Tirumaleswar Reddy <[email protected]<mailto:[email protected]>> wrote: > Major: > > - My advice would be to put S3 (Terminology) before S2. There are a lot of > terms defined in S3 that S2 simply uses; it will serve the reader well if they > already knew these terms by the time the encountered them. Works for me, moved Terminology Section. Great; thanks. > > Minor: > - S1, paragraph 2: "...NATs that are well behaved." Here, what is the > definition of a "well behaved" NAT? Is there a RFC that encodes expected > behaviour? If so, please provide a reference. If not, then some resource > should be made available (a paragraph or some reference) where the > expected behaviour of NATs is codified to some extent. Address-dependent or Address-and port-dependent mappings are not well behaved NATs, this paragraph refers to RFC4787 (see https://tools.ietf.org/html/rfc4787#section-4.1 ) and says hole-punching technique will not work with NATs having Address-dependent or Address-and port-dependent mapping behavior. NEW: As described in [RFC5128] and [RFC4787], hole punching techniques [...] The new text is a great addition. Thanks. > - 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: "When TCP transport is used ..." Here, [...] Please see the discussion in BEHAVE WG mailing list https://mailarchive.ietf.org/arch/msg/behave/O7A7vTihIBJ-uKmJT_bSea13wIA Hmm ... so according to the above link, the bit flip has to get through the TCP checksum AND hit the length field of the TURN packet. Given today's networks, such an event has a very low probability, but in the interest of specifying protocols to handle all kinds of errors, it makes sense to address this. Of course, this is not a problem endemic to TURN, it is a problem inherent any time TCP is used. [TR] Agreed. I do not know what mitigation strategies are used across IETF for an event like this. Perhaps the TSV area directorate can help. In any case, I am fine with leaving the text as-is, although it may make sense to talk to some of the folks in TSV to see how other protocols that ride in TCP handle such cases. (For curiosity's sake, ff not for anything else.) > - 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). Cheers, -Tiru Thanks. - vijay
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
