RE: Opsdir last call review of draft-ietf-ice-rfc5245bis-16

Qin Wu <bill.wu@huawei.com> Tue, 30 January 2018 02:53 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F06361273E2; Mon, 29 Jan 2018 18:53:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.23
X-Spam-Level:
X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 v8LBhTMPQaAu; Mon, 29 Jan 2018 18:53:40 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 D91A41314D6; Mon, 29 Jan 2018 18:53:39 -0800 (PST)
Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 093A72D2E7BBC; Tue, 30 Jan 2018 02:53:36 +0000 (GMT)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 30 Jan 2018 02:53:37 +0000
Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.231]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0361.001; Tue, 30 Jan 2018 10:53:30 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, "ops-dir@ietf.org" <ops-dir@ietf.org>
CC: "draft-ietf-ice-rfc5245bis.all@ietf.org" <draft-ietf-ice-rfc5245bis.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "ice@ietf.org" <ice@ietf.org>
Subject: RE: Opsdir last call review of draft-ietf-ice-rfc5245bis-16
Thread-Topic: Opsdir last call review of draft-ietf-ice-rfc5245bis-16
Thread-Index: AQHTmN8FNcBNiXVxRUW6BrVhA9ymqKOLuRLg
Date: Tue, 30 Jan 2018 02:53:29 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA9AD4823A@nkgeml513-mbs.china.huawei.com>
References: <151721108111.3093.7915132093422888914@ietfa.amsl.com> <D694A6BD.29F51%christer.holmberg@ericsson.com>
In-Reply-To: <D694A6BD.29F51%christer.holmberg@ericsson.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.79.67]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/MMQNcAEdRrC2OoovespAe1yV_bI>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jan 2018 02:53:42 -0000

Thanks Christer, you address my comments.

-Qin
-----邮件原件-----
发件人: Christer Holmberg [mailto:christer.holmberg@ericsson.com] 
发送时间: 2018年1月29日 16:56
收件人: Qin Wu; ops-dir@ietf.org
抄送: draft-ietf-ice-rfc5245bis.all@ietf.org; ietf@ietf.org; ice@ietf.org
主题: Re: Opsdir last call review of draft-ietf-ice-rfc5245bis-16

Hi Qin,

Thank You for the review! Please see inline.

>Summary:
>This document defines ICE protocol for NAT traversal in the UDP-based 
>communication. The draft is well written, especially operational 
>consideration section and security section. I believe it is ready for 
>publication.
>
>Major issue: None
>Minor issue: Editorial
>1.This draft discuss the difference between ICE and ICE difference in 
>many places, e.g., ³ 17.3.  ICE and ICE-lite
>
>   Deployments utilizing a mix of ICE and ICE-lite interoperate
>   perfectly.  They have been explicitly designed to do so, without loss
>   of function.
>³
>³
>4.  Terminology
>
>   Full Implementation:  An ICE implementation that performs the
>      complete set of functionality defined by this specification.
>
>   Lite Implementation:  An ICE implementation that omits certain
>      functions, implementing only as much as is necessary for a peer
>      implementation that is full to gain the benefits of ICE.  Lite
>      implementations do not maintain any of the state machines and do
>      not generate connectivity checks.
>³
>³
>Appendix A.  Lite and Full Implementations
>
>   ICE allows for two types of implementations.  A full implementation
>   supports the controlling and controlled roles in a session, and can
>   also perform address gathering.  In contrast, a lite implementation
>   is a minimalist implementation that does little but respond to STUN
>   checks.
>³
>I would suggest to make them consistent, e.g., in section 17.3, it 
>mentions that deploying combination of ICE and ICE-Lite can be designed 
>to interoperate perfect without loss of function, however ICE-Lite in 
>section 4 is defines as one implementation that could omit some of 
>function.

I think the ³without loss of function² part is a little misleading, as the lite implementation will not perform certain tasks.

I suggest to simply say:

 "Deployments utilizing a mix of ICE and ICE-lite interoperate
  perfectly.  They have been explicitly designed to do so."


>Also I want to know whether lite implementation supports the 
>controlling and controlled roles in Appendix A.

I suggest to modify the following sentence:

OLD:

   "In contrast, a lite implementation is a minimalist implementation that does little but respond to STUN
    checks.²


NEW:

   "In contrast, a lite implementation only is a minimalist implementation that does little but respond to STUN
    Checks, and only supports the controlled role in a session.²


---


>2. Section 17.2.2 said:
>"
>The gathering phase and the connectivity
>   check phase are meant to generate traffic at roughly the same
>   bandwidth as the data traffic itself.
>"
>"
>   Of course, the ICE
>   checks will cause a marginal increase in the total utilization;
>   however, this will typically be an extremely small increase.
>"
>I am wondering whether generated traffic in the first sentence is 
>referred to connectivity check signaling traffic+ gathering signaling 
>traffic+ user data traffic, in other words, whether connectivity check 
>signaling traffic+ gathering signaling traffic can be ignored comparing 
>with the total volume of data traffic?


The intension is to say that the ICE process (gathering and connectivity
check) will not consume more bandwidth than, once ICE has concluded, the data itself.

Would the following modified sentence be more clear?

 "The gathering phase and the connectivity check phase are meant to generate traffic at roughly the same
  bandwidth as the data traffic itself will consume once the ICE process conclude.²


I also think the second sentence could be clarified:

 ³Once ICE has concluded, the subsequent ICE keep-alives will later cause a marginal increase in the total bandwidth utilization;
  however, this will typically be an extremely small increase."


---

>3. Section 19.4.1 said:
>³
>19.4.1.  STUN Amplification Attack
>
>   he STUN amplification attack is similar to a "voice hammer" attack, 
>³ s/he STUN amplification attack/The STUN amplification attack


Will fix as suggested.

Regards,

Christer