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

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

> On 07 Jul 2016, at 06:12, Charlie Kaufman <[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.
> 
Rewrote the security section. Going into details regarding STUN is not needed.

How about:
The security considerations described in [I-D.ietf-ice-rfc5245bis]
are still valid.  This specification does not add or remove any
security considerations.  It changes recommended values and describes
how an agent could choose those values in a safe way.



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

That is a good summary. My only comment is that we are not dealing with “techniques” (ICE is the technique we are using).  What we are struggling with is multiple network paths that may or may not work. 

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

I tend to agree, but we struggled to find a better word than fairness. 

I am not a native speaker, so I might got this wrong. From http://www.dictionary.com:
“the state, condition, or quality of being fair, or free from bias or injustice; evenhandedness”.

We are trying to be free from bias or injustice when deciding what network paths to test first. 


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

The original intent of the draft was to provide a formula, but creating one that everyone was happy with proved difficult. So the draft reverted to provide guidelines and say what values safely could safely be experimented with. 
 
Added text to introduction:
“ This document describes what parameters an agent can safely alter to
   fairly order the checklist candidate pairs in multihomed and dual-
   stack environments, thus affecting the sending order of the
   connectivity checks.  Actual values of those parameters is an
   implementation detail.  Dependant on the nomination method in use,
   this might have an effect on what candidate pair ends up as the
   active one.  Ultimately it should be up to the agent to decide what
   candidate pair is best suited for transporting media.”


> 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…
> 
?? Did not find that text.

> 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.”
> 
Both of those sections talks about backward compatibility. The intent was to say if agent supporting dual-stack fairness talks to an old ICE agent things would probably still be better off, but since this is also only recommendations in the ICE RFC there is really know way for us to know. 

Saying anything about connection times will open up a big rat-hole in the WG. The use of the fairness wording was meant to indicate that overall connection times might go up ((Especially for those implementation that did a hard prioritisation of IPv4, but the goal of this is to help IPv6 as well), but you would avoid those scenarios where excessive delays ere encountered. 

> Typos:
> 
> Section 1 para 1 line 5: arguable -> arguably
Fixed.
> Section 1 para 1 line 7: know -> known
Fixed
> Section 1 para 2 line 7: describes -> describe
Fixed.
> Page 4 last para line 7: “too excessive" -> "not optimal"
Fixed
> Section 7 end of third to last paragraph: missing “.”
Ignored, text to be removed before publishing as RFC. 



Have posted a new version of the draft. We should probably take especially care to make sure we are happy with the new security section. 


.-.
Pål-Erik

> 
> 
> 
> Sent from Outlook