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

[Jiazi YI <[e-mail]>]

Hi Chris,

We have updated the draft based on your comments:

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-smf-sec-threats/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-manet-smf-sec-threats-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-smf-sec-threats-02


Please check below for details:


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

Because NHDP is one of the building blocks of SMF, RFC 7183 is cited in
"future work" section as one possibility to secure the control packets
exchange.


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

We used one MAY in the previous revision -- but it's quite trivial. We
removed the RFC 2119 language in the new revision.


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

We distinguished which threats are common to SMF, and which are
NHDP-specific in the new revision. Generally, the duplicate packet
detection is SMF-general and relay set selection is NHDP-specific.


>
> - Section 4.1.1 could discuss timestamps and whether they would be
> effective. (Not very I think, but should be discussed.]
>

Some discussion are added. In fact, if jitter manipulation is used,
timestamp won't be effective here (now it's in 4.2.1).


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

The common part is, "pre-activate" the duplicate detection mechanisms with
valid identification but invalid content. We updated the text accordingly.
For the possible countermeasures, we added in the "future work" section.


> - Section 4.1.2 I'm not sure what the benefits of modifying sequence
> numbers are over just creating a new packet. Greater verisimilitude?
>

Yes. With lower cost and 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.
>

Yes. It's just a brief introduction of SMF: SMF doesn't guarantee the
uniqueness of the hash value.


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

We moved the previous 4.2.1 to 4.1, as it's common for I-DPD and H-DPD.
They are certain overlaps, but the way of the attacks are different: one is
to the TTL field, one is to identification field (thus only for I-DPD).


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

I think there two possible sources of digest collision:
      - identical content
      - different content but the same digest (low probability, but
according to SMF, it might happen: *160-bit SHA-1 is being applied in SMF
only to*
*   provide a low probability of collision and is not being used for*
*   cryptographic or authentication purposes.*).

For the first one, always using HAV would be helpful. But for the second,
it won't be effective.



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

Updated as suggested.


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


We didn't try to make assumptions on the number of keys used. We just try
to say that the shared keys might cause some issues. The IBS is very
interesting to be mentioned here -- we added it as an informative
reference.


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

The final paragraph is about IP hop limit of the multicast datagram, not
RFC 5444 hop limit (of HELLO). Sorry that we didn't have it clear enough.
We made it more explicit in the new revision.


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

In the new revision, we put 6130 as normative, and 5614 as informative.
7182 and 7183 are informative, because this document mainly focus on
threats, not solutions.

thanks again for your detailed review. Hopefully the new revision and the
reply above solve your concern. Any further comments are welcome.

regards

Jiazi



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