As per the suggestion from Magnus, modified 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. If TCP-AO would be used between TURN client and server, it would not change the end-to-end security properties of
the UDP payload being relayed. Therefore applications using TURN will need to secure their application data end-to-end appropriately, e.g. SRTP for RTP applications.
Cheers,
-Tiru
> -----Original Message-----
> From: Magnus Westerlund <magnus.westerlund@xxxxxxxxxxxx>
> Sent: Tuesday, June 25, 2019 5:58 PM
> To: kaduk@xxxxxxx; Konda, Tirumaleswar Reddy
> <TirumaleswarReddy_Konda@xxxxxxxxxx>
> Cc: touch@xxxxxxxxxxxxxx; tsv-art@xxxxxxxx; draft-ietf-tram-
> turnbis.all@xxxxxxxx; ietf@xxxxxxxx; brandon.williams@xxxxxxxxxx;
> tram@xxxxxxxx
> Subject: RE: [Tsv-art] [tram] Tsvart last call review of draft-ietf-tram-turnbis-
> 25
>
> Hi,
>
> > -----Original Message-----
> > From: Benjamin Kaduk <kaduk@xxxxxxx>
> > Sent: den 25 juni 2019 01:37
> > To: Konda, Tirumaleswar Reddy
> <TirumaleswarReddy_Konda@xxxxxxxxxx>
> > Cc: Joe Touch <touch@xxxxxxxxxxxxxx>; Magnus Westerlund
> > <magnus.westerlund@xxxxxxxxxxxx>; tsv-art@xxxxxxxx; draft-ietf-tram-
> > turnbis.all@xxxxxxxx; ietf@xxxxxxxx; Brandon Williams
> > <brandon.williams@xxxxxxxxxx>; tram@xxxxxxxx
> > Subject: Re: [Tsv-art] [tram] Tsvart last call review of
> draft-ietf-tram-turnbis-
> > 25
> >
> > 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.
>
> And I think this requirement is backwards. Application of TCP-AO or TLS does
> not result in an improved security property for the higher layer that
> utilizes TURN. That is still regular IP/UDP datagram payloads in this
> version. There is nothing in this specification that gives you anything
> better on the server to peer leg. Thus, application of TLS/TCP or TCP-AO on
> the client to server leg is only to mitigate some threats on this client to
> server leg, potentially making it more robust.
>
> Thus, I would suggest that this requirement is removed. And instead it is
> explained that the actual upper layer security properties are not improved
> simply the client server leg is less vulnerable to certain attacks.
>
> /Magnus
> >
> > -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.
