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

I agree with Ulrich's reply. 

We can change 

>> [I-D] As wireless radio waves can be captured as well as transmitted
>> by any wireless
>> device within radio range

to 

> As radio signals can be received as well as transmitted
> by any compatible wireless device within radio range

It would be clearer. 

best

Jiazi

On Apr 8, 2013, at 9:00 PM, Ulrich Herberg <ulrich@herberg.name> wrote:

> AB,
> 
> see my answer below (note my reply represents my individual opinion; I
> don't claim to speak for the whole author group):
> 
> On Mon, Apr 8, 2013 at 11:35 AM, Abdussalam Baryun
> <abdussalambaryun@gmail.com> wrote:
> [...]
>> 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
>> ====================================
>> 
>> [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)
> 
> 
>> 
>> 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-D] Section 1.Introduction:
>> 
>> [I-D] The information acquired by NHDP is used by other protocols, such as
>> OLSRv2 [OLSRv2] and SMF [RFC6621].
>> 
>> AB> please add> AODVv2 as reactive protocol using NHDP, not only proactive,
> 
> 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...").
> 
> 
>> 
>> [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).
> 
> 
>> 
>> [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.
> 
> 
>> 
>> 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.
> 
> 
>> 
>> [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?
> 
> Best regards
> Ulrich
> 
> 
>> 
>> The Message-References:
>> [1] http://tools.ietf.org/html/draft-ietf-roll-security-threats-01
>> 
>> =======================================
>> This is not the last comment, still under process,
>> 
>> Regards
>> AB
>> 
>> ---------------------------------------------------------------------------------------
>> 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) <sratliff@cisco.com> 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
>>> manet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/manet
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet