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

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 2 Nov 2014 22:00:07 -0000

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.

> 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?

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.

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

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.

Adrian

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 3 Nov 2014 09:58:02 +0000

Adrian Farrel
> AB
>> 2- The draft mentions in the introduction:- This modification is 
>> strictly optional,
> >

> Good point.

The abstract does actually say "to permit", which indicates this is not mandatory. But we can add the word optional to that.

Regarding the title, there's a usual tradeoff between brevity (and it's already not brief) and detail. I wouldn't add the suggests "based on link quality" as that really adds nothing useful (it's not an optimisation based on link quality, it's an optimisation to remove a side-effect of the use of link quality). To be a useful lengthening of the title, it would, I think, have to mention something about the two hop neighbourhood. I haven't consulted with my co-author, but my proposal would be to see if anyone on the IESG has a problem with the title as-is.

-- 
Christopher Dearlove
Senior Principal Engineer, Information Assurance Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Thomas Clausen <[email-masked]>
Date: Mon, 3 Nov 2014 11:26:00 +0100

> On Nov 3, 2014, at 10:58, Dearlove, Christopher (UK) <[email-masked]> wrote:
> 
> Adrian Farrel
>> AB

Hm, after having re-read the abstract, I am not actually sure that adding the word “optional” brings you anything: pretty much the whole last paragraph states that as optional, as Chris writes, “…to permit…” and then “this allows…” etc.

I believe that the abstract does what it is supposed to do, i.e., calls out the documents that it updates and briefly summarizes the update. I do not see any overwhelming reason to stuff more words into it.

> Regarding the title, there's a usual tradeoff between brevity (and it's already not brief) and detail. I wouldn't add the suggests "based on link quality" as that really adds nothing useful (it's n…

Agree 100% with Chris here.

Thomas

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 7 Nov 2014 07:09:56 -0800

The optimisation is only when there is link quality, the link quality is
optional use within our standard RFC7181, so this proposal updates the 7181
while it uses the optional link quality feature.

AB

On Mon, Nov 3, 2014 at 1:58 AM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> The abstract does actually say "to permit", which indicates this is not
> mandatory. But we can add the word optional to that.
>
> Regarding the title, there's a usual tradeoff between brevity (and it's
> already not brief) and detail. I wouldn't add the suggests "based on link
> quality" as that really adds nothing useful (it's not an optimisation based
> on link quality, it's an optimisation to remove a side-effect of the use of
> link quality). To be a useful lengthening of the title, it would, I think,
> have to mention something about the two hop neighbourhood. I haven't
> consulted with my co-author, but my proposal would be to see if anyone on
> the IESG has a problem with the title as-is.
>
> --
> Christopher Dearlove

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 7 Nov 2014 07:28:01 -0800

Hi Adrian,

> > introduction such important information.

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.

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

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

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 7 Nov 2014 18:07:39 -0000

Hello again,

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

I *do* hear your stated preference, but I disagree with it.
I *do* hear that changes and additions to published RFCs worries you, but that is a normal and very beneficial part of the IETF process. You should, perhaps, worry less. The point about the new update being optional might help to sooth you.

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

Well, like I said: try not to worry about stuff.

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

The document is very clear what optimisation is relevant here. It is the speed of recovery of state without the need to wait for a retransmitted message.

Why didn't the IETF find this feature before? Must be because we are human.

Yes, you are very welcome to publish the performance figures for your implementation.

>>> 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].
>>>
>>> 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.
>>
>> 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).

No. You are at least half wrong.
Yes, the use of link quality in 7181 allows for a link that is attacked to be noticed.
But failing to notice an attack on a link is *worse* than noticing it. That is, if you don't notice you will continue to send traffic to a link that is under attack with the result that the traffic is not delivered. While, if you use the link quality to prune the link then you will route traffic through another part of the network.

This document makes no difference to the possibility of attacking a link. The attack is not carried out using the protocol so no change to the protocol could make any difference to that.

What *can* happen is that the protocol can react to or even amplify the attack. As noted, reacting to the attack is a good thing because you want to route around attacks. However, what the authors of this draft have discovered was that 7181 included a minor amplification of the attack, and this work provides a way to close that hole.

The document makes the security behaviour slightly better. Definitely not worse.

[Hint: if you remain convinced that it is worse, please construct a scenario where this can be demonstrated and send it to us. Such a scenario would be a topology and a series of events showing behaviour with and without this extension.]

>> 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?

I find your question hard to interpret in the context of what I said.

You can read exactly what security considerations are documented in Section 7 of the I-D. 
The author has proposed an additional sentence to include in the document as stated above.
Yes, I think it is a good idea to add that.

A

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 11 Nov 2014 09:59:55 +0000

No, it updates RFC 6130. Yes RFC 7181 uses RFC 6130, but it’s not the only thing to do so. Marking it as updating everything that uses RFC 6130 is not what’s done.

[email-masked]<mailto:[email-masked]> | http://www.baesystems.com

From: Abdussalam Baryun [mailto:[email-masked]]
Sent: 07 November 2014 15:10
To: Dearlove, Christopher (UK)
Cc: [email-masked]; [email-masked]; Thomas Heide Clausen ([email-masked])
Subject: Re: Last Call: <draft-ietf-manet-nhdp-optimization-03.txt> (An Optimization for the MANET Neighborhood Discovery Protocol (NHDP)) to Proposed Standard

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
The optimisation is only when there is link quality, the link quality is optional use within our standard RFC7181, so this proposal updates the 7181 while it uses the optional link quality feature.

AB

On Mon, Nov 3, 2014 at 1:58 AM, Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:
Adrian Farrel

--
Christopher Dearlove
Senior Principal Engineer, Information Assurance Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194<tel:%2B44%201245%20242194> |  Fax: +44 1245 242124<tel:%2B44%201245%20242124>
[email-masked]<mailto:[email-masked]> | http://www.baesystems.com