Re: [Roll] ID Tracker State Update Notice: <draft-ietf-roll-p2p-measurement-06.txt>

[Mukul Goyal <[e-mail]>]

Hi Adrian,

The new (07) version of the draft, modified based on your comments, has been posted. Please see my response to your comments below.

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

[Mukul]

Done. See the new text towards the end of Section 1.
--------------------------------------------------------

[Adrian]
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

[Mukul]

The title has been changed to meet your concern.

----------------------------------------------

[Adrian]
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)

[Mukul]
We have already resolved this issue.

------------------------------------------------------
[Adrian]
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.

[Mukul]

The draft is not using the "Origin/Target" terms any more. See the new terminology in Section 1.1. In addition to defining new terms (Start Point, End Point and Intermediate Point), I have (re)defined two terms from p2p-rpl (Forward direction, Backward direction). These terms occur a few times in the draft.
------------------------------------------------
[Adrian]

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.

[Mukul]
This was a bug in the previous version. The previous version required RPLInstanceID to be 0b10000000 if H = 0. But this causes RPLInstanceID (of a global non-storing DAG along which the Measurement Request had been traveling so far) to be lost whenever the root of this DAG switches the message to a Source Route towards the End Point. When this Measurement Request reaches the End Point, the End Point would not know which global DAG can be used to send Measurement Reply back to the Start Point. The new version corrects this bug. Now, the RPLInstanceID does not change even if the Measurement Request switches over to a Source Route. Now, only the H flag can correctly tell whether a Measurement Request is traveling over a Hop-by-hop Route or a Source Route.
------------------------------------------

[Adrian]
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?

[Mukul]
I started taking care of this and ended up editing Sections on MO description (Section 3) and how to setup MO in various cases (Section 4) significantly. There is no semantic change in the contents (except for the correction of the bug involving RPLInstanceID value described previously). Hopefully the new sections are clearer than before. 

Section 5, detailing processing by an Intermediate Point, was edited to have same structure as Section 4. Additionally, I did one minor correction in Section 5:

"A router MUST discard a received MO with no further processing if the
   value in the Compr field inside the received message is "more than"
   what the router considers the length of the common prefix used in
   IPv6 addresses in the LLN to be.

Here "more than" was previously "not same as".

Section 6, detailing processing by the End Point, was also edited to make it clearer. 

-----------------------------------------

[Adrian]
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.

[Mukul]
The Metric Container Option is described in RFC6550 whereas the routing metric objects are described in RFC6551. I have now included references to these two RFCs. Not sure if I should repeat what these RFCs describe. 
---------------------------------------------

[Adrian]
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?

[Mukul]
Here the Start Point (Origin) discards the MO message because the next hop address has problems (it is either not on-link or not unicast or not in the same RPL domain). The Start Point may not know the next hop address ahead of time (e.g. when a hop-by-hop route is being measured). Or may be it knew the next hop address ahead of time (e.g. if a source route is being measured) but did not notice the problems this address has.
 
------------------------------------------------

[Adrian]

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.

[Mukul]
Done.
-------------------------------------------------------

[Adrian]
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?

[Mukul]
I think the Start Point (previously Origin) does need to keep track of Measurement Requests it has sent. Otherwise, it becomes prone to attacks where a rogue node feeds it wrong information about the routing metric values along existing routes the Start Point uses.
-----------------------------------------------------

[Adrian]
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.

[Mukul]

Done.
------------------------------------
[Adrian]

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?

[Mukul]

The Security Considerations now have some discussion about this. See the last paragraph in Section 8.

----------------------------------------

[Adrian]
11.2
You have used [I-D.ietf-roll-p2p-rpl] as a normative reference (at 
least for the terminology).

[Mukul]

I am no longer using Origin/Target terms. But now I have redefined two other terms from p2p-rpl: Forward direction and Backward direction. So, now this draft lists p2p-rpl as a normative reference.

------------------------------------------------

Thanks
Mukul