Re: [secdir] secdir review of draft-ietf-ice-trickle-16

[Peter Saint-Andre <[e-mail]>]

On 2/21/18 2:09 PM, David Mandelberg wrote:
> Hi,

Hi David, thanks for the review.

> The summary of the review is: ready with nits.
> 
> (nit) Section 2: What is a "ufrag pair"? Is it short for username
> fragment pair? I might have just missed it, but I don't see a definition
> in the referenced terminology.

Perhaps it's a term of art, but in draft-ietf-ice-rfc5245bis it's called
the "Username Fragment and Password" so I suggest we use that.

> (nit) Section 15: If I understand correctly, the signaling protocol also
> needs to guarantee that the end-of-candidates indication is not
> re-ordered with respect to any trickled candidates. Is that correct? Is
> it worth adding to the requirements?

Good catch - in-order delivery applies here as well.

OLD
   o  A signaling protocol MUST deliver each trickled candidate not more
      than once and in the same order it was conveyed (see Section 8).

NEW
   o  A signaling protocol MUST deliver each trickled candidate or
      end-of-candidates indication not more than once and in the same
      order it was conveyed (see Section 8).

We might want to also modify the text in Section 8, as follows:

OLD
   When candidates are trickled, the signaling protocol MUST deliver
   each candidate to the receiving Trickle ICE implementation not more
   than once and in the same order it was conveyed.  If the signaling
   protocol provides any candidate retransmissions, they need to be
   hidden from the ICE implementation.

NEW
   When candidates are trickled, the signaling protocol MUST deliver
   each candidate (and any end-of-candidates indication as described in
   Section 8.2) to the receiving Trickle ICE implementation not more
   than once and in the same order it was conveyed.  If the signaling
   protocol provides any candidate retransmissions, they need to be
   hidden from the ICE implementation.

Peter