Re: [Tsv-art] [tram] Tsvart last call review of draft-ietf-tram-turnbis-25
Joe Touch <touch@strayalpha.com> Sat, 15 June 2019 18:52 UTC
Return-Path: <touch@strayalpha.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1743F1200F7; Sat, 15 Jun 2019 11:52:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.219
X-Spam-Level:
X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiuVa_dE_vTJ; Sat, 15 Jun 2019 11:52:20 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 020241200F4; Sat, 15 Jun 2019 11:52:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=a72M3YWl8IGhNTJ+WuyHVADG2CWdSFn4QjolRvhEmac=; b=aa+8wCuxpRWep2CsoX9iqDLrj 5FQTUAV4oWttCwlxcc437Rkwy2J/nMTsnkP03+HqSJrmpT+DL8MOZRlKa+PQCiE2yxyxBcZrcNH1Q qy9w2yvEDbbUP3UHGitaB9z9xy9nfTnrGy1O5oWQoDRygTxEQ0FLjnhSUAtuiRZsqsaLAZFkcl/oR KRssi1wm9OLVujKY6vR/saP4YyP6xf2nSAt3i5WxXyQLOs4GHMbm2v7cTzn5NrLRX1AZuo5mPgWvz lkJkNedppIydKK+r/+kur+BfkrGZ3tIzCoizyfL3FFwcyFpoX+8mzauhdGSl6Y+7MAdZbYHHXegqB tHIsoBt+g==;
Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:63849 helo=[192.168.1.250]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <touch@strayalpha.com>) id 1hcDmf-004K83-4D; Sat, 15 Jun 2019 14:52:18 -0400
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
Cc: Brandon Williams <brandon.williams@akamai.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>, "draft-ietf-tram-turnbis.all@ietf.org" <draft-ietf-tram-turnbis.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "tram@ietf.org" <tram@ietf.org>, "tsv-art@ietf.org" <tsv-art@ietf.org>
References: <155971464360.28104.6837263931145163343@ietfa.amsl.com> <F306B122-79F3-4C7A-8CE2-1C094D9F0FCC@strayalpha.com> <DM5PR16MB1705A4C370C4405AFFD63546EA100@DM5PR16MB1705.namprd16.prod.outlook.com> <5F2F8A3B-2887-4107-81E2-B4E222A4044E@strayalpha.com> <DM5PR16MB1705BD4E31370D2F5A179F17EA130@DM5PR16MB1705.namprd16.prod.outlook.com> <2C6B5776-CB95-4607-8D0C-07FDE2F6D515@strayalpha.com> <DM5PR16MB1705638AD29F3288E4AC0952EAED0@DM5PR16MB1705.namprd16.prod.outlook.com> <HE1PR0701MB252250AE4E7C158F985B0CC895ED0@HE1PR0701MB2522.eurprd07.prod.outlook.com> <D9A01E28-F9FB-4C86-AFD3-A2BA8D89C340@strayalpha.com> <a3bbeb17-e768-9ab2-9f34-3d179fa8fe38@akamai.com> <E41C125D-F3B4-475E-8AD0-124F531F1DC9@strayalpha.com> <DM5PR16MB170564C0438321CC3FDD0ACFEAEF0@DM5PR16MB1705.namprd16.prod.outlook.com> <4C41A2BC-0CBC-42D5-B313-22F9A9D51F6E@strayalpha.com> <DM5PR16MB1705874C023145D26DCB58E6EAEE0@DM5PR16MB1705.namprd16.prod.outlook.com>
From: Joe Touch <touch@strayalpha.com>
Message-ID: <edcd66c2-0dfb-8f89-d6a3-53482c433d4e@strayalpha.com>
Date: Sat, 15 Jun 2019 11:52:11 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <DM5PR16MB1705874C023145D26DCB58E6EAEE0@DM5PR16MB1705.namprd16.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------3686C164AD5DD70CCA2A7431"
Content-Language: en-US
X-OutGoing-Spam-Status: No, score=-0.5
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/-EGe-GLZ9qIGurH-UUKgKvF4Hyc>
Subject: Re: [Tsv-art] [tram] Tsvart last call review of draft-ietf-tram-turnbis-25
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Jun 2019 18:52:23 -0000
On 6/14/2019 12:49 AM, Konda, Tirumaleswar Reddy wrote: > > Hi Jon, > > > > Please see inline [TR] > > > > *From:* Joe Touch <touch@strayalpha.com> > *Sent:* Thursday, June 13, 2019 7:47 PM > *To:* Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com> > *Cc:* Brandon Williams <brandon.williams@akamai.com>; Magnus > Westerlund <magnus.westerlund@ericsson.com>; > draft-ietf-tram-turnbis.all@ietf.org; ietf@ietf.org; tram@ietf.org; > tsv-art@ietf.org > *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. > > ------------------------------------------------------------------------ > > Hi, Tiru, > > > > On Jun 13, 2019, at 1:42 AM, Konda, Tirumaleswar Reddy > <TirumaleswarReddy_Konda@McAfee.com > <mailto:TirumaleswarReddy_Konda@McAfee.com>> wrote: > > > > ... > The description in the document implies packet-to-packet > translation, which > seems dangerous (even as a description). This is especially > true for the > notion that each UDP packet is translated into exactly one TCP > frame directly. > > > The TURN specification only discusses packet-to-packet translation > for UDP-to-UDP relay and not for TCP-to-UDP relay. > > > > Sec 15 talks about setting IP fragmentation based on the received > messages. If this is not based on packet-to-packet translation, can > you explain how this can be achieved? TCP sets DF for a connection, > not on a per packet basis > > > > [TR] It is not based on packet-to-packet translation. TURN client can > set the DON’T-FRAGMENT attribute in the TURN message to tell the TURN > server to set the DF bit in the resulting UDP datagram sent to the > peer. Please see > https://tools.ietf.org/html/draft-ietf-tram-turnbis-25#section-15 > The section notes that only a single DSCP can be set for a TCP connection. A similar note should be included in the discussion of IP fragmentation and IP options - these too can be set on a per-message basis for UDP, but not for TCP. > > > …. > > Acknowledging that TCP options are being ignored when > messages are > relayed could be OK. I'm not entirely certain what you're > suggesting > relative to the security considerations though. Are you > just pointing > to the fact that security built into TCP (e.g., tcp-ao, > tcp-eno, > tcp-crypt) cannot be used to provide end-to-end security? > In the same > way that (D)TLS cannot be used for this purpose either? If > not that, > what else do you have in mind? > > > OK, so given you’re just terminating the connection, you need > to talk about > the implications of doing so, and yes, the kinds of issues > above are relevant. > If you were opening your own TCP connection, it would be > relevant to > discuss how you decide what options to enable as well and > whether those > options are determined based on the options of the other TCP > connection > (but you’re not doing that). > > > No, TURN server does not establish TCP connection to the peer. > TURN only supports UDP between the server and the peer. > Please > see https://tools.ietf.org/html/draft-ietf-tram-turnbis-25#section-2.1. > > > > > Yes, we agree (as I said, “if you were…” and “b..ut you’re not.”). > > > > [TR] Glad to see we are making progress J > > > > I.e., my suggestion would be to make the description of the > conversion > process match this email’s explanation, i.e., as an > application relay rather > than as direct packet-to-packet conversion, including: > > - adjust your description of how you relay messages to talk > about things at > the “application” layer > when you talk about IPv4 or IPv6 properties, the > issue is about how > you configure those as endpoints on the translator, not how > *each packet* is > translated > NOTE - your document is incorrect regarding TTL; > only routers drop > packets with hopcounts/TTLs of zero. A host MUST NOT (per RFC > 1122/8200) > > > You are right will remove TTL text for TCP-to-UDP relay but not > for UDP-to-UDP relay. RFC1122 says, the intent is that TTL > expiration will cause a datagram > to be discarded by a gateway but not by the destination > host; however, hosts that act as gateways by forwarding > datagrams must follow the gateway rules for TTL. > > > > This is correct behavior for IP-to-IP translation (sec 13), but not > UDP-to-UDP (sec 14). The latter is not the function of a gateway, but > rather the function of an app-layer proxy. > > > > [TR] Got it, will update draft. > > > - address how your endpoint deals with TCP options that might > have impact, > including TCP multiparty, AO, ENO, MD5, fastopen, and user timeout > > > The TURN server is not acting as a TCP-to-TCP relay and I don't > understand the need to discuss these options. > > > > You need to explain the impact of not being able to carry these > options or their behavior across the UDP part of a TCP-to-UDP relay. > > > > [TR] TCP multi-path is not supported by this specification because TCP > multi-path is not used by both SIP and WebRTC protocols for media and > non-media data. If the TCP connection uses TCP-AO, the client should > secure application data (e.g. SRTP) to provide confidentially, message > authentication and replay protection to protect the application data > relayed from the server to the peer (Fake data is already discussed in > Section 20.1.3). I don’t see a need to discuss TCP fast open (UDP is > 0-RTT), and MD5 is replaced by TCP-AO. TCP user-timeout equivalent for > application data (RTP) is RTCP. > You need to address these issues - e.g., by a version of the response above. Joe > > > Cheers, > > -Tiru > > > > Joe >
- [Tsv-art] Tsvart last call review of draft-ietf-t… Joseph Touch via Datatracker
- Re: [Tsv-art] [tram] Tsvart last call review of d… Konda, Tirumaleswar Reddy
- Re: [Tsv-art] [tram] Tsvart last call review of d… Joe Touch
- Re: [Tsv-art] [tram] Tsvart last call review of d… Konda, Tirumaleswar Reddy
- Re: [Tsv-art] [tram] Tsvart last call review of d… Joe Touch
- Re: [Tsv-art] [tram] Tsvart last call review of d… Konda, Tirumaleswar Reddy
- Re: [Tsv-art] [tram] Tsvart last call review of d… Joe Touch
- Re: [Tsv-art] [tram] Tsvart last call review of d… Konda, Tirumaleswar Reddy
- Re: [Tsv-art] [tram] Tsvart last call review of d… Magnus Westerlund
- Re: [Tsv-art] [tram] Tsvart last call review of d… Joe Touch
- Re: [Tsv-art] [tram] Tsvart last call review of d… Brandon Williams
- Re: [Tsv-art] [tram] Tsvart last call review of d… Joe Touch
- Re: [Tsv-art] [tram] Tsvart last call review of d… Konda, Tirumaleswar Reddy
- Re: [Tsv-art] [tram] Tsvart last call review of d… Joe Touch
- Re: [Tsv-art] [tram] Tsvart last call review of d… Konda, Tirumaleswar Reddy
- Re: [Tsv-art] [tram] Tsvart last call review of d… Joe Touch
- Re: [Tsv-art] [tram] Tsvart last call review of d… Konda, Tirumaleswar Reddy
- Re: [Tsv-art] [tram] Tsvart last call review of d… Joe Touch
- Re: [Tsv-art] [tram] Tsvart last call review of d… Konda, Tirumaleswar Reddy
- Re: [Tsv-art] [tram] Tsvart last call review of d… Magnus Westerlund
- Re: [Tsv-art] [tram] Tsvart last call review of d… Konda, Tirumaleswar Reddy
- Re: [Tsv-art] [tram] Tsvart last call review of d… Magnus Westerlund
- Re: [Tsv-art] [tram] Tsvart last call review of d… Joe Touch
- Re: [Tsv-art] [tram] Tsvart last call review of d… Joe Touch
- Re: [Tsv-art] [tram] Tsvart last call review of d… Joe Touch
- Re: [Tsv-art] [tram] Tsvart last call review of d… Konda, Tirumaleswar Reddy
- Re: [Tsv-art] [tram] Tsvart last call review of d… Konda, Tirumaleswar Reddy
- Re: [Tsv-art] [tram] Tsvart last call review of d… Joe Touch
- Re: [Tsv-art] [tram] Tsvart last call review of d… Konda, Tirumaleswar Reddy
- Re: [Tsv-art] [tram] Tsvart last call review of d… Joe Touch
- Re: [Tsv-art] [tram] Tsvart last call review of d… Konda, Tirumaleswar Reddy
- Re: [Tsv-art] [tram] Tsvart last call review of d… Joe Touch
- Re: [Tsv-art] [tram] Tsvart last call review of d… Konda, Tirumaleswar Reddy
- Re: [Tsv-art] [tram] Tsvart last call review of d… Joe Touch
- Re: [Tsv-art] [tram] Tsvart last call review of d… Konda, Tirumaleswar Reddy
- Re: [Tsv-art] [tram] Tsvart last call review of d… Joe Touch
- Re: [Tsv-art] [tram] Tsvart last call review of d… Konda, Tirumaleswar Reddy
- Re: [Tsv-art] [tram] Tsvart last call review of d… Benjamin Kaduk
- Re: [Tsv-art] [tram] Tsvart last call review of d… Konda, Tirumaleswar Reddy
- Re: [Tsv-art] [tram] Tsvart last call review of d… Magnus Westerlund
- Re: [Tsv-art] [tram] Tsvart last call review of d… Konda, Tirumaleswar Reddy
- Re: [Tsv-art] [tram] Tsvart last call review of d… Benjamin Kaduk
- Re: [Tsv-art] [tram] Tsvart last call review of d… Joe Touch
- Re: [Tsv-art] [tram] Tsvart last call review of d… Konda, Tirumaleswar Reddy
- Re: [Tsv-art] [tram] Tsvart last call review of d… Magnus Westerlund
- Re: [Tsv-art] [tram] Tsvart last call review of d… Joe Touch
- Re: [Tsv-art] [tram] Tsvart last call review of d… Joe Touch