On 19 Dec 2016, at 19:39, Abdussalam Baryun <abdussalambaryun@xxxxxxxxx> wrote: > > I recommend that if a reviewer did not find the answer to the simple security question then the answer should be clear in the document. Please note that this protocol has many RFCs involved but still this draft needs to answer clearly the security threat questions. I think maybe the confusion is that the draft refers to many drafts and does not clarify the differences between packets and messages, not sure but the reviewer can help with his observations. The main issues of threats is always about packets and messages, so why not clarify those differences rather than referring to other documents. > > - We may understand from the below answer is that the question answer is YES, and NO if using ICVs or signatures. It states in the draft in page 4, as OLSRv2 SHOULD use 7183 and MAY use other ....... (it is better not to use MAY if you don't define/determine the other alternative). > > - Section 3.2 page 7, mentions the attacks threats of modify hop-limit. It also mentions that hop-limit is not protected by integrity check,,, ( which is 7183). > > Recommend to clarify in draft: > The manet packet has no longer than one hop, it's messages that have the hop-limit that may be attacked. So the attacker to manet using 7183, just can change the hop-limits of messages if has the keys. There are a number of errors in the above, which I’m afraid I lack the patience to spell out in detail. But it does correctly point out that section 3.2 discusses the impact of attacks on hop count/limit - in fact in more detail than I did. And that this is not protected against by 7183 is indicated in section 6.2.1. (The keys are not required.) However there is a weakness in section 6, which is that it seems to only be considering message ICV use. But, as I had forgotten in my previous comment, although RFC 7182 defines packet and message level protections, RFC 7183 only discusses the message protection. (That will be because packets are RFC 5444 constructs, not limited to carrying OLSRv2 and NHDP.) Packet level protection therefore is correctly excluded if only considering RFC 7183, however I think a mention of packet protection using RFC 7182 would not be out of place. (Protecting hop count and limit is the main gain from packet protection over message protection, the other is some processing gain if using something more expensive like RFC 7859 - an RFC 7182 addition. The main losses are in trust model and the impact of key loss when not using a single shared key - as for RFC 7859 but not RFC 7183’s chosen option from RFC 7182.)