[secdir] secdir review of draft-ietf-karp-ops-model-07

Radia Perlman <radiaperlman@gmail.com> Wed, 14 August 2013 05:02 UTC

Return-Path: <radiaperlman@gmail.com>
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 A2DB811E80F0; Tue, 13 Aug 2013 22:02:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 JIuFDwXZVj9G; Tue, 13 Aug 2013 22:02:39 -0700 (PDT)
Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF1121F9C7B; Tue, 13 Aug 2013 22:02:39 -0700 (PDT)
Received: by mail-lb0-f175.google.com with SMTP id 13so6509149lba.34 for <multiple recipients>; Tue, 13 Aug 2013 22:02:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Phb9D1FyUf3vlPOCvs/OMkvjJY6SrRaS3QffkVtVGbo=; b=YwXl4DkU9VK2mtlzBcSJUm1fRcWLJk6l0k57VcxU/2Zs/pWg/x3dqGnCvf2ARyrz+P Pq4WG2OaUGqRdzkyiotna9hBEWoI/LN7GExVVPz4P/0kOU+Mliz6ZQOjwlMamy6xxB8R sqTldHiAKQTKatUxxl2QTs2DQpiCIF/eDileHzwxlDGemCCzGn0REdigYINfuLpovieH 5w4PCrf7OR4zacxLq3TNbuFdWWyZ8hIhuNHKupZ60C5Y3vgHa5Scu+bt0c5oqX6YcKhQ iBoRmGv3y3jbTA4aYQUicFNuEMb/mB4e6/+kJtM+kezq8NmR2/i+KJqi3G3nA2wtAtd7 edig==
MIME-Version: 1.0
X-Received: by 10.112.149.197 with SMTP id uc5mr6406957lbb.19.1376456558125; Tue, 13 Aug 2013 22:02:38 -0700 (PDT)
Received: by 10.112.22.201 with HTTP; Tue, 13 Aug 2013 22:02:38 -0700 (PDT)
Date: Tue, 13 Aug 2013 22:02:38 -0700
Message-ID: <CAFOuuo5cnWn8C6d+_ihA06Pc+gTP6jLgvuMXvJwrAwci12Pv-A@mail.gmail.com>
From: Radia Perlman <radiaperlman@gmail.com>
To: The IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-karp-ops-model.all@tools.ietf.org
Content-Type: multipart/alternative; boundary="047d7b343cd232296c04e3e144cf"
Subject: [secdir] secdir review of draft-ietf-karp-ops-model-07
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: Wed, 14 Aug 2013 05:02:40 -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.

This is a useful document as an informational RFC. The technical content is
interesting and useful.

I think the document would be much improved with an introduction about what
is different for "routing protocol security" rather than, say, an endnode
authenticating to an access point, or nodes forming a peer relationship in
an overlay network.  So, for instance, "normal security issues" (i.e.,
outside the scope of KARP) might assume the network is up, so that it's
possible to get CRLs, or be available to be managed, whereas perhaps KARP
is targetting cases which depend on less infrastructure.  It would be nice
if this document were to have an introduction that talks about things like
that.

As for typos...3rd line up from bottom of page 14 has a glitch involving a
bunch of spaces and an extra comma after the word "peers".  And I can't
parse the last sentence of the 1st paragraph of section 7. "...complexity
of and update and risk...."

Speaking of PKI...the document talks about certificates expiring, but not
being revoked (CRL, OCSP).

Radia