Re: [tram] [Tsv-art] Tsvart last call review of draft-ietf-tram-turnbis-25

["Konda, Tirumaleswar Reddy" <[e-mail]>]

> -----Original Message-----
> From: Benjamin Kaduk <[e-mail]>
> Sent: Tuesday, June 25, 2019 5:07 AM
> To: Konda, Tirumaleswar Reddy <[e-mail]>
> Cc: Joe Touch <[e-mail]>; Magnus Westerlund
> <[e-mail]>; [e-mail]; draft-ietf-tram-
> [e-mail]; [e-mail]; Brandon Williams
> <[e-mail]>; [e-mail]
> Subject: Re: [Tsv-art] [tram] Tsvart last call review of draft-ietf-tram-turnbis-
> 25
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
> 
> Sorry to jump in and hijack the middle of a different thread, but...
> 
> On Wed, Jun 19, 2019 at 01:24:42PM +0000, Konda, Tirumaleswar Reddy
> wrote:
> > Hi Joe,
> >
> > I have added the following lines to address your comment:
> >
> >    TCP multi-path [RFC6824] is not supported by this version of TURN
> >    because TCP multi-path is not used by both SIP and WebRTC protocols
> >    [RFC7478] for media and non-media data.  If the TCP connection
> >    between the TURN client and server uses TCP-AO [RFC5925] or TLS, the
> >    client must secure application data (e.g. using SRTP) to provide
> >    confidentially, message authentication and replay protection to
> >    protect the application data relayed from the server to the peer
> >    using UDP.  Attacker attempting to spoof in fake data is discussed
> > in
> 
> ... this kind of cross-layer security requirement ("if you were using TCP-layer
> protection, now you have to impose a requirement on the application
> protocol (stack) at a higher layer") has been quite problematic in the past
> when attempted for other protocols.  Consider this early warning that it will
> get a careful security area review during IESG evaluation, if not sooner.  Being
> very specific about which component of the system has what requirements
> under which conditions would be helpful, as a start.

Good point. I did not think from that angle, will re-phrase the text as follows  :

TCP connection between the TURN client and server can use TCP-AO [RFC5925] but UDP does not provide a similar type of authentication until UDP supports authentication option. Regardless of whether TCP-AO is used or not, In order to defend against various attacks against the application data (attacker attempting to spoof in fake data is discussed Section 20.1.4) , the client must secure application data (e.g. using SRTP). 

Cheers,
-Tiru

> 
> -Ben
> 
> >    Section 20.1.4.  Note that TCP-AO option obsoletes TCP MD5 option.
> >    Unlike UDP, TCP without the TCP Fast Open extension [RFC7413] does
> >    not support 0-RTT session resumption.  The TCP user timeout [RFC5482]
> >    equivalent for application data relayed by the TURN is the use of RTP
> >    control protocol (RTCP).  As a reminder, RTCP is a fundamental and
> >    integral part of RTP.