Re: [Roll] AD review of draft-ietf-roll-p2p-measurement-06

Hi,

Thanks Adrian - I would agree to post a new revision addressing your comment before IETF LC.

Thanks.

JP.

On Dec 5, 2012, at 3:22 PM, Adrian Farrel wrote:

> Hi,
> 
> I have done my usual AD review of your document as part of processing
> the publication request. This review should be considered alongside 
> my review of draft-ietf-roll-p2p-rpl as the documents are closely 
> linked.
> 
> I have a number of questions and minor issues that I would like to
> resolve before advancing the documents. 
> 
> As usual, all of my comments are up for discussion, but I think that a
> new revision will be needed, so I have moved the document into "Revised
> I-D Needed" state in the data tracker and will wait for your emails 
> and/or a new revision.
> 
> Many thanks for your work,
> Adrian
> 
> 
> ---
> 
> As with draft-ietf-roll-p2p-rpl, I would like some discussion in the
> Introduction about why this Experimental and what you expect to
> discover. I think the text is easier for this document...
> 
>   This document provides a mechanism that can be used to determine
>   whether and how to establish a new point-to-point route in an LLN.
>   This utility of the mechanism described in this document is, 
>   therefore, dependent on the existence of a protocol mechanism for
>   establishing P2P routes. [I-D.ietf-roll-p2p-rpl] is targeted at
>   publication as an Experimental RFC for reasons described in that
>   document. It makes sense, therefore, for this document also to be
>   targeted as Experimental.
> 
>   As experience is gained using the mechanisms described in
>   [I-D.ietf-roll-p2p-rpl] it is hoped that the mechanisms described in
>   this document will also be used, and feedback will be provided to the
>   ROLL working group on the utility and benefits of this document.
> 
> ---
> 
> I think that "quality" is the wrong word. "Quality" is usually
> associated with measures like packet loss, delay, and jitter. I don't
> think you are measuring those things, and while I understand why you
> say "quality of a route", I think you need some other phrase.
> 
> I think this more like...
> 
>  A Mechanism to Record the end-to-end Metrics of a Point-to-point
>             Route in a Low Power and Lossy Network
> 
> In the Introduction, you have some nice words...
> 
>   to measure
>   the aggregated values of the routing metrics along the existing
>   route
> 
> ---
> 
> Abstract
> 
> I'm confused :-)
> 
> The document title is very specific to P2P routes. But the Abstract 
> (deliberately?) does not mention P2P. Section 1 seems to imply that I
> could run the mechanisms on any route from origin to target to see if it
> is good enough - and that would include routes created using normal RPL.
> But section 2 explicitly constrains the mechanism to P2P routes.
> 
> Furthermore, the redefined terminology in 1.1 (see below for my 
> objection to that!) seem to suggest measuring from an arbitrary origin
> to an arbitrary target regardless of whether a P2P route exists.
> 
> Can you:
> - unconfuse me
> - make sure that the abstract and introduction explain the real
>  situation
> - make sure the document title is accurate
> - make sure that the document is consistent
> - be careful with terminology (just because you run the mechanism from
>  A to B in a point-to-point sort of way, doesn't mean that there is a
>  P2P route from A to B)
> 
> ---
> 
> 1.1                    
> 
> Did you really need to redefine these terms instead of use new terms for
> new concepts? Given how close the two documents are, it's a shame to 
> confuse things.
> 
> ---
> 
> 3.1
> 
> I was going to say...
> 
>   Seems like the H flag is not needed since leaving it clear is 
>   semantically equivalent to setting RPLInstanceID=0b10000000
> 
>   Not very important, but you increase the chances of a malformed 
>   message, and you use your last bit that could be reserved for 
>   future use.
> 
> ...but then I read the text lower down about how a transit router
> can change the H flag under special circumstances. Now I am confused
> because if the H flag setting is changed, surely the rule governing 
> the RPLInstanceID is broken.
> 
> ---
> 
> 3.1
> 
> Some of the flag settings that have no meaning dependent on other
> flag settings are described as "MUST be set to zero" which is fine.
> But should you also say they should be ignored?
> 
> ---
> 
> 3.1
> 
> I found the description of what goes in the Metric Container Options
> inadequate. There should at least be a forward pointer to some section
> that describes how this piece of the MO object is constructed, but some 
> text would help as well.
> 
> ---
> 
> Section 4
> 
>   The Origin MUST discard the MO message if:
> 
> That reads a bit odd. Didn't the Origin just build the message? Why 
> would it build a message and then discard it? Why not just not build a
> bad message?
> 
> ---
> 
> Section 5
> 
>   An Intermediate Router MUST discard the packet with no further
>   processing if the received MO is not a Measurement Request.
> 
> For clarity and consistency with other paragraphs, can you add...
> 
>   i.e., if the T flag is not set to one.
> 
> ---
> 
> Section 7
> 
>   The Origin MUST discard the packet with no further processing ...
>   ... if the Origin has no
>   recollection of sending a Measurement Request with the sequence
>   number listed in the received MO.
> 
> Trying to decide why that is a "MUST".
> I guess there are some security/bug considerations.
> But are you unduly limiting the Origin implementation to be required to
> keep track of the MOs that it sends?
> 
> ---
> 
> Section 7
> 
>   The Origin MUST examine the routing metric objects inside the Metric
>   Container options to evaluate the quality of the measured P2P route.
>   If a routing metric object contains local metric values recorded by
>   routers on the route, the Origin MUST aggregate these local values
>   into an end-to-end value as per the aggregation rules for the metric.
> 
> That is going too far in the use of "MUST". The Origin can do anything 
> it likes with the Measurement Reply including discard it, hash it and
> use it as a random number, or process it according to policy! I think
> what you need is...
> 
>   The Origin can use the routing metric objects inside the Metric
>   Container to evaluate the metrics for the measured P2P route. If a
>   routing metric object contains local metric values recorded by 
>   routers on the route, the Origin can make use of these local values
>   by aggregating them into an end-to-end metric according to the 
>   aggregation rules for the specific metric. An Origin is then free to 
>   interpret the metrics for the route according to its local policy.
> 
> ---
> 
> Section 8
> 
> Question. Can I use this mechanism to find out stuff about the network
> that should/would otherwise be private? And could I, as an outside node
> do that?
> 
> For example, if I sit next to the network and ping every possible P2P 
> route, can I find out which nodes are almost out of battery, and which
> nodes are key nodes in the topology? Knowing this would help me attack
> the network. What are the protections?
> 
> 
> ---
> 
> 11.2
> You have used [I-D.ietf-roll-p2p-rpl] as a normative reference (at 
> least for the terminology).
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll