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

[Joe Touch <[e-mail]>]

Hi, Tiru,

You still appear to be ignoring the issue about implying per-packet adjustment of IP options and parameters during a TCP connection, in specific.

Joe

> On Jun 19, 2019, at 6:24 AM, Konda, Tirumaleswar Reddy <[e-mail]> 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
>    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.
>  
> Cheers,
> -Tiru
>  
> From: Joe Touch <[e-mail] <mailto:[e-mail]>> 
> Sent: Tuesday, June 18, 2019 8:03 PM
> To: Magnus Westerlund <[e-mail] <mailto:[e-mail]>>
> Cc: Konda, Tirumaleswar Reddy <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; Brandon Williams <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
> Subject: Re: [Tsv-art] [tram] Tsvart 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.
> 
>  
> 
> 
> On Jun 18, 2019, at 6:47 AM, Magnus Westerlund <[e-mail] <mailto:[e-mail]>> wrote:
>  
> [TR] The comment from Joe is : if TCP-AO is used, application data is authenticated in the TCP leg but the data can be faked when relayed from the server to the peer using UDP. I tried to address this comment by saying if secure application data (SRTP) is used message authentication is available at the application layer even if UDP does not support authentication option.
> Sure, but this is equivalent to the case of TURN over TCP/TLS that also only have the security model to the middle. So pointing that aspect out is fine, but I think TURN is quite clear on that client to peer security are the responsibility of the end-to-end application using TURN. Like the statement in the Third paragraph of 20.1.4:
>    These attacks are more properly mitigated by application-layer
>    authentication techniques.  In the case of real-time traffic, usage
>    of SRTP [RFC3711] prevents these attacks.
>  
> FWIW, even with this statement, if you’re going to talk about preserving IP options and settings then it’s equally important to discuss how you preserve or interfere with TCP options and settings - and maybe other layers like TLS too - in the same place in the document.
>  
> It’s not just whether this is a security issue; it’s that the semantics are broken in half.
>  
> Joe