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

Joe Touch <touch@strayalpha.com> Fri, 21 June 2019 06:04 UTC

Return-Path: <touch@strayalpha.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88721200E5; Thu, 20 Jun 2019 23:04:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.218
X-Spam-Level:
X-Spam-Status: No, score=-1.218 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, URIBL_BLOCKED=0.001] 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 XXAE5OJQDZ40; Thu, 20 Jun 2019 23:04:33 -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 C7C06120025; Thu, 20 Jun 2019 23:04:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type: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=K31XcAyAIbK8ueQDf8fbQsulhPiE2pu0QdkhdHN8hkw=; b=2rtGL/oc1xq+MtUd7CnaXkEt/ w9JmOEJI12MEF4/f6Pi8oPCbhIYoJVeHCJopBZ0fLFFLROAhyxasCnLn7AQuzTcpeOcNjpcfOBG80 2P74R/pRK74RKeKG4tIsTCTbN0qMHrH/UOeugSR2dYDFCboJJokNYKSln0mkB8vF4zKYq9yPd7DD7 fQVEBa8I64PmfBY6bp+EP3H2MEs1sO3Sz8c7fAnz02tnjVn45W+nzO5hgXbtnY6nR0gedFRTjeIIE I4Bb0ukOgB9dFdWI/JNyRCfgTF84FELIwq5BOvIFDVv/o7ur/95484bLuhOT6HE7fw2ApW4DNdBoU 2ZyBdBtZw==;
Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:51635 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <touch@strayalpha.com>) id 1heCeu-001Dra-Jl; Fri, 21 Jun 2019 02:04:29 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_0E3F6E1F-B497-4D22-96EB-51EDB4EB0A3F"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <touch@strayalpha.com>
In-Reply-To: <DM5PR16MB17054AE0DA33AE71D7B44AB3EAE40@DM5PR16MB1705.namprd16.prod.outlook.com>
Date: Thu, 20 Jun 2019 23:04:23 -0700
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, "tram@ietf.org" <tram@ietf.org>, Brandon Williams <brandon.williams@akamai.com>, "draft-ietf-tram-turnbis.all@ietf.org" <draft-ietf-tram-turnbis.all@ietf.org>, "tsv-art@ietf.org" <tsv-art@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Message-Id: <BC91A2DA-210B-419A-963E-1F50E8D74121@strayalpha.com>
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> <edcd66c2-0dfb-8f89-d6a3-53482c433d4e@strayalpha.com> <DM5PR16MB17057CCD4D2543D84254EFD1EAEB0@DM5PR16MB1705.namprd16.prod.outlook.com> <HE1PR0701MB2522DCB2459055A6319C439B95EA0@HE1PR0701MB2522.eurprd07.prod.outlook.com> <DM5PR16MB1705E3EF8260B456A9B02C10EAEA0@DM5PR16MB1705.namprd16.prod.outlook.com> <HE1PR0701MB2522C0A1063877D45985619795EA0@HE1PR0701MB2522.eurprd07.prod.outlook.com> <BD41AC2D-3925-4E11-B1EC-AD24680376AE@strayalpha.com> <DM5PR16MB1705F636477B6234FEA35A04EAE50@DM5PR16MB1705.namprd16.prod.outlook.com> <A47BFD15-B787-484D-A678-698B2C7D77A6@strayalpha.com> <DM5PR16MB1705339D00B060CC7D8366FAEAE50@DM5PR16MB1705.namprd16.prod.outlook.com> <F7645044-C75D-4C52-87A1-514B576A41B6@strayalpha.com> <DM5PR16MB1705CFF84A31E550EB0415C9EAE50@DM5PR16MB1705.namprd16.prod.outlook.com> <125E7AE0-97D6-4BFD-BE1F-F1FB2B74BFB1@strayalpha.com> <DM5PR16MB1705D7AB3DB31338F0905D87EAE50@DM5PR16MB1705.namprd16.prod.outlook.com> <6C2A2BBA-801B-4B17-BFD3-A8235BE2C10C@strayalpha.com> <DM5PR16MB17054AE0DA33AE71D7B44AB3EAE40@DM5PR16MB1705.namprd16.prod.outlook.com>
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
X-Mailer: Apple Mail (2.3445.9.1)
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/tram/SMoZ045hHdSkZTlN4ZtjdVAK_p0>
Subject: Re: [tram] [Tsv-art] Tsvart last call review of draft-ietf-tram-turnbis-25
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Jun 2019 06:04:36 -0000

Hi, Tiru,

> On Jun 20, 2019, at 3:46 AM, Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com> wrote:
> 
> Hi Joe,
>  
> Please see inline [TR]
> ...
> This sort of patch isn’t sufficient. It doesn’t address the confusion throughout section 15 as to what’s actually happening.
>  
> Sec 15 shouldn’t talk about “setting” IP header values at all; it should refer to “configuring transport sessions” in the desired ways. Otherwise you’re implying direct packet-level conversion. Even the title of that section is a problem in this regard.
>  
> [TR] What title do you want me to use for Section 15 ?

Sec 14 could be “UDP relay”

Sec 15 could be “Mixed transport relay” or “TCP/UDP and UDP/TCP relay”

In both cases, the issue isn’t to focus on the IP header fields.

> Tthe sections themselves should be revised to similarly refer to transport-level actions, not packet level, e.g.:
> 15.1 TCP to UDP
>               - because DSCP should not vary within a TCP session, there is no packet-level tracking of copying DSCP from TCP to UDP; instead, DSCP would be a property of the TCP session that would be used to configure the UDP socket pair.
>  
> [TR] Agreed, but the text looks correct to me. It says “Note, the TCP connection can only use a single DSCP code point so inter flow differentiation is not possible”.   

It’s not a note. It’s the point. You don’t set the outgoing to the incoming per se; you set the *TCP connection* to use the DSCP of the first UDP packet.

>               - IP fragmentation control needs to be explained in terms of UDP interactions
>  
> [TR] Yes, DONT-FRAGMENT attribute in the TURN message is used to set the DF bit in the outgoing IP header to 1. What specific change are you expecting ?

Again, you’re talking about building a network layer packet header. The point is that you should be describing this in terms of “setting the UDP packet to not fragment”. That is NOT merely IP DF=1; that would only prevent *in-network* fragmentation. You need to tell UDP not to source fragment too.

And all of this should be described in a way that doesn’t imply that the only approach is to have the user build the packet all the way to the IP headers.

Here’s why it matters - an IPv4 packet can *already be source fragmented* and still have the individual fragments set DF=0. DF=0 just means the *network* should not sub-fragment what it receives, not that the packet is “atomic” (not fragmented a the source AND not fragmentable by the network)

>               - IPv6 fragmentation has nothing to do with the received packet (which is TCP
>  
> [TR] Same as above,  DONT-FRAGMENT attribute in the TURN message is used to set the DF bit in the outgoing IP header to 1.

The server doesn’t ignore the the fragment fields of the received packets; it uses them to reassemble (by the IP stack). They are ignored in terms of whether to set the *transport* to avoid UDP using source fragmentation. Again, though, this isn’t about setting IP header fields.


>               - IP options are *as default*; it’ isn’t correct that you never use IP options (or are you actively disabling them?)
>                               NOTE: that goes for the direct IPv4 to IPv6 translation in section 4 (which is similarly problematic)
>  
> [TR]   I am not aware of default IPv4 options and extension headers, and I don’t see any default IPv4 options discussed inhttps://tools.ietf.org/html/rfc6274 <https://tools.ietf.org/html/rfc6274>. What IP4 options and IPv6 extension headers are default ?

By “default” I’m referring to system-wide configurations to use particular IP options. Your description appears to prevent their use; are you actively prohibiting all IP options? Even system-wide defaults, if so configured?

>           RTP/RTCP do not use any IPv4 options and IPv6 extension headers. What is the loss of functionality if IP options and extension headers are not set by the TURN server for outgoing UDP packets to the peer ?

You would be expecting the transport to override a system-wide network default, which may not be possible on some systems.

You can probably just say “use system defaults”.

> 15.2 UDP to TCP
>               - the last sentence of the second paragraph seems at odds with the first; the first says “set these once per connection”, it is sufficient IMO.
>  
> [TR] Okay, removed the last sentence of the second paragraph.
>  
>               -TCP DSCP should be based on the *first* UDP value seen (it could vary)
>  
> [TR] No, the client first establishes TCP connection with the server and exchanges TURN messages for allocation and permission, UDP packets can only be sent by the peer after permission is created. Please seehttps://tools.ietf.org/html/rfc7657#section-5.3 <seehttps://tools.ietf.org/html/rfc7657#section-5.3>
OK, but then you need to say *in this section* how you expect to set the TCP DSCP. The text is confusing - it talks about “server-to-client” matching “client-to-server” - that’s just the other direction of the same TCP connection. If you are referring to other endpoints or transport protocols, be specific and clear. 

>  
> Cheers,
> -Tiru
>  
>               - same issue with IP extension headers and options (presumably you use the default
>  
> Joe
> 
> 
> On Jun 19, 2019, at 8:14 AM, Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com <mailto:TirumaleswarReddy_Konda@McAfee.com>> wrote:
>  
> Hi Joe,
>  
> The IPv4 and IPv6 fragmentation description is specific to TCP-to-UDP relaying between the client and the peer (only for TCP-to-UDP relay, the DF attribute in the TURN message will be used to set the DF bit in the outgoing UDP packet to the peer). To avoid confusion, I have added two new sub-sections:
> 15.1.  IP Header Fields for TCP-to-UDP relaying and 15.2 IP Header Fields for UDP-to-TCP relaying
>  
> Please see the attached updated draft.
>  
> Cheers,
> -Tiru
> _______________________________________________
> Tsv-art mailing list
> Tsv-art@ietf.org <mailto:Tsv-art@ietf.org>
> https://www.ietf.org/mailman/listinfo/tsv-art <https://www.ietf.org/mailman/listinfo/tsv-art>