[secdir] secdir review of draft-ietf-manet-rfc6622-bis

Stephen Hanna <shanna@juniper.net> Tue, 09 July 2013 20:53 UTC

Return-Path: <shanna@juniper.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id EE6B421E8053; Tue, 9 Jul 2013 13:53:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.638
X-Spam-Status: No, score=-101.638 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id g0hGkDADHjOS; Tue, 9 Jul 2013 13:53:45 -0700 (PDT)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com []) by ietfa.amsl.com (Postfix) with ESMTP id 8DF3821E8050; Tue, 9 Jul 2013 13:53:45 -0700 (PDT)
Received: from mail110-co9-R.bigfish.com ( by CO9EHSOBE010.bigfish.com ( with Microsoft SMTP Server id; Tue, 9 Jul 2013 20:53:44 +0000
Received: from mail110-co9 (localhost []) by mail110-co9-R.bigfish.com (Postfix) with ESMTP id A9B1F420098; Tue, 9 Jul 2013 20:53:44 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI
X-SpamScore: -1
X-BigFish: PS-1(zz4015Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1155h)
Received-SPF: pass (mail110-co9: domain of juniper.net designates as permitted sender) client-ip=; envelope-from=shanna@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ;
X-Forefront-Antispam-Report-Untrusted: CIP:; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT
Received: from mail110-co9 (localhost.localdomain []) by mail110-co9 (MessageSwitch) id 1373403222274648_28857; Tue, 9 Jul 2013 20:53:42 +0000 (UTC)
Received: from CO9EHSMHS013.bigfish.com (unknown []) by mail110-co9.bigfish.com (Postfix) with ESMTP id 3F5E5200E0; Tue, 9 Jul 2013 20:53:42 +0000 (UTC)
Received: from P-EMHUB01-HQ.jnpr.net ( by CO9EHSMHS013.bigfish.com ( with Microsoft SMTP Server (TLS) id; Tue, 9 Jul 2013 20:53:39 +0000
Received: from P-CLDFE01-HQ.jnpr.net ( by P-EMHUB01-HQ.jnpr.net ( with Microsoft SMTP Server (TLS) id; Tue, 9 Jul 2013 13:53:38 -0700
Received: from o365mail.juniper.net ( by o365mail.juniper.net ( with Microsoft SMTP Server id 14.1.355.2; Tue, 9 Jul 2013 13:53:37 -0700
Received: from ch1outboundpool.messaging.microsoft.com ( by o365mail.juniper.net ( with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 9 Jul 2013 13:57:22 -0700
Received: from mail31-ch1-R.bigfish.com ( by CH1EHSOBE003.bigfish.com ( with Microsoft SMTP Server id; Tue, 9 Jul 2013 20:53:37 +0000
Received: from mail31-ch1 (localhost []) by mail31-ch1-R.bigfish.com (Postfix) with ESMTP id D5F6860B54; Tue, 9 Jul 2013 20:53:36 +0000 (UTC)
Received: from mail31-ch1 (localhost.localdomain []) by mail31-ch1 (MessageSwitch) id 1373403215338679_22884; Tue, 9 Jul 2013 20:53:35 +0000 (UTC)
Received: from CH1EHSMHS021.bigfish.com (snatpool2.int.messaging.microsoft.com []) by mail31-ch1.bigfish.com (Postfix) with ESMTP id 4E9274C004E; Tue, 9 Jul 2013 20:53:35 +0000 (UTC)
Received: from SN2PRD0510HT002.namprd05.prod.outlook.com ( by CH1EHSMHS021.bigfish.com ( with Microsoft SMTP Server (TLS) id; Tue, 9 Jul 2013 20:53:32 +0000
Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([]) by SN2PRD0510HT002.namprd05.prod.outlook.com ([]) with mapi id 14.16.0329.000; Tue, 9 Jul 2013 20:53:26 +0000
From: Stephen Hanna <shanna@juniper.net>
To: The IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-manet-rfc6622bis.all@tools.ietf.org" <draft-ietf-manet-rfc6622bis.all@tools.ietf.org>
Thread-Topic: secdir review of draft-ietf-manet-rfc6622-bis
Thread-Index: Ac585lquiSITc2udRvyhyrd4ww7TEQ==
Date: Tue, 9 Jul 2013 20:53:25 +0000
Message-ID: <F1DFC16DCAA7D3468651A5A776D5796E1AA5D04B@SN2PRD0510MB372.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-OriginatorOrg: juniper.net
Subject: [secdir] secdir review of draft-ietf-manet-rfc6622-bis
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jul 2013 20:54:00 -0000

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. And I apologize
for missing the IETF Last Call deadline with this email.

In my view, this document is Not Ready.

This document obsoletes RFC 6622 but the text is confusing.
Instead of having one section that explains what changed
and the rest of the document just saying how it is now (as
if this document is an RFC), the text is forever referring
to the old RFC. For example, "This document reports previously
assigned TLV types (from [RFC6622]) from the registries
defined for Packet, Message, and Address Block TLVs in
[RFC5444]." What do you mean "reports"? This document
should stand on its own and only refer to RFC 6622 in
a few places since RFC 6622 will be obsolete once this
document is adopted. Otherwise, you're going to need to
add a normative reference to an obsolete RFC!

Section 1 contains these contradictory sentences:

   This document retains the IANA registries, defined in [RFC6622], for
   recording code points for ICV calculations, and requests an
   additional allocation from each these registries.  This document
   retains the IANA registries, defined in [RFC6622], for recording code
   points for timestamps, hash-functions, and cryptographic functions,
   but does not request any additional allocations from these

To resolve IANA's confusion, I suggest that the
IANA Considerations section state how things will
be after this document is adopted and also include
a section in square brackets with clear instructions
about what IANA should change relative to what they
have now in their registries. The section in square
brackets can be marked for deletion by the RFC editor.

Changing the name of existing TLVs is confusing!
I guess I see why you changed "Packet ICV TLV" to
"ICV Packet TLV" but it's still confusing. You
should at least mention this change in the section
that lists changes since the last version. And
you should search your draft for instances of the
old names ("Packet ICV TLV", "Packet TIMESTAMP TLV",
and so on). There are still some of them left.

I see that you changed the normative requirements
in some places to make them more strict. For example,
you changed a SHOULD to a MUST in section 9.2. That's
OK if there's a good reason but this may cause
implementations that comply with RFC 6622 to not
comply with this new version. Therefore, you should
mention any such changes in the "What Changed" section.
People who implemented the old version will want to
know what they need to change in their implementation.

Although this document includes algorithm identifiers
for RSA and DSA, there's no provision for conveying
certificates. Perhaps the recipient is expected to
already have those certificates on hand and to find
them somehow (based on the Message Originator Address
and the Key Identifier?). If the authors really intend
for these algorithms to be useful, they should describe
how certificates are handled.

At first, I thought there were not Mandatory-To-Implement
(MTI) algorithms in this document. Later, I learned that
OLSRv2 says that all implementations of that document
MUST implement draft-ietf-manet-nhdp-olsrv2-sec-03,
which makes certain algorithms in RFC6622bis mandatory.
RFC 6622bis should refer to draft-ietf-manet-nhdp-olsrv2-sec-03
and mention that it makes some of the algorithms in
RFC 6622bis mandatory to implement.

Finally, I would like to point out that implementing
draft-ietf-manet-nhdp-olsrv2-sec-03 (which seems to
be mandatory for OLSRv2 implementations) means that
the ICV uses a "secret key shared by all routers".
If any router is compromised, this shared key will
be compromised as well so the attacker will be able
to forge or modify OLSRv2 packets. Essentially, the
compromise of any router will compromise the entire
network. Such a security model is not suitable for
use on the Internet. Therefore, I suggest that OLSRv2
and all the associated documents be published with
Experimental status. If that is not possible, they
should be published with an Applicability Statement
limiting their use to networks where such a security
flaw is acceptable.