Subject: [secdir] Secdir Review of draft-ietf-manet-olsrv2-dat-metric-08

From: Dacheng <[email-masked]>
Date: Sun, 15 Nov 2015 15:40:00 +0800

Dear all,

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.

These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

This draft is about a new routing  metro for OLSRv2.

Technical questions/comments:

1) In this draft, “RFC5444 packet” can be found in many places. I didn’t find the definition of this term. Do you indicate this solution may need to process a packet which is not specified in OLSRv2?

2) There is a good security consideration section in RFC 7181. Since this draft is closely related to OLSRv2 (although this work does not specify any new message or TLV), it will be good to build the security considerations of this work based upon what has been discussed in RFC7181. For example, maybe the authors could say ’there will be some new security issues introduced by this work but not mentioned in RFC 7181, there will be some security issues if we only use the mandatory security mechanism specified in RFC7181, or our work does not introduce any additional security issues..

3) This question is about the last sentence in the security consideration—“The signature scheme described in [RFC7183] does not protect the additional sequence number of the DAT metric because it does only sign the RFC5444 messages, not the RFC5444 packet header.” First of all, there is no signature mechanism specified in RFC7183, only HMAC is used to protect the message integrity. In addition, the RFC7183 reuse the process specified in RFC7182 to generate hashes, and so it should be able to cover the message headers.   Open for discussion.

Editorial:

Section 2:

MAX(a,b) -> MAX(a, b)
Section 3:

The administrator should take care that link layer multicast transmission do not not have ->  The administrator should take care that link layer multicast transmission do not have
Section 4:

The routing decision of most operation systems don't take packet size into account. -> The routing decisions of most operation systems don't take packet size into account.
Section 7:
with a very slow or very fast linklayer -> with a very slow or very fast link layer
Cheers
Dacheng

---

From: Henning Rogge <[email-masked]>
Date: Tue, 17 Nov 2015 10:14:40 +0100

On 11/15/2015 08:40 AM, Dacheng wrote:
> Dear all,
>
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
>
> These comments were written primarily for the benefit of the security
> area directors. Document editors and WG chairs should treat these
> comments just like any other last call comments.
>
> 1) In this draft, “RFC5444 packet” can be found in many places. I didn’t
> find the definition of this term. Do you indicate this solution may need
> to process a packet which is not specified in OLSRv2?

The header of the Terminology Section contains the following paragraph:

    The terminology introduced in [RFC5444], [RFC7181] and [RFC6130],
    including the terms "packet", "message" and "TLV" are to be
    interpreted as described therein.

Do you think this paragraph needs to be improved or extended?

> 2) There is a good security consideration section in RFC 7181. Since
> this draft is closely related to OLSRv2 (although this work does not
> specify any new message or TLV), it will be good to build the security
> considerations of this work based upon what has been discussed in
> RFC7181. For example, maybe the authors could say ’there will be some
> new security issues introduced by this work but not mentioned in RFC
> 7181, there will be some security issues if we only use the mandatory
> security mechanism specified in RFC7181, or our work does not introduce
> any additional security issues..

I think my security considerations section explicitly says (in the last 
sentence) that the Mandatory Security Mechanism for OLSRv2 (RFC7183) 
does NOT protect against modified packet sequence numbers.

> 3) This question is about the last sentence in the security
> consideration—“The signature scheme described in [RFC7183] does not
> protect the additional sequence number of the DAT metric because it does
> only sign the RFC5444 messages, not the RFC5444 packet header.” First of
> all, there is no signature mechanism specified in RFC7183, only HMAC is
> used to protect the message integrity. In addition, the RFC7183 reuse
> the process specified in RFC7182 to generate hashes, and so it should be
> able to cover the message headers.   Open for discussion.

RFC7183 introduces a RFC5444 message level integrity protection 
extension for RFC7181 (OLSRv2), based on the ICV Message TLV defined in 
RFC7182 (see section 9.1 of RFC7182).

The ICV Message TLV does NOT protect the PACKET header fields of RFC5444 
packets, including the RFC5444 packet sequence number.

> Editorial:
>
> Section 2:
>
> MAX(a,b) -> MAX(a, b)
>
> Section 3:
>
> The administrator should take care that link layer multicast
> transmission do not not have ->  The administrator should take care that
> link layer multicast transmission do not have
>
> Section 4:
>
> The routing decision of most operation systems don't take packet size
> into account. -> The routing decisions of most operation systems don't
> take packet size into account.
>
> Section 7:
>

Will be fixed in the next revision.

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de

---

From: Dacheng <[email-masked]>
Date: Mon, 23 Nov 2015 14:53:50 +0800

> Do you think this paragraph needs to be improved or extended?
Ok, I think ’a packet specified in RFC5444' looks better. But it is not a big problem.

> RFC7183 introduces a RFC5444 message level integrity protection extension for RFC7181 (OLSRv2), based on the ICV Message TLV defined in RFC7182 (see section 9.1 of RFC7182).
> 
> The ICV Message TLV does NOT protect the PACKET header fields of RFC5444 packets, including the RFC5444 packet sequence number.

I see and you are right. The only comment about this sentence is not to use “security mechanism” instead of “signature mechanism “ because only a HMAC mechanism is specified in RFC 7183.

---

From: Dacheng <[email-masked]>
Date: Mon, 23 Nov 2015 15:04:26 +0800

Sorry for sending out an unfinished email by mistake. See my comments in line please.

> I think my security considerations section explicitly says (in the last sentence) that the Mandatory Security Mechanism for OLSRv2 (RFC7183) does NOT protect against modified packet sequence numbers.

It is fine. I just tried to give some comments to make this section looks better, and I understand your point. In addition, maybe you could mention at the end of the fist paragraph that the methods of protecting against the MITM attacks performed by rogue routers are out of scope. 
> 
>> 3) This question is about the last sentencoe in the security

Ok, you have answered my second question, and I think you are right.  The first comment about this sentence is to replace  “signature mechanism “ with “security mechanism”, because only there is only a HMAC mechanism specified in RFC 7183, right?

---

From: Henning Rogge <[email-masked]>
Date: Tue, 24 Nov 2015 14:24:38 +0100

Am 23.11.2015 um 08:04 schrieb Dacheng:
> It is fine. I just tried to give some comments to make this section
> looks better, and I understand your point. In addition, maybe you could
> mention at the end of the fist paragraph that the methods of protecting
> against the MITM attacks performed by rogue routers are out of scope.

I will add a sentence mentioning MITM attacks are out of scope.

> Ok, you have answered my second question, and I think you are right.
>   The first comment about this sentence is to replace  “signature
> mechanism “ with “security mechanism”, because only there is only a HMAC
> mechanism specified in RFC 7183, right?

RFC7183 uses only a single type of signature described in RFC7182 
(SHA256 HMAC).

I will change the wording to "security mechanism".

Henning Rogge