Re: Last Call: <draft-ietf-manet-nhdp-optimization-03.txt> (An Optimization for the MANET Neighborhood Discovery Protocol (NHDP)) to Proposed Standard

[Abdussalam Baryun <[e-mail]>]

Hi Adrian,

On Sun, Nov 2, 2014 at 2:00 PM, Adrian Farrel <[e-mail]> wrote:

> Hello AB,
>
> Thanks for your review.
>
> > 1- The reviewer suggests that the title to be changed to specify the
> > type of optimization or its condition. As to chang it to:
> >
> > An Optimization for the MANET Neighborhood Discovery Protocol (NHDP)
> > based on link quality.
>
> Left for authors to respond.
>
> > 2- The draft mentions in the introduction:-
> > This modification is strictly optional,
> >
> > [AB] the reviewer suggests to include in the ID-Abstract that this
> > standard is optional. It is not enough to only mention in the
> > introduction such important information.
>
> Good point.
>

The issue is that this proposal updates an optional feature use within 7181
while getting better performance. I think it is important to clarify that
to future users.

>
> > 3- The draft proposes to update two IETF standards but does not show
> > any testings information. It is prefered to test the standard
> > performance by IETF before published.
>
> "It is preferred" presumably means you would prefer it?
>
Yes but usually meaning readers with prefer clarifying it because it is a
standard and updating a new standard RFC7181. If I am implementing the new
7181 and then find out that there are new updates I will be worried what is
happening within IETF publications and tests.


>
> The document shepherd write-up confirms that there are multiple
> implementations of this specification. I assume, therefore, that you are
> suggesting that the modulus of the optimization be tested. Isn't that
> obvious, however? You can quantify this very exactly simply by looking at
> the protocol exchanges.
>

When we notice that OLSR is already an optimised routing and then another
update is for optimisation, that make me worry. What is optimisation,
usually there is better performance, but why did not IETF find this feature
before issuing 7181, the test will help us find our the best optimisation
is it 7181 (OLSRv2) or this proposal standard.

>
> > 4- The draft states:-
> > As such, this protocol introduces no new security considerations to an
> > implementation of [RFC6130] or of any other protocol that uses it,
> > such as RFC7181].
> >
> > [AB] The standard is based on the use of link quality in such
> > optimization, however, the proposed standard can be attacked (requires
> > considerations) if the link quality is attacked frequently. The
> > proposed choice of the quality-threashold and its acceptance decisions
> > are very important to the proposed standard to function successfully,
> > therefore, the reviewer suggests to remove the above text from the
> > draft and to add some security considerations.
>
> Haven't you got this exactly the wrong way around?
> That is, without this optimization, an attack on the stability of the link
> (such as by radio interference) can cause disruption to 2-hop neighbors (or
> at least to their robustness).
> This document makes these neighbors more able to rapidly recover when the
> link is restored.
>

The link quality is optional in RFC7181, but when used there can be
attacks, however in this proposal there is higher possibility for attacking
links.

>
> This point was already made by me in my review and in the Sec Dir review
> by Charlie Kaufmann and lead one of the authors to propose including a
> simple statement that "It may sometimes provide a small improvement in
> availability against attacks such as short bursts of deliberate
> interference" although it was also discussed that this is not a very
> substantial security improvement given that it is a second (or even third)
> order effect compared to the basic attack on the link.
>

There was no security consideration with in the section. So do you still
think that this proposal needs no consideration for security?

AB

>
> Adrian
>
>