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

[Vijay Gurbani <[e-mail]>]

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 <
[e-mail]> 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.


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


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

Thanks.

- vijay