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

[Abdussalam Baryun <[e-mail]>]

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,


> 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.
>

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


>
> 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.
>

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.


>
> 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.
>
>
>
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,


>
> 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.
>

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,

>
> 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.
>
>
>

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