From ops-area-bounces@ietf.org Sun Jan 4 13:14:50 2009 Return-Path: X-Original-To: ops-area-archive@optimus.ietf.org Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 230E93A698E; Sun, 4 Jan 2009 13:14:50 -0800 (PST) X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FF993A698E for ; Sun, 4 Jan 2009 13:14:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 Wgf5gaYSOAC1 for ; Sun, 4 Jan 2009 13:14:48 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id D45183A6920 for ; Sun, 4 Jan 2009 13:14:48 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so6393620rvf.49 for ; Sun, 04 Jan 2009 13:14:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:content-type :content-transfer-encoding; bh=CmdtTB6rWcrm5/kEhQ626hi6bffE5jY4A2Aj7WFfx1c=; b=UoBbF4QEbkJtoKFLSOENRyOracm+tcGCxy5XrKwSInhmXTcdSLbhy7+WjsfQzS1pSY hUVp7TPbDxqzC18wQgoHAZqvRUy+OBTuiREhlP1GL/cpdhv9gmpgWphqN1J5quqmO5l5 7EWpVuLQpuFwNYE6nltFgdvorDZpShwvTsItg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:content-type:content-transfer-encoding; b=F2mgZYBkVrUoKQwdvRjTZZkBMMIPvw8ZPntQ8LUfG4a9qzkAbqsjWF9xl5nJ0FV7P8 CsWXNipVC9MIkni/Np/6ekDJRt2vA+rYzIHT/+QYvaCAMbgQsA6r8nSuLZXs+SV3oLif dlCsy3+CzAYOpX3eI4pvan9rHelTcCO+CEK+w= Received: by 10.140.178.10 with SMTP id a10mr9995433rvf.199.1231103675485; Sun, 04 Jan 2009 13:14:35 -0800 (PST) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id f21sm52063594rvb.7.2009.01.04.13.14.34 (version=SSLv3 cipher=RC4-MD5); Sun, 04 Jan 2009 13:14:35 -0800 (PST) Message-ID: <496126B8.60400@gmail.com> Date: Mon, 05 Jan 2009 10:14:32 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ops-area@ietf.org Cc: RJ Atkinson , "Flinck, Hannu" Subject: [OPS-AREA] Renumbering needs work X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org A draft on this topic has been updated: http://www.ietf.org/internet-drafts/draft-carpenter-renum-needs-work-01.txt Comments and discussion are invited on the OPS Area list, ops-area@ietf.org Brian Carpenter Ran Atkinson Hannu Flinck P.S. Apologies if you receive multiple copies, but that seems preferable to cross-posting to multiple lists. _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Jan 7 13:32:56 2009 Return-Path: X-Original-To: ops-area-archive@optimus.ietf.org Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 120BC3A695A; Wed, 7 Jan 2009 13:32:56 -0800 (PST) X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FCCF3A687C for ; Wed, 7 Jan 2009 13:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 cX2pIaKxyROF for ; Wed, 7 Jan 2009 13:32:53 -0800 (PST) Received: from smtp4.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 388533A689D for ; Wed, 7 Jan 2009 13:32:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=uclouvain.be; h= message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; q= dns/txt; s=selucl; bh=UkpIuRHfhrgUROvIZO1P2FXgNpU=; b=DAOT/S2+xO w0sRCkvTG7wBkINg8DZEinUfKy0oQ2WPsrwA3vsOb6dzYg+fvrH4FdwaWiNkGSLK bInLhA7bP+BBHRXrLvhpHLWYlgOlPfshBPAGLcTDCIkxOs7l2K1HvvypIGfI+n+L tXyXv/nq2x5jV6YNP+yw0McAiI2QD10n8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=uclouvain.be; h=message-id:date: from:reply-to:mime-version:to:cc:subject:references:in-reply-to: content-type:content-transfer-encoding; q=dns; s=selucl; b=Pweoo VZa8dIyPFfBeVphCM6XxApS83Fu/etMKomqFf0/NUG5H4WQyk8vFHR1x6gyc2H/i WNBAC4/jv6doAfl+AXD0KVOMjMaW/Y40QA3L69LcFSkZmS5unzdoeeEENwdIP/Z1 /PqhW/wyPRP2bO39iVUtaNSo8mjjqWJ9k9Hpqg= Received: from mbpobo.local (ip-83-134-217-251.dsl.scarlet.be [83.134.217.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp4.sgsi.ucl.ac.be) by smtp4.sgsi.ucl.ac.be (Postfix) with ESMTPSA; Wed, 7 Jan 2009 22:32:45 +0100 (CET) Message-ID: <49651F6B.3070004@uclouvain.be> Date: Wed, 07 Jan 2009 22:32:27 +0100 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: ops-area@ietf.org References: <4961273D.6090209@gmail.com> In-Reply-To: <4961273D.6090209@gmail.com> X-Enigmail-Version: 0.95.7 X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 2CD33F1A30.BD385 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: RJ Atkinson , Damien Leroy Subject: Re: [OPS-AREA] [rrg] Renumbering needs work X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org Brian, > A draft on this topic has been updated: > http://www.ietf.org/internet-drafts/draft-carpenter-renum-needs-work-01.txt > > Comments and discussion are invited on the OPS Area list, > ops-area@ietf.org I completely agree that renumbering needs more work. For IPv4, I guess that this will always remain difficult. For IPv6, as most networks have still not deployed IPv6 and there are more addresses, there is still some hope. I think that a key point for renumbering is that it should be planned from day one when the first lines of the configuration of a network or network service are written. Every IPv6 operator should expect that he will have to renumber his network one day and should plan for this event. In most cases, there numbering will be due to economic factors such as merging or acquisition. An important recommendation in the draft (section 5.3.4) is that the network configuration should be based on databases and scripts/automated tools. The database stores all the information about the network and the tools derive the configuration from the database. As you note, this way of configuring networks is not the most widespread, but is being used by more network operators. It is also possible to prepare network configurations so that renumbering will be much easier. We have recently proposed a tool based on macros that allows to ease the reconfiguration of a network after a renumbering event. We applied the tool on real DNS, firewall and DHCP configuration as case studies, but it could also be applied to the configurations of routers or other services. More detailed informations about this work are available in http://inl.info.ucl.ac.be/publications/preparing-network-configurations-ipv6-renumbering Best regards, Olivier Bonaventure -- http://inl.info.ucl.ac.be , UCLouvain, Belgium _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Sun Jan 18 00:27:03 2009 Return-Path: X-Original-To: ops-area-archive@optimus.ietf.org Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FCA83A68EC; Sun, 18 Jan 2009 00:27:03 -0800 (PST) X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91F0A3A68EC; Sun, 18 Jan 2009 00:27:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 yZPKu7ziG0kb; Sun, 18 Jan 2009 00:27:01 -0800 (PST) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 9E6C93A6882; Sun, 18 Jan 2009 00:27:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,283,1231131600"; d="url'?txt'?scan'208";a="158184333" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 18 Jan 2009 03:26:45 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 18 Jan 2009 03:26:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C97946.734AB158" Date: Sun, 18 Jan 2009 09:26:22 +0100 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-gray-mpls-tp-nm-req-02.txt Thread-Index: Acl4z9A9R6RAmPifQrWgoPWEla8fXAAdlROw From: "Romascanu, Dan (Dan)" To: , "ops-area (IETF)" Cc: Scott.Mansfield@Ericsson.com, hklam@Alcatel-Lucent.com, Eric Gray Subject: [OPS-AREA] FW: I-D Action:draft-gray-mpls-tp-nm-req-02.txt X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C97946.734AB158 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe that this I-D deserves some scrutiny from the OPS folks.=20 Dan -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Saturday, January 17, 2009 8:15 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-gray-mpls-tp-nm-req-02.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MPLS TP Network Management Requirements Author(s) : S. Mansfield, et al. Filename : draft-gray-mpls-tp-nm-req-02.txt Pages : 15 Date : 2009-01-17 This document specifies the requirements necessary to manage the=20 elements and networks that support an MPLS Transport Profile=20 (MPLS-TP). This document is a product of a joint International=20 Telecommunications Union - Telecommunications Standardization=20 Sector (ITU-T) and Internet Engineering Task Force (IETF) effort=20 to include a MPLS Transport Profile within the IETF MPLS=20 architecture. The requirements are driven by the management=20 functionality needs defined by ITU-T for packet transport=20 networks.=20 Gray, et al Expires July, 2009 [page 1]=20 Internet-Draft MPLS-TP NM Requirements January, 2009 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gray-mpls-tp-nm-req-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C97946.734AB158 Content-Type: application/octet-stream; name="draft-gray-mpls-tp-nm-req-02.URL" Content-Transfer-Encoding: base64 Content-Description: draft-gray-mpls-tp-nm-req-02.URL Content-Disposition: attachment; filename="draft-gray-mpls-tp-nm-req-02.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1ncmF5LW1wbHMtdHAtbm0tcmVxLTAyLnR4dA0K ------_=_NextPart_001_01C97946.734AB158 Content-Type: text/plain; name="ATT968708.txt" Content-Transfer-Encoding: base64 Content-Description: ATT968708.txt Content-Disposition: attachment; filename="ATT968708.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K ------_=_NextPart_001_01C97946.734AB158 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area ------_=_NextPart_001_01C97946.734AB158-- From ops-area-bounces@ietf.org Sun Jan 18 00:57:24 2009 Return-Path: X-Original-To: ops-area-archive@optimus.ietf.org Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6189728C161; Sun, 18 Jan 2009 00:57:24 -0800 (PST) X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 425BE3A6924; Sun, 18 Jan 2009 00:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 0x1jhXIZ8Xqm; Sun, 18 Jan 2009 00:57:21 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 9A91B3A67D2; Sun, 18 Jan 2009 00:57:20 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,283,1231131600"; d="scan'208,223";a="134403749" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 18 Jan 2009 03:57:02 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 18 Jan 2009 03:57:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 18 Jan 2009 09:56:51 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BOF requests and OPS open area meeting at IETF-74 Thread-Index: Acl5SrRgCTE+f0rqSoaYG501AQC32A== From: "Romascanu, Dan (Dan)" To: "ops-area (IETF)" Cc: aaa-doctors@ietf.org, "MIB Doctors \(E-mail\)" , ops-dir@ietf.org Subject: [OPS-AREA] BOF requests and OPS open area meeting at IETF-74 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org >From the list of cut-off dates of IETF-74: > February 2, 2009 Monday - Cutoff date for requests to Area Directors to schedule BOFs at 17:00 PST (01:00 Tuesday, February 3 UTC/GMT). To request a BOF, please see instructions on Requesting a BOF. > February 9, 2009 Monday - Cutoff date for Area Directors to approve BOF requests at 17:00 PST (01:00 Tuesday, February 10 UTC/GMT). In between the IAB and IESG telechat that will review the BOF requests is scheduled for Thursday 2/5. If there are plans to submit any such request in the OPS Area, Ron and me would be interested to hear as soon as possible. Also, we have asked for a 2-hour meeting slot for the OPS Open Area meeting in San Francisco. Please send us any requests for mini-BOFs, presentations or items for discussion at the open area meeting. Thanks and Regards, Ron and Dan _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area From ietfdbh@comcast.net Wed Feb 4 07:47:15 2009 Return-Path: X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B16CF3A69F6 for ; Wed, 4 Feb 2009 07:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.476 X-Spam-Level: X-Spam-Status: No, score=-1.476 tagged_above=-999 required=5 tests=[AWL=-0.736, BAYES_20=-0.74] 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 Eqgl8GQwHK9Z for ; Wed, 4 Feb 2009 07:47:15 -0800 (PST) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id C99903A6941 for ; Wed, 4 Feb 2009 07:47:14 -0800 (PST) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA08.westchester.pa.mail.comcast.net with comcast id BoRZ1b00816LCl058rmw9L; Wed, 04 Feb 2009 15:46:56 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA06.westchester.pa.mail.comcast.net with comcast id Brml1b00V0UQ6dC3Srml42; Wed, 04 Feb 2009 15:46:45 +0000 From: "David Harrington" To: "'ops-area \(IETF\)'" Date: Wed, 4 Feb 2009 10:46:54 -0500 Message-ID: <051c01c986df$ce1b89b0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcmG383FnizJvCtzRlGxWt2+OoWVPA== Subject: [OPS-AREA] Issue 1: should we have a security boilerplate for management protocols and data models? X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 15:47:15 -0000 Hi, I plan to propose some replacement text for the current boilerplate for secure management protocols, and for the sensitivity of data model objects. I think the debate aboiut whether we should have boilerplate is a different issue than what the replacement text should be, so this thread is for tha debate about whether a boilerplate is desirable. Please keep the threads separate. now, my opinion on whether to have boilerplate: I have seen editors try to write their own recommendations for securing management using SNMPv3 or other secure protocol, and they typically get the text way wrong. I think it is important for us to provide accurate text for them to use. I personally find the existing MIB object sensitivity boilerplate longer than I like, and I think we should consider whether it can be shortened, but I think it is important that the security considerations for a data model document include a discussion of the sensitivity, and potential problems, associated with the data model objects. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com From ietfdbh@comcast.net Wed Feb 4 07:47:43 2009 Return-Path: X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 728573A6A60 for ; Wed, 4 Feb 2009 07:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207, 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 x-KHK-iH--GX for ; Wed, 4 Feb 2009 07:47:42 -0800 (PST) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 674CE3A6941 for ; Wed, 4 Feb 2009 07:47:42 -0800 (PST) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA04.westchester.pa.mail.comcast.net with comcast id Bo7X1b00D0SCNGk54rnP2m; Wed, 04 Feb 2009 15:47:23 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA09.westchester.pa.mail.comcast.net with comcast id BrnP1b00Y0UQ6dC3VrnPFg; Wed, 04 Feb 2009 15:47:23 +0000 From: "David Harrington" To: "'ops-area \(IETF\)'" Date: Wed, 4 Feb 2009 10:47:22 -0500 Message-ID: <051d01c986df$de905640$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcmG395EhEi4bk55TFmd0N81G5eh3Q== Subject: [OPS-AREA] Issue 2: replacement text for secure management protocol boilerplate X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 15:47:43 -0000 Hi, The IETF has been in the process of changing from a managenent strategy that basically said "write a MIB" (and presumably use SNMP to access it) to a strategy that says "consider the nature of the management functionality required, and select an appropriate protocol to address the requirements. I think the existing boilerplate should be modified to reflect this change. OLD: SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. NEW: Any protocol used to manage a device should support authentication, encryption, integrity checking, and control of access to the management information. It is RECOMMENDED that operators deploy an IETF standard protocol for secure management, such as Netconf over SSH [RFC4742] or SNMPv3 [RFC3410] or syslog over TLS [RFC5425]. Operators SHOULD enable cryptographic security and ensure that the server/agent giving access to management information is properly configured to give access only to those principals (users) that have legitimate rights to read/create/change/delete the information. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com From ietfdbh@comcast.net Wed Feb 4 07:47:48 2009 Return-Path: X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE8833A6C69 for ; Wed, 4 Feb 2009 07:47:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.203, 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 cAAKAdKZB5Nr for ; Wed, 4 Feb 2009 07:47:48 -0800 (PST) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id BAE3D3A6BFE for ; Wed, 4 Feb 2009 07:47:47 -0800 (PST) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA04.westchester.pa.mail.comcast.net with comcast id Bmia1b00C0mv7h054rnV6D; Wed, 04 Feb 2009 15:47:29 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA11.westchester.pa.mail.comcast.net with comcast id BrnV1b00A0UQ6dC3XrnVj7; Wed, 04 Feb 2009 15:47:29 +0000 From: "David Harrington" To: "'ops-area \(IETF\)'" Date: Wed, 4 Feb 2009 10:47:28 -0500 Message-ID: <051e01c986df$e2075490$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcmG3+G7iBIcWVVrR8aFTjLe0a+Xwg== Subject: [OPS-AREA] Issue 3: replacement boilerplate for management object sensitivity X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 15:47:49 -0000 Hi, There is an existing boilerplate for the security consideration section of a document defining objects of management information. This boilerplate text discusses the read and write sensitivity of management information in the data model. The current text is SMIv2 oriented. As the IETF moves to a strategy of supporting multiple languages for defining management data models, the boilerplate text should be updated to address the sensitivity of the information, regardless of the language used to define the information. (This discussion is about how to update the existing boilerplate, not whether to have such a boilerplate. Please see issue 1 if you think we should not have boilerplate.) OLD: -- if you have any read-write and/or read-create objects, please -- describe their specific sensitivity or vulnerability. -- RFC 2669 has a very good example. There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: -- else if there are no read-write objects in your MIB module There are no management objects defined in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create. So, if this MIB module is implemented correctly, then there is no risk that an intruder can alter or create any management objects of this MIB module via direct SNMP SET operations. -- for all MIB modules you must evaluate whether any readable objects -- are sensitive or vulnerable (for instance, if they might reveal -- customer information or violate personal privacy laws such as -- those of the European Union if exposed to unathorized parties) Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: NEW: -- include this paragraph if the management information can be created, deleted, or modified: Some management information defined in this document can be created, deleted, or modified by one or more management protocols. Unauthorized or inappropriate modification could have a negative effect on network operations or security. -- include the following in all documents that define management information: The management information defined in this document can be considered sensitive or lead to network vulnerabilities in some environments. It is important to control access to this information and possibly to encrypt the information when sending the information over a network using a management protocol, to prevent unauthorized or inappropriate exposure of this information. Following is a list of the potentially sensitive information, and why this information is sensitive: ---- comments welcome David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com From randy_presuhn@mindspring.com Wed Feb 4 10:13:10 2009 Return-Path: X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93D053A686C for ; Wed, 4 Feb 2009 10:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=0.203, 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 n1kVdqA7snsq for ; Wed, 4 Feb 2009 10:13:09 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id BAD153A6843 for ; Wed, 4 Feb 2009 10:13:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=lqrE4K/3cPYmyAlPfQ67hDiYw7VPuPjcOzJp3z1DjpIK+BccK8r7Q/PR2FydVczD; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.6.31] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LUmEy-0003lA-0D for ops-area@ietf.org; Wed, 04 Feb 2009 13:12:48 -0500 Message-ID: <004401c986f4$238daf40$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "'ops-area \(IETF\)'" References: <051d01c986df$de905640$0600a8c0@china.huawei.com> Date: Wed, 4 Feb 2009 10:12:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f1732aca8b9c32088e74a2dbacc7bd51b3c5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.6.31 Subject: Re: [OPS-AREA] Issue 2: replacement text for secure management protocolboilerplate X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 18:13:10 -0000 Hi - > From: "David Harrington" > To: "'ops-area (IETF)'" > Sent: Wednesday, February 04, 2009 7:47 AM > Subject: [OPS-AREA] Issue 2: replacement text for secure management protocolboilerplate ... > NEW: > Any protocol used to manage a device should support authentication, > encryption, integrity checking, and control of access to the > management information. It is RECOMMENDED that operators deploy an > IETF standard protocol for secure management, such as Netconf over SSH > [RFC4742] or SNMPv3 [RFC3410] or syslog over TLS [RFC5425]. Operators > SHOULD enable cryptographic security and ensure that the server/agent > giving access to management information is properly configured to give > access only to those principals (users) that have legitimate rights to > read/create/change/delete the information. ... I think the last sentence isn't quite right for syslog and SNMP notification originators. It's true that that's how we handle the "giving access" part in VACM, but at the level of the cryptographic security happening during the actual transfer of the information (rather than the configuration of how the information is to be transferred) it's a different matter. Randy From randy_presuhn@mindspring.com Wed Feb 4 10:17:56 2009 Return-Path: X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A28BF3A69DA for ; Wed, 4 Feb 2009 10:17:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[AWL=-0.761, BAYES_20=-0.74] 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 HTtrAZYPC2ty for ; Wed, 4 Feb 2009 10:17:56 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id E92703A6964 for ; Wed, 4 Feb 2009 10:17:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Mh98NXUG+k2TGLhOkvouGkC88fdQv+q4RluABt8LydI9P7aX/HIawvunHc3C3uLa; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.6.31] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LUmJc-0008I3-5f for ops-area@ietf.org; Wed, 04 Feb 2009 13:17:36 -0500 Message-ID: <004901c986f4$cf21a280$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "'ops-area \(IETF\)'" References: <051e01c986df$e2075490$0600a8c0@china.huawei.com> Date: Wed, 4 Feb 2009 10:17:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f17369f1ab71e6f3845b92a5b6a058157954350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.6.31 Subject: Re: [OPS-AREA] Issue 3: replacement boilerplate for management objectsensitivity X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 18:17:56 -0000 Hi - > From: "David Harrington" > To: "'ops-area (IETF)'" > Sent: Wednesday, February 04, 2009 7:47 AM > Subject: [OPS-AREA] Issue 3: replacement boilerplate for management objectsensitivity ... > NEW: ... > Following is a list of the potentially sensitive information, and why > this information is sensitive: > > sensitive to modification and exposure> ... I prefer the approach of the old text, which split the information elements according to concern (modification or mere exposure), rather than lumping everything together like this, since separating them may help in security policy formulation and sanity checking. Randy From randy_presuhn@mindspring.com Wed Feb 4 10:23:12 2009 Return-Path: X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CECA3A6954 for ; Wed, 4 Feb 2009 10:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[AWL=0.277, 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 1Wop3VnpLfgJ for ; Wed, 4 Feb 2009 10:23:11 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 879203A6A45 for ; Wed, 4 Feb 2009 10:23:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ERDNViqElrIcOJaRBd5PsiYmOA1l+EpfqrU05aFay0/15c5op5BBxFGHBiuq+4Jl; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.6.31] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LUmOh-00088g-Vb for ops-area@ietf.org; Wed, 04 Feb 2009 13:22:52 -0500 Message-ID: <004e01c986f5$8b8aaac0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "'ops-area \(IETF\)'" References: <051c01c986df$ce1b89b0$0600a8c0@china.huawei.com> Date: Wed, 4 Feb 2009 10:22:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f173671dbb0b5492097b303483e3ecf4447d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.6.31 Subject: Re: [OPS-AREA] Issue 1: should we have a security boilerplate formanagement protocols and data models? X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 18:23:12 -0000 Hi - > From: "David Harrington" > To: "'ops-area (IETF)'" > Sent: Wednesday, February 04, 2009 7:46 AM > Subject: [OPS-AREA] Issue 1: should we have a security boilerplate formanagement protocols and data models? ... > I think the debate aboiut whether we should have boilerplate is a > different issue than what the replacement text should be, so this > thread is for tha debate about whether a boilerplate is desirable. ... While this is an admirable goal, I think it is premature. Does *anyone* have an idea of what *standardized* access control for netconf is going to look like? Though I know folks would like to make it simpler than VACM, until folks work through how access control interacts with augmentations and vendor extensions in that environment, I'd be very wary of trying to set out meta-policies (which is what the filled-in boilerplate will be) for that environment. Randy From ietfdbh@comcast.net Wed Feb 4 10:25:11 2009 Return-Path: X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92F5128C24F for ; Wed, 4 Feb 2009 10:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 SLHYi9nEspVF for ; Wed, 4 Feb 2009 10:25:09 -0800 (PST) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id 4B11628C1BB for ; Wed, 4 Feb 2009 10:25:09 -0800 (PST) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA08.westchester.pa.mail.comcast.net with comcast id Bp7e1b0030cZkys58uQqyj; Wed, 04 Feb 2009 18:24:50 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA10.westchester.pa.mail.comcast.net with comcast id BuQq1b00Y0UQ6dC3WuQqT6; Wed, 04 Feb 2009 18:24:50 +0000 From: "David Harrington" To: "'Randy Presuhn'" , "'ops-area \(IETF\)'" References: <051d01c986df$de905640$0600a8c0@china.huawei.com> <004401c986f4$238daf40$6801a8c0@oemcomputer> Date: Wed, 4 Feb 2009 13:24:49 -0500 Message-ID: <054701c986f5$dd5c1a00$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <004401c986f4$238daf40$6801a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcmG9DQKmkzkbjlxTtiMgUswHw3PtwAAQeyA Subject: Re: [OPS-AREA] Issue 2: replacement text for secure managementprotocolboilerplate X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 18:25:11 -0000 Hi, Would the following be better? "Operators SHOULD enable cryptographic security and ensure that the protocol giving access to management information is properly configured to give access only to those principals (users/applications) that have legitimate rights to read/create/change/delete the information." i.e., s:server/agent:protocol: s:(users):(users/applications)/ or does that get so diluted as to be meaningless? dbh > -----Original Message----- > From: ops-area-bounces@ietf.org > [mailto:ops-area-bounces@ietf.org] On Behalf Of Randy Presuhn > Sent: Wednesday, February 04, 2009 1:12 PM > To: 'ops-area (IETF)' > Subject: Re: [OPS-AREA] Issue 2: replacement text for secure > managementprotocolboilerplate > > Hi - > > > From: "David Harrington" > > To: "'ops-area (IETF)'" > > Sent: Wednesday, February 04, 2009 7:47 AM > > Subject: [OPS-AREA] Issue 2: replacement text for secure > management protocolboilerplate > ... > > NEW: > > Any protocol used to manage a device should support authentication, > > encryption, integrity checking, and control of access to the > > management information. It is RECOMMENDED that operators deploy an > > IETF standard protocol for secure management, such as > Netconf over SSH > > [RFC4742] or SNMPv3 [RFC3410] or syslog over TLS [RFC5425]. > Operators > > SHOULD enable cryptographic security and ensure that the > server/agent > > giving access to management information is properly > configured to give > > access only to those principals (users) that have > legitimate rights to > > read/create/change/delete the information. > ... > > I think the last sentence isn't quite right for syslog and > SNMP notification > originators. It's true that that's how we handle the "giving > access" part in > VACM, but at the level of the cryptographic security happening during > the actual transfer of the information (rather than the > configuration of how > the information is to be transferred) it's a different matter. > > Randy > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area > From ietfdbh@comcast.net Wed Feb 4 10:28:16 2009 Return-Path: X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B977B3A698E for ; Wed, 4 Feb 2009 10:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.403 X-Spam-Level: X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=0.196, 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 Cn0Ew-KcLGGT for ; Wed, 4 Feb 2009 10:28:15 -0800 (PST) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id A376F3A6954 for ; Wed, 4 Feb 2009 10:28:15 -0800 (PST) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA02.westchester.pa.mail.comcast.net with comcast id Boce1b00A0mv7h052uTxCV; Wed, 04 Feb 2009 18:27:57 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA11.westchester.pa.mail.comcast.net with comcast id BuTw1b00B0UQ6dC3XuTwhz; Wed, 04 Feb 2009 18:27:57 +0000 From: "David Harrington" To: "'Randy Presuhn'" , "'ops-area \(IETF\)'" References: <051e01c986df$e2075490$0600a8c0@china.huawei.com> <004901c986f4$cf21a280$6801a8c0@oemcomputer> Date: Wed, 4 Feb 2009 13:27:55 -0500 Message-ID: <054801c986f6$4c8967c0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <004901c986f4$cf21a280$6801a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcmG9N6CEqxIiUWFS3yQJZIwE87p7gAAR7qA Subject: Re: [OPS-AREA] Issue 3: replacement boilerplate for managementobjectsensitivity X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 18:28:16 -0000 Hi, > I prefer the approach of the old text, which split the > information elements > according to concern (modification or mere exposure), So would this work better? -- include this paragraph if the management information can be created, deleted, or modified: Some management information defined in this document can be created, deleted, or modified by one or more management protocols. Unauthorized or inappropriate modification could have a negative effect on network operations or security. -- include the following in all documents that define management information: The management information defined in this document can be considered sensitive or lead to network vulnerabilities in some environments. It is important to control access to this information and possibly to encrypt the information when sending the information over a network using a management protocol, to prevent unauthorized or inappropriate exposure of this information. Following is a list of the potentially sensitive information, and why this information is sensitive: dbh > -----Original Message----- > From: ops-area-bounces@ietf.org > [mailto:ops-area-bounces@ietf.org] On Behalf Of Randy Presuhn > Sent: Wednesday, February 04, 2009 1:17 PM > To: 'ops-area (IETF)' > Subject: Re: [OPS-AREA] Issue 3: replacement boilerplate for > managementobjectsensitivity > > Hi - > > > From: "David Harrington" > > To: "'ops-area (IETF)'" > > Sent: Wednesday, February 04, 2009 7:47 AM > > Subject: [OPS-AREA] Issue 3: replacement boilerplate for > management objectsensitivity > ... > > NEW: > ... > > Following is a list of the potentially sensitive > information, and why > > this information is sensitive: > > > > > sensitive to modification and exposure> > ... > > I prefer the approach of the old text, which split the > information elements > according to concern (modification or mere exposure), rather than > lumping everything together like this, since separating them may help > in security policy formulation and sanity checking. > > Randy > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area > From randy_presuhn@mindspring.com Wed Feb 4 10:29:00 2009 Return-Path: X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EBA43A698E for ; Wed, 4 Feb 2009 10:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=0.243, 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 LNRFoNL-Q3xe for ; Wed, 4 Feb 2009 10:28:59 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id ADD143A6954 for ; Wed, 4 Feb 2009 10:28:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=J6L+MmbJQwhk7/9/TGyosIEMXEHSb2NZ+cKIDOi1Mh426D6TVayW7aRLnj4j7pI0; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.6.31] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LUmUJ-00034G-Ja for ops-area@ietf.org; Wed, 04 Feb 2009 13:28:40 -0500 Message-ID: <007101c986f6$5ac4e620$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "'ops-area \(IETF\)'" References: <051d01c986df$de905640$0600a8c0@china.huawei.com> <004401c986f4$238daf40$6801a8c0@oemcomputer> <054701c986f5$dd5c1a00$0600a8c0@china.huawei.com> Date: Wed, 4 Feb 2009 10:28:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f173037d67c0d3a801f7ae156fe31a204944350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.6.31 Subject: Re: [OPS-AREA] Issue 2: replacement text for secure managementprotocolboilerplate X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 18:29:00 -0000 Hi - > From: "David Harrington" > To: "'Randy Presuhn'" ; "'ops-area (IETF)'" > Sent: Wednesday, February 04, 2009 10:24 AM > Subject: RE: [OPS-AREA] Issue 2: replacement text for secure managementprotocolboilerplate ... > Would the following be better? > > "Operators SHOULD enable cryptographic security and ensure that the > protocol giving access to management information is properly > configured to give access only to those principals > (users/applications) that have legitimate rights to > read/create/change/delete the information." > > i.e., > s:server/agent:protocol: > s:(users):(users/applications)/ > > or does that get so diluted as to be meaningless? I think it's better. To more explicitly address the syslog/notification cases, perhaps one could add "/receive" after "delete"? Randy From randy_presuhn@mindspring.com Wed Feb 4 10:30:24 2009 Return-Path: X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D53E33A6B8B for ; Wed, 4 Feb 2009 10:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.216, 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 V7ALCyBGdYZt for ; Wed, 4 Feb 2009 10:30:21 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 173AC3A6BD8 for ; Wed, 4 Feb 2009 10:30:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=AlnlHi2FniKQqTUfrJBpoIZ6uOSjDpQiQvqhZVQbDKcxGI6i2kRCnVO9XLIpZfc3; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.6.31] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LUmVd-0004eD-FT for ops-area@ietf.org; Wed, 04 Feb 2009 13:30:01 -0500 Message-ID: <007601c986f6$8bae42e0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "'ops-area \(IETF\)'" References: <051e01c986df$e2075490$0600a8c0@china.huawei.com> <004901c986f4$cf21a280$6801a8c0@oemcomputer> <054801c986f6$4c8967c0$0600a8c0@china.huawei.com> Date: Wed, 4 Feb 2009 10:29:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f17365ba6a9bd228688bb540611d55ff627f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.6.31 Subject: Re: [OPS-AREA] Issue 3: replacement boilerplate for managementobjectsensitivity X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 18:30:25 -0000 Hi - > From: "David Harrington" > To: "'Randy Presuhn'" ; "'ops-area (IETF)'" > Sent: Wednesday, February 04, 2009 10:27 AM > Subject: RE: [OPS-AREA] Issue 3: replacement boilerplate for managementobjectsensitivity > > Hi, > > > I prefer the approach of the old text, which split the > > information elements > > according to concern (modification or mere exposure), > > So would this work better? Yes, I think it's an improvement over the original proposal. Randy > -- include this paragraph if the management information can be > created, deleted, or modified: > > Some management information defined in this document can be > created, deleted, or modified by one or more management protocols. > Unauthorized or inappropriate modification could have a negative > effect on network operations or security. > > sensitive to modification> > > -- include the following in all documents that define management > information: > > The management information defined in this document can be > considered sensitive or lead to network vulnerabilities in some > environments. It is important to control access to this information > and possibly to encrypt the information when sending the information > over a network using a management protocol, to prevent unauthorized or > inappropriate exposure of this information. > > Following is a list of the potentially sensitive information, and why > this information is sensitive: > > sensitive to exposure> > > > dbh > > > -----Original Message----- > > From: ops-area-bounces@ietf.org > > [mailto:ops-area-bounces@ietf.org] On Behalf Of Randy Presuhn > > Sent: Wednesday, February 04, 2009 1:17 PM > > To: 'ops-area (IETF)' > > Subject: Re: [OPS-AREA] Issue 3: replacement boilerplate for > > managementobjectsensitivity > > > > Hi - > > > > > From: "David Harrington" > > > To: "'ops-area (IETF)'" > > > Sent: Wednesday, February 04, 2009 7:47 AM > > > Subject: [OPS-AREA] Issue 3: replacement boilerplate for > > management objectsensitivity > > ... > > > NEW: > > ... > > > Following is a list of the potentially sensitive > > information, and why > > > this information is sensitive: > > > > > > are > > > sensitive to modification and exposure> > > ... > > > > I prefer the approach of the old text, which split the > > information elements > > according to concern (modification or mere exposure), rather than > > lumping everything together like this, since separating them may > help > > in security policy formulation and sanity checking. > > > > Randy > > > > _______________________________________________ > > OPS-AREA mailing list > > OPS-AREA@ietf.org > > https://www.ietf.org/mailman/listinfo/ops-area > > > From ietfdbh@comcast.net Wed Feb 4 10:45:35 2009 Return-Path: X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0AB63A6A04 for ; Wed, 4 Feb 2009 10:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=0.193, 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 BexFujyI0IMh for ; Wed, 4 Feb 2009 10:45:34 -0800 (PST) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 698943A69E5 for ; Wed, 4 Feb 2009 10:45:34 -0800 (PST) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA09.westchester.pa.mail.comcast.net with comcast id Bmtn1b00717dt5G59ulFiP; Wed, 04 Feb 2009 18:45:15 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA13.westchester.pa.mail.comcast.net with comcast id BulF1b0070UQ6dC3ZulFax; Wed, 04 Feb 2009 18:45:15 +0000 From: "David Harrington" To: "'Randy Presuhn'" , "'ops-area \(IETF\)'" References: <051d01c986df$de905640$0600a8c0@china.huawei.com><004401c986f4$238daf40$6801a8c0@oemcomputer><054701c986f5$dd5c1a00$0600a8c0@china.huawei.com> <007101c986f6$5ac4e620$6801a8c0@oemcomputer> Date: Wed, 4 Feb 2009 13:45:14 -0500 Message-ID: <054f01c986f8$b76daf40$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <007101c986f6$5ac4e620$6801a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcmG9mpIyX8OnTJKQ6WRwCZPaIQizQAAeoZA Subject: Re: [OPS-AREA] Issue 2: replacement text for securemanagementprotocolboilerplate X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 18:45:36 -0000 Hi, I think the original formulation could lead one to assume the access control was "standardized" as part of the standard protocol. I think it might be clearer to separate this into two separate recommendations: "Any protocol used to manage a device should support authentication, encryption, integrity checking, and control of access to the management information. It is RECOMMENDED that operators deploy an IETF standard protocol for secure management, such as Netconf over SSH [RFC4742] or SNMPv3 [RFC3410] or syslog over TLS [RFC5425]. Operators SHOULD enable cryptographic security and ensure that the protocol giving access to management information is properly configured to give access only to those principals (users/applications) that have legitimate rights to create/change/delete/read/receive the information." dbh > -----Original Message----- > From: ops-area-bounces@ietf.org > [mailto:ops-area-bounces@ietf.org] On Behalf Of Randy Presuhn > Sent: Wednesday, February 04, 2009 1:28 PM > To: 'ops-area (IETF)' > Subject: Re: [OPS-AREA] Issue 2: replacement text for > securemanagementprotocolboilerplate > > Hi - > > > From: "David Harrington" > > To: "'Randy Presuhn'" ; > "'ops-area (IETF)'" > > Sent: Wednesday, February 04, 2009 10:24 AM > > Subject: RE: [OPS-AREA] Issue 2: replacement text for > secure managementprotocolboilerplate > ... > > Would the following be better? > > > > "Operators SHOULD enable cryptographic security and ensure that the > > protocol giving access to management information is properly > > configured to give access only to those principals > > (users/applications) that have legitimate rights to > > read/create/change/delete the information." > > > > i.e., > > s:server/agent:protocol: > > s:(users):(users/applications)/ > > > > or does that get so diluted as to be meaningless? > > I think it's better. To more explicitly address the > syslog/notification > cases, perhaps one could add "/receive" after "delete"? > > Randy > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area > From ietfdbh@comcast.net Wed Feb 4 11:55:15 2009 Return-Path: X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB6BE3A6A3D for ; Wed, 4 Feb 2009 11:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.409 X-Spam-Level: X-Spam-Status: No, score=-2.409 tagged_above=-999 required=5 tests=[AWL=0.190, 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 cYLkoEwOr-Zz for ; Wed, 4 Feb 2009 11:55:15 -0800 (PST) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 145573A693B for ; Wed, 4 Feb 2009 11:55:14 -0800 (PST) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA07.westchester.pa.mail.comcast.net with comcast id Bntu1b0050SCNGk57vuvlK; Wed, 04 Feb 2009 19:54:55 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA09.westchester.pa.mail.comcast.net with comcast id Bvuu1b0130UQ6dC3Vvuu2r; Wed, 04 Feb 2009 19:54:55 +0000 From: "David Harrington" To: "'Randy Presuhn'" , "'ops-area \(IETF\)'" References: <051c01c986df$ce1b89b0$0600a8c0@china.huawei.com> <004e01c986f5$8b8aaac0$6801a8c0@oemcomputer> Date: Wed, 4 Feb 2009 14:54:53 -0500 Message-ID: <056401c98702$731e26d0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <004e01c986f5$8b8aaac0$6801a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcmG9Zt0WpNmdcy3SdmMTGg911KKqAAC3nvA Subject: Re: [OPS-AREA] Issue 1: should we have a security boilerplateformanagement protocols and data models? X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 19:55:16 -0000 Hi, > While this is an admirable goal, I think it is premature. > Does *anyone* > have an idea of what *standardized* access control for > netconf is going > to look like? Though I know folks would like to make it simpler than > VACM, until folks work through how access control interacts with > augmentations and vendor extensions in that environment, I'd be > very wary of trying to set out meta-policies (which is what > the filled-in > boilerplate will be) for that environment. I am not sure which goal you find admirable, but I assume you mean suggesting that protocols should support access control, and the info model access should differentiate between modify sensitivity and expose sensitivity. I tried to write the text to say that the protocol should support control of access to the information. I tried to avoid saying anything about using a particular conceptualization/model of access control. "support" could be for a proprietary access control model, or a standardized one - but some type of access control should be supported. I think that whether the access control is standardized or proprietary, it will be reasonable to expect that the access control will differentiate between operations that expose and those that modify (if there is a modify capability). dbh From randy_presuhn@mindspring.com Wed Feb 4 17:25:24 2009 Return-Path: X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81EBA28C1B7 for ; Wed, 4 Feb 2009 17:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[AWL=0.536, 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 AIAW1g+2B4IQ for ; Wed, 4 Feb 2009 17:25:13 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 6999428C1AD for ; Wed, 4 Feb 2009 17:25:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=B5qHVxGREYkQNLsCvpIkq84Lmk4Y9gBu0io4HpdlKbVeXM1qJfn7QlkDCkN4LPWU; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.189.129] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LUsz7-00066h-46 for ops-area@ietf.org; Wed, 04 Feb 2009 20:24:53 -0500 Message-ID: <001201c98730$806a4d40$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "'ops-area \(IETF\)'" References: <051c01c986df$ce1b89b0$0600a8c0@china.huawei.com> <004e01c986f5$8b8aaac0$6801a8c0@oemcomputer> <056401c98702$731e26d0$0600a8c0@china.huawei.com> Date: Wed, 4 Feb 2009 17:24:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f173afb3478488c11dbfc486ba46765ac95d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.189.129 Subject: Re: [OPS-AREA] Issue 1: should we have a security boilerplateformanagement protocols and data models? X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 01:25:24 -0000 Hi - > From: "David Harrington" > To: "'Randy Presuhn'" ; "'ops-area (IETF)'" > Sent: Wednesday, February 04, 2009 11:54 AM > Subject: RE: [OPS-AREA] Issue 1: should we have a security boilerplateformanagement protocols and data models? ... > I am not sure which goal you find admirable, but I assume you mean > suggesting that protocols should support access control, and the info > model access should differentiate between modify sensitivity and > expose sensitivity. However, it's not even clear whether netconf access control will even be formulated in those terms (it might be "per RPC") nor do we even know whether the granularity of "information element" would be congruent with what netconf might do. (I would hope so, but then it might start to look surprisingly like VACM.) > I tried to write the text to say that the protocol should support > control of access to the information. I tried to avoid saying anything > about using a particular conceptualization/model of access control. > "support" could be for a proprietary access control model, or a > standardized one - but some type of access control should be > supported. We're in agreement. The difficulty is that access control models aren't *necessarily* formulated in terms of information elements, even though doing so is in my opinion a very sensible thing. > I think that whether the access control is standardized or > proprietary, it will be reasonable to expect that the access control > will differentiate between operations that expose and those that > modify (if there is a modify capability). Maybe. If it looks like some CLI access control models, it will be organized around a set of "verbs" rather than information objects. I certainly don't recommend such an approach, but until netconf nails this down, I'd be wary of trying to predict how it will end up. Randy From dromasca@avaya.com Thu Feb 5 01:02:23 2009 Return-Path: X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98BA03A6B4D for ; Thu, 5 Feb 2009 01:02:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 k16UpAKCOoJw for ; Thu, 5 Feb 2009 01:02:22 -0800 (PST) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 9AB583A689B for ; Thu, 5 Feb 2009 01:02:22 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,384,1231131600"; d="scan'208";a="160397532" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 05 Feb 2009 04:02:02 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 05 Feb 2009 04:02:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Feb 2009 10:01:25 +0100 Message-ID: In-Reply-To: <054801c986f6$4c8967c0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] Issue 3: replacement boilerplate formanagementobjectsensitivity thread-index: AcmG9N6CEqxIiUWFS3yQJZIwE87p7gAAR7qAAB6G7TA= References: <051e01c986df$e2075490$0600a8c0@china.huawei.com><004901c986f4$cf21a280$6801a8c0@oemcomputer> <054801c986f6$4c8967c0$0600a8c0@china.huawei.com> From: "Romascanu, Dan (Dan)" To: "David Harrington" , "Randy Presuhn" , "ops-area (IETF)" Subject: Re: [OPS-AREA] Issue 3: replacement boilerplate formanagementobjectsensitivity X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 09:02:23 -0000 I support the separation the texts and lists of writeable and readable (only) objects. I believe that this variant works better.=20 Dan (speaking as contributor)=20 > -----Original Message----- > From: ops-area-bounces@ietf.org=20 > [mailto:ops-area-bounces@ietf.org] On Behalf Of David Harrington > Sent: Wednesday, February 04, 2009 8:28 PM > To: 'Randy Presuhn'; 'ops-area (IETF)' > Subject: Re: [OPS-AREA] Issue 3: replacement boilerplate=20 > formanagementobjectsensitivity >=20 > Hi, >=20 > > I prefer the approach of the old text, which split the information=20 > > elements according to concern (modification or mere exposure), >=20 > So would this work better? >=20 > -- include this paragraph if the management information can=20 > be created, deleted, or modified: >=20 > Some management information defined in this document can=20 > be created, deleted, or modified by one or more management protocols. > Unauthorized or inappropriate modification could have a=20 > negative effect on network operations or security.=20 >=20 > they are sensitive to modification> >=20 > -- include the following in all documents that define management > information: >=20 > The management information defined in this document can be=20 > considered sensitive or lead to network vulnerabilities in=20 > some environments. It is important to control access to this=20 > information and possibly to encrypt the information when=20 > sending the information over a network using a management=20 > protocol, to prevent unauthorized or inappropriate exposure=20 > of this information.=20 >=20 > Following is a list of the potentially sensitive information,=20 > and why this information is sensitive: >=20 > they are sensitive to exposure> > =20 >=20 > dbh >=20 > > -----Original Message----- > > From: ops-area-bounces@ietf.org > > [mailto:ops-area-bounces@ietf.org] On Behalf Of Randy Presuhn > > Sent: Wednesday, February 04, 2009 1:17 PM > > To: 'ops-area (IETF)' > > Subject: Re: [OPS-AREA] Issue 3: replacement boilerplate for=20 > > managementobjectsensitivity > >=20 > > Hi - > >=20 > > > From: "David Harrington" > > > To: "'ops-area (IETF)'" > > > Sent: Wednesday, February 04, 2009 7:47 AM > > > Subject: [OPS-AREA] Issue 3: replacement boilerplate for > > management objectsensitivity > > ... > > > NEW: > > ... > > > Following is a list of the potentially sensitive > > information, and why > > > this information is sensitive: > > >=20 > > > are > > > sensitive to modification and exposure> > > ... > >=20 > > I prefer the approach of the old text, which split the information=20 > > elements according to concern (modification or mere=20 > exposure), rather=20 > > than lumping everything together like this, since=20 > separating them may > help > > in security policy formulation and sanity checking. > >=20 > > Randy > >=20 > > _______________________________________________ > > OPS-AREA mailing list > > OPS-AREA@ietf.org > > https://www.ietf.org/mailman/listinfo/ops-area > >=20 >=20 > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area >=20 From dromasca@avaya.com Thu Feb 5 01:03:12 2009 Return-Path: X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E00493A6A81 for ; Thu, 5 Feb 2009 01:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 5bGm6jkwuH-f for ; Thu, 5 Feb 2009 01:03:12 -0800 (PST) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id ED6CD3A6B64 for ; Thu, 5 Feb 2009 01:03:11 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,384,1231131600"; d="scan'208";a="151219858" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 05 Feb 2009 04:02:50 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 05 Feb 2009 04:02:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Feb 2009 10:02:44 +0100 Message-ID: In-Reply-To: <007101c986f6$5ac4e620$6801a8c0@oemcomputer> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] Issue 2: replacement text for securemanagementprotocolboilerplate thread-index: AcmG9m4337TLg90kTPqJN9VGIpcvcgAegF7g References: <051d01c986df$de905640$0600a8c0@china.huawei.com><004401c986f4$238daf40$6801a8c0@oemcomputer><054701c986f5$dd5c1a00$0600a8c0@china.huawei.com> <007101c986f6$5ac4e620$6801a8c0@oemcomputer> From: "Romascanu, Dan (Dan)" To: "Randy Presuhn" , "ops-area (IETF)" Subject: Re: [OPS-AREA] Issue 2: replacement text for securemanagementprotocolboilerplate X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 09:03:13 -0000 =20 > -----Original Message----- > From: ops-area-bounces@ietf.org=20 > [mailto:ops-area-bounces@ietf.org] On Behalf Of Randy Presuhn > Sent: Wednesday, February 04, 2009 8:28 PM > To: 'ops-area (IETF)' > Subject: Re: [OPS-AREA] Issue 2: replacement text for=20 > securemanagementprotocolboilerplate >=20 > Hi - >=20 > > From: "David Harrington" > > To: "'Randy Presuhn'" ; "'ops-area=20 > > (IETF)'" > > Sent: Wednesday, February 04, 2009 10:24 AM > > Subject: RE: [OPS-AREA] Issue 2: replacement text for secure=20 > > managementprotocolboilerplate > ... > > Would the following be better? > > =20 > > "Operators SHOULD enable cryptographic security and ensure that the=20 > > protocol giving access to management information is properly=20 > > configured to give access only to those principals > > (users/applications) that have legitimate rights to=20 > > read/create/change/delete the information." > >=20 > > i.e., > > s:server/agent:protocol: > > s:(users):(users/applications)/ > >=20 > > or does that get so diluted as to be meaningless? >=20 > I think it's better. To more explicitly address the=20 > syslog/notification cases, perhaps one could add "/receive"=20 > after "delete"? >=20 > Randy >=20 +1=20 Dan (speaking as contributor) From ietfdbh@comcast.net Thu Feb 5 10:04:01 2009 Return-Path: X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 307E33A6997 for ; Thu, 5 Feb 2009 10:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 duu0KBhn5yr2 for ; Thu, 5 Feb 2009 10:04:00 -0800 (PST) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id C749D3A69F9 for ; Thu, 5 Feb 2009 10:03:59 -0800 (PST) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA10.westchester.pa.mail.comcast.net with comcast id CBjo1b00G0EZKEL5AJ3hQV; Thu, 05 Feb 2009 18:03:41 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA01.westchester.pa.mail.comcast.net with comcast id CJ3g1b00f0UQ6dC3MJ3gVd; Thu, 05 Feb 2009 18:03:41 +0000 From: "David Harrington" To: "'Randy Presuhn'" , "'ops-area \(IETF\)'" References: <051c01c986df$ce1b89b0$0600a8c0@china.huawei.com><004e01c986f5$8b8aaac0$6801a8c0@oemcomputer><056401c98702$731e26d0$0600a8c0@china.huawei.com> <001201c98730$806a4d40$6801a8c0@oemcomputer> Date: Thu, 5 Feb 2009 13:03:39 -0500 Message-ID: <063c01c987bc$13151540$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <001201c98730$806a4d40$6801a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcmHMJXoGAESPjPqQOuFn0hWKwuCOQAiZzJQ Subject: Re: [OPS-AREA] Issue 1: should we have a securityboilerplateformanagement protocols and data models? X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 18:04:01 -0000 Hi, I think you may be reading more into "information element" than I am. In a management information system that uses verbs or RPCs, I consider those as information elements as well. Some verbs modify, some expose. Some RPCs modify, some expose. In a system that uses hierarchies of things, like MIBs and XML and UNIX filesystems, both leafs and subtrees can be information elements that can expose or possibly be modifed. I do not think the whole IETF strategy for managing networks should be totally dependent on what Netconf and netmod decide to do about access control, anyway. There are quite a few different protocols in the IETF that address network management. dbh > -----Original Message----- > From: ops-area-bounces@ietf.org > [mailto:ops-area-bounces@ietf.org] On Behalf Of Randy Presuhn > Sent: Wednesday, February 04, 2009 8:25 PM > To: 'ops-area (IETF)' > Subject: Re: [OPS-AREA] Issue 1: should we have a > securityboilerplateformanagement protocols and data models? > > Hi - > > > From: "David Harrington" > > To: "'Randy Presuhn'" ; > "'ops-area (IETF)'" > > Sent: Wednesday, February 04, 2009 11:54 AM > > Subject: RE: [OPS-AREA] Issue 1: should we have a security > boilerplateformanagement protocols and data models? > ... > > I am not sure which goal you find admirable, but I assume you mean > > suggesting that protocols should support access control, > and the info > > model access should differentiate between modify sensitivity and > > expose sensitivity. > > However, it's not even clear whether netconf access control will > even be formulated in those terms (it might be "per RPC") nor > do we even know whether the granularity of "information element" > would be congruent with what netconf might do. (I would hope so, > but then it might start to look surprisingly like VACM.) > > > I tried to write the text to say that the protocol should support > > control of access to the information. I tried to avoid > saying anything > > about using a particular conceptualization/model of access control. > > "support" could be for a proprietary access control model, or a > > standardized one - but some type of access control should be > > supported. > > We're in agreement. The difficulty is that access control models > aren't *necessarily* formulated in terms of information elements, > even though doing so is in my opinion a very sensible thing. > > > I think that whether the access control is standardized or > > proprietary, it will be reasonable to expect that the access control > > will differentiate between operations that expose and those that > > modify (if there is a modify capability). > > Maybe. If it looks like some CLI access control models, it will > be organized around a set of "verbs" rather than information objects. > I certainly don't recommend such an approach, but until netconf > nails this down, I'd be wary of trying to predict how it will end up. > > Randy > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area > From randy_presuhn@mindspring.com Thu Feb 5 12:49:13 2009 Return-Path: X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80E9D3A6ABB for ; Thu, 5 Feb 2009 12:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.242, 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 byhK+hXQEJ36 for ; Thu, 5 Feb 2009 12:49:12 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 8BC253A68C5 for ; Thu, 5 Feb 2009 12:49:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=tNAURB1vgwZrwaNUTwBLWBwhbk3He2zOst2nYGuwxl4rpNDlwLIiCd3IBitKHp88; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [69.3.26.31] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LVB9q-00029f-W9 for ops-area@ietf.org; Thu, 05 Feb 2009 15:49:11 -0500 Message-ID: <004801c987d3$2830b620$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "'ops-area \(IETF\)'" References: <051c01c986df$ce1b89b0$0600a8c0@china.huawei.com><004e01c986f5$8b8aaac0$6801a8c0@oemcomputer><056401c98702$731e26d0$0600a8c0@china.huawei.com> <001201c98730$806a4d40$6801a8c0@oemcomputer> <063c01c987bc$13151540$0600a8c0@china.huawei.com> Date: Thu, 5 Feb 2009 12:48:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f173bd2349df5b350227c21c3470d86141a6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.26.31 Subject: Re: [OPS-AREA] Issue 1: should we have a securityboilerplateformanagement protocols and data models? X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 20:49:13 -0000 Hi - > From: "David Harrington" > To: "'Randy Presuhn'" ; "'ops-area (IETF)'" > Sent: Thursday, February 05, 2009 10:03 AM > Subject: RE: [OPS-AREA] Issue 1: should we have a securityboilerplateformanagement protocols and data models? ... > I think you may be reading more into "information element" than I am. > In a management information system that uses verbs or RPCs, I consider > those as information elements as well. Some verbs modify, some expose. > Some RPCs modify, some expose. In a system that uses hierarchies of > things, like MIBs and XML and UNIX filesystems, both leafs and > subtrees can be information elements that can expose or possibly be > modifed. Consequently, until we know the granularity and orientation of the netconf access control model, the boilerplate is premature. To be most useful, it should make it abundantly clear to the document writer what bits have to be filled in, and at what granularity. > I do not think the whole IETF strategy for managing networks should be > totally dependent on what Netconf and netmod decide to do about access > control, anyway. There are quite a few different protocols in the IETF > that address network management. Agreed, and there seem to be more every week. Though it would be nice for there to be a coherent architecture, I'm afraid the horses have already left the barn. If a boilerplate document like this is going to be truly useful, it needs appropriate hooks corresponding to the knobs provided by the various protocols' access control facilities. Randy From dromasca@avaya.com Sun Feb 15 02:22:02 2009 Return-Path: X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D707B28C0D6 for ; Sun, 15 Feb 2009 02:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=0.580, 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 XLTNY06D38sF for ; Sun, 15 Feb 2009 02:22:02 -0800 (PST) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id DCA7728B56A for ; Sun, 15 Feb 2009 02:22:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,210,1233550800"; d="scan'208";a="152339332" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 15 Feb 2009 05:22:09 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 15 Feb 2009 05:22:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sun, 15 Feb 2009 11:21:57 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OPSAREA - Requested session has been scheduled for IETF 74 Thread-Index: AcmONm7B/7jA/PGLRLyDkxSs1cPhxgBIJMgQ From: "Romascanu, Dan (Dan)" To: "ops-area (IETF)" Subject: [OPS-AREA] FW: OPSAREA - Requested session has been scheduled for IETF 74 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 10:22:02 -0000 =20 The open OPS area meeting is scheduled for Monday afternoon.=20 Please continue to send your requests for items in the agenda.=20 Dan -----Original Message----- From: IETF Secretariat [mailto:agenda@ietf.org]=20 Sent: Saturday, February 14, 2009 1:54 AM To: Romascanu, Dan (Dan) Cc: rbonica@juniper.net; Romascanu, Dan (Dan); rbonica@juniper.net; session-request@ietf.org Subject: OPSAREA - Requested session has been scheduled for IETF 74=20 Dear Dan Romascanu, The sessions that you have requested have been scheduled. Below is the scheduled session information followed by the information of sessions that you have requested. OPSAREA Session 1 (2 hours) Monday, Afternoon Session II 1520-1720 Room Name: Breakout 8 ---------------------------------------------- Requested Information: --------------------------------------------------------- Working Group Name: opsarea Area Name: Operations and Management Area Session Requester: Dan Romascanu Number of Sessions: 1 Length of Session(s): 2 hours =20 =20 Number of Attendees: 100 Conflicts to Avoid: First Priority: adslmib bmwg capwap dime dnsop grow imss isms l2vpn mboned netconf netmod opsawg opsec pmol psamp radext syslog ippm ipfix Second Priority: apparea avt behave btns dnsext ecrit geopriv genarea intarea mmusic mpls p2psip raiarea rtgarea simple sip sipping speermint tsvarea tsvwg BOF or IRTF Session: all BOFs should be avoided if possible Special Requests: =20 --------------------------------------------------------- From brian.e.carpenter@gmail.com Fri Feb 20 13:06:25 2009 Return-Path: X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 289B03A6A1D for ; Fri, 20 Feb 2009 13:06:25 -0800 (PST) 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] 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 CXGXOIVKVZwU for ; Fri, 20 Feb 2009 13:06:24 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.184]) by core3.amsl.com (Postfix) with ESMTP id 3ED4D3A63D3 for ; Fri, 20 Feb 2009 13:06:24 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id 11so695671tim.25 for ; Fri, 20 Feb 2009 13:06:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:content-type :content-transfer-encoding; bh=jb79tuBvh3Utixd8RJbJSbEqwrqZvP0eVkX1p0usrHg=; b=cRoN8XQIYVyY3DYFY35y64xEpiyaWXnAknCg2w+SHZ7TMCtzSlUayYpZ4/THapJV9b PP5eST5iWhOzxR3frH0vNzkey2t0FlUhziPa1NQ055Q+YIfh5xr5ssHnT1pVIceLH19/ ejVM5KqlkmuQxv7geVeLlr5y6mscUqsQH2EE8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:content-type:content-transfer-encoding; b=Pk+aB20iv1sxXHnQttzjWzZoxotm9/E1B4iv2O+Q0kl5yhdcf0zVJ9Ipx/uHNPITlu NnFLFovuU1kxP1rWw134KL37yI0zgFBD7qgkT7V83uNsRqeyTk2WdorpyzVpiRpiMRXB ofa5aosDPIk/0DFcw66tFuO2oF8RO0cNvjrKg= Received: by 10.110.105.10 with SMTP id d10mr1611667tic.33.1235163997976; Fri, 20 Feb 2009 13:06:37 -0800 (PST) Received: from ?10.1.1.4? (118-92-129-217.dsl.dyn.ihug.co.nz [118.92.129.217]) by mx.google.com with ESMTPS id d7sm1991647tib.2.2009.02.20.13.06.35 (version=SSLv3 cipher=RC4-MD5); Fri, 20 Feb 2009 13:06:37 -0800 (PST) Message-ID: <499F1B58.3040103@gmail.com> Date: Sat, 21 Feb 2009 10:06:32 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ops-area@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: RJ Atkinson , "Flinck, Hannu" Subject: [OPS-AREA] Renumbering needs work version 02 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 21:06:25 -0000 A draft on this topic has been updated: http://www.ietf.org/internet-drafts/draft-carpenter-renum-needs-work-02.txt Comments and discussion are invited on the OPS Area list, ops-area@ietf.org Brian Carpenter Ran Atkinson Hannu Flinck P.S. Apologies if you receive multiple copies, but that seems preferable to cross-posting to multiple lists. From dromasca@avaya.com Tue Feb 24 09:55:11 2009 Return-Path: X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BAC428C15C for ; Tue, 24 Feb 2009 09:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 6nqA20leZx3e for ; Tue, 24 Feb 2009 09:55:10 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id D85C228C149 for ; Tue, 24 Feb 2009 09:55:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,260,1233550800"; d="scan'208";a="138437880" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 24 Feb 2009 12:55:26 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Feb 2009 12:55:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Feb 2009 18:55:04 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Preliminary Agenda for the OPSAREA Open Meeting at IETF-74 Thread-Index: AcmWqQVgahzBmhRMT96P5LLc8DAEdg== From: "Romascanu, Dan (Dan)" To: "ops-area (IETF)" Subject: [OPS-AREA] Preliminary Agenda for the OPSAREA Open Meeting at IETF-74 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 17:55:11 -0000 Please find below the preliminary agenda for the OPSAREA Open Meeting at IETF 74.=20 Please let us know if you will be requiring time for any presentations or discussions.=20 Thanks and Regards, Ron and Dan ------------------------------------------------------- OPSAREA Open Meeting Area Directors: Dan Romascanu and Ron Bonica Monday, March 23, 2009 1520-1720 Afternoon Session II 1. Note well, agenda bashing, note takers, blue sheets - 5 min 2. Renumbering still works - Brian Carpenter, Hannu Flinck, Ran Atkinson - 30 min 3. WG Status reports: WG chairs, 3 min each=20 4. Open microphone: whatever time is left