Subject: Re: [Ice] Alissa Cooper's Discuss on draft-ietf-ice-dualstack-fairness-04: (with DISCUSS and COMMENT)

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Mon, 5 Sep 2016 10:31:34 +0000

> On 31 Aug 2016, at 21:11, Alissa Cooper <[email-masked]> wrote:
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ice-dualstack-fairness/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> = Section 4 =
> 
> "However, modifying the check list
>   directly can lead to uncoordinated local and remote check lists that
>   result in ICE taking longer to complete or in the worst case scenario
>   fail.  The best approach is to modify the formula for calculating the
>   candidate priority value described in ICE [I-D.ietf-ice-rfc5245bis]
>   section "4.1.2.1 Recommended Formula"."
> 
> ICEbis section 4.1.2.1 then says:
> 
> "If a host is
>   multihomed because it is dual-stack, the local preference should be
>   set according to the current best practice described in
>   [I-D.ietf-ice-dualstack-fairness]."
> 
> So, there is a circular reference, and nowhere is it specified how the
> formula should actually change. I think it's fine to put this in ICEbis,
> but if this draft is going to reference it then it actually needs to be
> specified there.
> 
> Alternatively, if this text is meant to reference the discussion further
> down in Section 5, I wouldn't call that modifying the formula, but rather
> providing guidance about how to set local preferences within the formula.
> 
Yes. Modifying is bad wording.

Changed to:
“  However, modifying the check list
   directly can lead to uncoordinated local and remote check lists that
   result in ICE taking longer to complete or in the worst case scenario
   fail.  The best approach is to set the appropriate value for local
   preference in the formula for calculating the candidate priority
   value described in ICE [I-D.ietf-ice-rfc5245bis] section "4.1.2.1
   Recommended Formula”."

> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> = Section 3 =
> 
> "If the agent has access to
>   information about the physical network it is connected to (Like SSID
>   in a WiFi Network) this can be used as information regarding how that
>   network interface should be prioritized at this point in time."
> 
> I think this needs further elaboration, as it's not obvious how knowledge
> of the SSID correlates to knowledge of the stability of the network.
> 

I think the whole sentence could safely be removed. The previous sentence,

“ To avoid unnecessary delay when performing connectivity checks it would
   be beneficial to prioritize interfaces and IP addresses known by the
   agent to provide stable connectivity.”,

describes the intent fairly clear. 

How things are “known t the application” would vary from OSes and environments the agent is operating in. 

> "Candidates from an interface known to the application to provide
>   unreliable connectivity should get a low candidate priority.  This
>   ensures they appear near the end of the candidate list, and would be
>   the last to be tested during the connectivity check phase.  This
>   allows candidate pairs more likely to succeed to be tested first."
> 
> All three of these sentences say more or less the same thing, so two of
> them could be dropped.

:-) 

New text:
"Candidates from an interface known to the application to provide
   unreliable connectivity should get a low candidate priority.”

> 
> = Section 8 =
> 
> Doesn't following the recommendations in Section 3 potentially leak
> information to a remote peer about the quality of a local peer's
> connectivity on different interfaces? That is, if the remote peer
> maintains some state about past ICE interactions, would it be able to
> detect a change of priority that could indicate a change in connectivity
> quality? If so, this seems worth mentioning.
> 
> 
Sort of. The passive attacker could possible learn the same information by looking at the connectivity checks in the without this as well.

But this leaks how the current agent priorities the different network interfaces (Really IP addresses, because the remote peer would not know what interface has what IP address, at least not with IPv6.)

New Security Section:
"The security considerations described in [I-D.ietf-ice-rfc5245bis]
   are still valid.  It changes recommended values and describes how an
   agent could choose those values in a safe way.  In section Section 3
   the agent can prioritize the network interface based on previous
   network knowledge.  This can potentially be unwanted information
   leakage towards the remote agent.”

Thanks for the thorough review!

.-.
Pål-Erik

> _______________________________________________
> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice