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