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

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 19 Mar 2015 12:20:18 +0000

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: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | 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.
********************************************************************

---

From: Jiazi YI <[email-masked]>
Date: Thu, 19 Mar 2015 13:44:33 +0100

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) <
[email-masked]> 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 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, 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 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.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.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.
> - 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

---

From: Jiazi YI <[email-masked]>
Date: Thu, 19 Mar 2015 15:01:37 +0100

Dear all,

One of Chris' comments is:

> 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 <[email-masked]> wrote:

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

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 19 Mar 2015 14:52:22 +0000

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

[email-masked]<mailto:[email-masked]> | http://www.baesystems.com

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jiazi YI
Sent: 19 March 2015 14:02
To: Dearlove, Christopher (UK)
Cc: [email-masked]; Thomas Heide Clausen ([email-masked]); Ulrich Herberg ([email-masked])
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,

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 <[email-masked]<mailto:[email-masked]>> 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) <[email-masked]<mailto:[email-masked]>> 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.

--
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: +44 1245 242194<tel:%2B44%201245%20242194> |  Fax: +44 1245 242124<tel:%2B44%201245%20242124>
[email-masked]<mailto:[email-masked]> | http://www.baesystems.com

---

From: Jiazi YI <[email-masked]>
Date: Thu, 19 Mar 2015 16:22:02 +0100

Yes, that's very good point. thanks

Jiazi

On Thu, Mar 19, 2015 at 3:52 PM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

>  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
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Jiazi
> YI
> *Sent:* 19 March 2015 14:02
> *To:* Dearlove, Christopher (UK)
> *Cc:* [email-masked]; Thomas Heide Clausen ([email-masked]);
> Ulrich Herberg ([email-masked])
> *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,
>
>
>