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

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

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