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

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

Return-Path: <shanna@juniper.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 952DF21F9C4C; Tue, 9 Jul 2013 14:30:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.581
X-Spam-Level:
X-Spam-Status: No, score=-99.581 tagged_above=-999 required=5 tests=[AWL=-2.114, BAYES_00=-2.599, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72nulnpZ-Cvh; Tue, 9 Jul 2013 14:30:00 -0700 (PDT)
Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0253.outbound.messaging.microsoft.com [213.199.154.253]) by ietfa.amsl.com (Postfix) with ESMTP id A369F21F9C41; Tue, 9 Jul 2013 14:29:57 -0700 (PDT)
Received: from mail29-db9-R.bigfish.com (10.174.16.227) by DB9EHSOBE027.bigfish.com (10.174.14.90) with Microsoft SMTP Server id 14.1.225.22; Tue, 9 Jul 2013 21:29:56 +0000
Received: from mail29-db9 (localhost [127.0.0.1]) by mail29-db9-R.bigfish.com (Postfix) with ESMTP id 861FF140131; Tue, 9 Jul 2013 21:29:56 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI
X-SpamScore: -23
X-BigFish: VPS-23(zz9371I542I4015Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1155h)
Received-SPF: pass (mail29-db9: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=shanna@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ;
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT
Received: from mail29-db9 (localhost.localdomain [127.0.0.1]) by mail29-db9 (MessageSwitch) id 1373405394526506_4561; Tue, 9 Jul 2013 21:29:54 +0000 (UTC)
Received: from DB9EHSMHS027.bigfish.com (unknown [10.174.16.228]) by mail29-db9.bigfish.com (Postfix) with ESMTP id 71CDF300031; Tue, 9 Jul 2013 21:29:54 +0000 (UTC)
Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.53) by DB9EHSMHS027.bigfish.com (10.174.14.37) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 9 Jul 2013 21:29:53 +0000
Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 9 Jul 2013 14:29:39 -0700
Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Tue, 9 Jul 2013 14:29:38 -0700
Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.182) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 9 Jul 2013 14:33:23 -0700
Received: from mail122-ch1-R.bigfish.com (10.43.68.229) by CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id 14.1.225.22; Tue, 9 Jul 2013 21:29:38 +0000
Received: from mail122-ch1 (localhost [127.0.0.1]) by mail122-ch1-R.bigfish.com (Postfix) with ESMTP id 05C723201C2; Tue, 9 Jul 2013 21:29:38 +0000 (UTC)
Received: from mail122-ch1 (localhost.localdomain [127.0.0.1]) by mail122-ch1 (MessageSwitch) id 1373405375303019_5546; Tue, 9 Jul 2013 21:29:35 +0000 (UTC)
Received: from CH1EHSMHS024.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230]) by mail122-ch1.bigfish.com (Postfix) with ESMTP id 3C1174A007D; Tue, 9 Jul 2013 21:29:35 +0000 (UTC)
Received: from SN2PRD0510HT001.namprd05.prod.outlook.com (157.56.234.117) by CH1EHSMHS024.bigfish.com (10.43.70.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 9 Jul 2013 21:29:34 +0000
Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.9.180]) by SN2PRD0510HT001.namprd05.prod.outlook.com ([10.255.116.36]) with mapi id 14.16.0329.000; Tue, 9 Jul 2013 21:29:33 +0000
From: Stephen Hanna <shanna@juniper.net>
To: The IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-manet-rfc6622-bis.all@tools.ietf.org" <draft-ietf-manet-rfc6622-bis.all@tools.ietf.org>
Thread-Topic: RESEND: secdir review of draft-ietf-manet-rfc6622-bis
Thread-Index: AQHOfOtnTP8JImNHZEu4EyoEiBOZiQ==
Date: Tue, 9 Jul 2013 21:29:32 +0000
Message-ID: <F1DFC16DCAA7D3468651A5A776D5796E1AA5D150@SN2PRD0510MB372.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.232.2]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
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
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Subject: [secdir] RESEND: 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 21:30:06 -0000

I left out a hyphen in the email alias for the draft
authors. Sorry about that!

Thanks,

Steve

-----Original Message-----
From: secdir-bounces@ietf.org [mailto:secdir-bounces@ietf.org] On Behalf Of Stephen Hanna
Sent: Tuesday, July 09, 2013 4:53 PM
To: The IESG; secdir@ietf.org; draft-ietf-manet-rfc6622bis.all@tools.ietf.org
Subject: [secdir] secdir review of draft-ietf-manet-rfc6622-bis

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

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.

Thanks,

Steve



_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview