Subject: Re: [Roll] AD review of draft-ietf-roll-trickle-04

From: Philip Levis <[email-masked]>
Date: Thu, 11 Nov 2010 11:25:09 -0800

Adrian,

I've just submitted version -05 of the draft, which tries to address all of your comments. The security considerations section does not have any RECOMMEND statements, but rather instead just has a few comments on ways in which an adversary might try to subvert the algorithm, and how protocols might protect against such.

Phil

On Oct 9, 2010, at 4:09 AM, Adrian Farrel wrote:

> I have performed an AD review of your draft.
> 
> Don't panic!
> 
> I review all drafts that I am responsible for before putting them forward for IETF last call. The main objective is to catch nits and minor issues that would show up during the last call or in IESG review. The intention is to help polish your document and make sure
> it is clean and shiny so that other reviewers will stick to the technical details.
> 
> Thanks you for a really well-written and clear document. Excellent work!
> 
> On reviewing it, there are a couple of small points I think it would be helpful to sort out to ensure complete understanding from all your readers. I'd like to see a quick respin of the document before I issue the IETF last call. As soon as I see a new revision posted, I'll set the ball in motion.
> 
> Of course, all of my issues are up for discussion.
> 
> Thanks for the work,
> Adrian
> 
> ---
> 
> idnits (http://tools.ietf.org/tools/idnits/) reports
> 
> == You're using the IETF Trust Provisions' Section 6.b License Notice
>    from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009.
>    (See http://trustee.ietf.org/license-info/)
> 
> Can you fix this, plase.
> 
> ---
> 
> Good that you pulled "trickle communication rate" out for attention as a term. Could you also pull out "trickle transmission rate"?
> 
> ---
> 
> In section 3
> 
>  The Trickle
>  algorithm balances the load in such a scenario, as each node's
>  Trickle transmission rate is 1/nth of the Trickle communication rate.
>  Sparser networks require more transmissions per node, but utilization
>  of the radio channel over space will not increase.
> 
> No issues with the facts.
> But this is the first mention of radio channels. Up to this point we would have been quite happy thinking of fixed-line connectivity.
> Can you tweak something?
> 
> ---
> 
> Section 4.1
> 
>  o  The maximum interval size is described as a number of doublings of
>     the minimum interval size (the base-2 log(max/min)).  For example,
>     a protocol might define the maximum interval as 16.  If the
>     minimum interval is 100ms, then the maximum interval is 100ms *
>     65536, 6,553.6 seconds, or approximately 109 minutes.
> 
> There is a slight discrepency in terminology here, and a little tidying that could be done to the expression of the example.
> 
> The problem comes that you have "maximum interval sixe" as a number of doublings, but you are also trying to state the amount of time it implies.
> 
> Can I suggest...
> 
>  o  The maximum interval size is described as a number of doublings of
>     the minimum interval size (the base-2 log(max/min)).  For example,
>     a protocol might define the maximum interval size as 16.  If the
>     minimum interval size is 100ms, then the amount of time specified
>     by the maximum interval size of 16 is
>        100ms * 2^16 = 6,553.6 seconds
>     or approximately 109 minutes.
> 
> A similar terminology problem shows up in 6.2
> 
>  Note that mismatched Imin values and matching
>  Imax doubling constants will lead to mismatched Imax values.
> 
> Can you go through the document and decide whether Imax is the doubling constant or the time period.
> 
> ---
> 
> Section 4.2
> 
>  5.  If Trickle hears a transmission that is "inconsistent," the
>      Trickle timer resets.  If I is greater than Imin, resetting a
>      Trickle timer sets I to Imin and begins a new interval.  If I is
>      equal to Imin, resetting a Trickle timer does nothing.  Trickle
>      can also reset the timer in response to external "events."
> 
> If "resetting a Trickle timer does nothing", how can you justify the word "reset"? Doesn't a new interval always start when the timer is
> reset? Or are you saying that the timer restarts, but the counter is not reset to zero?
> 
> ---
> 
> Section 6.1
> 
> OLD
>  Hence, the danger of
>  mismatched k values is uneven transmission load that can deplete the
>  energy of some nodes.
> NEW
>  Hence, the danger of
>  mismatched k values is uneven transmission load that can deplete the
>  energy of some nodes in a lower-power network.
> END
> 
> ...because there is no specific limitation to apply this to low-power networks..
> 
> ---
> 
> Section 6.5
> 
> having the parameter describe (k-1)
> 
> Do you mean k=-1 ?
> 
> ---
> 
> Section 6.6
> 
>  Finally, a protocol SHOULD set k and Imin such that Imin is at least
>  two to three as long as it takes to transmit k packets.
> 
> s/three as/three times as/
> 
> ---
> 
> Section 9
> 
> I am worried about this section being so empty. I don't think the algorithm needs any security work, but I do think that you can give advice on the security implications for protocols that use the algorithm.
> 
> For example, what would be the impact of a false positive or a false negative? Given that impact, what precautions should a protocol that uses Trickle take?
> 
> For example, in Section 6 you have:
> 
>  It is RECOMMENDED that a protocol which uses Trickle include
>  mechanisms to inform nodes of configuration parameters at runtime.
> 
> What would happen if these mecahnisms were attacked?
> 
> In short, can you add some RECOMMENDations about what protocols that use Trickle shold consider in their specifications.
>