Last Call Review of draft-ietf-ice-dualstack-fairness-03
review-ietf-ice-dualstack-fairness-03-secdir-lc-kaufman-2016-07-14-00

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs
 should treat these comments just like any other last call comments.

I don't believe this proposal raises any security concerns. It has a short
Security Considerations section containing information relevant to ICE but not
to this proposed modification.

This document proposes a modification to RFC5245bis (which specifies a protocol
for NAT traversal). When trying to establish a connection through a NAT, there
are a number of different techniques that can be used, some of which will work
and some of which will
 not work depending on the characteristics of the NAT and other aspects of the
 environment. RFC5245 specifies an enumeration of such techniques and specifies
 an order in which they should be attempted.

Apparently, there are problems in real world deployments where there are a
large number of possible NAT traversal techniques and checking them in the
order prescribed by RFC5245bis results in long delays and sometimes connection
failures based on timeouts.
 This document proposes changing the order in order to get better performance
 and reliability. It makes no other changes to the protocol.

Detailed review:

I'm not an ICE expert, so some of these comments may be completely misguided.
Take them for whatever they may be worth.

I don't think "fairness" is the right term in this context. The goal is not a
fair division of resources between different clients or even any sort of
balance between use of IPv4 and IPv6. If many different connectivity mechanisms
worked, the preferred mechanism
 would be (I assume) the one computed using the formula in RFC5245bis. The
 problem is that checking all of the mechanisms in order to too time consuming,
 and there is a desire to check (and settle on) techniques more likely to work
 ahead of techniques less likely to work but more optimal if they do (in
 particular, checking some IPv4 based techniques before all of the IPv6 based
 techniques have been tried).

Section 5 says:

> ICE [I-D.ietf-ice-rfc5245bis] section 4.1.2.2 has guidelines for how

> the type preference and local preference value should be chosen.

> Instead of having a static local preference value for IPv4 and IPv6

> addresses, it is possible to choose this value dynamically in such a

> way that IPv4 and IPv6 address candidate priorities end up

> intermingled within the same candidate type. It is also possible to

> assign lower priorities to IP addresses derived from unreliable

> interfaces using the local preference value.

This specification says what is possible, but it does not (as far as I could
see) specify any particular means of accomplishing it. If the intent of this
RFC is to encourage people to experiment with different priority techniques,
that's fair but the document
 should say so. If the intent is to encourage people to copy the design in
 ICE_dualstack_imp, then it's formula for priority should be specified here in
 sufficient detail to implement it.

Section 1 para 1 line 5: All interfaces and address types are known to the
application. Perhaps this was intended to say all interfaces and address types
known by the application to be unreliable...

Section 1 last paragraph and Section 5 third to last paragraph say:

> The introduced fairness might be better, but not

> worse than what exists today

This is probably not true. There are probably unusual cases where this
reordering will result in slightly increased connection times. I suspect what
is meant is that "In almost all cases this change will result in connection
times at least as fast as those
 using the previous system, and in many cases the benefit will be substantial."

Typos:

Section 1 para 1 line 5: arguable -> arguably

Section 1 para 1 line 7: know -> known

Section 1 para 2 line 7: describes -> describe

Page 4 last para line 7: "too excessive" -> "not optimal"

Section 7 end of third to last paragraph: missing "."

Reply all

Sent from

Outlook