ietf
[Top] [All Lists]

Re: [manet] New Version Notification for draft-ietf-manet-nhdp-sec-threats-02.txt

2013-03-24 06:42:28
Hi Jazi,

I disagree with draft-editors decision, comments below,

On 3/23/13, Jiazi Yi <ietf(_at_)jiaziyi(_dot_)com> wrote:
Dear AB,

On this particular issue (threats of packet sequence number), as far as I
can remember, the change was not based on (or influenced by) your input. In
the meantime, the input from Chris, Henning, Teco, etc., does have impact on
the document.

my input had impact as well, please read my input, and discussion with
you, you did not consider Teco input while I supported, the editors
input was against to mention the change to consider NHDP sequence
number consideration, now the WG draft considers,


It is true that you mentioned several times that message sequence number
threat should be kept in nhdp-sec-threat. However, you didn't provide valid
technical argument why it should be kept. Actually, there is no doubt that
the original section of sequence number in -00 revision was wrong.

No I did provide valid argument, I mentioned RFC6130 content that this
threat draft ignored and one editor named that content as it was not
normative, I continued arguing the important to mention thoes items
then Teco supported my concerns as well, then the editors found that
my argument is important because an old participant supported.


My understanding of "IETF input" must be based on technical argument.
Simply saying "I want *foo*, not *bar*" - without explaining why - doesn't
say much thing. Even *foo* was adopted in the end.
In the contrast, even some one is against *foo*, but he provided valid
arguments during the discussion that help improving the design, he should be
regarded as contributor.


I explained why, not sure why you think my input has no reason, but
please don't ignore that reviewers in IETF consider consistency of
drafts, so I was focusing that your draft is following RFC6130, and
that the draft mentioned sequence number in its draft-00 then removed
without the WG consensus (which was not reflecting some participants
concerns that I reminded the WG) do you think there is no reason now,

Last but not least, we acknowledged all the MANET participants - if you
regard yourself as one of the participants, then you are acknowledged.

You mean the editors of this draft (I will note them as not
acknowledging participants, for my future review). I am a MANET WG
participants, but if you mention the names that made efforts it is
more true because many are MANET participants and never send a
comment. Please note that IETF mentioned, Request For Comments= RFC. I
commented on the draft, and will only continue commenting on drafts
that are edited and monitored by acknowledging IETF participants.


btw, I remembered that you brought a discussion on RFC Acknowledgement
http://www.ietf.org/mail-archive/web/ietf/current/msg77065.html before. I
didn't follow that thread, but I think other participants have already
explained fairly well how it works.

Yes, which I am following, because my input was impact on changes on
this draft and I claim impact indirectly on others as to update
RFC6130 and other RFCs in MANET WG.

My personal suggestion is that, if you put move attention to the previous
sections of the document(s), rather than acknowledgment section, you would
be naturally listed there - that's how IETF works.


my suggestion is that editors SHOULD not ignore the WG participants
input and suggestions. The editors don't control the edit process of
WG drafts, it is controled by WG, the editors just follow, represent
versions of participants related input and edit.

Overall, if the way you do is the true IETF work way then I will know
now why many people leave the IETF, because I want IETF WG work as a
team in IETF. I would like to change that also if it was true. There
is no harm if you acknowledge efforts and inputs, don't know why
people like to do that, I always acknowledge my document reviewers,
hope that ALL IETF drafts and RFC acknowledges its commenters. If you
don't acknowledge why you request for comments, that is strange and
not reasonable.

Regards
Abdussalam Baryun

sincerely

Jiazi

On Mar 23, 2013, at 9:17 PM, Abdussalam Baryun 
<abdussalambaryun(_at_)gmail(_dot_)com>
wrote:

Hi Jiazi (draft editor)

Please note that I had effort to make below change in this draft, but
my name is not in acknowledgement as others were. Please add my name.
I don't think the changes was not influenced by my inputs and
discussions. I don't think that the changes was to happen if I ignored
the draft ( i.e. it was in WGLC and not much discussions). I don't
think I should be discouraged,

Best regards
Abdussalam Baryun,
+++++++++++++++++
If the IETF culture is to encourage participants then editors SHOULD
add efforts owners in acknowledgements, otherwise participants MAY be
discouraged (depends on individual culture).
+++++++++++++++++++++++++++++++++++++++++++++++++++++++

The below message in MANET WG list

On 3/20/13, Jiazi Yi <ietf(_at_)jiaziyi(_dot_)com> wrote:
Dear all,

The authors of nhdp-sec-threats have submitted a new revision based on
the
comments during WGLC.

The only technical change is that, a new sub-section is added on link
quality update:

==========
4.8.  Attack on Link Quality Update

 According to NHDP, "Link quality is a mechanism whereby a router MAY
 take considerations other than message exchange into account for
 determining when a link is and is not a candidate for being
 considered as HEARD or SYMMETRIC.  As such, it is a link admission
 mechanism.".

 Section 14.4 of NHDP [RFC6130] then lists several examples of which
 information can be used to update link quality.  One of the listed
 examples is to update link quality based on [RFC5444] packet
 exchanges between neighbor routers, e.g., an NHDP Router may update
 the link quality of a neighbor based on receipt or loss of packets if
 they include a sequential packet sequence number.

 NHDP does not specify how to acquire link quality updates
 normatively, however, attack vectors may be introduced if an
 implementation chooses to calculate link quality based on packet
 sequence numbers.  The consequences of such threats would depend on
 specific implementations.  For example, if the link quality update is
 based on sequential packet sequence number from neighbor routers, a
 Comprised NDHP Router can spoof packets appearing to be from another
 Legitimate NHDP Router that skips some packet sequence numbers.  The
 NHDP Router receiving the spoofed packets may degrade the link
 quality as it appears that several packets have been dropped.
 Eventually, the router remove the neighbor when the link quality
 drops below HYST_REJECT.
==========

Your comments are welcome.

@chairs:
I suppose that if this section gets approved, there is no need for
another
WGLC for the whole document?

best

Jiazi

Begin forwarded message:

From: internet-drafts(_at_)ietf(_dot_)org
Subject: New Version Notification for
draft-ietf-manet-nhdp-sec-threats-02.txt
Date: March 20, 2013 11:43:53 AM GMT+01:00
To: jiazi(_at_)jiaziyi(_dot_)com
Cc: t(_dot_)clausen(_at_)computer(_dot_)org, ulrich(_at_)herberg(_dot_)name


A new version of I-D, draft-ietf-manet-nhdp-sec-threats-02.txt
has been successfully submitted by Jiazi Yi and posted to the
IETF repository.

Filename:   draft-ietf-manet-nhdp-sec-threats
Revision:   02
Title:              Security Threats for NHDP
Creation date:      2013-03-20
Group:              manet
Number of pages: 17
URL:
http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-sec-threats-02.txt
Status:
http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats
Htmlized:
http://tools.ietf.org/html/draft-ietf-manet-nhdp-sec-threats-02
Diff:
http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-nhdp-sec-threats-02

Abstract:
 This document analyses common security threats of the Neighborhood
 Discovery Protocol (NHDP), and describes their potential impacts on
 MANET routing protocols using NHDP.




The IETF Secretariat


_______________________________________________
manet mailing list
manet(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/manet