Subject: [manet] AB#2 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 9 Apr 2013 05:47:06 +0200

This message Author: Abdussalam Baryun
Classified: I-D Review

Second Message Reply to your WGLC request dated 25/03/2013
The I-D Reviewed By: Abdussalam Baryun (AB)         Dated: 08/04/2013
Reviewer Comment AB#2: Questions and Comments
++++++++++++++++++++++++++++++++++++

Copyright Notice:
Copyright (c) 2012 IETF Trust and the person identified as the
message author. All rights reserved.
This message is to comment on the MANET WG work in progress I-D:
draft-ietf-manet-nhdp-sec-threats-02 [I-D], which means this message
may contain parts/texts of the I-D under review
=======================================

[Overall]

AB> The I-D structure approach is a little not clear, because it
states threats, but mostly describes the attacker possibility not the
way attacker uses the NHDP to make threat. I suggest focus on: 1) NHDP
messages, 2)IIB and NIB, then 3)Impact routing using NHDP (as you
mentioned in section-5). Both point 1 and 2 are not clear in I-D (they
were mentioned in RFC6130 security consideration section). I don’t
find in I-D about; threats against NHDP confidentiality, integrity,
Info-Freshness, and availability (may be in other words or meanings,
but these words are mostly used).

AB> Using the words *Exploits Allowed by protocol* by Sanzgiri et al.
(2002)[2] is better to clarify threats. In your approach you describe
attacks as the threats. They are not the same thing. Please read to
compare this I-D approach with [2]. I recommend editing *Exploits
Allowed by NHDP* into the work to clarify threats, making it easier to
read.

[I-D][section 4.3] Eavesdropping does not pose a direct threat to the
network nor to NHDP,

AB> From above text, what is an *indirect threat* mentioned? How can
we know if direct or indirect while information was accessed (lost
privacy), means a threat, don’t you think? Elsewhere you mention
passive threat/attack where is that definition?

AB> section 4.8 mentions my comments on the list before regarding
attacks on sequence number, just you named it attack on link quality.
It is ok.
------------------------

[Layer Protocol affects]

AB> Does attacks on IP layer increase threats to NHDP? Not understood from I-D.
AB> Does attacks on MAC, L2 or L2.5 increase threats to L3-NHDP?
Does/Can NHDP possible depend on the lower layers, if yes, what are
the threats? Please note that these issues mentioned in RFC6130 but
not in this I-D.
----------------------

[The use of NHDP]

AB> If there is an attack on NHDP does that mostly mean that its users
are attacked as well?
AB> In AODVv2 mentions that NHDP used to monitor and assure
bi-directional links, does that use have threats, why not mentioned,
please do.
AB> Does the NHDP detect the attack neighbor? IMO, it can, please mention this.
AB> Is the NHDP using an unreliable communication? If yes then should
explain the threats of that. In high density of neighbors/malicious
what is the threat?
AB> Does the threat increase if packets have more neighbor messages
packed in one packet?

[I-D] [section 3] An Attacker has several ways of harming this
neighbor discovery process: It can announce "wrong" information about
its identity,
postulate non-existent links, and replay HELLO messages.

AB> wrong identity!, what about interface address, network address?
-----------------------------

[NHDP-Messaging]
AB> This I-D does not distinguish between IP packets and RFC5444
Packets, as to describe the influence of the attacks on both packets.

AB> Regarding Invalid Hello Messages of:  interface addresses or its
IP addresses, and network addresses relate to threats, what are their
influences to NHDP threats?
AB> Please consider the Scenarios of RFC6130 Appendix F [Topology
Picture] (from 1 to 11, if related). You need to explain how the
threats in different topologies, as mentioned topology positions in
introduction of this I-D. If no NHDP threats due to those different
topologies then please mention no threats. IMHO, is important to
mention, they are same number of neighbors, but different topologies
with different NHDP threat levels.
[RFC6130] This is acquired through HELLO message exchange between
neighboring routers. This information is made available through the
Interface Information Bases and Neighbor Information Base, describing
the router’s 1-hop neighborhood and symmetric 2-hop neighborhood.

AB> As per above text of 6130, please explain threats of invalid IIB
and NIB in the I-D.

AB> In the I-D security consideration, you mention that you in this
I-D make security consideration for NHDP, but in RFC6130 one of its
security consideration mentions invalid messages. I expected to see
Invalid Hello Messages as mentioned in RFC6130 security section 17.1,
why not consider as an NHDP threat?

AB> If a node receives the NHDP messages that are not as specified in
procedure of RFC6130 section 10 and 10.1, then is that a threat? IMO,
yes it is, please mention it.
-------------------------------

[NHDP Security Considerations]

[RFC6622][section 4] security in MANETs, "one size rarely fits all"
and that MANET routing protocol deployment domains have varying
security requirements ranging from "unbreakable" to "virtually none".

AB> Different deployment domains, which make the security requirement
different. So could we say threats are different also in different
deployment domains. Please mention in this I-D.
AB> wrong behavior can come from a malicious node, but it can also
come from a neighbor that is malfunctioning. Do you consider both as
same threats? This should be clear in I-D.

This Message Reference:
------------------------------------
[2] Sanzgiri, K., et al., A Secure Routing Protocol for Ad Hoc
Network, IEEE ICNP, 2002.

=======================================
This is last message comment, I really hope this is useful, thanking you.

Best Regards,

Abdussalam Baryun

---------------------------------------------------------------------------------------
This message is not sent to private email boxes, but sent to IETF
MANET mail box.
This message 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.
This message is in compliance with the IETF regulations.
---------------------------------------------------------------------------------------

> On 3/25/13, Stan Ratliff (sratliff) <[email-masked]> wrote:
>> WG,
>>
>> I've re-started the WGLC on this document. There's a 2-week WGLC period,
>> ending on April 8, 2013.
>>
>> Regards,
>> Stan
>> _______________________________________________
>> manet mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 9 Apr 2013 15:25:07 +0200

On 4/9/13, Jiazi Yi <[email-masked]> wrote:
> Hi,
>
> On Apr 9, 2013, at 5:47 AM, Abdussalam Baryun <[email-masked]>
> wrote:
>
> I don't know what's IIB and NIB. But this draft mainly focus on the
> threats/attacks to NHDP, not impacts to the routing protocol using NHDP -
> because we can't assume how NDHP used, but just illustrate some examples
> like MPR selection, etc.
>
sorry thought is was denoted in RFC6130,

Interface Information Bases= IIB
Neighbor Information Base= NIB

These information are important to RFC6130, not sure about their
threats by reading the I-D under-review.

AB

---

From: Jiazi Yi <[email-masked]>
Date: Tue, 9 Apr 2013 18:00:25 +0200

Hi, 

(AB, sorry if you received multiple copies of this reply. My previous message was rejected by the mailing list because of some technical reasons). 

> Reviewer Comment AB#2: Questions and Comments

I don't know what's IIB and NIB. But this draft mainly focus on the threats/attacks to NHDP, not impacts to the routing protocol using NHDP - because we can't assume how NDHP used, but just illustrate some examples like MPR selection, etc. This issue has been fully discussed in previous sessions, and I believe the WG consensus is clear. 

> Allowed by NHDP* into the work to clarify threats, making it easier to

I think Chris' post http://www.ietf.org/mail-archive/web/manet/current/msg15259.html
gives a very good definition of threat/attack. They are not the same, but highly related. I don't see there is misuse of those two words in the draft. 

> passive threat/attack where is that definition?

"Passive attack" is well-known term in network security, and is used in numerous articles.
Personally, I don't see there is need to define every word like "direct", "passive", "common", "range" in the ID. They have no different means than in the dictionary. 

> attacks on sequence number, just you named it attack on link quality.

No, it's different from your comments. 

> the threats? Please note that these issues mentioned in RFC6130 but

We don't even know what L2 L2.5 will be used with NHDP, so it's impossible to have further discussions on it. 

> AB> If there is an attack on NHDP does that mostly mean that its users

The consequence of the attacks has been introduced in the ID. 

> bi-directional links, does that use have threats, why not mentioned,

No. AODVv2 has no normative reference to NHDP. 

> AB> Does the NHDP detect the attack neighbor? IMO, it can, please mention this.

It's not relevant to this draft. 

> explain the threats of that. In high density of neighbors/malicious

NHDP is for ad hoc networks, i.e., it would be through unreliable medium. The whole ID is based on this assumption. I didn't see there is need to mention it -- because it has been included. 

> AB> Does the threat increase if packets have more neighbor messages

I can't see it. 

> AB> wrong identity!, what about interface address, network address?

They are identities. 

This I-D is about RFC 5444 message. 

> influences to NHDP threats?

I'm not sure you understand interface/IP/network addresses. 

> with different NHDP threat levels.

The appendix F of rfc6130 is just a set of examples, not a normative part of NHDP. 
It's impossible/unnecessary to illustrate all different topologies. 

> why not consider as an NHDP threat?

In fact, it has been documented in the ID, like link spoofing/identity spoofing. 

> yes it is, please mention it.

NHDP will verify the message in section 12.1 Invalid Message

> deployment domains. Please mention in this I-D.

The assumption of the document is in section 1 Introduction. That's one of reasons why we call it "common" threats. 

> same threats? This should be clear in I-D.

It is already in the I-D:

=================
The document analyses possible attacks and mis-configurations on NHDP and...
=================

since -01 revision 
http://www.ietf.org/mail-archive/web/manet/current/msg13831.html

best

Jiazi

> This Message Reference:

Jiazi

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 10 Apr 2013 03:28:12 +0200

Please note that you need to consider all issues in RFC6130, Interface
information bases and Neighbor Information bases should be discuss
further in your I-D. Regarding L2, I repeat that you need to discuss
what is in RFC6130, if mentioned any interaction then consider,

However, I will respond to this below message after two weeks from now,

AB

On 4/9/13, Jiazi Yi <[email-masked]> wrote:
> Hi,
>
> (AB, sorry if you received multiple copies of this reply. My previous
> message was rejected by the mailing list because of some technical reasons).
>
>
> like MPR selection, etc. This issue has been fully discussed in previous
> sessions, and I believe the WG consensus is clear.
>
>>
> I think Chris' post
> http://www.ietf.org/mail-archive/web/manet/current/msg15259.html
> gives a very good definition of threat/attack. They are not the same, but
> highly related. I don't see there is misuse of those two words in the draft.
>
>
>>
> Personally, I don't see there is need to define every word like "direct",
> "passive", "common", "range" in the ID. They have no different means than in
> the dictionary.
>
>
>>
> NHDP is for ad hoc networks, i.e., it would be through unreliable medium.
> The whole ID is based on this assumption. I didn't see there is need to
> mention it -- because it has been included.
>