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

[Ulrich Herberg <[e-mail]>]

AB,

On Mon, Apr 8, 2013 at 9:33 PM, Abdussalam Baryun
<[e-mail]> wrote:
[...]
>>> [I-D] Abstract:
>>> [I-D] This document analyses common security threats of the Neighborhood
>>> Discovery Protocol (NHDP), and describes their potential impacts on
>>> MANET routing protocols using NHDP.
>>>
>>> AB>question> What is the meaning of *common* security threats?
>>> Mentioned in the abstract,
>>
>> I think the word is fairly clear. See
>> http://dictionary.reference.com/browse/common
>> (definition 4/5)
>
> I mean why common why not ALL threats, or the explaining the *Exploits
> Allowed by the NHDP* as per the reference [2] I gave in my AB#2
> message.


Because we cannot know if we listed ALL threats that could potentially
exist. It may be that we overlooked one, or that a future threat may
be thought of (I assume that when MD5 was standardized, they would
have loved to know about the threat that led to its obsoletion)




>
>>
>>
>>>
>>> AB>question> How can I define threats when I don’t know on which layer
>>> NHDP[RFC6130] is located in router, is it in L4 or L3. Please define
>>> that you concern with IP layer if it is the only you concern with.
>>
>> That is given by RFC6130, which is running on the IP layer. I think
>> this is not a task of NHDP-sec-threats to define.
>
> I don't find that defined, but if so, does IP threats affect the NHDP threats?

RFC6130 runs either on UDP or directly on IP (see section 5.1 of
RFC6130), and uses a multicast LL address (section 5.2). In multiple
occasions of the text in RFC6130 it is mentioned that either IPv4 or
IPv6 can be used. It is true that there is no sentence in the
beginning of RFC6130 "This is an IP protocol and all addresses used in
this specification are either IPv4 or IPv6 addresses". But whether or
not that would be a good idea to mention as clarification in RFC6130
is irrelevant because it's already completed.




[...]
>>
>> AODVv2 has no normative reference to RFC6130. In many cases of AODVv2
>> deployments, I don't think that RFC6130 would be used (whereas it must
>> be used for OLSRv2 and SMF). I am against adding a reference. Anyway,
>> the sentence just lists some example protocols ("such as...").
>>
>
> Just I prefered showing that NHDP explains all its threats when used
> by different MANET routings, if we explain one only then we don't
> explain all threats.


As said above, we cannot assure to discuss *all* threats. I also don't
see how the draft would improve by citing AODVv2 here, as in its
current form, it does not mandate to use RFC6130. And AODVv2 is only a
-00 draft, so there could be many changes to it yet, so we don't even
know what will be included in it (whereas SMF and OLSRv2 are
completed).


>
>>
>>>
>>> [I-D] As wireless radio waves can be captured as well as transmitted
>>> by any wireless
>>> device within radio range
>>>
>>> AB>confused> not true, different antennas have different
>>> waves/frequencies, please delete.
>>
>> I think that this is fairly clear; it's about contrasting
>> communication over cable vs wireless, where the access to the channel
>> is much easier, i.e., security threats can be exploited more easily
>> since there is no physical access protection (read: cable).
>>
>
> Please delete word *any* and change to *some*, because think it is not
> clear to me,


See the other email and suggestion from Stewart.


>
>>>
>>> [I-D] The document analyses possible attacks and mis-configurations on
>>> NHDP and outlines the consequences of such attacks/mis-configurations
>>> to the state
>>> maintained by NHDP in each router (and, thus, made available to
>>> protocols using this state).
>>>
>>> AB> I don’t think it makes full analyses for NHDP threats? Please see
>>> threat analysis by Tsao et al (2013) [1].
>>>
>>> AB> the doc should consider information exchanged attacks and network
>>> attacks as well.
>>
>>
>> I think that this is exactly what NHDP-sec-threats does; section 4
>> describes the possible exploits when using no protection of NHDP.
>> Section 5 outlines the consequences for protocols using NHDP.
>
> I need analysis which was mentioned but not done. I mean what is
> exploited by the NHDP messages and the NHDP IIB and NIB, don't see
> much explaining about those information and the exploitation. Yes in
> section 4 explains but in the point of view of the attacker, and no
> possibility of malfunctions or other issues,


I don't understand which attacks you would like to see in the draft.


>>
>>
>>>
>>> Section 2. Terminology:
>>>
>>> AB> you don’t define *Threat*, and *Attack*, please do same definition
>>> as threat analysis draft in ROLL WG (or refer to it).
>>
>> The words "threat" and "attack" are pretty well known; I don't see any
>> reason why they are ambiguous. I don't see any reason to cite the ROLL
>> draft; why is that related in any way to NHDP? It describes security
>> threats to a completely different protocol.
>
> In the I-D the titles of section make me feel that authors made;
> threats = attacks, so I need that to be answered in the doc.


I don't see how this would improve the draft. Anyone else thinking
this is a problem?


>
>>
>>
>>>
>>> [I-D] Compromised NHDP Router: An attacker, present in the network and
>>> which generates syntactically correct NHDP control messages.
>>> Control messages emitted by a Compromised NHDP router may contain
>>> additional information, or omit information, as compared to a
>>> control message generated by a non-compromized NHDP router located
>>> in the same topological position in the network.
>>>
>>> AB> you mention network position, or topological position, but why the
>>> document ignores the network domain(s) (just topology), could the NHDP
>>> threats affect the network domain policy/states? If not say so,
>>
>>
>> I don't understand your point. What do you mean?
>
> Is the NHDP threats affecting the network domains? as it was mentioned
> in the RFC6130 the different deployments and low-value  WSN. Does
> different deployments mean different NHDP threats.


The draft describes potential threats to NHDP; whether they are always
feasible for an attacker cannot be answered in this document, I think
(and also irrelevant).

Ulrich