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

["Dearlove, Christopher (UK)" <[e-mail]>]

Even if deciding to limit to NHDP where the issue is between it and an (unknown) alternative, it might be worth indicating which threats are NHDP specific, and which are not. For example the hash attacking is not NHDP specific. (Depending on which is most common, which could be called out as an exception, possibly by section.)

--
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]<mailto:[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

From: [e-mail] [mailto:[e-mail]] On Behalf Of Jiazi YI
Sent: 19 March 2015 14:02
To: Dearlove, Christopher (UK)
Cc: [e-mail]; Thomas Heide Clausen ([e-mail]); Ulrich Herberg ([e-mail])
Subject: Re: draft-ietf-manet-smf-sec-threads-01


*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
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]<mailto:[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]<mailto:[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]<tel:%2B44%201245%20242194> |  Fax: [phone]<tel:%2B44%201245%20242124>
[e-mail]<mailto:[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.
********************************************************************