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

[Jiazi YI <[e-mail]>]

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