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

From: Qin Wu <[email-masked]>
Date: Sun, 28 Jan 2018 23:31:21 -0800

Reviewer: Qin Wu
Review result: Ready

I have reviewed this document as part of the Operational directorate’s ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments. Document reviewed:
 draft-ietf-ice-rfc5245bis-16

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.

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

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?

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 29 Jan 2018 08:56:05 +0000

Hi Qin,

Thank You for the review! Please see inline.

>places, e.g., ³ 17.3.  ICE and ICE-lite
>
>³
>³
>³
>³
>³

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."

>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.²

---

>gathering signaling traffic can be ignored comparing with the total

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."

---

>³
>³

Will fix as suggested.

Regards,

Christer

---

From: Qin Wu <[email-masked]>
Date: Tue, 30 Jan 2018 02:53:29 +0000

Thanks Christer, you address my comments.

-Qin
-----邮件原件-----
发件人: Christer Holmberg [mailto:[email-masked]] 
发送时间: 2018年1月29日 16:56
收件人: Qin Wu; [email-masked]
抄送: [email-masked]; [email-masked]; [email-masked]
主题: Re: Opsdir last call review of draft-ietf-ice-rfc5245bis-16

Hi Qin,

>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
>
>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:

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

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.²

---

>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.

 "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.²

 ³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."

---

>³ s/he STUN amplification attack/The STUN amplification attack

Will fix as suggested.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 30 Jan 2018 06:56:48 +0000

Thank You! :)

On 30/01/18 04:53, "Qin Wu" <[email-masked]> wrote:

>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:
>
>   "In contrast, a lite implementation only is a minimalist
>implementation that does little but respond to STUN