Hello again,
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.
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.
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.
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].
[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.
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