Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 23 Feb 2013 17:16:02 +0100

On 10/23/12, Jiazi YI <[email-masked]> wrote:
> Dear all,
>
> The new revision of the WG document draft-ietf-manet-nhdp-sec-threats has
> addressed most of the comments from the WG.
>
> The main changes include:
>
> 	o Take the misconfiguration of NHDP routers into consideration.
> 	o Added a sub-section of Denial of service attack.

ok, agree

> 	o Removed sub-section Sequence Number Attack, which should be more related
> to OLSRv2.

Why related only to the router do you mean that NHDP has no sequence
number, or its sequence numbers have no threats on the protocol?
please advise,

> 	o some text on the assumption & scope of the document.
>
> I would like to thank again for the comments from the WG. Further comments
> are always appreciated.

Thanks to the update, but I recommend you mention thanks into the
document, which has no acknowledgements :)

AB

---

From: Jiazi Yi <[email-masked]>
Date: Sat, 23 Feb 2013 20:07:31 +0100

Hi, 

> number, or its sequence numbers have no threats on the protocol?

In fact, it's because sequence number is normally not used in HELLO message. 

> document, which has no acknowledgements :)

Thanks for the reminder. I think for a document at its very early revision, it's normal that the acknowledgements section is not included. 
It will be added in the future, and all the major contributors will be acknowledged, according to RFC 3978. 

best

Jiazi

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 24 Feb 2013 01:35:00 +0100

Hi Jiazi

So I understand that you state if there is an attack on the sequence
number in the packet/message, there is no threat on the NHDP,

AB

On 2/23/13, Jiazi Yi <[email-masked]> wrote:
> Thanks for the reminder. I think for a document at its very early revision,
> it's normal that the acknowledgements section is not included.

---

From: Ulrich Herberg <[email-masked]>
Date: Sun, 24 Feb 2013 00:31:06 -0800

AB,

packet sequence numbers are irrelevant for NHDP because they are used on a
lower layer (RFC5444 multiplexer). Message sequence numbers don't matter
for NHDP because HELLO sequence numbers are not recorded (like TC messages
in the "Received Set" in OLSRv2). So there is no such DoS attack possible
in NHDP.

Ulrich

On Sat, Feb 23, 2013 at 4:35 PM, Abdussalam Baryun <
[email-masked]> wrote:

> > On Feb 23, 2013, at 5:16 PM, Abdussalam Baryun <
> [email-masked]>
> > wrote:
> >
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 24 Feb 2013 11:12:02 +0100

Hi Ulrich,

Usually in reactive protocols sequence number is very important in
nieghbor discovery, and maybe also in proactive. In
RFC6130-section14.4 it states an affect as below (may be a threat);

[RFC6130]
14.4 Updating Link Quality
A router MAY update link quality based on any information available
to it. Particular cases that MAY be used include:

[I include only one from list related]

o Receipt or loss of control packets. If control packets include a
sequential packet sequence number, as defined in [RFC5444], then
link quality can be updated when a control packet is received,
whether or not it contains a HELLO message. The link quality may
then, for example, be based on whether the last N out of M control
packets on the link were received, or may use a "leaky integrator"
tracking packet reception and loss.

[AB]
So I feel that the input of John regarding sequencing MAY be related
to NHDP, it changes link quality,

AB

---

From: Ulrich Herberg <[email-masked]>
Date: Sun, 24 Feb 2013 02:31:52 -0800

AB,

On Sun, Feb 24, 2013 at 2:12 AM, Abdussalam Baryun <
[email-masked]> wrote:

> nieghbor discovery, and maybe also in proactive.

It is not used by NHDP, though. It is not mandated to use the message
sequence number, and it is not used a single time in the normative part of
the document.

> In

This is non normative part of NHDP, thus I don't think it can be a threat
to NHDP itself. If someone implements (or specifies in a document) such a
mechanism (that is purely given as example in RFC6130), then maybe that can
be considered a threat to that implementation or document.

For such a mechanism (again, outside of the normative part of RFC6130) that
uses lost packets for link quality calculation, an attacker could spoof
another router's address and increase link quality by sending many packets.
I don't think that's a very efficient attack though.

Ulrich

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 24 Feb 2013 13:20:46 +0000

Hi Ulrich,

comments below,
On Sun, Feb 24, 2013 at 10:31 AM, Ulrich Herberg <[email-masked]>wrote:

> I don't know what you mean by normative part if nothing in the document
mentions norm-partitions of the documents, there are sections, and no text
mentions that this is normative and this is not normative (my speculate or
understanding). I believe that section 14 is important to NHDP and we
should not ignore.
Regarding implementation, John input [1] already mentioned in his input the
implementation issue is not considered in the threat doc, why the authors
don't include it if you now stating that a threat may occur with such
implementation,

> For such a mechanism (again, outside of the normative part of RFC6130)
> that uses lost packets for link quality calculation, an attacker could
> spoof another router's address and increase link quality by sending many
> packets. I don't think that's a very efficient attack though.
>
>
but you do think it is an attack. Please note that IMHO; the NHDP can be
implemented with thoes mechanism the RFC6130 does not exclude them from its
function.

[1] http://www.ietf.org/mail-archive/web/manet/current/msg13286.html

AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 24 Feb 2013 13:35:06 +0000

> sequence number, and it is not used a single time in the normative part of

I think it MAY be used sequence number (SQN) by NHDP [RFC6130], so the NHDP
can depend on it. I don't care her about mandates items, because this
protocol is a general use by MANET so it cannot mandate every thing, it
should be flexible.  I care now about  the RFC6130 does not exclude the
*USE* of SQNs in Packet/Message, as we can see from section 14 and others.

AB
+++++++++++++++++++
If I am wrong please advise. Please note that the above is the poster
understanding (we never claim that we are always right, nor does any IETF
participants) from reading RFC6130 and the subject WGLC draft.

---

From: Henning Rogge <[email-masked]>
Date: Sun, 24 Feb 2013 23:01:16 +0100

> *USE* of SQNs in Packet/Message, as we can see from section 14 and others.

RFC5444 is designed as a very flexible and easily extendable format.

If we include everything into the NHDP-threat document that MAY be
used in a NHDP implementation but is out of scope of the normative
sections, the threat document might become VERY long.

Henning Rogge
-- 
We began as wanderers, and we are wanderers still. We have lingured
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan

---

From: Ulrich Herberg <[email-masked]>
Date: Sun, 24 Feb 2013 14:20:22 -0800

AB,

this part about link quality calculation is not normative, i.e., it does
not mandate you "MUST do it exactly this way", but it is merely an example
what could be done to calculate link quality (read: "The link quality may
then, *for example*, be based on whether the last N out of M control
packets on the link were received, or may use a "leaky integrator" tracking
packet reception and loss.")

Like Henning said, the draft would be of infinite length if I tried to
predict what each implementer may add to the normative part of the protocol.

Regards
Ulrich

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 25 Feb 2013 07:19:20 +0100

Hi Ulrich and Henning

My intentions was not about RFC5444 nor about making things long, it
is about the RFC6130 job to backup routing and the threats to that
job.

We understand that RFC6130 is used most by the MANET routing protocols
(OLSRv2, AODVv2, etc.), my point is why we don't mention in the
document Sequence Number threat (mentioned in NHDP Hello Msg, but MAY
be used by NHDP), while I think is important use in AODVv2 neighbor
discovery.

The document will not be long but reasonable if it considers all
important threats affecting the NHDP job as a discovery for the
routing protocol concerns (proactive and reactive).

AB

---

From: Ulrich Herberg <[email-masked]>
Date: Sun, 24 Feb 2013 23:12:20 -0800

AB,

again, sequence numbers are not used by NHDP, therefore not a threat to
NHDP. If another protocols uses that information, it may be a threat to
that protocol, and may be documented in a security threats analysis for
that protocol.

It seems you are the only one advocating for changing the draft on this
aspect. I will wait if someone else also asks for changes on this matter
before changing it.

Regards
Ulrich

On Sun, Feb 24, 2013 at 10:19 PM, Abdussalam Baryun <
[email-masked]> wrote:

> tracking

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 25 Feb 2013 08:17:52 +0100

Hi Ulrich,

It seems that some editors like to take over wg drafts, and making
things difficult to participation. There was John input that I
supported but you ignored, please check my input related.

I don't care of the way the draft management is doing, but I will note
this down,

AB

On 2/25/13, Ulrich Herberg <[email-masked]> wrote:
>> >> > I think it MAY be used sequence number (SQN) by NHDP [RFC6130], so
>> >> > the
>> >> NHDP

---

From: Henning Rogge <[email-masked]>
Date: Mon, 25 Feb 2013 08:42:20 +0100

> I don't care of the way the draft management is doing, but I will note

Maybe instead of shouting and "noting things down", you should read my 
last advise mail again...

after this you should read the NHDP RFC again, especially the section 
you are talking about (Section 14.4 I think).

after doing this too, you will notice RFC6130 talks about the 
possibility to use **packet** sequence numbers.

Packet sequence numbers are not used to detect incoming duplicates, you 
are mixing things up with message sequence numbers.

In my opinion message sequence numbers are USELESS for hysteresis 
calculation, because the NHDP Hello messages will not have a continuous 
sequence (no pun intended) of message sequence numbers (unless you ONLY 
run NHDP and do not combine it with another protocol).

Any attack mitigation for NHDP sequence numbers will highly depend on 
the hysteresis implementation, which makes the value of your request 
dubious at best.

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 25 Feb 2013 08:49:45 +0100

> last advise mail again...

I never shout, how do you hear the sound on the list, my voice is
nice, just comments responding, to understand how things should be,
> are mixing things up with message sequence numbers.

I mean both sequence are important otherwise why do we have them in our work,

> run NHDP and do not combine it with another protocol).

If useless then you should remove them why making things difficult,

> the hysteresis implementation, which makes the value of your request

Ok why does the document not talk about the hysteresis implementation then :)

Please note that I respect all works in the WG so my voice for all
inputs is low not high, please don't assume other :-)

Regards
AB

---

From: Henning Rogge <[email-masked]>
Date: Mon, 25 Feb 2013 09:07:47 +0100

On 02/25/2013 08:49 AM, Abdussalam Baryun wrote:
>> after this you should read the NHDP RFC again, especially the
>> section you are talking about (Section 14.4 I think).
>>
>> Packet sequence numbers are not used to detect incoming duplicates,
>> you are mixing things up with message sequence numbers.
>

You certainly do not understand the "duplicate detection poison" attack.

>> calculation, because the NHDP Hello messages will not have a
>> continuous sequence (no pun intended) of message sequence numbers
>> (unless you ONLY run NHDP and do not combine it with another
>> protocol).
>

Okay, I will explain it once again.

RFC6130 mentions the possibility (among other things) to use packet
sequence numbers for hysteresis calculations, without going into details
what to do with them.

Because of this its a not a good idea to describe the "drop duplicate 
because of spoofed high sequence numbers attack", because the attack 
does not apply to this case at all. The duplicate detection described 
for RFC5444 does only work for message sequence numbers.

An attack on packet sequence level would not be a NHDP attack but a 
RFC5444 (de-)multiplixer attack, which would belong into a 
packetbb-sec-threats document.

>> Any attack mitigation for NHDP sequence numbers will highly depend
>> on the hysteresis implementation, which makes the value of your
>> request dubious at best.
>

There was a hysteresis implementation example in OLSRv1 (RFC3626)... it
didn't worked well. I think that is the reason NHDP only gives some 
hints what you could look at when implementing a hysteresis function.

NHDP also mentions the possibility to use signal-to-noise ratio or 
packet-acknowledgements.

Do you want to add "threats descriptions and mitigations" to this 
attacks too?

If I ever write down my "packet sequence number based ETX", it should 
contain a "security" section because it would be the first Manet-WG 
document using the packet sequence numbers I think.

Henning Rogge

---

From: Daniel He <[email-masked]>
Date: Mon, 25 Feb 2013 09:27:46 +0000

Hi Mr Abdussalam Baryun,

Since early 2012, you started to give "COMMENTS" on many things in IETF
mailing list, which seems good. However, most of your comments are
unnecessary!

if I have to say about your "noting things down", I have to cite Murray S.
Kucherawy's comment on you

>>If I may quote Blazing Saddles:

>>Reverend!

http://www.ietf.org/mail-archive/web/ietf/current/msg74224.html

("+2", for those unfamiliar.)

Cheers,

Daniel

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 25 Feb 2013 12:36:02 +0000

Hi Henning,

I agree that we should first had RFC5444-sec-threats, but don't mind just
doing NHDP because this discovery protocol is used by our routing
protocols. We should focus on the NHDP's processes and information if
attacked in this doc. Comments below,

> sequence numbers for hysteresis calculations, without going into details

I agree not to go into details as well, I like that, but want details what
are the information in NHDP,

> because of spoofed high sequence numbers attack", because the attack does
> not apply to this case at all. The duplicate detection described for
> RFC5444 does only work for message sequence numbers.
>

We don't want to describe the duplicate detection, I wanted to describe the
threats is a change in the NHDP information which may be wrong info. Any
information in NHDP may be used by the router. Some think it is threat to
router only, I think no also NHDP is attacked in its useless info that may
be useful for more important functions in the node.

> packetbb-sec-threats document.
All messages are in RFC5444 packet , if the packet attacked then message is
attacked,
if the message is attacked may not mean that packet is attacked. Does that
make sense?

I agree that we will need packetbb-sec-threat to be added in all threat
documents that use packetbb, but if we don't have now a participant
volunteering on the packetbb-threat then we should add related issues in
our other threat docs. We separated routing and NHDP but I don't agree to
separate messaging from protocols because such protocols not only use
packetbb but eat packetbb,

> didn't worked well. I think that is the reason NHDP only gives some hints
> what you could look at when implementing a hysteresis function.
>

maybe that SNR can be a threat but did not see a wg routing using that
info. If the NHDP is updating SNR and another routing protocol is using
that info from NHDP, I think if an attack on SNR then it will affect the
NHDP info and then the routing process.

>
> Do you want to add "threats descriptions and mitigations" to this attacks
> too?
>

Threats documented are not only to the NHDP processes, but also its
information. If the NHDP does not use one information item, then it does
not mean that if the item information was attacked the NHDP is not
attacked. Any information in NHDP is the NHDP responsibility don't you
think,

> document using the packet sequence numbers I think.

I did not want to make it complicated just simple issues that affect the
neighbor discovery related to our standard routings OLSR and AODV.

AB

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 25 Feb 2013 04:45:42 -0800

AB,

I disclaim your accusations. An editor is supposed to write text that
represents WG consensus. I have heard your argument, provided arguments
against it (confirmed by Henning and Jiazi), nobody has backed up your
argument. Therefore, your arguments hardly represent WG consensus.

Best regards
Ulrich

On Sun, Feb 24, 2013 at 11:17 PM, Abdussalam Baryun <
[email-masked]> wrote:

> >> >> > protocol is a general use by MANET so it cannot mandate every
> thing,
> >> it

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 25 Feb 2013 13:03:25 +0000

> argument. Therefore, your arguments hardly represent WG consensus.

The editor/authors should not decide on behalf of the WG (maybe chair can).
There is no consensus on any update you done so far either, people are
bussy, but for me the reputation of the draft is not good, however, good
luck,

AB

>> >> >> > should be flexible.  I care now about  the RFC6130 does not
>> exclude
>> >> the

---

From: Henning Rogge <[email-masked]>
Date: Mon, 25 Feb 2013 14:16:51 +0100

Am 25.02.2013 13:36, schrieb Abdussalam Baryun:
>> There was a hysteresis implementation example in OLSRv1
>> (RFC3626)... it didn't worked well. I think that is the reason NHDP
>> only gives some hints what you could look at when implementing a
>> hysteresis function.
>>
> maybe that SNR can be a threat but did not see a wg routing using
> that info.

Then you are just ignorant about things like SNR based hysteresis and 
link metrics.

I suggest reading RFC6130 and 
draft-ietf-manet-olsrv2-metrics-rationale-02 as a start, both mention 
SNR in relation to MANET routing.

Search engines like Google will give you lots of results about the topic 
too.

 > If the NHDP is updating SNR and another routing protocol
> is using that info from NHDP, I think if an attack on SNR then it
> will affect the NHDP info and then the routing process.

NHDP "updating" SNR?

> information. If the NHDP does not use one information item, then it
> does not mean that if the item information was attacked the NHDP is
> not attacked. Any information in NHDP is the NHDP responsibility
> don't you think,

Threats documents are about attacks against the specified protocol 
mechanisms. NHDP does not specify any hysteresis mechanism.

NHDP suggest a couple of ideas how to to hysteresis. Nobody (including 
you) seems to suggest to put attacks against all of them into the threat 
document.

Henning Rogge

GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 25 Feb 2013 15:51:35 +0000

There is an update by RFC5444 author regarding sequence number of the
RFC5444 packet. Now it become related to interface sequencing,

AB

On Mon, Feb 25, 2013 at 1:16 PM, Henning Rogge <
[email-masked]> wrote:

> Then you are just ignorant about things like SNR based hysteresis and link
> metrics.
>
> I suggest reading RFC6130 and draft-ietf-manet-olsrv2-**metrics-rationale-02
> as a start, both mention SNR in relation to MANET routing.
>
> mailto:henning.rogge@fkie.**fraunhofer.de<[email-masked]>
> http://www.fkie.fraunhofer.de

---

From: Henning Rogge <[email-masked]>
Date: Mon, 25 Feb 2013 16:57:34 +0100

It always was... the "error" has been known for a long time.

My implementation of the RFC5444 (de)multiplexer has been using this
"packet sequence number per interface" for a long time.

Henning Rogge

On Mon, Feb 25, 2013 at 4:51 PM, Abdussalam Baryun
<[email-masked]> wrote:
> On Mon, Feb 25, 2013 at 1:16 PM, Henning Rogge
> <[email-masked]> wrote:
>>
>> I suggest reading RFC6130 and draft-ietf-manet-olsrv2-metrics-rationale-02

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 25 Feb 2013 16:21:08 +0000

Both errata I submitted today were originally pointed out by other people, I forget who (maybe even Henning for this one). Originally I left it to the discovers to submit and claim the (fairly small) credit, but they didn't, and it drifted, and then I finally got around to them today.

This in fact just matches behaviour in RFC 3626.

As for how to protect it, should you care, the answer would be in a security mechanism for RFC 5444. It's fairly obvious reading RFC 6622 (or bis) what that would be (ICV and TIMESTAMP packet TLVs).

-- 
Christopher Dearlove
Senior Principal Engineer, Communications 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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 25 February 2013 15:58
To: Abdussalam Baryun
Cc: [email-masked]
Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Henning Rogge

********************************************************************
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: Henning Rogge <[email-masked]>
Date: Mon, 25 Feb 2013 17:28:49 +0100

> Both errata I submitted today were originally pointed out by other people, I forget who (maybe even Henning for this one). Originally I left it to the discovers to submit and claim the (fairly smal…

Might be... but the important thing is that we got it fixed.

> This in fact just matches behaviour in RFC 3626.

Yes.

> As for how to protect it, should you care, the answer would be in a security mechanism for RFC 5444. It's fairly obvious reading RFC 6622 (or bis) what that would be (ICV and TIMESTAMP packet TLVs).

Yes. It is packet level data, it should be protected by packet-level security.

Henning Rogge

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 25 Feb 2013 16:32:07 +0000

Hi Chris,

What is more important for me is your opinion about adding NHDP sequence
number in the threat doc or not, please advise,

AB

On Mon, Feb 25, 2013 at 4:21 PM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> Both errata I submitted today were originally pointed out by other people,
> I forget who (maybe even Henning for this one). Originally I left it to the
> discovers to submit and claim the (fairly small) credit, but they didn't,
> and it drifted, and then I finally got around to them today.
>
> As for how to protect it, should you care, the answer would be in a
> security mechanism for RFC 5444. It's fairly obvious reading RFC 6622 (or
> bis) what that would be (ICV and TIMESTAMP packet TLVs).
>
> --
> Christopher Dearlove
> link
> draft-ietf-manet-olsrv2-metrics-rationale-02

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 25 Feb 2013 16:41:11 +0000

> "packet sequence number per interface" for a long time.

That is good so the RFC5444 was not correct for a long time then, and some
people in the Internet Community did not know that. I knew also that
RFC5444 needed update and still beleive that,

This is wrong behavior of a WG to keep things related to RFC5444 for long
time, I may misunderstanded your point,

AB

---

From: Henning Rogge <[email-masked]>
Date: Mon, 25 Feb 2013 17:52:07 +0100

On Mon, Feb 25, 2013 at 5:41 PM, Abdussalam Baryun
<[email-masked]> wrote:
> people in the Internet Community did not know that. I knew also that RFC5444
> needed update and still beleive that,

We talked about this on this list quite some time ago.

http://www.ietf.org/mail-archive/web/manet/current/msg11340.html

Most likely the "trigger errata" got lost in the long discussion.

Henning Rogge

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 25 Feb 2013 17:03:22 +0000

Hi Henning,

I agree that these things may happen in WG but we should try to not let it
happen again. Many people may use the RFC5444 and not know that discussion.
I think the WG Chair assigned within that discussion time is responsible
for such situation,

AB

---

From: Henning Rogge <[email-masked]>
Date: Mon, 25 Feb 2013 18:17:20 +0100

On Mon, Feb 25, 2013 at 6:03 PM, Abdussalam Baryun
<[email-masked]> wrote:
> I think the WG Chair assigned within that discussion time is responsible for
> such situation,

I think you are trying to make an issue out of nothing.

First, the errata is a SHOULD, which means that any proprietary
protocol can do whatever it likes.

Second, neither DYMO nor NHDP nor OLSRv2 nor DLEP (which was using
RFC5444 for some time) uses packet sequence numbers.

In fact the only draft I remember which used RFC5444 packet sequence
numbers was the "funkfeuer ETX" draft, which explicitly specified that
the packet sequence numbers had to be interface specific to use this
ETX variant.

Henning Rogge

---

From: Daniel He <[email-masked]>
Date: Mon, 25 Feb 2013 18:55:27 +0000

Hi Mr Baryun,

So what? if you didn't know that issues, that is you not on the whole
internet
community. Don't speak for US!

Even we didn' t know  those issues, now it is corrected that it
is pretty fine to US. there is no wrong behavior as you accused of commiting
on the time. I would like to remind you: DON'T SPAM in this mailing list.
Every day I received your email for nothing!

Cheers,

Dan

---

From: Teco Boot <[email-masked]>
Date: Tue, 26 Feb 2013 07:41:54 +0100

Op 25 feb. 2013, om 08:12 heeft Ulrich Herberg <[email-masked]> het volgende geschreven:

> AB,
> 
> again, sequence numbers are not used by NHDP, therefore not a threat to NHDP. If another protocols uses that information, it may be a threat to that protocol, and may be documented in a security threats analysis for that protocol. 
> 
> It seems you are the only one advocating for changing the draft on this aspect. I will wait if someone else also asks for changes on this matter before changing it.
Don't judge too early. I'm with AB that threats on optional parts of a standard should be enlightened.

Teco

---

From: Teco Boot <[email-masked]>
Date: Tue, 26 Feb 2013 07:51:03 +0100

> Might be... but the important thing is that we got it fixed.

Just for the record: I commented on per link packet seq numbers on the mike, as comment on mib link quality reporting.

Teco

---

From: Henning Rogge <[email-masked]>
Date: Tue, 26 Feb 2013 08:35:23 +0100

On 02/26/2013 07:41 AM, Teco Boot wrote:
>> again, sequence numbers are not used by NHDP, therefore not a
>> threat to NHDP. If another protocols uses that information, it may
>> be a threat to that protocol, and may be documented in a security
>> threats analysis for that protocol.
>>
>> It seems you are the only one advocating for changing the draft on
>> this aspect. I will wait if someone else also asks for changes on
>> this matter before changing it.

In my opinion the interesting question is where to put generic RFC5444
attacks.

Attacks on packet sequence numbers is one of them, attacks on message
sequence numbers is another one.

But we also have attacks on hopcount and hoplimit fields of messages,
both which can NOT be solved by signing messages (except for messages
like NHDP Hellos that are not forwarded at all).

Hopcount attacks look very interesting when a protocol use Multi-Value
Time TLVs as described in RFC 5497.

The classic attack would be to fake the originator field of an RFC5444
message to impersonate a different node.

I have a problem with putting sequence number based attacks in a NHDP 
attached document because NHDP doesn't specify anything in relation to 
sequence numbers, not even as an optional part.

What it does is mentioning a few possibilities what could be useful for 
hysteresis calculation without specifying a protocol or algorithm.

Henning Rogge

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 25 Feb 2013 23:37:25 -0800

> standard should be enlightened.

But it is *not* an optional part of NHDP (nor is it mandatory). It is
simply named as example what implementers may do, but it is outside of the
normative part. I cannot guess what people can implement in addition to the
normative part, since there may be infinite possibilities. Please tell me
how I should write security threats for these potentially infinite,
non-normative, things that people can implement.

I can only repeat it again: NHDP does *not* use sequence numbers, neither
packet nor message sequence numbers.

Ulrich

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 26 Feb 2013 11:21:59 +0000

> non-normative, things that people can implement.

There were comments for the draft to be updated, so please just do what we
think needs to be added we don't want infinite, no one said that as all
unmentioned options, I think it is editor assumption,

> packet nor message sequence numbers.

That is your opinion which I disagree, and disagree that the editors
removed the section of sequence number without consensus of WG.

AB

---

From: Henning Rogge <[email-masked]>
Date: Tue, 26 Feb 2013 12:38:35 +0100

On 02/26/2013 12:21 PM, Abdussalam Baryun wrote:
>     I can only repeat it again: NHDP does *not* use sequence numbers,
>     neither packet nor message sequence numbers.
>

You know that the old section was plain WRONG, yes?

(I suggest reading section 4.5 of nhdp-threats-00)

Because the attack it described cannot happen to NHDP.

If you want to get the "sequence number attack" paragraph back, maybe 
you should write a new one... one that applies to NHDP.

Henning Rogge

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 26 Feb 2013 20:45:20 +0900

Exactly. We confused it with OLSRv2. The old section is 100% wrong.

Ulrich

Sent from my iPhone

On Feb 26, 2013, at 8:38 PM, Henning Rogge
<[email-masked]> wrote:

> If you want to get the "sequence number attack" paragraph back, maybe you should write a new one... one that applies to NHDP.
>
> Henning Rogge
>
> --

---

From: Henning Rogge <[email-masked]>
Date: Tue, 26 Feb 2013 13:08:13 +0100

Hi,

so do we have an agreement that the old "sequence number attack" section 
of nhdp-threats-00 is wrong and must be removed because it describes 
something that does not apply to NHDP?

If we (as a working group) decide we want a "sequence number attack" 
section in nhdp-threats, someone needs to write up a corresponding 
section and we have to see if it gets consensus in the group.

Henning Rogge

On 02/26/2013 12:41 PM, Abdussalam Baryun wrote:
> your right thanks :)
> AB
>
> On Tue, Feb 26, 2013 at 11:38 AM, Henning Rogge
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     If you want to get the "sequence number attack" paragraph back,
>     maybe you should write a new one... one that applies to NHDP.
>
>
>     Henning Rogge
>
>     --
>     Telefon +49 228 9435-961 <tel:%2B49%20228%209435-961>,   Fax +49 228
>     9435 685 <tel:%2B49%20228%209435%20685>
>     mailto:[email-masked]
>     <mailto:[email-masked]> http://www.fkie.fraunhofer.de
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Daniel He <[email-masked]>
Date: Tue, 26 Feb 2013 12:13:14 +0000

I don't see why we need sequence number. if you disagree, could you please
explain why? I couldn't image which particular threat will be?

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 26 Feb 2013 12:18:12 +0000

Yes the content of the section may be removed if the editors made mistake
or confused with other protocol, but the should not remove the section
title I think, it will change the structure of the draft,

AB

On Tue, Feb 26, 2013 at 12:08 PM, Henning Rogge <
[email-masked]> wrote:

> section in nhdp-threats, someone needs to write up a corresponding section
> and we have to see if it gets consensus in the group.
>
> Henning Rogge
>
>
>> <henning.rogge@fkie.**fraunhofer.de <[email-masked]>
>> <mailto:henning.rogge@fkie.**fraunhofer.de<[email-masked]>>>
>> wrote:
>>
>>     mailto:[email-masked]**aunhofer.de <http://fraunhofer.de>
>>
>>     <mailto:henning.rogge@fkie.**fraunhofer.de<[email-masked]>>
>>     ______________________________**_________________
>>     manet mailing list
>>     https://www.ietf.org/mailman/**listinfo/manet<https://www.ietf.org/mailman/listinfo/manet>
>>
>>
>>
>
> --

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 26 Feb 2013 13:18:58 +0100

On Feb 26, 2013, at 1:08 PM, Henning Rogge <[email-masked]> wrote:

> Hi,
> 
> so do we have an agreement that the old "sequence number attack" section of nhdp-threats-00 is wrong and must be removed because it describes something that does not apply to NHDP?
> 
> If we (as a working group) decide we want a "sequence number attack" section in nhdp-threats, someone needs to write up a corresponding section and we have to see if it gets consensus in the group.
> 

I believe that if there is a sequence number attack on NHDP, then it should be written down.
I also believe that I've not seen anything indicating that such an attack exists.

That's what you're saying, isn't it?

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 26 Feb 2013 12:20:45 +0000

There was a input of John which I refered to in the ticket,

AB

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 26 Feb 2013 15:35:50 +0000

An attacker can spoof packets appearing to be from a router that skips some packet sequence numbers since the last packet sent by the router (and received and analysed by the attacker).

This may have an effect on an implementation of NHDP that uses those packet sequence numbers to recognise missing packets, and thus to change link quality. (There's no required use of the packet sequence number, and I'm fairly sure no other even suggested possible use.)

This is an implementation of link quality that frankly isn't very good. That's why in the translation from RFC 3626, where this is a formal option, to NHDP, it got downgraded to a comment that it's something you can use in specifying link quality should you want to.

Now against an unprotected NHDP, even one using that mechanism, there are a lot of much more effective attacks that require less effort to mount, using HELLO messages.

So about the only case where this attack is worth mounting is when you know that the NHDP implementation has gone to the trouble of protecting messages, but is using a 5444 implementation that doesn't protect packets, and you know that it uses this packet sequence number in the way described, despite having gone to the effort of protecting messages.

Or in other words it's a smart but stupid NHDP implementer. (He made two mistakes, using a poor link quality mechanism, and using something unprotected despite the work in protecting most things.)

So it's rather specialised. And even in those circumstances I might (as the attacker) spend my effort on something else.

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 26 Feb 2013 16:40:17 +0100

....and that description of Chris' might be something worth folding into the I-D?

Thomas

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 26 Feb 2013 15:52:45 +0000

Hi Thomas,

happy to know you agree to add that into the I-D, I will just hope/pray the
editors agree, :-)

AB

On Tue, Feb 26, 2013 at 3:40 PM, Thomas Clausen <[email-masked]>wrote:

> > An attacker can spoof packets appearing to be from a router that skips
> some packet sequence numbers since the last packet sent by the router (and
> received and analysed by the attacker).
> >
> > This may have an effect on an implementation of NHDP that uses those
> packet sequence numbers to recognise missing packets, and thus to change
> link quality. (There's no required use of the packet sequence number, and
> I'm fairly sure no other even suggested possible use.)
> >
> > This is an implementation of link quality that frankly isn't very good.
> That's why in the translation from RFC 3626, where this is a formal option,
> to NHDP, it got downgraded to a comment that it's something you can use in
> specifying link quality should you want to.
> >
> > Now against an unprotected NHDP, even one using that mechanism, there
> are a lot of much more effective attacks that require less effort to mount,
> using HELLO messages.
> >
> > So about the only case where this attack is worth mounting is when you
> know that the NHDP implementation has gone to the trouble of protecting
> messages, but is using a 5444 implementation that doesn't protect packets,
> and you know that it uses this packet sequence number in the way described,
> despite having gone to the effort of protecting messages.
> >
> > Or in other words it's a smart but stupid NHDP implementer. (He made two
> mistakes, using a poor link quality mechanism, and using something
> unprotected despite the work in protecting most things.)
> >
> > So it's rather specialised. And even in those circumstances I might (as
> the attacker) spend my effort on something else.
> >
> > --
> > Christopher Dearlove
> >> so do we have an agreement that the old "sequence number attack"
> section of nhdp-threats-00 is wrong and must be removed because it
> describes something that does not apply to NHDP?
> >>

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 26 Feb 2013 16:55:54 +0100

On Feb 26, 2013, at 4:52 PM, Abdussalam Baryun <[email-masked]> wrote:

> Hi Thomas,
>  
> happy to know you agree to add that into the I-D, I will just hope/pray the editors agree, :-)

The editors do what the WG consensus tells them to do.

Chris made a proposal, for the WG to consider.

Thomas

> AB
> 
> On Tue, Feb 26, 2013 at 3:40 PM, Thomas Clausen <[email-masked]> wrote:

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 26 Feb 2013 16:01:10 +0000

Just to be clear, I didn't make this as a proposal to be included - it's a bit more colloquial than such text should be.

I just made it as a statement of what (in my - fairly well informed - opinion) the situation is.

Of course as a contribution on the list the authors are free to make use of it as a contribution should they wish. As I noted, if so I'd advise rewording it a bit.

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

From: Thomas Clausen [mailto:[email-masked]]
Sent: 26 February 2013 15:56
To: Abdussalam Baryun
Cc: Dearlove, Christopher (UK); [email-masked]
Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Keep this in mind if you answer this message.
Please see this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf> on how to deal with suspicious emails.

On Feb 26, 2013, at 4:52 PM, Abdussalam Baryun <[email-masked]<mailto:[email-masked]>> wrote:

Hi Thomas,

Thomas

AB

On Tue, Feb 26, 2013 at 3:40 PM, Thomas Clausen <[email-masked]<mailto:[email-masked]>> wrote:
....and that description of Chris' might be something worth folding into the I-D?

Thomas

On Feb 26, 2013, at 4:35 PM, "Dearlove, Christopher (UK)" <[email-masked]<mailto:[email-masked]>> wrote:

> 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<http://www.baesystems.com/>
>
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Thomas Clausen
> Cc: [email-masked]<mailto:[email-masked]>
> On Feb 26, 2013, at 1:08 PM, Henning Rogge <[email-masked]<mailto:[email-masked]>> wrote:
>
>> Hi,
>>
>>> <[email-masked]<mailto:[email-masked]>
>>> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>>
>>>   Telefon +49 228 9435-961<tel:%2B49%20228%209435-961> <tel:%2B49%20228%209435-961>,   Fax +49 228
>>>   mailto:henning.rogge@fkie.<mailto:henning.rogge@fkie.>__fraunhofer.de<http://fraunhofer.de/>
>>>   <mailto:[email-masked]<mailto:[email-masked]>> http://www.fkie.fraunhofer.de<http://www.fkie.fraunhofer.de/>
>>>
>>>
>>>   [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>> Telefon +49 228 9435-961<tel:%2B49%20228%209435-961>,   Fax +49 228 9435 685<tel:%2B49%20228%209435%20685>
>> mailto:[email-masked]<mailto:[email-masked]> http://www.fkie.fraunhofer.de<http://www.fkie.fraunhofer.de/>
>>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 26 Feb 2013 16:01:29 +0000

I made many proposals but  not considered by editors,

AB

On Tue, Feb 26, 2013 at 3:55 PM, Thomas Clausen <[email-masked]>wrote:

>> > Or in other words it's a smart but stupid NHDP implementer. (He made
>> two mistakes, using a poor link quality mechanism, and using something

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 26 Feb 2013 16:02:35 +0000

Hi Chris,

I know that it was not your proposal, it was Thomas's proposal and I
support :-),

AB

On Tue, Feb 26, 2013 at 4:01 PM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

>  Just to be clear, I didn't make this as a proposal to be included - it's
> a bit more colloquial than such text should be.****
>
> ** **
>
> I just made it as a statement of what (in my - fairly well informed -
> opinion) the situation is.****
>
> ** **
>
> Of course as a contribution on the list the authors are free to make use
> of it as a contribution should they wish. As I noted, if so I'd advise
> rewording it a bit.****
>
> ** **
>
> -- ****
>
> Christopher Dearlove****
>
> Tel: +44 1245 242194 |  Fax: +44 1245 242124****
>
> Registered in England & Wales No: 1996687****
>
> ** **
>
> *From:* Thomas Clausen [mailto:[email-masked]]
> *Sent:* 26 February 2013 15:56
> *To:* Abdussalam Baryun
> *Cc:* Dearlove, Christopher (UK); [email-masked]
>
> *Subject:* Re: [manet] I-D Action:
> draft-ietf-manet-nhdp-sec-threats-01.txt****
>
>  ** **
>
> ** **
>
> **** WARNING ****
>
> *This message originates from outside our organisation, either from an
> external partner or the internet.***
> *
>
> Please see this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>on how to deal with suspicious emails.
> *****
>
>  ** **
>
> On Feb 26, 2013, at 4:52 PM, Abdussalam Baryun <[email-masked]>
> wrote:****
>
>
>
> ****
>
> Hi Thomas,****
>
>  ****
>
> happy to know you agree to add that into the I-D, I will just hope/pray
> the editors agree, :-)****
>
> ** **
>
> The editors do what the WG consensus tells them to do.****
>
> ** **
>
> Chris made a proposal, for the WG to consider.****
>
> ** **
>
> Thomas****
>
>
>
> ****
>
> AB****
>
> ** **
>
> On Tue, Feb 26, 2013 at 3:40 PM, Thomas Clausen <[email-masked]>
> wrote:****
>
> Thomas****
> https://www.ietf.org/mailman/listinfo/manet****
>
> ** **
>
> ** **
>

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 26 Feb 2013 17:05:26 +0100

> Of course as a contribution on the list the authors are free to make use of it as a contribution should they wish. As I noted, if so I'd advise rewording it a bit.

Speaking as one of the authors of this document, the above is quite understood. Having concrete text such as what you wrote, with a concrete example given, makes the task easy.

> Please see this process on how to deal with suspicious emails.
> 
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 26 Feb 2013 16:10:18 +0000

You mean not implemented by editors. Different thing.

From: Abdussalam Baryun [mailto:[email-masked]]
Sent: 26 February 2013 16:01
To: Thomas Clausen
Cc: Dearlove, Christopher (UK); [email-masked]
Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt

*** WARNING ***

AB
On Tue, Feb 26, 2013 at 3:55 PM, Thomas Clausen <[email-masked]<mailto:[email-masked]>> wrote:

Hi Thomas,

Thomas

AB

Thomas

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 26 Feb 2013 16:31:27 +0000

On Tue, Feb 26, 2013 at 11:38 AM, Henning Rogge <
[email-masked]> wrote:

> If you want to get the "sequence number attack" paragraph back, maybe you
> should write a new one... one that applies to NHDP.
>
> I don't think writing something will help for this threat draft, I should
leave this item for others to discuss. This draft review was a bad
experience for me and I may report that when the time comes.

AB

---

From: Henning Rogge <[email-masked]>
Date: Tue, 26 Feb 2013 17:36:14 +0100

> experience for me and I may report that when the time comes.

Another good advise for you.

"Reporting" is a two-edged sword.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Tue, 26 Feb 2013 17:50:57 +0100

Op 26 feb. 2013, om 08:37 heeft Ulrich Herberg <[email-masked]> het volgende geschreven:

> But it is *not* an optional part of NHDP (nor is it mandatory). It is simply named as example what implementers may do, but it is outside of the normative part. I cannot guess what people can implement in addition to the normative part, since there may be infinite possibilities. Please tell me how I should write security threats for these potentially infinite, non-normative, things that people can implement. 
> 
> I can only repeat it again: NHDP does *not* use sequence numbers, neither packet nor message sequence numbers.

Than that is your valid response.

If a protocol has same optional or non-normative elements, I cannot see any reason not to fold in security considerations for it.
No reason to write security considerations down for what is not present. No infinity here.

Teco

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 26 Feb 2013 17:16:45 +0000

Let's be crystal clear on what NHDP says - whichever way you want to read it.  Section 14.4 is the relevant part, and in whole it reads (where the second bullet is the relevant one, but I've included it all for context).

   o  Information from the link layer, such as signal-to-noise ratio or
      packet acknowledgment reception and loss information.

   o  Receipt or loss of HELLO messages.  If the maximum interval
      between HELLO messages is known (such as by inclusion in HELLO
      messages of a Message TLV with Type := INTERVAL_TIME, as defined
      in [RFC5497]), then the loss of HELLO messages can be determined
      without the need to receive a later HELLO message.  Note that if
      this case is combined with the previous case, then care must be
      taken to avoid "double counting" a lost HELLO message in a lost
      packet.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Teco Boot
Sent: 26 February 2013 16:51
To: Ulrich Herberg
Cc: <[email-masked]> List
Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt

Teco

---

From: "A .Riley Eller" <[email-masked]>
Date: Tue, 26 Feb 2013 09:46:03 -0800

Sorry to pick nits, but couldn't "sequential packet sequence number"
be just "packet sequence number" or "sequential packet number"?

---

From: Christopher Dearlove <[email-masked]>
Date: Tue, 26 Feb 2013 18:03:43 +0000

Well, it's rather late to pick nits. But technically packet sequence number is the name of the field in RFC 5444. But you could use it non-sequentially (e.g. pseudo-randomly) which would lead to that form of words to be precise.

-- 
Christopher Dearlove
[email-masked] (iPhone)
[email-masked] (home)

---

From: Teco Boot <[email-masked]>
Date: Tue, 26 Feb 2013 20:00:29 +0100

Due to some mail bombs, I couldn't find time to check the documents. I'm not the only one. Today, the mail server I'm using was overloaded. It is not the smallest mail system on earth, so to say. Please send real contributions only.

I have nothing against a description of a NHDP security threat on packet sequence number attack. Could be a single sentence, such as: "If a NHDP link quality measurement is based on MANET control packet sequence numbers, as described in RFC 6130 section 14.4, such a mechanism can be influenced by spoofed packets or other attacks."

BTW: why are NHDP message sequence numbers mentioned in Appendix C? If unneeded, let's not send such. If it has some purpose, what are the threats?

Teco

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 26 Feb 2013 19:54:59 +0000

+1

AB

On Tue, Feb 26, 2013 at 7:00 PM, Teco Boot <[email-masked]> wrote:

> Due to some mail bombs, I couldn't find time to check the documents. I'm
> not the only one. Today, the mail server I'm using was overloaded. It is
> not the smallest mail system on earth, so to say. Please send real
> contributions only.
>
> I have nothing against a description of a NHDP security threat on packet
> sequence number attack. Could be a single sentence, such as: "If a NHDP
> link quality measurement is based on MANET control packet sequence numbers,
> as described in RFC 6130 section 14.4, such a mechanism can be influenced
> by spoofed packets or other attacks."
>
> BTW: why are NHDP message sequence numbers mentioned in Appendix C? If
> unneeded, let's not send such. If it has some purpose, what are the threats?
>
> Teco
>
>
> > Let's be crystal clear on what NHDP says - whichever way you want to
> read it.  Section 14.4 is the relevant part, and in whole it reads (where
> the second bullet is the relevant one, but I've included it all for
> context).
> >
> >>> again, sequence numbers are not used by NHDP, therefore not a threat
> to NHDP. If another protocols uses that information, it may be a threat to
> this aspect. I will wait if someone else also asks for changes on this
> matter before changing it.
> >>
> > If a protocol has same optional or non-normative elements, I cannot see
> any reason not to fold in security considerations for it.

---

From: Jiazi Yi <[email-masked]>
Date: Tue, 26 Feb 2013 21:04:23 +0100

Hi, 

On the threat related to sequence number, my opinion is:

1. The "sequence number attack" in revision -00 is clearly wrong (for duplicate detection), and not relevant to NHDP. So it has to be removed. 

2. The packet sequence number is not normative part of NHDP, however, it may affects link quality updates. Therefore, I would agree with Teco, that we can have a brief sentence to describe this threat, for example, in identity spoofing section.

On the appendix C, it is a little strange that a message sequence number is included. For me, it's unnecessary. 

best 

Jiazi

---

From: Henning Rogge <[email-masked]>
Date: Tue, 26 Feb 2013 21:12:24 +0100

> 1. The "sequence number attack" in revision -00 is clearly wrong (for duplicate detection), and not relevant to NHDP. So it has to be removed.

Yes. This one HAD to go.

> 2. The packet sequence number is not normative part of NHDP, however, it may affects link quality updates. Therefore, I would agree with Teco, that we can have a brief sentence to describe this thr…

What do you think about a compromise.

Instead of focusing on the packet sequence for attacks on the link
hysteresis, we could add a text that by implementing the hysteresis,
the new input of the protocol will open more possible attack
vectors... and add the packet sequence number as an example.

We cannot even say for sure how/if an attack through this vector would
work, because it would depend on the implementation of the link
hysteresis. So we should not go into too much details.

We might want to add a similar section for the coming olsrv2 threats
document... by implementing a link metric, the implementation might
open new attack vectors through the input of the metric.

Henning Rogge

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 26 Feb 2013 15:53:23 -0800

Jiazi,

On Tue, Feb 26, 2013 at 12:04 PM, Jiazi Yi <[email-masked]> wrote:

> 1. The "sequence number attack" in revision -00 is clearly wrong (for
> duplicate detection), and not relevant to NHDP. So it has to be removed.
>

Yes.

>
> 2. The packet sequence number is not normative part of NHDP, however, it
> may affects link quality updates. Therefore, I would agree with Teco, that
> we can have a brief sentence to describe this threat, for example, in
> identity spoofing section.
>

Alright, even though I still think it's only in a non-normative part, and a
rare case (as described by Chris), it may not hurt adding a few sentences
to the draft.

> is included. For me, it's unnecessary.

True, can be removed IMO.

Ulrich

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 27 Feb 2013 10:06:40 +0000

I will just quote the AD statement once on MANET WG list once;

[....
 I don't think it is a valuable use of time for anyone to debate the
meaning of the responses or their number. ]

Please don't respond to this,
AB

---

From: Daniel He <[email-masked]>
Date: Wed, 27 Feb 2013 10:54:07 +0000

I don't think it is a valuable use of time for anyone to send me useless
and unnecessary responses!!

stop it please