Re: [secdir] Secdir review of draft-ietf-ice-dualstack-fairness-03

["Pal Martinsen (palmarti)" <[e-mail]>]

Thanks for the thorough review. Due to paternity leave there will be a slight delay fixing the issues. Will attend to this early August.

P?l-Erik
Sent from my iPhone

On 07 Jul 2016, at 06:39, Charlie Kaufman <[e-mail]<mailto:[e-mail]>> wrote:


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



[https://cid-ee6944db1998bb09.users.storage.live.com/users/0xee6944db1998bb09/myprofile/expressionprofile/profilephoto:UserTileMedium,UserTileStatic,UserTileSmall/MeControlMediumUserTile?ck=1&ex=24&fofoff=1&sc=1467864372864]
Reply all



Sent from Outlook<http://aka.ms/weboutlook>