[secdir] secdir review of draft-ietf-opsec-igp-crypto-requirements
Samuel Weiler <weiler@watson.org> Wed, 15 September 2010 18:13 UTC
Return-Path: <weiler@watson.org>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 050CC3A696B; Wed, 15 Sep 2010 11:13:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.859
X-Spam-Level:
X-Spam-Status: No, score=-1.859 tagged_above=-999 required=5 tests=[AWL=0.740, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8hesBnSQV+l; Wed, 15 Sep 2010 11:13:29 -0700 (PDT)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 8DB133A6848; Wed, 15 Sep 2010 11:13:29 -0700 (PDT)
Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id o8FIDs59013201; Wed, 15 Sep 2010 14:13:54 -0400 (EDT) (envelope-from weiler@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id o8FIDrQA013198; Wed, 15 Sep 2010 14:13:53 -0400 (EDT) (envelope-from weiler@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Wed, 15 Sep 2010 14:13:53 -0400
From: Samuel Weiler <weiler@watson.org>
To: ietf@ietf.org, secdir@ietf.org, draft-ietf-opsec-igp-crypto-requirements.all@tools.ietf.org
Message-ID: <alpine.BSF.2.00.1009151357390.4814@fledge.watson.org>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Wed, 15 Sep 2010 14:13:54 -0400 (EDT)
Subject: [secdir] secdir review of draft-ietf-opsec-igp-crypto-requirements
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 15 Sep 2010 18:13:41 -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 an informational document that appearently recaps requirement levels for implementation and use of crypto algorithms for hop-by-hop authentication of routing data. Assuming that no requirements are being changed, I have no objections to the security considerations analysis, but I do have editorial comments. I got lost as to the purpose of this doc. Please reword the abstract and intro to make it clear that you're merely recapping requirements, not setting them (if that is indeed true). Is there a way to present this information more compactly? I suggest a table with routing protocol on one axis, crypto suite on another, and requirement status in the elements (perhaps with a cite to the doc that sets the requirement). You might separely say "MANDATORY to implement, OPTIONAL to use, NOT SUGGESTED for use". You could also put suggestions and speculation about the future in the same table, though you may need to define some terms. And it needs to be clear when this doc diverges from past ones or makes a new statement. I have not gone back through the previous docs to confirm that this doc isn't changing anything. I see a whole bunch of lower case "may" and "should", and I'm wondering what to make of them. In describing each routing protocol's authentication options, it would be helpful to say whether there's any in-band negotiation available. If so, more needs to be said about that in the security considerations. If not, it should be documented here. I don't need to hear three or four separate times that cleartext passwords are bad. Minor: remove citations from the abstract (per rfc editor policy). -- Sam
- [secdir] secdir review of draft-ietf-opsec-igp-cr… Samuel Weiler
- Re: [secdir] secdir review of draft-ietf-opsec-ig… Joel Jaeggli
- Re: [secdir] secdir review of draft-ietf-opsec-ig… Bhatia, Manav (Manav)
- Re: [secdir] secdir review of draft-ietf-opsec-ig… Samuel Weiler
- Re: [secdir] secdir review of draft-ietf-opsec-ig… Bhatia, Manav (Manav)