Re: [Gen-art] [tram] Genart last call review of draft-ietf-tram-turnbis-25

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Tue, 04 June 2019 09:46 UTC

Return-Path: <TirumaleswarReddy_Konda@mcafee.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292341200F4; Tue, 4 Jun 2019 02:46:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level:
X-Spam-Status: No, score=-4.31 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] 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 alJBKsmLLR9s; Tue, 4 Jun 2019 02:46:25 -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 DF5CA1200CD; Tue, 4 Jun 2019 02:46:21 -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=1559641082; 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-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=SAouRGqqdx0NfI/OtAtTCsqFkyZMiRGT/FkgMW Febrs=; b=RZyK9Qjo94Wk5uAvO3vb9UsbSfPUKMNYtKUCVm5C 4VdXTKoHLvCJCKU9UFGTYwOr2OBmh8blkdeipOXDDhxUBOgcxk ClGx36Ji8o0RFFdAxkIraWySM+Bs9ff7S6/gagi/gD3tvlqazn SfQRP9rQ3gGO3FHLHccqj20twuUGtrQ=
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 4f6d_e457_2253c5e6_1081_4b85_a0d7_2cab93a8c435; Tue, 04 Jun 2019 03:38:01 -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; Tue, 4 Jun 2019 03:46:17 -0600
Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 4 Jun 2019 03:46:17 -0600
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 4 Jun 2019 03:46:11 -0600
Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB2294.namprd16.prod.outlook.com (52.132.142.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1943.22; Tue, 4 Jun 2019 09:46:09 +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; Tue, 4 Jun 2019 09:46:09 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: Vijay Gurbani <vijay.gurbani@gmail.com>, "gen-art@ietf.org" <gen-art@ietf.org>
CC: "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: [tram] Genart last call review of draft-ietf-tram-turnbis-25
Thread-Index: AQHVF8AO1lDWTpR4KEeu7XcJ/Za4SaaJ4XTw
Date: Tue, 04 Jun 2019 09:46:09 +0000
Message-ID: <DM5PR16MB17053ED6AA91994433095303EA150@DM5PR16MB1705.namprd16.prod.outlook.com>
References: <155931411903.6360.15337432658764941505@ietfa.amsl.com>
In-Reply-To: <155931411903.6360.15337432658764941505@ietfa.amsl.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: 717f19c8-8a19-4f06-1b5f-08d6e8d17931
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB2294;
x-ms-traffictypediagnostic: DM5PR16MB2294:
x-ms-exchange-purlcount: 7
x-microsoft-antispam-prvs: <DM5PR16MB2294D0BF793FD0EF31C7ED60EA150@DM5PR16MB2294.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 0058ABBBC7
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(366004)(39860400002)(346002)(396003)(32952001)(189003)(199004)(13464003)(51914003)(66556008)(66476007)(64756008)(66946007)(5660300002)(73956011)(74316002)(53936002)(25786009)(76116006)(52536014)(6246003)(4326008)(86362001)(33656002)(110136005)(76176011)(7696005)(2501003)(99286004)(54906003)(14444005)(5024004)(71200400001)(256004)(71190400001)(8676002)(966005)(72206003)(26005)(6506007)(2906002)(66066001)(66446008)(6116002)(102836004)(68736007)(3846002)(53546011)(55016002)(6306002)(9686003)(229853002)(305945005)(316002)(8936002)(7736002)(80792005)(14454004)(476003)(6436002)(81166006)(81156014)(486006)(11346002)(478600001)(446003)(186003)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB2294; 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: 4L8OUyUmWZD+zOVNaq5yhS3V/gtll9+05aMRDbnfjzwHUj8uA/YK42rApoeh91KmzUgT8re6CE0n2DFBbzlmESqGQbIu1VgTGw2MQ19dCMilzsCvHUg8aI6YFlOW2DiVdBqJxbigaG/HTEwPmFdZAbeEnqulhLdm3pGn4rU2qp++mggHtSaNb0uxfxLU9nC4ap83/eZuyBa1wt5YH8k1gJgwRAJ6VuuSco0XBUVYsTHdMyD3CVCSu9vyqGrBfVZ32QW8k6TPgFIt5vjRD7rzI8rTBjCtsHtpSycqYvW6U/NzShKP4dDZTAfRe6ZAUHBMFEEJjONVQhKLpZtM4jcMb5E9zLH10u+RgKINywaFAzGwM+ENMfcOY3CwZ4U1MX4Xq3IXHsSqj3++yJi1AfpcWk+kzxyOpILlvO7EmtDVpI8=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 717f19c8-8a19-4f06-1b5f-08d6e8d17931
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2019 09:46:09.6692 (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: DM5PR16MB2294
X-OriginatorOrg: mcafee.com
X-NAI-Spam-Flag: NO
X-NAI-Spam-Level:
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0.1
X-NAI-Spam-Version: 2.3.0.9418 : core <6560> : inlines <7096> : streams <1823496> : uri <2852536>
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/_sxRL38hL96EvyAdQiFPkegXovw>
Subject: Re: [Gen-art] [tram] Genart last call review of draft-ietf-tram-turnbis-25
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Jun 2019 09:46:27 -0000

Hi Vijay,

Thanks for the review, Please see inline.

> -----Original Message-----
> From: tram <tram-bounces@ietf.org> On Behalf Of Vijay Gurbani via
> Datatracker
> Sent: Friday, May 31, 2019 8:19 PM
> To: gen-art@ietf.org
> Cc: draft-ietf-tram-turnbis.all@ietf.org; ietf@ietf.org; tram@ietf.org
> Subject: [tram] Genart 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: Vijay Gurbani
> Review result: Ready with Issues
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
> the IETF Chair.  Please treat these comments just like any other last call
> comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-tram-turnbis-25
> Reviewer: Vijay K. Gurbani
> Review Date: 2019-05-31
> IETF LC End Date: 2019-05-28
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: Ready but has some issues that need to be looked at as described
> below.
> 
> Major:
> 
> - My advice would be to put S3 (Terminology) before S2.  There are a lot of
> terms defined in S3 that S2 simply uses; it will serve the reader well if they
> already knew these terms by the time the encountered them.

Works for me, moved Terminology Section.

> 
> Minor:
> - S1, paragraph 2: "...NATs that are well behaved."  Here, what is the
> definition of a "well behaved" NAT?  Is there a RFC that encodes expected
> behaviour?  If so, please provide a reference.  If not, then some resource
> should be made available (a paragraph or some reference) where the
> expected  behaviour of NATs is codified to some extent.

Address-dependent or Address-and port-dependent mappings are not well behaved NATs, this paragraph refers to RFC4787 (see https://tools.ietf.org/html/rfc4787#section-4.1 ) and says hole-punching technique will not work
with NATs having Address-dependent or Address-and port-dependent mapping behavior. 

NEW:
   As described in [RFC5128] and [RFC4787], hole punching techniques
   will fail if both hosts are behind NATs that are not well behaved.
   For example, if both hosts are behind NATs that have a mapping
   behavior of "address-dependent mapping" or "address- and port-
   dependent mapping" (Section 4.1 in RFC4787), then hole punching techniques generally fail.

> 
> - S 2.4, Figure 3: "To partly mitigate this attack ...", just to be explicit,  this is
> partial mitigation because an attacker, observing the CreatePermission
> request and response can masquerade as the client and immediately send a
> Send  indication to the peer address observed in the CreatePermission
> request.  Is  this correct?  
>If so, I think it is worth documenting in the draft.  If
> not,  some idea on the origins of the "partial mitigation" will be good to know
> for  the implementors of the specification for the sake of completeness.

If the attacker spoofs the TURN client IP address and sends bogus Send indication to the server to a peer based on the permission installed by the TURN client to the peer, this attack cannot be mitigated the server unless (D)TLS is used. However, if the attacker spoofs the TURN client IP address and sends bogus Send indication to the server to peer but the client has not installed permission to the peer, this attack can be mitigated by the server.  The above points are covered in https://tools.ietf.org/html/draft-ietf-tram-turnbis-25#section-20.1.4. 
> 
> - S2.7, first paragraph: s/try hard to avoid/avoid/  (What does it for a program
> compliant to this specification to "try hard"?
>  Either the author of the program knows fragmentation is not desirable or
> they don't and the packet is fragmented.)

Done.

> 
> - S5, second to last paragraph: "When TCP transport is used ..."  Here,
> wouldn't  TCP detect the bit flip?  What am I missing here?  TCP is
> transporting TURN  packets, if one of the bits in the TURN packet flips, won't
> the TCP checksum  become invalid?

Please see the discussion in BEHAVE WG mailing list https://mailarchive.ietf.org/arch/msg/behave/O7A7vTihIBJ-uKmJT_bSea13wIA 

> 
> - S5, second to last paragraph: "...a long sequence of invalid..."  Here, how
>   long is "long"?  2 messages?  3 messages?  4 messages?  I think an explicit
>   guideline may help make the error handling more robust.

The threshold for long sequence of invalid TURN messages looks implementation specific to me, it was not specified in the base TURN spec (see https://tools.ietf.org/html/rfc5766#section-4).  

> 
> - S7.3, third paragraph: "...before trying to request any more ..."  Here, how
>   many times should a client retry the request upon the receipt of a 508?
>   Again, an explicit guideline will help interoperability; otherwise, some
>   clients will retry only once, other more than once, and so on.

The number of attempts the client would retry is implementation specific. For example, if other TURN servers are available, the client can try to get the relayed transport address from the other TURN servers and need not retry the request (see https://tools.ietf.org/html/rfc8445#section-5.1.1.2). 

> 
> - S12: Please label the figure that appears in this section, especially since it
>   will be nice to refer to it explicitly, as is required in S12.6.  (There, the
>   text simply says "...as described above.", where "above" probably implies
> the
>   table in S12.)

Sure, added label and referred to it explicitly.
, 

> 
> - S13: s/runs in userland/runs in user space/  ("userland" is colloquial usage,
> better to use "user space".)

Updated.

> 
> Nits:
> 
> - Abstract: s/from some other/from other/

Fixed.

Cheers,
-Tiru

> 
> That's it!  Thanks.
> 
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram