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.
<<attachment: smime.p7s>>
