Re: [manet] draft-ietf-manet-smf-sec-threads-01

[Jiazi YI <[e-mail]>]

Dear all,

One of Chris' comments is:

- Section 3, para 1, last sentence. Some of the threats discussed in this
> document assume RFC 6130, but some don't. And limiting across the board to
> when using RFC 6130 is, I think, too limiting.


The sentence mentioned is:

This document assumes that NHDP is used.


The co-authors have discussed about this issue before. One of the reasons
we had this assumptions is that, to the best of our knowledge, NHDP is the
only layer-3 protocol currently used for SMF.
There are probably some L2 neighbour detection mechanisms, but NHDP is
still required to get 2-hop neighbour information.

As our knowledge is limited, we would therefore, ask the WG if there are
other mechanisms that used as a replacement of NHDP in SMF.
It is appreciated if related information can be provided, so that we can
consider it in this SMF security-threats draft.

regards

Jiazi



On Thu, Mar 19, 2015 at 1:44 PM, Jiazi YI <[e-mail]> wrote:

> Thanks very much, Chris.
>
> We have identified some of the errors in the draft, but haven't had chance
> to make a new submission yet -- will do as soon as the submission system is
> available next Monday, merging your comments.
>
> regards
>
> Jiazi
>
> On Thu, Mar 19, 2015 at 1:20 PM, Dearlove, Christopher (UK) <
> [e-mail]> wrote:
>
>> I have read draft-ietf-manet-smf-sec-threads-01 and found a higher level
>> of typographic and other nits than I might have expected from a document
>> that's passed WGLC. My review comments below will cover what I have to say,
>> I think another draft is called for.
>>
>> Wearing my just agreed Document Shepherd hat on this, I haven't yet
>> consulted the mailing list history to see what comments have been made on
>> it, but if anyone has reviewed it and commented or not commented, please
>> let me (via the list) know.
>>
>> - There are quite a few uses of which that I'm sure the RFC editor (who
>> is hot on this) will want to turn into uses of that. I'm not going to
>> discuss those (and the related whether they should have a comma before)
>> here.
>> - Section 1 line 1, of -> to
>> - Section 1 para 4 vecors -> vectors
>> - Section 1 para 5 and elsewhere. I think most references to RFC 7183
>> should be to RFC 7182. As a reminder, RFC 7182 is the generic framework,
>> RFC 7183 is its specific application to OLSRv2 and NHDP.
>> - Section 2, it's usual to quote from RFC 2119 if referencing it. But I'm
>> not sure an informational document should be using RFC 2119 language. There
>> is, I think, terminology from RFC 6130 used - MANET router is defined there
>> (unless also repeated in RFC 6621, I've not checked).
>> - Section2, definition of compromised SMF router, the words "present in
>> the network@ are redundant, as attacker includes that.
>> - Section 3, line 2 orde -> order
>> - Section 3, para 1, last sentence. Some of the threats discussed in this
>> document assume RFC 6130, but some don't. And limiting across the board to
>> when using RFC 6130 is, I think, too limiting.
>> - Section 3, first bullet draing ->draining
>> - Section 3, last para forforwarding -> for forwarding
>> - Section 3, last para certain part -> certain parts
>> - Section 3, last para. Need a reference for MPR-CDS.
>> - Section 4.1 para 1, penultimate line received packet -> received packets
>> - Section 4.1 para 1, penultimate line determine the coming packet ->
>> determine whether the incoming packet
>> - Section 4.1.1 first para IP source IP -> source [IP] address
>> - Section 4.1.1 could discuss timestamps and whether they would be
>> effective. (Not very I think, but should be discussed.]
>> - Section 4.1.1 the first two paragraphs are discussing different things.
>> Both are important, but they need clearly separating. One is future
>> prediction of sequence numbers (which a timestamp would limit the future
>> horizon). The other is what one might call fast misforwarding with malice.
>> The latter is immune to timestamps, and even to using randomised sequence
>> numbers.
>> - Section 4.1.2 I'm not sure what the benefits of modifying sequence
>> numbers are over just creating a new packet. Greater verisimilitude?
>> - Section 4.2 para 2, the probability of collision is critical here, but
>> I guess that is SMF's job, not that here.
>> - Section 4.2.1 last paragraph, the jitter bypassing is another way
>> (other than a wormhole) to achieve this. This shows that there is a fuzzy
>> boundary between what's in 4.1.1 and 4.2.1.
>> - Section 4.2.2 (which I like the pointing out of the dangers of
>> selective use of HAV) there's a countermeasure by always using HAV on all
>> packets if it's felt it's likely to be useful on some.
>> - Section 5.2.2 para 2, 2x of a -> than a
>> - Section 5.4 para 2, I think this is a weak argument. I think the
>> conclusion is true, but just "A has weakness, B has weakness, this is A and
>> B, therefore has weakness" needs at least a step of "and the combination
>> does nothing to address the weakness".
>> - Section 6, para 3 is assuming that you are using a single key (or small
>> numbers of keys). I think all the examples in RFC 7182 (which is main
>> issue) are small numbers of keys, and that in RFC 7183 (sic) definitely is.
>> But the3 RFC 7182 framework permits other options, we are trying to get one
>> (IBS) standardised. Should timestamps be mentioned here?
>> - Section 6 final para are we talking about RFC 5444 hop limit (never
>> TTL, even for IPv4)? If so, as I think, this implicitly assumes use of RFC
>> 7182 applied to messages. Applied to packets (hop by hop) the hop limit is
>> protected. As IP packets only travel one hop, their TTL is not critical.
>> - Section 7 could be a bit stronger and say the whole document is
>> security considerations.
>> - Section 8 doesn't have the usual "RFC Editor may remove" text.
>> - References. I'm not sure why the specific normative/informative split.
>> Why is 5614 normative when 6130 is informative? What is a normative
>> reference in a document such as this? As previously noted, 7182 should
>> definitely be here, 7183, maybe, maybe not.
>>
>> --
>> Christopher Dearlove
>> Senior Principal Engineer, Information Assurance Group
>> Communications, Networks and Image Analysis Capability
>> BAE Systems Advanced Technology Centre
>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
>> Tel: [phone] |  Fax: [phone]
>> [e-mail] | http://www.baesystems.com
>>
>> BAE Systems (Operations) Limited
>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace
>> Centre, Farnborough, Hants, GU14 6YU, UK
>> Registered in England & Wales No: 1996687
>>
>>
>> ********************************************************************
>> This email 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.
>> You should not copy it or use it for any purpose nor disclose or
>> distribute its contents to any other person.
>> ********************************************************************
>>
>>
>>
>