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

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Fri, 07 June 2019 08:40 UTC

Return-Path: <TirumaleswarReddy_Konda@mcafee.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 D8E1112010D; Fri, 7 Jun 2019 01:40:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.309
X-Spam-Level:
X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 GAiPvZwY4UlT; Fri, 7 Jun 2019 01:40:11 -0700 (PDT)
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 8857912008D; Fri, 7 Jun 2019 01:40:10 -0700 (PDT)
X-NAI-Header: Modified by McAfee Email Gateway (5500)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1559896286; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=g H4Y9DU0fc3TWnXe8HiUooYDzSf2XjBFwgQRBSFOB9 Y=; b=CrdCor2haK4ugv9UABCCbRb/DohLtOKwoxsjPFaaFSaV 2H62YrZCOvCHv3zsbjE8BnzxID8+Ceo2t9rWpKNyHWHT2ZFIgh qhJjaQnUBlDBVVVrPMLgzo5HEiOqDGbtfNMZpIPZR285pZiMNN Qv0NS+ZnYi3asSVCd2nouLHLyc8=
Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 0c4a_558b_1e1cb678_1701_4187_b3d9_31b615a9cccd; Fri, 07 Jun 2019 02:31:25 -0600
Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 7 Jun 2019 02:39:48 -0600
Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Fri, 7 Jun 2019 02:39:47 -0600
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 7 Jun 2019 02:39:47 -0600
Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB1369.namprd16.prod.outlook.com (10.173.211.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.15; Fri, 7 Jun 2019 08:39:46 +0000
Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::3d0a:95ec:9842:68f7]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::3d0a:95ec:9842:68f7%9]) with mapi id 15.20.1943.018; Fri, 7 Jun 2019 08:39:46 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: Joe Touch <touch@strayalpha.com>
CC: "tsv-art@ietf.org" <tsv-art@ietf.org>, "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>
Thread-Topic: [Tsv-art] [tram] Tsvart last call review of draft-ietf-tram-turnbis-25
Thread-Index: AQHVG2SmpiSgt26O+0yT1OWnZzXhh6aM/GYwgAGpzgCAAA60gA==
Date: Fri, 07 Jun 2019 08:39:46 +0000
Message-ID: <DM5PR16MB1705A4C370C4405AFFD63546EA100@DM5PR16MB1705.namprd16.prod.outlook.com>
References: <155971464360.28104.6837263931145163343@ietfa.amsl.com> <DM5PR16MB170560F51A9F7C281A9BC752EA170@DM5PR16MB1705.namprd16.prod.outlook.com> <F306B122-79F3-4C7A-8CE2-1C094D9F0FCC@strayalpha.com>
In-Reply-To: <F306B122-79F3-4C7A-8CE2-1C094D9F0FCC@strayalpha.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.3.0.8
dlp-reaction: no-action
authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com;
x-originating-ip: [103.245.47.20]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 808b6f64-0c72-4ab6-bf11-08d6eb23b231
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB1369;
x-ms-traffictypediagnostic: DM5PR16MB1369:
x-ms-exchange-purlcount: 5
x-microsoft-antispam-prvs: <DM5PR16MB13697C9AC00840CAEC1BB8FEEA100@DM5PR16MB1369.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0061C35778
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(39860400002)(376002)(136003)(366004)(32952001)(189003)(199004)(13464003)(51914003)(99286004)(81156014)(81166006)(8676002)(7696005)(8936002)(316002)(7736002)(54906003)(68736007)(5024004)(14444005)(256004)(486006)(186003)(26005)(9686003)(6306002)(53936002)(478600001)(6916009)(966005)(72206003)(6246003)(6436002)(55016002)(14454004)(229853002)(6506007)(53546011)(2906002)(25786009)(76176011)(66066001)(102836004)(4326008)(5660300002)(66556008)(66476007)(64756008)(66446008)(74316002)(80792005)(86362001)(71190400001)(476003)(446003)(71200400001)(11346002)(66946007)(73956011)(76116006)(52536014)(6116002)(3846002)(305945005)(33656002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1369; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: NEQw+JamhLLr9NIStayNuVLC/AYPFsfL17QsNAfdtB1asc4RILPHVKeEKbZHRiiBGVtbbyvkl3gmWqnBPceRlJ6e8B6cnEhmkGh9CNH8QK39qxs8b5gBbCG9z/dGwbsVoCV/RdtKuBOQqJ+IglMgt/IL8WoriqUVoamsi/Uc1Wz06uF6NofN9IPbPpkomosVRhNlWxbiw9bQG5pHlp+NIKsiUQgsky/De5pDSkXMup62qKICwW8sswhP/u++zihS5vZFJLszmH2wq9iUJJiSuvwUKAjisjgpKoj3Hyam4I9lclcicifFCxwVFP1X6vF4NDhqYMb/i890/bhXlu3+2r3j+3LXOtdZuT4p7DautFYa2sEhHSP7MHRTo98Mmb1loI9r8mKCMaGFOwwjXXJbdJ3EY1OSnub+pgjNdFnse+0=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 808b6f64-0c72-4ab6-bf11-08d6eb23b231
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2019 08:39:46.4120 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1369
X-OriginatorOrg: mcafee.com
X-NAI-Spam-Flag: NO
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0
X-NAI-Spam-Version: 2.3.0.9418 : core <6563> : inlines <7098> : streams <1823778> : uri <2853582>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/xJ1GfoKiG-bbvF5KPJOxfOxbY-0>
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: Fri, 07 Jun 2019 08:40:14 -0000

> -----Original Message-----
> From: Joe Touch <touch@strayalpha.com>
> Sent: Thursday, June 6, 2019 7:18 PM
> To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>
> Cc: tsv-art@ietf.org; draft-ietf-tram-turnbis.all@ietf.org; ietf@ietf.org;
> tram@ietf.org
> Subject: Re: [Tsv-art] [tram] Tsvart last call review of draft-ietf-tram-turnbis-
> 25
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
> 
> 
> 
> > On Jun 6, 2019, at 9:12 AM, Konda, Tirumaleswar Reddy
> <TirumaleswarReddy_Konda@mcafee.com> wrote:
> >
> > Hi Joseph,
> >
> > Thanks for the review, Please see inline
> >
> >> -----Original Message-----
> >> From: tram <tram-bounces@ietf.org> On Behalf Of Joseph Touch via
> >> Datatracker
> >> Sent: Wednesday, June 5, 2019 11:34 AM
> >> To: tsv-art@ietf.org
> >> Cc: draft-ietf-tram-turnbis.all@ietf.org; ietf@ietf.org;
> >> tram@ietf.org
> >> Subject: [tram] Tsvart last call review of draft-ietf-tram-turnbis-25
> >>
> >> This email originated from outside of the organization. Do not click
> >> links or open attachments unless you recognize the sender and know
> >> the content is safe.
> >>
> >> Reviewer: Joseph Touch
> >> Review result: Ready with Issues
> >>
> >> This document has been reviewed as part of the transport area review
> >> team's ongoing effort to review key IETF documents. These comments
> >> were written primarily for the transport area directors, but are
> >> copied to the document's authors and WG to allow them to address any
> >> issues raised and also to the IETF discussion list for information.
> >>
> >> When done at the time of IETF Last Call, the authors should consider
> >> this review as part of the last-call comments they receive. Please
> >> always CC tsv- art@ietf.org if you reply to or forward this review.
> >>
> >> As a preface, this review is performed focusing on the changes since
> >> RFC 5766, as this document appears to be a fairly direct update of that
> content.
> >
> > Yes.
> >
> >>
> >> Transport issues:
> >>
> >> Although this document has substantial implications for transport
> >> protocols, it does not significantly alter the content of RFC5766 in
> >> this regard. However, there is a significant gap as follows:
> >>
> >> - The direct translation of TCP into UDP or UDP into TCP is arguably
> >> a host endpoint emulation function, which strongly suggests that this
> >> document needs to explicitly address both receiving and transmitting
> transport options.
> >> Even if all received options are ignored and no options are used on
> >> transmission, that should be more directly stated – as well as the
> >> impact of that decision, both on functionality and security.
> >
> > The specification has two sections 14 and 15 (IP Header Fields for UDP-to-
> UDP translation and IP Header Fields for TCP-to-UDP translation) to discuss
> direct translations. https://tools.ietf.org/html/rfc5766 only covered UDP-to-
> UDP translation in Section 12.
> 
> Yes, but both sections ignore the impact of transport options - both current
> for TCP and pending for UDP. These are ignored both when packets with
> such transport options are received (the input packet to the translation) and
> whether / how they are used on transmit (the output packet)

TURN is used to relay real-time data (e.g. audio and video streams) and the approach taken by VOIP related specifications 
is to avoid fragmentation for RTP packets. 

> 
> >
> >>
> >> Sec 2.7 might also note that the support for UDP fragmentation and
> >> reassembly could be of benefit here in avoiding IP fragmentation, but
> >> that would be contingent on the previous note – i.e., being able to
> >> use and react to UDP options in the translation process.
> >
> > I don't get the comment, what specific change are you looking in the
> document ?
> 
> The doc currently indicates that UDP relies only on IP fragmentation, but this
> isn’t the case with UDP options (there is a UDP-level frag and reassembly
> that preserves port numbers on each fragment and would thus be TURN-
> compatible).

Okay, I will add the following line:
However, Section 5.7 in https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-07 discusses Fragmentation option to support UDP fragmentation and
reassembly to transfer UDP messages larger than the IP receive MTU.

> 
> >
> >>
> >> Non-transport issues:
> >>
> >> Like RFC 5766, this doc continues to cite
> >> I-D.rosenberg-mmusic-ice-nonsip as guidance, even using a gentle
> >> version of “must”, but this no longer seems appropriate because that
> >> document has expired over a decade ago. Either the guidance should be
> >> summarized in this document or the recommendation should be removed.
> >
> > Good point, Revised ICE specification (https://tools.ietf.org/html/rfc8445)
> has been updated to make the procedures independent of the signaling
> protocol by removing the SIP and SDP procedures.
> >
> > I have updated the text as follows:
> >
> >   For example, if TURN and ICE are used as part of a multimedia
> >   solution using SIP [RFC3261], then SIP serves the role of the
> >   rendezvous protocol, carrying the ICE candidate information inside
> >   the body of SIP messages [I-D.ietf-mmusic-ice-sip-sdp].  If TURN and
> >   ICE are used with some other rendezvous protocol, then ICE provides
> >   guidance on the services the rendezvous protocol must perform.
> >
> >>
> >> Section 2.7 is incorrect in its claim of 576 for IPv4; it confuses
> >> the receiver reassembly minimum (EMTU_R, 576) for the link MTU
> >> (EMTU_S, 68). See draft-ietf-tunnels for details. If 576 is the
> >> focus, at best it could be claimed that 576 is the “de-facto” EMTU_S for
> IPv4. Other nits:
> >
> > Section 2.7 says IPv4 host must be capable of receiving a packet whose
> length is equal to 576 bytes (EMTU_R, 576).
> > Why do you say the text is incorrect ?
> 
> 576 is the reassembly MTU, but is also referred as the PMTU. The PMTU is
> EMTU_S and is strictly only 68.

Got it, I will update the text as follows:

If IPv4 support on legacy or otherwise unusual networks is a
consideration, the application MAY assume on an effective MTU of 576 bytes for
IPv4 datagrams, as every IPv4 host must be capable of receiving a
packet whose length is equal to 576 bytes as discussed in [RFC0791] and [RFC1122].

Cheers,
-Tiru


> 
> >>
> >> Sec 23 indicates the changes since RFC5766; a similar section
> >> addressing changes since RFC6156 would be useful to add.
> >
> > Okay, added another Section (updates to RFC6156).
> >
> > Cheers,
> > -Tiru
> >
> >>
> >>
> >> _______________________________________________
> >> tram mailing list
> >> tram@ietf.org
> >> https://www.ietf.org/mailman/listinfo/tram
> > _______________________________________________
> > Tsv-art mailing list
> > Tsv-art@ietf.org
> > https://www.ietf.org/mailman/listinfo/tsv-art