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

"JP Vasseur (jvasseur)" <jvasseur@cisco.com> Thu, 06 December 2012 15:27 UTC

Return-Path: <jvasseur@cisco.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54ABB21F85C7 for <roll@ietfa.amsl.com>; Thu, 6 Dec 2012 07:27:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtvisPJMxAWR for <roll@ietfa.amsl.com>; Thu, 6 Dec 2012 07:27:48 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 49E9C21F859D for <roll@ietf.org>; Thu, 6 Dec 2012 07:27:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7819; q=dns/txt; s=iport; t=1354807668; x=1356017268; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=abT7HGaAPh8VPyDZbkwfexe7pj7cDgYfC7ENmkCl3Cs=; b=cTVuuH2bTPrlx+xoUS7+Cx3vKcTMS3T0979u4KO//67MpYp+1iSiCSfu opyB48c6I9kFxnc1Gej8z/IVfL+1sJy5qoiL7xp7VrR2lwzA4aLcuVwHW kow5ppuZ/oqo8C8mQaM680PBgkEwopgmMPDFGDjfG03BQLol9RYUlytb8 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAIW4wFCtJV2b/2dsb2JhbABEvikWc4IeAQEBAwEBAQE3MgILBQsCAQgiFBAnCyUCBA4FCIgCBgzCKwSMOQUXg0ZhA6ZKgnOCIg
X-IronPort-AV: E=McAfee;i="5400,1158,6917"; a="147101978"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 06 Dec 2012 15:27:47 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qB6FRlV3000359 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Dec 2012 15:27:47 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.204]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.001; Thu, 6 Dec 2012 09:27:47 -0600
From: "JP Vasseur (jvasseur)" <jvasseur@cisco.com>
To: "<adrian@olddog.co.uk>" <adrian@olddog.co.uk>
Thread-Topic: [Roll] AD review of draft-ietf-roll-p2p-measurement-06
Thread-Index: AQHN08Y++FRW99v7tkWHC7Kkbt2jkw==
Date: Thu, 6 Dec 2012 15:27:46 +0000
Message-ID: <03B78081B371D44390ED6E7BADBB4A77230C78E5@xmb-rcd-x02.cisco.com>
References: <00e901cdd2f3$f8ffc510$eaff4f30$@olddog.co.uk>
In-Reply-To: <00e901cdd2f3$f8ffc510$eaff4f30$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.144.49]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <E3292B3AEE579447BB57EC8C2C791465@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<draft-ietf-roll-p2p-measurement.all@tools.ietf.org>" <draft-ietf-roll-p2p-measurement.all@tools.ietf.org>, "<roll@ietf.org>" <roll@ietf.org>
Subject: Re: [Roll] AD review of draft-ietf-roll-p2p-measurement-06
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Dec 2012 15:27:49 -0000

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