From isms-bounces@ietf.org Thu Sep 2 15:43:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01518; Thu, 2 Sep 2004 15:43:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2xWk-0000Ga-I8; Thu, 02 Sep 2004 15:45:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2xQr-0004pW-2l; Thu, 02 Sep 2004 15:39:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2xHU-0006Rb-3x for isms@megatron.ietf.org; Thu, 02 Sep 2004 15:30:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00611 for ; Thu, 2 Sep 2004 15:29:58 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2xJv-0007lZ-BB for isms@ietf.org; Thu, 02 Sep 2004 15:32:32 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 1893B11D941; Thu, 2 Sep 2004 12:29:49 -0700 (PDT) To: isms@ietf.org From: Wes Hardaker Organization: Sparta Date: Thu, 02 Sep 2004 12:29:49 -0700 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.5 (chayote, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [Isms] first post to new list X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 This should be the first post to the new isms@ietf.org mailing list. Whee. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Sep 2 15:53:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02205; Thu, 2 Sep 2004 15:53:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2xgU-0000zD-Hd; Thu, 02 Sep 2004 15:55:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2xaQ-0003do-FU; Thu, 02 Sep 2004 15:49:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2xCa-0003Ik-LX for isms@megatron.ietf.org; Thu, 02 Sep 2004 15:24:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00351 for ; Thu, 2 Sep 2004 15:24:54 -0400 (EDT) Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2xF1-0007KF-9q for isms@ietf.org; Thu, 02 Sep 2004 15:27:28 -0400 Received: by machshav.com (Postfix, from userid 512) id B2791FB453; Thu, 2 Sep 2004 15:24:52 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 67D59FB44C for ; Thu, 2 Sep 2004 15:24:52 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: sbsm-request@machshav.com To: isms@ietf.org X-No-Archive: yes Message-ID: Date: Thu, 02 Sep 2004 15:24:52 -0400 Precedence: bulk X-BeenThere: sbsm@machshav.com X-Mailman-Version: 2.1.4 X-List-Administrivia: yes X-Spam-Score: 0.3 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 02 Sep 2004 15:49:33 -0400 Subject: [Isms] Welcome to the "Sbsm" mailing list X-BeenThere: isms@lists.ietf.org List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Welcome to the Sbsm@machshav.com mailing list! To post to this list, send your email to: sbsm@machshav.com General information about the mailing list is at: https://www.machshav.com/mailman/listinfo.cgi/sbsm If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: https://www.machshav.com/mailman/options.cgi/sbsm/isms%40ietf.org You can also make such adjustments via email by sending a message to: Sbsm-request@machshav.com with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: baedut Normally, Mailman will remind you of your machshav.com mailing list passwords once every month, although you can disable this if you prefer. This reminder will also include instructions on how to unsubscribe or change your account options. There is also a button on your options page that will email your current password to you. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Sep 2 15:54:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02265; Thu, 2 Sep 2004 15:54:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2xhS-0001Bv-Lk; Thu, 02 Sep 2004 15:56:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2xaQ-0003ds-NP; Thu, 02 Sep 2004 15:49:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2xGH-0005iC-35 for isms@megatron.ietf.org; Thu, 02 Sep 2004 15:28:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00530 for ; Thu, 2 Sep 2004 15:28:43 -0400 (EDT) Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2xIh-0007Yq-VU for isms@ietf.org; Thu, 02 Sep 2004 15:31:17 -0400 Received: by machshav.com (Postfix, from userid 512) id 4409DFB451; Thu, 2 Sep 2004 15:28:42 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E2E68FB44C for ; Thu, 2 Sep 2004 15:28:41 -0400 (EDT) Delivered-To: sbsm@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7FC2EFB451; Thu, 2 Sep 2004 15:28:21 -0400 (EDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by machshav.com (Postfix) with ESMTP id 17234FB44C for ; Thu, 2 Sep 2004 15:28:21 -0400 (EDT) Received: by wes.hardakers.net (Postfix, from userid 274) id D70FF11D941; Thu, 2 Sep 2004 12:28:16 -0700 (PDT) To: sbsm@machshav.com From: Wes Hardaker Organization: Sparta Date: Thu, 02 Sep 2004 12:28:16 -0700 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.5 (chayote, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Thu, 02 Sep 2004 15:28:40 -0400 X-BeenThere: sbsm@machshav.com X-Mailman-Version: 2.1.4 Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-Mailman-Approved-At: Thu, 02 Sep 2004 15:49:33 -0400 Subject: [Isms] [Sbsm] SBSM mailing list moving to ISMS@ietf.org X-BeenThere: isms@lists.ietf.org List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 I've just removed everyone from the sbsm mailing list and transferred everyone to the new isms@ietf.org list. Please use that for all future communication about ISMS related work. -- Wes Hardaker Sparta _______________________________________________ Sbsm mailing list Sbsm@machshav.com https://www.machshav.com/mailman/listinfo.cgi/sbsm _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Sep 2 16:01:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02769; Thu, 2 Sep 2004 16:01:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2xol-0001ni-Rw; Thu, 02 Sep 2004 16:04:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2xdL-0005YN-PZ; Thu, 02 Sep 2004 15:52:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2xZa-0002yD-Rw for isms@megatron.ietf.org; Thu, 02 Sep 2004 15:48:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01888 for ; Thu, 2 Sep 2004 15:48:40 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2xc2-0000jk-CZ for isms@ietf.org; Thu, 02 Sep 2004 15:51:15 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 2E3FB11D941; Thu, 2 Sep 2004 12:48:37 -0700 (PDT) To: isms@ietf.org From: Wes Hardaker Organization: Sparta Date: Thu, 02 Sep 2004 12:48:37 -0700 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.5 (chayote, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Isms] ISMS mail test... ignore this. X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 It could be that something somewhere is just real slow, or that the new list is potentially not working. Checking... -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Sep 2 17:07:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11696; Thu, 2 Sep 2004 17:07:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2yqU-0008VY-6R; Thu, 02 Sep 2004 17:10:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2yZu-0006tL-K9; Thu, 02 Sep 2004 16:53:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2yB2-0007nZ-TR for isms@megatron.ietf.org; Thu, 02 Sep 2004 16:27:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05298 for ; Thu, 2 Sep 2004 16:27:22 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2yDU-0004AK-4f for isms@ietf.org; Thu, 02 Sep 2004 16:29:57 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id i82KQnSH021572 for ; Thu, 2 Sep 2004 15:26:50 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 2 Sep 2004 22:26:48 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550526AD04@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Wes Hardaker Subject: RE: [Isms] ISMS mail test... ignore this. Date: Thu, 2 Sep 2004 22:26:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a mailing lists at ietf.org do (occasionally... probably too often) experience some delay. Sometimes even up to an hour or so. Just so you know. Thanks, Bert > -----Original Message----- > From: Wes Hardaker [mailto:hardaker@tislabs.com] > Sent: Thursday, September 02, 2004 21:49 > To: isms@ietf.org > Subject: [Isms] ISMS mail test... ignore this. > > > > It could be that something somewhere is just real slow, or that the > new list is potentially not working. Checking... > > -- > Wes Hardaker > Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Sep 7 00:13:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28789; Tue, 7 Sep 2004 00:13:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4XPE-0002ms-QM; Tue, 07 Sep 2004 00:16:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4XLB-0001Ff-IY; Tue, 07 Sep 2004 00:12:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4XJm-0000nA-De for isms@megatron.ietf.org; Tue, 07 Sep 2004 00:10:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28616 for ; Tue, 7 Sep 2004 00:10:51 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4XN7-0002ka-Tp for isms@ietf.org; Tue, 07 Sep 2004 00:14:23 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 955EB12239F; Mon, 6 Sep 2004 21:10:41 -0700 (PDT) To: isms@ietf.org From: Wes Hardaker Organization: Sparta Date: Mon, 06 Sep 2004 21:10:41 -0700 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.5 (chayote, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: [Isms] documentation style for SBSM: pseudo-code vs text X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 In revising the SBSM draft over time I've considered many ways to document the elements of procedures required to implement the protocol. Initially I started out writing everything in text, but in the last document I switched some of the simpler assignment type actions to simple equations since I think it's much more concise and harder to mis-read [there is a section that documents that both text and equations MUST be followed for the protocol implementation to be complete]. But lately, I'm thinking that stream-lining things even more would actually improve the document. Right now, its fairly lengthy in large part due to the sentence-text required to document how to do particular things, when pseudo-code could be quite a bit shorter. So, let me give me some examples of the same way to say something and ask which people would prefer. a) all english text for more complex decisions: * If the current time minus the session.startTime is greater than the number of seconds from the session.legalSessionLength field (or any other value from a policy that restricts session time lengths), then the session MUST be immediately closed (see Section for information on closing a session) and an unknownSBSMSession error returned to the calling module. b) all pseudo-code: if (current_time - session.startTime > session.legalSessionLength) { session.status = CLOSED; return unknownSBSMSession; } c) pseudo-code with a introductory bullet: * Check the session for whether it should be expired or not: if (current_time - session.startTime > session.legalSessionLength) { session.status = CLOSED; return unknownSBSMSession; } d) pseudo-code with a introductory pseudo-code comment: /* Check the session for whether it should be expired or not: */ if (current_time - session.startTime > session.legalSessionLength) { session.status = CLOSED; return unknownSBSMSession; } The end result is that I am now leaning toward (c). Does anyone else have preferences for style that they'd prefer to read? Currently, the pseudo-code statements I have in there are very simple assignments without things like the above if() type clauses. [FYI, to see the current introductory text see the section entitled "Protocol documentation conventions" in the full document]. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Sep 7 10:44:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27262; Tue, 7 Sep 2004 10:44:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4hFx-0005Ml-39; Tue, 07 Sep 2004 10:47:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4h6e-0005YR-Vc; Tue, 07 Sep 2004 10:38:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4h4S-0004oE-Dr for isms@megatron.ietf.org; Tue, 07 Sep 2004 10:35:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26528 for ; Tue, 7 Sep 2004 10:35:41 -0400 (EDT) Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103] helo=hosting.revelstone.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4h7s-0005Dx-Pf for isms@ietf.org; Tue, 07 Sep 2004 10:39:18 -0400 Received: from localhost ([127.0.0.1] helo=dev.localdomain) by hosting.revelstone.com with smtp (Exim 4.42) id 1C4h2o-0003nY-19; Tue, 07 Sep 2004 10:34:02 -0400 Date: Tue, 7 Sep 2004 10:35:35 -0400 From: Robert Story To: Wes Hardaker Subject: Re: [Isms] documentation style for SBSM: pseudo-code vs text Message-Id: <20040907103535.0405cb36@dev.localdomain> In-Reply-To: References: X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.revelstone.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - freesnmp.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: sbsm@machshav.com, isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit On Mon, 06 Sep 2004 21:10:41 -0700 Wes wrote: WH> The end result is that I am now leaning toward (c). Does anyone else WH> have preferences for style that they'd prefer to read? Currently, the WH> pseudo-code statements I have in there are very simple assignments WH> without things like the above if() type clauses. If the text preceding the pseudo-code explains what is going on, then b-d are pretty much equivalent. My initial reaction was d, but now I'm wonder if a+b isn't better. You didn't include the text that would have been above the examples. My concern is that if I read just a or just b, I don't know that I would have came to the same understanding. In particular: WH> session.status = CLOSED; simply sets a flag, whereas WH> * If [session expired], then the session MUST be immediately closed would have ended up in my code as session_close(close); If the text preceding the example were sufficiently clear on the closing of the session, the I suppose any of b-d would be fine. -- Robert Story; NET-SNMP Junkie You are lost in a twisty maze of little standards, all different. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Sep 7 10:49:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27641; Tue, 7 Sep 2004 10:49:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4hLV-0005Tg-Px; Tue, 07 Sep 2004 10:53:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4hDl-00076k-Un; Tue, 07 Sep 2004 10:45:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4hBi-0006PQ-B1 for isms@megatron.ietf.org; Tue, 07 Sep 2004 10:43:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27141 for ; Tue, 7 Sep 2004 10:43:11 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4hF9-0005Kv-9R for isms@ietf.org; Tue, 07 Sep 2004 10:46:48 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id DE5A011D30B; Tue, 7 Sep 2004 07:43:08 -0700 (PDT) To: Robert Story Subject: Re: [Isms] documentation style for SBSM: pseudo-code vs text References: <20040907103535.0405cb36@dev.localdomain> From: Wes Hardaker Organization: Sparta Date: Tue, 07 Sep 2004 07:43:08 -0700 In-Reply-To: <20040907103535.0405cb36@dev.localdomain> (Robert Story's message of "Tue, 7 Sep 2004 10:35:35 -0400") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.5 (chayote, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: sbsm@machshav.com, isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f >>>>> On Tue, 7 Sep 2004 10:35:35 -0400, Robert Story said: Robert> If the text preceding the pseudo-code explains what is going Robert> on, then b-d are pretty much equivalent. The intent was to drop the text if the pseudo-code could be made sufficiently clear. WH> session.status = CLOSED; Robert> simply sets a flag, whereas WH> * If [session expired], then the session MUST be immediately WH> closed What wasn't shown in the example was preceding text early on that explained the different states with the status value, etc. And actually, the way the EoP is structured setting the above flag would work just fine. Robert> would have ended up in my code as Robert> session_close(close); Entirely deleting the session actually isn't desired as its supposed to stay around for 5 minutes or so and just be closed. Hence a flag is actually closer to the correct interpretation. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Sep 7 12:02:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03510; Tue, 7 Sep 2004 12:02:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4iU4-00070W-5X; Tue, 07 Sep 2004 12:06:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4iH3-0007oi-Nw; Tue, 07 Sep 2004 11:52:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4i2R-000855-Bo for isms@megatron.ietf.org; Tue, 07 Sep 2004 11:37:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01110 for ; Tue, 7 Sep 2004 11:37:40 -0400 (EDT) Message-Id: <200409071537.LAA01110@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4i5t-0006J4-UB for isms@ietf.org; Tue, 07 Sep 2004 11:41:18 -0400 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc13) with SMTP id <2004090715371001500sm45qe>; Tue, 7 Sep 2004 15:37:10 +0000 From: "David B Harrington" To: "'Wes Hardaker'" , "'Robert Story'" Subject: RE: [Isms] documentation style for SBSM: pseudo-code vs text Date: Tue, 7 Sep 2004 11:37:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSU6etZfcy71IzBTVehndEURVqh1gABaA3Q X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: sbsm@machshav.com, isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Hi, I think the example is a good one. "session.status = CLOSED;" does not convey the MUST keyword. Pure pseudo-code seems inadeqaute for expressing MUST/SHOULD/MAY behaviors needed for a standard. I recommend text plus psuedo-code. I don't much care about whether the text is contained in plain text, or in pseudocode comments as long as it is made clear what behavior is required, without ambiguity. A mix of the styles would also be fine by me, chosen to best meet the specific situation; if there is no MUST/SHOULD/MAY to convey, I don't see any reason not to use a pseudocode comment. David Harrington dbharrington@comcast.net -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Wes Hardaker Sent: Tuesday, September 07, 2004 10:43 AM To: Robert Story Cc: sbsm@machshav.com; isms@ietf.org Subject: Re: [Isms] documentation style for SBSM: pseudo-code vs text >>>>> On Tue, 7 Sep 2004 10:35:35 -0400, Robert Story said: Robert> If the text preceding the pseudo-code explains what is going on, Robert> then b-d are pretty much equivalent. The intent was to drop the text if the pseudo-code could be made sufficiently clear. WH> session.status = CLOSED; Robert> simply sets a flag, whereas WH> * If [session expired], then the session MUST be immediately WH> closed What wasn't shown in the example was preceding text early on that explained the different states with the status value, etc. And actually, the way the EoP is structured setting the above flag would work just fine. Robert> would have ended up in my code as Robert> session_close(close); Entirely deleting the session actually isn't desired as its supposed to stay around for 5 minutes or so and just be closed. Hence a flag is actually closer to the correct interpretation. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Sep 7 12:03:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03587; Tue, 7 Sep 2004 12:03:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4iUe-00071o-6F; Tue, 07 Sep 2004 12:06:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4iMV-0001LB-Tx; Tue, 07 Sep 2004 11:58:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4iCe-0004JK-Ch for isms@megatron.ietf.org; Tue, 07 Sep 2004 11:48:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01913 for ; Tue, 7 Sep 2004 11:48:13 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4iG6-0006Xr-Cz for isms@ietf.org; Tue, 07 Sep 2004 11:51:51 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 1758F11D30B; Tue, 7 Sep 2004 08:48:12 -0700 (PDT) To: Subject: Re: [Isms] documentation style for SBSM: pseudo-code vs text References: <200409071534.i87FYH69022742@nutshell.tislabs.com> From: Wes Hardaker Organization: Sparta Date: Tue, 07 Sep 2004 08:48:12 -0700 In-Reply-To: <200409071534.i87FYH69022742@nutshell.tislabs.com> (David B. Harrington's message of "Tue, 7 Sep 2004 11:37:00 -0400") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.5 (chayote, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: sbsm@machshav.com, isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f >>>>> On Tue, 7 Sep 2004 11:37:00 -0400, "David B Harrington" said: David> I recommend text plus psuedo-code. So both you and Robert are opting for (a) the original style then it sounds like. Paragraph style. I don't want to do a full paragraph plus psuedo-code, however. It's redundant and more work than its worth. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Sep 7 13:08:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11067; Tue, 7 Sep 2004 13:08:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4jWE-0000mY-Am; Tue, 07 Sep 2004 13:12:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4ipP-0003FA-VN; Tue, 07 Sep 2004 12:28:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4igi-0001CB-H3 for isms@megatron.ietf.org; Tue, 07 Sep 2004 12:19:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04820 for ; Tue, 7 Sep 2004 12:19:17 -0400 (EDT) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4ikA-0007J1-Pz for isms@ietf.org; Tue, 07 Sep 2004 12:22:56 -0400 Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated bits=0) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id i87GJ6vR028320 for ; Tue, 7 Sep 2004 12:19:06 -0400 (EDT) Message-Id: <200409071619.i87GJ6vR028320@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] documentation style for SBSM: pseudo-code vs text In-Reply-To: X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Tue, 07 Sep 2004 12:19:06 -0400 From: Ken Hornstein X-Spam-Score: () hits=0 User Authenticated X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Just my $0.02, I find _this_ > a) all english text for more complex decisions: > > * If the current time minus the session.startTime is > greater than the number of seconds from the > session.legalSessionLength field (or any other value from > a policy that restricts session time lengths), then the > session MUST be immediately closed (see Section target="closed"/> for information on closing a session) > and an unknownSBSMSession error returned to the calling > module. A LOT more confusing than this: > b) all pseudo-code: > > if (current_time - session.startTime > session.legalSessionLength) { > session.status = CLOSED; > return unknownSBSMSession; > } As a programmer, I find this simple and elegant. I can think of a number of cases in IETF standards where the explanatory text was misunderstood upon reading, but I don't think this would be misunderstood. One other standard that took a more program-like description of the protocol (I am thinking of IrDA, which descripted a FSM along with the English text) helped to explain a lot of the more confusing parts. So I think I'm leaning toward (c) or (d), but maybe with two or three sentences as opposed to one (ideally, you'd put the whole paragraph in there, but in addition to being redundant, I'm sure you don't have infinte time :-) ) --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Sep 7 13:23:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12283; Tue, 7 Sep 2004 13:23:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4jk9-00017F-5w; Tue, 07 Sep 2004 13:27:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4jV9-0002oe-VF; Tue, 07 Sep 2004 13:11:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4iwx-0004xW-U8 for isms@megatron.ietf.org; Tue, 07 Sep 2004 12:36:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06163 for ; Tue, 7 Sep 2004 12:36:04 -0400 (EDT) Message-Id: <200409071636.MAA06163@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4j0Q-0007c0-BB for isms@ietf.org; Tue, 07 Sep 2004 12:39:43 -0400 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc12) with SMTP id <20040907163529014002h203e>; Tue, 7 Sep 2004 16:35:29 +0000 From: "David B Harrington" To: "'Wes Hardaker'" Subject: RE: [Isms] documentation style for SBSM: pseudo-code vs text Date: Tue, 7 Sep 2004 12:35:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSU8hZHfosBwGsrQj6Yw3ORZmzpkwAAB1hw X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: sbsm@machshav.com, isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Hi Wes, I didn't say that I opted for full paragraph style. I believe there is some info that needs to be communicated using text, and some that can be communicated using pseudocode. For expressions, I prefer the conciseness of psuedocode to the wordiness of text, but pseudocode cannot specify a MUST, so different portions of the communications will require different formats. You need to select whichever is most appropriate to what you are conveying, including a combination of the two where needed. The pseudocode "session.status = CLOSED;" needs to be supplemented with some text that indicates this assignment is REQUIRED for interoperability. David Harrington dbharrington@comcast.net -----Original Message----- From: Wes Hardaker [mailto:hardaker@tislabs.com] Sent: Tuesday, September 07, 2004 11:48 AM To: ietfdbh@comcast.net Cc: 'Robert Story'; sbsm@machshav.com; isms@ietf.org Subject: Re: [Isms] documentation style for SBSM: pseudo-code vs text >>>>> On Tue, 7 Sep 2004 11:37:00 -0400, "David B Harrington" said: David> I recommend text plus psuedo-code. So both you and Robert are opting for (a) the original style then it sounds like. Paragraph style. I don't want to do a full paragraph plus psuedo-code, however. It's redundant and more work than its worth. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Sep 7 13:30:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13180; Tue, 7 Sep 2004 13:30:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4jrP-0001ML-7n; Tue, 07 Sep 2004 13:34:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4jfd-0008L6-DQ; Tue, 07 Sep 2004 13:22:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4jLK-000626-H0 for isms@megatron.ietf.org; Tue, 07 Sep 2004 13:01:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09603 for ; Tue, 7 Sep 2004 13:01:14 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4jOm-0000Gs-Po for isms@ietf.org; Tue, 07 Sep 2004 13:04:54 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id i87H0DX4004813; Tue, 7 Sep 2004 10:00:13 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Tue, 7 Sep 2004 10:00:13 -0700 Message-ID: From: "McDonald, Ira" To: "'Wes Hardaker'" , ietfdbh@comcast.net Subject: RE: [Isms] documentation style for SBSM: pseudo-code vs text Date: Tue, 7 Sep 2004 10:00:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: sbsm@machshav.com, isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Hi, I was actually leaning toward (c). I find that long paragraphs of text with sprinkled MUST/SHOULD/MAY are generally ignored or misunderstood. Pseudo-code with bullet headers preceded by something like the following would be much less ambiguous: "All assignments (expressed by '=') in the following pseudo-code MUST be implemented by every conforming implementation." Cheers, - Ira PS - I've found SHOULD to be useless in protocol specs. Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]On Behalf Of Wes Hardaker Sent: Tuesday, September 07, 2004 11:48 AM To: ietfdbh@comcast.net Cc: sbsm@machshav.com; isms@ietf.org Subject: Re: [Isms] documentation style for SBSM: pseudo-code vs text >>>>> On Tue, 7 Sep 2004 11:37:00 -0400, "David B Harrington" said: David> I recommend text plus psuedo-code. So both you and Robert are opting for (a) the original style then it sounds like. Paragraph style. I don't want to do a full paragraph plus psuedo-code, however. It's redundant and more work than its worth. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Sep 7 13:38:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13726; Tue, 7 Sep 2004 13:38:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4jz1-0001V2-0B; Tue, 07 Sep 2004 13:42:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4jfx-0000CI-7c; Tue, 07 Sep 2004 13:22:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4jQ0-0001hg-EV for isms@megatron.ietf.org; Tue, 07 Sep 2004 13:06:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10483 for ; Tue, 7 Sep 2004 13:06:05 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4jTT-0000Zu-2v for isms@ietf.org; Tue, 07 Sep 2004 13:09:44 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 18D2712239F; Tue, 7 Sep 2004 10:05:58 -0700 (PDT) To: Subject: Re: [Isms] documentation style for SBSM: pseudo-code vs text References: <200409071632.i87GWd0p001198@nutshell.tislabs.com> From: Wes Hardaker Organization: Sparta Date: Tue, 07 Sep 2004 10:05:57 -0700 In-Reply-To: <200409071632.i87GWd0p001198@nutshell.tislabs.com> (David B. Harrington's message of "Tue, 7 Sep 2004 12:35:21 -0400") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.5 (chayote, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: sbsm@machshav.com, isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 >>>>> On Tue, 7 Sep 2004 12:35:21 -0400, "David B Harrington" said: David> The pseudocode "session.status = CLOSED;" needs to be David> supplemented with some text that indicates this assignment is David> REQUIRED for interoperability. To be clear: if pseudo-code was used, it would *always* be supplemented with text describing what it meant if the intention wasn't clear. I don't think I picked a good example (I pulled a paragraph at random) because I didn't include all the text that would have an impact on the interpretation (like the entire section describing the documentation conventions where the pseudo-code style is described include the paragraph: Finally, it should be important to note that both these equations and the surrounding text must be read and understood in order to get the protocol correct. IE, a successful implementation must take everything into account: both the text wording and the equations. Order of execution of both the text and equations are critical for preserving some of the security properties of the SBSM protocol. The real intent of my question was which would people prefer to read, assuming all integral aspects of the protocol could be specified in both ways. If it was clear in both cases, which would people prefer? It sounds like the general feeling is that it is not possible to describe intents clearly in code much of the time, and thus text should be preferred unless it is nearly impossible to mis-interpret the code. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Sep 7 13:48:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14867; Tue, 7 Sep 2004 13:48:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4k8B-0001qD-LO; Tue, 07 Sep 2004 13:51:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4jno-0003Zx-BO; Tue, 07 Sep 2004 13:30:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4jdw-0007Rf-1H for isms@megatron.ietf.org; Tue, 07 Sep 2004 13:20:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11929 for ; Tue, 7 Sep 2004 13:20:26 -0400 (EDT) Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4jhM-000111-Js for isms@ietf.org; Tue, 07 Sep 2004 13:24:06 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i87HJusB116140; Tue, 7 Sep 2004 13:19:56 -0400 Received: from d03nm118.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i87HJuUR372530; Tue, 7 Sep 2004 11:19:56 -0600 In-Reply-To: To: Wes Hardaker MIME-Version: 1.0 Subject: Re: [Isms] documentation style for SBSM: pseudo-code vs text X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Dinakaran Joseph Date: Tue, 7 Sep 2004 11:19:46 -0600 X-MIMETrack: S/MIME Sign by Notes Client on Dinakaran Joseph/Raleigh/IBM(Release 6.0.2CF1|June 9, 2003) at 09/07/2004 01:19:57 PM, Serialize by Notes Client on Dinakaran Joseph/Raleigh/IBM(Release 6.0.2CF1|June 9, 2003) at 09/07/2004 01:19:57 PM, Serialize complete at 09/07/2004 01:19:57 PM, S/MIME Sign failed at 09/07/2004 01:19:57 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 09/07/2004 11:19:56, Serialize complete at 09/07/2004 11:19:56 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0339812423==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca This is a multipart message in MIME format. --===============0339812423== Content-Type: multipart/alternative; boundary="=_alternative 005F361885256F08_=" This is a multipart message in MIME format. --=_alternative 005F361885256F08_= Content-Type: text/plain; charset="US-ASCII" Hi Wes, As a programmer, I find it much easier to read the psuedo-code rather than the text. Having said that, I would also agree with Dave that there needs to be a way to specify MUST/MAY/SHOULD that the psuedo-code method does not provide. (c) or (d) would be a great way to document the elements of procedure. The comment could specify the MUST/MAY/SHOULD aspect of what needs to happen along with the pseudo-code, if possible. /Dinakaran. --=_alternative 005F361885256F08_= Content-Type: text/html; charset="US-ASCII"
Hi Wes,

As a programmer, I find it much easier to read the psuedo-code rather than the text. Having said that, I would also agree with Dave that there needs to be a way to specify MUST/MAY/SHOULD that the psuedo-code method does not provide. (c) or (d) would be a great way to document the elements of procedure. The comment could specify the MUST/MAY/SHOULD aspect of what needs to happen along with the pseudo-code, if possible.

/Dinakaran.
--=_alternative 005F361885256F08_=-- --===============0339812423== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --===============0339812423==-- From isms-bounces@ietf.org Tue Sep 7 14:01:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16125; Tue, 7 Sep 2004 14:01:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4kKi-00027N-8f; Tue, 07 Sep 2004 14:04:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4k3u-0008Dm-Sd; Tue, 07 Sep 2004 13:47:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4jmI-00035X-5X for isms@megatron.ietf.org; Tue, 07 Sep 2004 13:29:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12918 for ; Tue, 7 Sep 2004 13:29:06 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4jpk-0001HI-SN for isms@ietf.org; Tue, 07 Sep 2004 13:32:46 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 983A411D30B; Tue, 7 Sep 2004 10:29:00 -0700 (PDT) To: isms@ietf.org From: Wes Hardaker Organization: Sparta Date: Tue, 07 Sep 2004 10:28:59 -0700 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.5 (chayote, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Isms] administrative: please don't post to the old list X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Now that the list has moved, please don't post to the old list. The last discussion was CCed to the old list as well as the new one. Nothing will be approved through the old list anymore if the discussion is on the new one as well. I'm only going to look for posts on the old list admin interface that didn't go to the main one as well. It's dead Jim. Thanks! -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Sep 8 10:40:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16584; Wed, 8 Sep 2004 10:40:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C53g8-0001n5-R1; Wed, 08 Sep 2004 10:44:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C53Zx-0002K3-D1; Wed, 08 Sep 2004 10:37:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C53SH-0001Iq-Uw for isms@megatron.ietf.org; Wed, 08 Sep 2004 10:29:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16022 for ; Wed, 8 Sep 2004 10:29:47 -0400 (EDT) Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C53Vv-0001fz-PO for isms@ietf.org; Wed, 08 Sep 2004 10:33:37 -0400 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id KAA27113 for ; Wed, 8 Sep 2004 10:34:00 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma027099; Wed, 8 Sep 04 10:33:16 -0400 Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Wed, 08 Sep 2004 10:28:59 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Wed, 08 Sep 2004 10:28:59 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 8 Sep 2004 10:28:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] documentation style for SBSM: pseudo-code vs text Date: Wed, 8 Sep 2004 10:28:54 -0400 Message-ID: Thread-Topic: [Isms] documentation style for SBSM: pseudo-code vs text Thread-Index: AcSVAY4tLzYCXtqfRDqJhy0tXcPLUQArXfxw From: "Nelson, David" To: "Wes Hardaker" X-OriginalArrivalTime: 08 Sep 2004 14:28:56.0994 (UTC) FILETIME=[2CB33020:01C495B0] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:78.1961 M:98.8113 P:95.9108 R:95.9108 S:56.1982 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: sbsm@machshav.com, isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable > It sounds like the general feeling is that it is not possible to > describe intents clearly in code much of the time, and thus text > should be preferred unless it is nearly impossible to mis-interpret > the code. My personal conviction is that formal languages (e.g. pseudo code) are less ambiguous than natural languages (e.g. English) in describing algorithms. If the intended semantics are that when a protocol implementation receives a protocol data message with the "foo bit" set it must return a message to the peer with the "bar bit" set, then pseudo code is to be preferred. On the other hand, if we are describing the various and sundry conditions under which it is desirable or mandatory to set the "foo bit" in a given protocol data message, then it is likely that natural languages are preferable. I think this touches on the discussion of SHOULD or MUST language. -- Dave _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Sep 8 11:16:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19328; Wed, 8 Sep 2004 11:16:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C54FG-0002TG-UX; Wed, 08 Sep 2004 11:20:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C544Z-0001aR-5E; Wed, 08 Sep 2004 11:09:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C53x3-00089C-KG; Wed, 08 Sep 2004 11:01:37 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18417; Wed, 8 Sep 2004 11:01:35 -0400 (EDT) Message-Id: <200409081501.LAA18417@ietf.org> From: The IESG To: IETF-announce@ietf.org Date: Wed, 08 Sep 2004 11:01:34 -0400 Cc: isms@ietf.org Subject: [Isms] WG Review: Integrated Security Model for SNMP (isms) X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 A new IETF working group has been proposed in the Security Area. The IESG has not made any determination as yet. The following description was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by September 15. Integrated Security Model for SNMP (isms) ========================================= Current Status: Proposed Working Group Description of Working Group: Version 3 of the Simple Network Management Protocol (SNMPv3) was elevated to Internet Standard in late 2002 and added security to the previous versions of the protocol. Although the enhanced protocol is secure, operators and administrators find that deploying it can be problematic in large distributions. This is due primarily to two synchronization problems. The first is the addition of yet another authentication system specific to SNMPv3 that needs to be maintained across all networking devices. Most of these devices already contain local accounts and/or the ability to negotiate with authentication servers (e.g. RADIUS servers). However, SNMPv3 does not make use of these authentication mechanisms, and this causes additional synchronization burdens. The second issue found with deploying SNMPv3 is that distributing and maintaining View-based Access Control Model (VACM) rules is also difficult in large-scale environments. The ISMS working group will focus on finding and identifying a solution for the first of the two above mentioned problems: creating a security model for SNMPv3 that will meet the security and operational needs of network administrators. The solution should maximize useability in operational environments to achieve high deployment success and at the same time minimize implementation and deployment costs to minimize the time until deployment is possible. The work will include the ability to make use of existing and commonly deployed security infrastructure. The following security infrastructures will be considered by the working group as potential existing authentication infrastructures to make use of within the new security model. The solution will hopefully be able to be integrated with multiple of these user databases although it is expected that one will be mandatory. - Local accounts - SSH identities - Radius - TACACS+ - X.509 Certificates - Kerberos - LDAP - Diameter A solution must not modify the other aspects of SNMPv3 protocol as defined in STD 62 (EG, it must not create new PDU types). It should also be compliant with the security model architectural block of SNMPv3, as outlined in RFC 3411. And if at all possible, it should also not change any other protocols either. The working group will begin focusing on initial proposals, which must be submitted for consideration by the Internet-Draft cut-off date for the 61st IETF (Oct 19th, 2004). Documents submitted for consideration need not be well-polished but are expected to adequately describe the proposed model enough that working group participants can adequately understand them to make an informed decision when considering it along with the other candidates. The working group will select one forward path from all the proposals submitted by the cut-off date. If no such selection is made by the end of March, 2004 then the working group will be closed down. Work Items - Choose a technical direction for the working group to focus on. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Sep 8 17:25:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22938; Wed, 8 Sep 2004 17:25:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5A0K-0003Su-SU; Wed, 08 Sep 2004 17:29:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C59iL-00075v-Uf; Wed, 08 Sep 2004 17:10:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C597m-0004Vz-U6 for isms@megatron.ietf.org; Wed, 08 Sep 2004 16:33:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16781 for ; Wed, 8 Sep 2004 16:33:00 -0400 (EDT) Received: from moby.atcorp.com ([204.72.172.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C59BU-0001X3-Bw for isms@ietf.org; Wed, 08 Sep 2004 16:36:53 -0400 Received: from STRIPER (conger.atcorp.com [204.72.172.102]) by moby.atcorp.com (8.11.6/8.11.2) with ESMTP id i88KbrI03723; Wed, 8 Sep 2004 15:37:53 -0500 From: "Wayne Kading" To: "'Wes Hardaker'" Subject: RE: [Isms] documentation style for SBSM: pseudo-code vs text Date: Wed, 8 Sep 2004 15:32:14 -0500 Organization: ATC Message-ID: <004301c495e2$ed743520$84aca8c0@STRIPER> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Score: 0.3 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1707832576==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 This is a multi-part message in MIME format. --===============1707832576== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0044_01C495B9.049E2D20" This is a multi-part message in MIME format. ------=_NextPart_000_0044_01C495B9.049E2D20 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Wes, =20 I agree with the following comment from Joseph. I believe it would also have been important to note in the comment text for the 'c' and 'd' = examples that the MUST aspect also applies to the returned error code. =20 Wayne =20 -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] = On Behalf Of Dinakaran Joseph Sent: Tuesday, September 07, 2004 12:20 PM To: Wes Hardaker Cc: isms@ietf.org Subject: Re: [Isms] documentation style for SBSM: pseudo-code vs text =20 Hi Wes,=20 As a programmer, I find it much easier to read the psuedo-code rather = than the text. Having said that, I would also agree with Dave that there = needs to be a way to specify MUST/MAY/SHOULD that the psuedo-code method does not provide. (c) or (d) would be a great way to document the elements of procedure. The comment could specify the MUST/MAY/SHOULD aspect of what needs to happen along with the pseudo-code, if possible.=20 /Dinakaran.=20 ------=_NextPart_000_0044_01C495B9.049E2D20 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Wes,

 

I agree with the following comment = from Joseph.  I believe it would also have been important to note in the comment = text for the ‘c’ and ‘d’ examples that the MUST = aspect also applies to the returned error code.

 

Wayne

 

-----Original Message-----
From: = isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Dinakaran Joseph
Sent: Tuesday, September = 07, 2004 12:20 PM
To: Wes Hardaker
Cc: isms@ietf.org
Subject: Re: [Isms] = documentation style for SBSM: pseudo-code vs text

 


Hi Wes,

As a programmer, I find it much easier to read the psuedo-code rather than = the text. Having said that, I would also agree with Dave that there needs to = be a way to specify MUST/MAY/SHOULD that the psuedo-code method does not = provide. (c) or (d) would be a great way to document the elements of procedure. = The comment could specify the MUST/MAY/SHOULD aspect of what needs to happen = along with the pseudo-code, if possible.

/Dinakaran.

------=_NextPart_000_0044_01C495B9.049E2D20-- --===============1707832576== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --===============1707832576==-- From isms-bounces@ietf.org Wed Sep 8 17:50:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25028; Wed, 8 Sep 2004 17:50:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5AO1-00045p-SK; Wed, 08 Sep 2004 17:53:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5AFH-00010j-UO; Wed, 08 Sep 2004 17:44:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C59lK-0000Oy-Br for isms@megatron.ietf.org; Wed, 08 Sep 2004 17:13:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21905 for ; Wed, 8 Sep 2004 17:13:51 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C59p2-00039B-AG for isms@ietf.org; Wed, 08 Sep 2004 17:17:45 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 666AC11D941; Wed, 8 Sep 2004 14:13:49 -0700 (PDT) To: "Wayne Kading" Subject: Re: [Isms] documentation style for SBSM: pseudo-code vs text References: <004301c495e2$ed743520$84aca8c0@STRIPER> From: Wes Hardaker Organization: Sparta Date: Wed, 08 Sep 2004 14:13:49 -0700 In-Reply-To: <004301c495e2$ed743520$84aca8c0@STRIPER> (Wayne Kading's message of "Wed, 8 Sep 2004 15:32:14 -0500") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.5 (chayote, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 >>>>> On Wed, 8 Sep 2004 15:32:14 -0500, "Wayne Kading" said: Wayne> I agree with the following comment from Joseph. I believe it Wayne> would also have been important to note in the comment text for Wayne> the 'c' and 'd' examples that the MUST aspect also applies to Wayne> the returned error code. Ok, it is clear from the last few messages that pseudo-code is preferred when the intent (and requirements to implement it) can be made clear. I'll endeavor to do that as I revise it. Thanks for all the input. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Sep 16 16:53:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20803; Thu, 16 Sep 2004 16:53:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C83Lq-0004dd-3e; Thu, 16 Sep 2004 16:59:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C831c-0004Fu-LI; Thu, 16 Sep 2004 16:38:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C82X8-0002Xh-Hw for isms@megatron.ietf.org; Thu, 16 Sep 2004 16:07:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13334 for ; Thu, 16 Sep 2004 16:07:07 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C82cV-0001wl-DV for isms@ietf.org; Thu, 16 Sep 2004 16:12:44 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i8GK75mf001504 for ; Thu, 16 Sep 2004 15:07:06 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 16 Sep 2004 22:07:05 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503C79BD6@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: isms@ietf.org Date: Thu, 16 Sep 2004 22:07:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Isms] IESG just approved the formation of the ISMS WG X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 ISMS friends, the IESG just approved this WG. Formal announcement will follow in the next few days by the IESG secretarait. Bert and Steve _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Sep 16 17:24:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22766; Thu, 16 Sep 2004 17:24:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C83ow-0005OO-8x; Thu, 16 Sep 2004 17:29:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C83U3-00056t-Mw; Thu, 16 Sep 2004 17:08:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C83MF-0002n6-VK for isms@megatron.ietf.org; Thu, 16 Sep 2004 17:00:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21146 for ; Thu, 16 Sep 2004 16:59:57 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C83Rd-0004n3-KC for isms@ietf.org; Thu, 16 Sep 2004 17:05:34 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id AD1FB11D941; Thu, 16 Sep 2004 13:59:47 -0700 (PDT) To: "Wijnen, Bert (Bert)" Subject: Re: [Isms] IESG just approved the formation of the ISMS WG References: <7D5D48D2CAA3D84C813F5B154F43B15503C79BD6@nl0006exch001u.nl.lucent.com> From: Wes Hardaker Organization: Sparta Date: Thu, 16 Sep 2004 13:59:47 -0700 In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15503C79BD6@nl0006exch001u.nl.lucent.com> (Bert Wijnen's message of "Thu, 16 Sep 2004 22:07:04 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.5 (chayote, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 >>>>> On Thu, 16 Sep 2004 22:07:04 +0200, "Wijnen, Bert (Bert)" said: Bert> the IESG just approved this WG. I'd just like to say: :-) :-) :-) :-) :-) :-) -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Sep 22 09:28:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05807; Wed, 22 Sep 2004 09:28:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA7HA-00073Z-Cz; Wed, 22 Sep 2004 09:35:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA782-00024w-Qa; Wed, 22 Sep 2004 09:25:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9kVz-0001zX-QB for isms@megatron.ietf.org; Tue, 21 Sep 2004 09:17:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12586 for ; Tue, 21 Sep 2004 09:17:02 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9kcL-0002hL-Pj for isms@ietf.org; Tue, 21 Sep 2004 09:23:39 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8LDGPi05721; Tue, 21 Sep 2004 16:16:25 +0300 Date: Tue, 21 Sep 2004 16:16:25 +0300 (EEST) From: Pekka Savola To: snmpv3@lists.tislabs.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-Mailman-Approved-At: Wed, 22 Sep 2004 09:25:50 -0400 Cc: isms@ietf.org Subject: [Isms] Why SNMPv3? [WG Review: Integrated Security Model for SNMP (isms)] X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Hi, [note: I'm not subscribed on either list] Now that the IESG has approved the isms WG, it might be OK for me to raise one particular issue which is slightly off-topic but might be worth bringing up in order to make sure that it's adequately addressed. That is, I haven't found (granted, I haven't tried looking hard) a concise statement(s) to the question that's relevant to many operators (including the NREN/ISP I'm associated with): What benefits does SNMPv3 offer to us, compared to our use of SNMPv1 and SNMPv2? The isms WG problem statement (below) brings up two problems with access controls, but it is not clear whether these are the only two (major) reasons for using SNMPv3 instead of SNMPv1/2. It is important to figure out the answer to this question so that we don't misinterpret why many operators are not using SNMPv3 and the security model (below). On Wed, 8 Sep 2004, The IESG wrote: > A new IETF working group has been proposed in the Security Area. The IESG has not made > any determination as yet. The following description was submitted, and is provided > for informational purposes only. Please send your comments to the IESG mailing list > (iesg@ietf.org) by September 15. > > Integrated Security Model for SNMP (isms) > ========================================= > > Current Status: Proposed Working Group > > Description of Working Group: > > Version 3 of the Simple Network Management Protocol (SNMPv3) was > elevated to Internet Standard in late 2002 and added security to the > previous versions of the protocol. Although the enhanced protocol > is secure, operators and administrators find that deploying it can > be problematic in large distributions. This is due primarily to two > synchronization problems. The first is the addition of yet another > authentication system specific to SNMPv3 that needs to be maintained > across all networking devices. Most of these devices already > contain local accounts and/or the ability to negotiate with > authentication servers (e.g. RADIUS servers). However, SNMPv3 does > not make use of these authentication mechanisms, and this causes > additional synchronization burdens. The second issue found with > deploying SNMPv3 is that distributing and maintaining View-based > Access Control Model (VACM) rules is also difficult in large-scale > environments. [...] -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Sep 22 10:08:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09163; Wed, 22 Sep 2004 10:08:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA7te-0007pN-Hn; Wed, 22 Sep 2004 10:15:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA7g7-0008Ik-Dk; Wed, 22 Sep 2004 10:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA7cc-0007E1-Rw for isms@megatron.ietf.org; Wed, 22 Sep 2004 09:57:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08107 for ; Wed, 22 Sep 2004 09:57:24 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA7jC-0007eg-1R for isms@ietf.org; Wed, 22 Sep 2004 10:04:15 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 9833211D941; Wed, 22 Sep 2004 06:57:19 -0700 (PDT) To: Pekka Savola Subject: Re: [Isms] Why SNMPv3? [WG Review: Integrated Security Model for SNMP (isms)] References: From: Wes Hardaker Organization: Sparta Date: Wed, 22 Sep 2004 06:57:19 -0700 In-Reply-To: (Pekka Savola's message of "Tue, 21 Sep 2004 16:16:25 +0300 (EEST)") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.5 (chayote, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: snmpv3@lists.tislabs.com, isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 >>>>> On Tue, 21 Sep 2004 16:16:25 +0300 (EEST), Pekka Savola said: Pekka> What benefits does SNMPv3 offer to us, compared to our use of Pekka> SNMPv1 and SNMPv2? Security? That's the primary achievement of SNMPv3 over anything previous. SNMPv1 and SNMPv2c aren't even close to secure. SNMPv3 is, albeit with some of the deployment problems that ISMS is hoping to fix. SNMPv3 contains other miscellaneous improvements as well (max msg size specification, ...) -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Sep 22 12:05:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19923; Wed, 22 Sep 2004 12:05:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA9jO-0001uA-7U; Wed, 22 Sep 2004 12:12:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA9Vw-0000g1-1H; Wed, 22 Sep 2004 11:58:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA9Nl-0006a2-I9 for isms@megatron.ietf.org; Wed, 22 Sep 2004 11:50:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18443 for ; Wed, 22 Sep 2004 11:50:10 -0400 (EDT) Message-Id: <200409221550.LAA18443@ietf.org> Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA9UM-0001RC-R6 for isms@ietf.org; Wed, 22 Sep 2004 11:57:03 -0400 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc12) with SMTP id <2004092215494101200mhjore>; Wed, 22 Sep 2004 15:49:41 +0000 From: "David B Harrington" To: "'Wes Hardaker'" , "'Pekka Savola'" Subject: RE: [Isms] Why SNMPv3? [WG Review: Integrated Security Model for SNMP (isms)] Date: Wed, 22 Sep 2004 11:49:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: Thread-Index: AcSgtAMc7nJZYn7jSZKMcNyRw7/mcAAAa8Aw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: 7bit Cc: snmpv3@lists.tislabs.com, isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: 7bit Hi, As Wes point sout, SNMPv3 provides security enhancements, but I think we need to be more specific. 1) SNMPv3 provides an application-level authentication of the security principal. I could just run SNMPv1 over IPSec and have "security". But as Jeff Schiller's Sunday Security presentation points out, "just use IPSec" isn't good enough as an answer. One needs to understand how SNMP has bindings to any underlying security mechanisms. That fact is, there are no bindings to an SNMP application (agent/manager) because, at this point, an underlying IPSec, SSH, TLS, VPN, or whatever does not identify an authenticated application-layer security principal that SNMP can use to apply access control. 2) SNMPv3 USM provides robust authentication of a security principal. Do operators want user-level access control? They have user-level authentication in SSH to control access to the CLI. Most web-based device configuration tools require some sort of user-based authentication to control who has access. So it appears that user-level authentication is desired to control who is granted access to the management interface. But the CLI, web-based mgmt, and SNMP-based mgmt all control the same underlying instrumentation. If SNMP (or CLI or web-based or Netconf or ....) doesn't provide a comparable level of authentication for access, then an attacker can simply select the management interface with the weakest security to gain access to the underlying instrumentation. The security of the different interfaces need to be balanced. Ideally, they might share a common authentication mechanism. SNMPv1 and SNMPv2 do not provide this beyond the trivial authentication provided by community strings, and since these ar epassed in cleartext, they really provide no security. SNMPv3 USM provides robust authentication of a security principal. I deliberately say security principal rather than user because many organizations configure their devices to permit a trusted application to have access. For example, Spectrum has a user login to the application, and Spectrum is a USM security princiapl in many devices. The manager application aggregates the requests of many users. For another example, many applications actually don't support SNMPv3; they use local SNMPv1 or IPC to talk to a daemon that converts the request into the secure SNMPv3 format, and the daemon is a security principal at the managed device. I raise this only because in these cases, operators apparently do NOT care if the operator is authenticated. If the CLI,web,Netconf interfaces provided manager-level authentication, and the manager interface aggregated services for authenticated users, then all the interfaces could be balanced. I don't know whether this is adeqaute for all operators, but it apparently is adequate for some. 3) SNMPv3 provides access control over the principal's data-level authorization SNMPv3 provides per-principal control over what operations can be performed, to which datasets (contexts or communities), to which mib modules within the data set, and to which subtrees of the dataset (all the way down to the object level if desired). SNMPv1 and SNMPv2 cannot provide this because they cannot provide authentication of the principal, and without an authenticated principal, the additional controls make no sense. Do operators want user-level access control to different portions of the management data? We were told by the operators, especially Mike O'Dell, that it was critically important functionality. Mike O'Dell told us UUNET would refuse to buy products that did not have this functionality. CLIs and web-based mgmt tools often provide per-user task-based authorization functionality for those management interfaces. For applications that are confiured as an SNMPv3 security principal, the manager typically provides thi slevel of access control within the application, because customers demand this type of per-user access control to datasets/modules/objects, etc. Do operators want this functionality or not? I suspect different operators have different levels of authroization (and user aggregation) they find useful, which depends on the companies they work for and the environment in which they operate. SNMPv3 can provide this functionaity; SNMPv1 and SNMPv3 do not. If SNMP doesn't provide this, while the CLI and web-based interfaces do, then the security of the management infrastructure is weakened across the board. -- Those are the major features provided by SNMPv3 that are not provided by SNMPv1 and SNMPv2. It is important that these features be present in SNMP to provide balanced security with the other common management interfaces. David Harrington dbharrington@comcast.net co-chair SNMPv3 WG, concluded -----Original Message----- From: owner-snmpv3@lists.tislabs.com [mailto:owner-snmpv3@lists.tislabs.com] On Behalf Of Wes Hardaker Sent: Wednesday, September 22, 2004 9:57 AM To: Pekka Savola Cc: snmpv3@lists.tislabs.com; isms@ietf.org Subject: Re: [Isms] Why SNMPv3? [WG Review: Integrated Security Model for SNMP (isms)] >>>>> On Tue, 21 Sep 2004 16:16:25 +0300 (EEST), Pekka Savola said: Pekka> What benefits does SNMPv3 offer to us, compared to our use of Pekka> SNMPv1 and SNMPv2? Security? That's the primary achievement of SNMPv3 over anything previous. SNMPv1 and SNMPv2c aren't even close to secure. SNMPv3 is, albeit with some of the deployment problems that ISMS is hoping to fix. SNMPv3 contains other miscellaneous improvements as well (max msg size specification, ...) -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Sep 23 01:26:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28420; Thu, 23 Sep 2004 01:26:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAMEO-0008He-6G; Thu, 23 Sep 2004 01:33:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAM6k-0006aT-5l; Thu, 23 Sep 2004 01:25:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAM4i-0006G1-Li for isms@megatron.ietf.org; Thu, 23 Sep 2004 01:23:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28274 for ; Thu, 23 Sep 2004 01:23:23 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAMBL-0008Ec-GU for isms@ietf.org; Thu, 23 Sep 2004 01:30:21 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id D951A11D3AA; Wed, 22 Sep 2004 22:23:14 -0700 (PDT) To: Pekka Savola Subject: Re: [Isms] Why SNMPv3? [WG Review: Integrated Security Model for SNMP (isms)] References: From: Wes Hardaker Organization: Sparta Date: Wed, 22 Sep 2004 22:23:14 -0700 In-Reply-To: (Pekka Savola's message of "Thu, 23 Sep 2004 07:51:24 +0300 (EEST)") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.5 (chayote, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: snmpv3@lists.tislabs.com, isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab >>>>> On Thu, 23 Sep 2004 07:51:24 +0300 (EEST), Pekka Savola said: Pekka> .. then the justification for SNMPv3's increased security Pekka> features would indeed be higher. But few folks do SNMP writes, Pekka> and many don't bother providing SNMP access to untrusted Pekka> parties, so the features may not be all that interesting. You fall right into one category of users, I agree. Your situation is likely even common. However, its not the only case. If you look at the proceeding slides from the last ISMS BOF you'll see that the variation in who is using SNMP, what versions they're using, how they're using it and what they want from it don't boil down to a single case. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Sep 23 09:26:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11400; Thu, 23 Sep 2004 09:26:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CATiq-0007nH-Ls; Thu, 23 Sep 2004 09:33:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CATaY-0007mp-Lh; Thu, 23 Sep 2004 09:24:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CALbA-0006yZ-Lo for isms@megatron.ietf.org; Thu, 23 Sep 2004 00:52:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26459 for ; Thu, 23 Sep 2004 00:52:49 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CALhp-0007lH-F8 for isms@ietf.org; Thu, 23 Sep 2004 00:59:49 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8N4pOn29470; Thu, 23 Sep 2004 07:51:25 +0300 Date: Thu, 23 Sep 2004 07:51:24 +0300 (EEST) From: Pekka Savola To: David B Harrington Subject: RE: [Isms] Why SNMPv3? [WG Review: Integrated Security Model for SNMP (isms)] In-Reply-To: <200409221549.i8MFnmQ11501@netcore.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 X-Mailman-Approved-At: Thu, 23 Sep 2004 09:24:45 -0400 Cc: isms@ietf.org, snmpv3@lists.tislabs.com X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Thanks for the explicit note. On Wed, 22 Sep 2004, David B Harrington wrote: > As Wes point sout, SNMPv3 provides security enhancements, but I think > we need to be more specific. > > 1) SNMPv3 provides an application-level authentication of the security > principal. [...] > 2) SNMPv3 USM provides robust authentication of a security principal. [...] > 3) SNMPv3 provides access control over the principal's data-level > authorization [...] So, in short, the security features (different kinds) set SNMPv3 apart from SNMPv1/2. Then I'll have to say that SNMPv3 does not seem all that interesting to many operators, but I'll totally agree that some indeed absolutely want these features. Let's consider our particular case (a national research network). I guess it should be quite common. 1) we only use SNMP for read-only access. 2) we only use SNMP to the routers from (about) two network management hosts within our own network. 2.b) there is one external host from a network monitoring organization, using separate [direct] connectivity, which has the same RO privileges 3) we restrict the access to the SNMP port [in all the routers] to the IP addresses of the network management. 4) we eliminate IP spoofing of the network management host addresses (actually all the addresses, but that's beside the point) at the edge. To sum it up, as we use SNMP only for RO, the hosts are well-defined, and the borders are secure, we don't need any encryption or strong authentication. Community 'public' is good enough. Further, we also don't require providing different views to the different users (two our own, 1 external) -- that would be more trouble than its worth. It should seem obvious to me why a lot of folks still stick to SNMPv1/2, and will continue to do so. On the other hand, if we wanted to do something like: - SNMP writes (e.g., config updates, etc.) - provide the customers access to certain parts of the MIB tree of their (C)PE router [though some of this is already part of SNMPv2 I recall] - [etc.] .. then the justification for SNMPv3's increased security features would indeed be higher. But few folks do SNMP writes, and many don't bother providing SNMP access to untrusted parties, so the features may not be all that interesting. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Sep 23 10:19:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16460; Thu, 23 Sep 2004 10:19:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAUYo-0000Ik-Qp; Thu, 23 Sep 2004 10:27:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAUO2-0002KX-LN; Thu, 23 Sep 2004 10:15:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAUHb-0008FC-QA for isms@megatron.ietf.org; Thu, 23 Sep 2004 10:09:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15255 for ; Thu, 23 Sep 2004 10:09:13 -0400 (EDT) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAUOK-000086-Mc for isms@ietf.org; Thu, 23 Sep 2004 10:16:17 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id A75EC99F6; Thu, 23 Sep 2004 16:08:37 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 14587-03; Thu, 23 Sep 2004 16:08:36 +0200 (CEST) Received: from james (unknown [212.201.46.187]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 883D29AFA; Thu, 23 Sep 2004 16:08:34 +0200 (CEST) Received: from schoenw by james with local (Exim 4.34) id 1CAUGw-0000fq-IZ; Thu, 23 Sep 2004 16:08:34 +0200 Date: Thu, 23 Sep 2004 16:08:34 +0200 From: Juergen Schoenwaelder To: Pekka Savola Subject: Re: [Isms] Why SNMPv3? [WG Review: Integrated Security Model for SNMP (isms)] Message-ID: <20040923140834.GA2580@james> Mail-Followup-To: Pekka Savola , isms@ietf.org, snmpv3@lists.tislabs.com References: <200409221549.i8MFnmQ11501@netcore.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: isms@ietf.org, snmpv3@lists.tislabs.com X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 On Thu, Sep 23, 2004 at 07:51:24AM +0300, Pekka Savola wrote: > To sum it up, as we use SNMP only for RO, the hosts are well-defined, > and the borders are secure, we don't need any encryption or strong > authentication. [...] > On the other hand, if we wanted to do something like: > - SNMP writes (e.g., config updates, etc.) > - provide the customers access to certain parts of the MIB tree of > their (C)PE router [though some of this is already part of SNMPv2 I > recall] > - [etc.] > .. then the justification for SNMPv3's increased security features > would indeed be higher. This goes back to a rather old discussion whether there are environments where SNMP writes are used, how big these environments might be (I leave it to you do define the metric) and whether the IETF should worry about these environments. There are two camps, one arguing that SNMP writes are just an illusion since nobody actually uses them. The other camp claims that SNMP writes are a reality (or believes they will become a reality once all the security issues have been solved). To this end, there was never a real investigation to sort this out. It would be more than interesting to collect packet traces from real-world networks (and not just ISP IP networks since SNMP seems to be used quite a bit in telco networks, cable networks, enterprise networks largely based on IEEE 802 LANs, ATM networks, ...) just to see which features of SNMP are used and to which extend and for which purpose. The NMRG is (slowly) working on creating up a measurement infrastructure (means easy to use tools) which will hopefully lead to answers to some of these questions. If you are running networks and want to help with this, please get in contact with me since we need to create a pool of people running very different networks who help us to get the necessary data we need. Bottom line: We do not really know how SNMP is used in practice. Different opinions do exist and debating them is at the end wasted time. We therefore need to collect facts and I believe this is not too hard to do, even taking privacy issues related to packet traces into account. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Sep 23 10:33:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17388; Thu, 23 Sep 2004 10:33:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAUlQ-0000XW-NY; Thu, 23 Sep 2004 10:40:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAUdI-0005av-JB; Thu, 23 Sep 2004 10:31:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAUXr-0004R2-LL; Thu, 23 Sep 2004 10:26:03 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16840; Thu, 23 Sep 2004 10:26:00 -0400 (EDT) Message-Id: <200409231426.KAA16840@ietf.org> From: The IESG To: IETF-Announce@ietf.org Date: Thu, 23 Sep 2004 10:26:00 -0400 Cc: isms@ietf.org Subject: [Isms] WG Action: Integrated Security Model for SNMP (isms) X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f A new IETF working group has been formed in the Security Area. For additional information, please contact the Area Directors or the WG Chairs. Integrated Security Model for SNMP (isms) ========================================= Current Status: Active Working Group Chair(s): Ken Hornstein Juergen Quittek Security Area Director(s) Steven Bellovin Russell Housley Security Area Advisor: Steven Bellovin ; Thu, 23 Sep 2004 11:19:23 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAVUJ-0001n6-Ci for isms@ietf.org; Thu, 23 Sep 2004 11:26:28 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id i8NFIoHW023965; Thu, 23 Sep 2004 08:18:50 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Thu, 23 Sep 2004 08:18:51 -0700 Message-ID: From: "McDonald, Ira" To: "'Pekka Savola'" , David B Harrington Subject: RE: [Isms] Why SNMPv3? [WG Review: Integrated Security Model for SNMP (isms)] Date: Thu, 23 Sep 2004 08:18:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: isms@ietf.org, snmpv3@lists.tislabs.com X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Hi Pekka, SNMPv1 read-only still allows anyone INSIDE your network to monitor and read interesting configuration and event info from your routers by packet-sniffing. And your "direct" connection to your outside network manager had better be entirely non-Internet (or completely encrypted) if you want reasonable security and also availability for their network management functionality. I'd say secure SNMPv3 has a lot to offer in your network. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]On Behalf Of Pekka Savola Sent: Thursday, September 23, 2004 12:51 AM To: David B Harrington Cc: isms@ietf.org; snmpv3@lists.tislabs.com Subject: RE: [Isms] Why SNMPv3? [WG Review: Integrated Security Model for SNMP (isms)] <...snip...> Let's consider our particular case (a national research network). I guess it should be quite common. 1) we only use SNMP for read-only access. 2) we only use SNMP to the routers from (about) two network management hosts within our own network. 2.b) there is one external host from a network monitoring organization, using separate [direct] connectivity, which has the same RO privileges 3) we restrict the access to the SNMP port [in all the routers] to the IP addresses of the network management. 4) we eliminate IP spoofing of the network management host addresses (actually all the addresses, but that's beside the point) at the edge. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Sep 23 11:49:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24725; Thu, 23 Sep 2004 11:49:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAVxc-0002XI-HR; Thu, 23 Sep 2004 11:56:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAVmT-0002Y1-E0; Thu, 23 Sep 2004 11:45:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAVRZ-0007ad-Vb for isms@megatron.ietf.org; Thu, 23 Sep 2004 11:23:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22612 for ; Thu, 23 Sep 2004 11:23:35 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAVYM-0001x6-7Z for isms@ietf.org; Thu, 23 Sep 2004 11:30:40 -0400 Received: from [10.1.1.171] (dummy.netlab.nec.de [195.37.70.40]) by kyoto.netlab.nec.de (Postfix) with ESMTP id A5E861BAC4D; Thu, 23 Sep 2004 17:23:00 +0200 (CEST) Date: Thu, 23 Sep 2004 17:23:00 +0200 From: Juergen Quittek To: isms@ietf.org Message-ID: <1171138004.1095960180@[10.1.1.171]> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Subject: [Isms] ISMS solution seslection procedure X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Dear all, Welcome to the ISMS working group! We have a very ambitious schedule and need to start discussing how we want to achieve our goal in time. Our major objective is selecting a solution for integrating SNMP with a security infrastructure as described in the charter. The charter also defines a submission deadline for solutions, but it does not specify the selection process. This message is a first step towards an agreement on the selection process. Basically, we have to evaluate all submitted solutions and then select one. For the evaluation we need a list of evaluation criteria and evaluators. Wes already spent a lot of time on identifying criteria/requirements. We should start with his list and discuss it on a separate email thread. Concerning the evaluators it can be useful to have a look at other WGs. Similar selections were made in the SEAMOBY, IPFIX and MIDCOM WGs. In the SEAMOBY WG the chairs evaluated proposed solutions, in the IPFIX and MIDCOM WGs an evaluations team performed this task. Since SEAMOBY decision ended up in a disaster (shutting down the entire work item at the IETF) it might be a good idea to go the way of IPFIX and MIDCOM where the decisions went reasonably well. Of course we are free to go our own way and our experiences may be completely different from the ones made in SEAMOBY, IPFIX and MIDCOM. So, please give us your opinion on the evaluators. Do you prefer - the WG chairs - an evaluation team - others ??? The evaluators should prepare a written evaluation and give a recommendation. Preferably the evaluation and recommendation should be available as an Internet draft, see for example . Ideally, a first version of this draft (containing the final list of evaluation criteria, but probably not yet any evaluation) would already be posted by the deadline for submitting solutions. Then we need to hurry to get to a recommendation in November. Please send any comment, suggestion, opinion on the selection procedure. And since little time is left, please send it rather soon than late. Thanks, Ken and Juergen _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Sep 23 12:25:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27637; Thu, 23 Sep 2004 12:25:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAWWS-0003Oh-Up; Thu, 23 Sep 2004 12:32:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAWG3-0001BO-Bw; Thu, 23 Sep 2004 12:15:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAW0u-0005dL-Tz for isms@megatron.ietf.org; Thu, 23 Sep 2004 12:00:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25494 for ; Thu, 23 Sep 2004 12:00:05 -0400 (EDT) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAW7g-0002lG-AU for isms@ietf.org; Thu, 23 Sep 2004 12:07:11 -0400 Received: from NHROCAVG2.ets.enterasys.com (nhrocavg2.enterasys.com [134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id i8NG03ao000365 for ; Thu, 23 Sep 2004 12:00:03 -0400 (EDT) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Thu, 23 Sep 2004 12:00:03 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Thu, 23 Sep 2004 12:00:03 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 23 Sep 2004 12:00:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] ISMS solution seslection procedure Date: Thu, 23 Sep 2004 12:00:03 -0400 Message-ID: Thread-Topic: [Isms] ISMS solution seslection procedure Thread-Index: AcShhPq0Mz3K6xlmQEmlCDGje7xCwAAAVJZA From: "Nelson, David" To: X-OriginalArrivalTime: 23 Sep 2004 16:00:03.0504 (UTC) FILETIME=[6330AB00:01C4A186] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:78.1961 M:98.9607 P:95.9108 R:95.9108 S:44.7427 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Content-Transfer-Encoding: quoted-printable X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: quoted-printable I prefer an evaluation team. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Sep 23 12:48:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00475; Thu, 23 Sep 2004 12:48:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAWsv-0004Jb-Sn; Thu, 23 Sep 2004 12:55:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAWeI-0008Gd-Us; Thu, 23 Sep 2004 12:40:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAWHE-0001f7-Se for isms@megatron.ietf.org; Thu, 23 Sep 2004 12:17:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26629 for ; Thu, 23 Sep 2004 12:16:57 -0400 (EDT) Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103] helo=hosting.revelstone.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAWO2-000388-Ih for isms@ietf.org; Thu, 23 Sep 2004 12:24:03 -0400 Received: from localhost ([127.0.0.1] helo=dev.localdomain) by hosting.revelstone.com with smtp (Exim 4.42) id 1CAWHB-0005LS-Hf; Thu, 23 Sep 2004 12:16:57 -0400 Date: Thu, 23 Sep 2004 12:16:57 -0400 From: Robert Story To: isms@ietf.org Subject: Re: [Isms] Why SNMPv3? [WG Review: Integrated Security Model for SNMP (isms)] Message-Id: <20040923121657.3312b5e9@dev.localdomain> In-Reply-To: <20040923140834.GA2580@james> References: <200409221549.i8MFnmQ11501@netcore.fi> <20040923140834.GA2580@james> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.revelstone.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - freesnmp.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: snmpv3@lists.tislabs.com X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit On Thu, 23 Sep 2004 16:08:34 +0200 Juergen wrote: JS> This goes back to a rather old discussion whether there are environments JS> where SNMP writes are used, how big these environments might be (I leave JS> it to you do define the metric) and whether the IETF should worry about JS> these environments. There are two camps, one arguing that SNMP writes JS> are just an illusion since nobody actually uses them. The other camp JS> claims that SNMP writes are a reality (or believes they will become a JS> reality once all the security issues have been solved). SNMP writes are a reality. I personally have developed at least 3 SNMP agents with write support that interface with existing proprietary control mechanisms. JS> To this end, there was never a real investigation to sort this out. It JS> would be more than interesting to collect packet traces from real-world JS> networks (and not just ISP IP networks since SNMP seems to be used quite JS> a bit in telco networks, cable networks, enterprise networks largely JS> based on IEEE 802 LANs, ATM networks, ...) All of the agents were for clients in the cable industry who were adding SNMP support under pressure from their customers. All used SNMP v1/v2c, relaying on a non-public network for access control. -- Robert Story; NET-SNMP Junkie You are lost in a twisty maze of little standards, all different. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Sep 23 13:24:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02847; Thu, 23 Sep 2004 13:24:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAXRX-00054W-MF; Thu, 23 Sep 2004 13:31:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAXC5-0007OM-4m; Thu, 23 Sep 2004 13:15:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAWuz-0003gb-SR for isms@megatron.ietf.org; Thu, 23 Sep 2004 12:58:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01023 for ; Thu, 23 Sep 2004 12:58:02 -0400 (EDT) Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAX1o-0004UO-GW for isms@ietf.org; Thu, 23 Sep 2004 13:05:09 -0400 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id i8NGw2qt013220; Thu, 23 Sep 2004 09:58:02 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id i8NGw2aM013215; Thu, 23 Sep 2004 09:58:02 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 23 Sep 2004 09:58:02 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Pekka Savola Subject: RE: [Isms] Why SNMPv3? [WG Review: Integrated Security Model for SNMP (isms)] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: isms@ietf.org, snmpv3@lists.tislabs.com X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 HI, Do you use syslog? Are you dissatisfied with it? Do you know it's limitations? If you answsered "yes" to any of the above, then I believe that SNMPv3/SBSM will provide you great benefit. In SNMPv3/USM, the mechanisms for administering notifications was, I believe pretty horrible. However, I believe that using SNMPv3/SBSM with a little work on the MIB modules for notification targets and loggings, then we will have a real winner. And, all of the below I believe, but I also believe that with SNMPv3/SBSM it will be even easier to deploy a new system than what is required for SNMPv1 and SNMPv2c. On Thu, 23 Sep 2004, Pekka Savola wrote: > Thanks for the explicit note. > > On Wed, 22 Sep 2004, David B Harrington wrote: > > As Wes point sout, SNMPv3 provides security enhancements, but I think > > we need to be more specific. > > > > 1) SNMPv3 provides an application-level authentication of the security > > principal. > [...] > > 2) SNMPv3 USM provides robust authentication of a security principal. > [...] > > 3) SNMPv3 provides access control over the principal's data-level > > authorization > [...] > > So, in short, the security features (different kinds) set SNMPv3 apart > from SNMPv1/2. > > Then I'll have to say that SNMPv3 does not seem all that interesting > to many operators, but I'll totally agree that some indeed absolutely > want these features. > > Let's consider our particular case (a national research network). I > guess it should be quite common. > > 1) we only use SNMP for read-only access. > 2) we only use SNMP to the routers from (about) two network > management hosts within our own network. > 2.b) there is one external host from a network monitoring > organization, using separate [direct] connectivity, which has the same > RO privileges > 3) we restrict the access to the SNMP port [in all the routers] to > the IP addresses of the network management. > 4) we eliminate IP spoofing of the network management host addresses > (actually all the addresses, but that's beside the point) at the edge. > > To sum it up, as we use SNMP only for RO, the hosts are well-defined, > and the borders are secure, we don't need any encryption or strong > authentication. Community 'public' is good enough. Further, we also > don't require providing different views to the different users (two > our own, 1 external) -- that would be more trouble than its worth. > > It should seem obvious to me why a lot of folks still stick to > SNMPv1/2, and will continue to do so. > > On the other hand, if we wanted to do something like: > - SNMP writes (e.g., config updates, etc.) > - provide the customers access to certain parts of the MIB tree of > their (C)PE router [though some of this is already part of SNMPv2 I > recall] > - [etc.] > > .. then the justification for SNMPv3's increased security features > would indeed be higher. But few folks do SNMP writes, and many don't > bother providing SNMP access to untrusted parties, so the features may > not be all that interesting. > > -- > Pekka Savola "You each name yourselves king, yet the Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Sep 23 13:43:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04013; Thu, 23 Sep 2004 13:43:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAXjk-0005Pm-5M; Thu, 23 Sep 2004 13:50:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAXZB-0002qi-9g; Thu, 23 Sep 2004 13:39:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAXNo-0001JF-Ui for isms@megatron.ietf.org; Thu, 23 Sep 2004 13:27:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03113 for ; Thu, 23 Sep 2004 13:27:49 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAXUd-00058Y-Tr for isms@ietf.org; Thu, 23 Sep 2004 13:34:56 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8NHR5c16006; Thu, 23 Sep 2004 20:27:08 +0300 Date: Thu, 23 Sep 2004 20:27:05 +0300 (EEST) From: Pekka Savola To: "McDonald, Ira" Subject: RE: [Isms] Why SNMPv3? [WG Review: Integrated Security Model for SNMP (isms)] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: isms@ietf.org, snmpv3@lists.tislabs.com X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 I agree that this may be a partially useless discussion, but hopefully it would help in ensuring that the applicability of different SNMP management techniques remains to be clearly spelled out.. Combining two messages. On Thu, 23 Sep 2004, McDonald, Ira wrote: > SNMPv1 read-only still allows anyone INSIDE your network to > monitor and read interesting configuration and event info > from your routers by packet-sniffing. Certainly, but you can do a lot of things if you're able to sniff the packets (practically requiring a physical man-in-the-middle attack or the like :), including over 99% of all traffic. If an attacker is able to do that, I would be surprised if the read-only information of the routers was all that interesting in comparison. > And your "direct" connection to your outside network manager > had better be entirely non-Internet (or completely encrypted) > if you want reasonable security and also availability for > their network management functionality. It's, as said, "direct" in the sense that it isn't routed over the Internet. >From David Perkins: > Do you use syslog? Are you dissatisfied with it? Do you know it's > limitations? > > If you answsered "yes" to any of the above, then I believe that > SNMPv3/SBSM will provide you great benefit. Yes. Works for 95% but there are some issues. At least some of them. The biggest issue is the unreliability of the transport, i.e., when link goes down, the syslog message may end up being lost. In future, it might also be useful to provide more finer-grained manage what information to send and where. > In SNMPv3/USM, the mechanisms for administering notifications > was, I believe pretty horrible. However, I believe that using > SNMPv3/SBSM with a little work on the MIB modules for notification > targets and loggings, then we will have a real winner. > > And, all of the below I believe, but I also believe that with > SNMPv3/SBSM it will be even easier to deploy a new system than > what is required for SNMPv1 and SNMPv2c. Traps/notification is indeed an area of interesting potential. However, it is still not clear what kind of authentication is required there, in the case you can filter out bogus traps based on the IP address. The greatest advantages seem to be a reliable transport, better specification of which notifications to send and to where, and more advanced means of de-multiplexing the notifications to different watcher processes, but I would be surprised if this wasn't doable already (compare to e.g. demux capabilities of syslog-ng). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Sep 23 13:55:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04912; Thu, 23 Sep 2004 13:55:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAXvX-0005iD-22; Thu, 23 Sep 2004 14:02:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAXct-0003Q9-Ip; Thu, 23 Sep 2004 13:43:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAXYx-0002mF-7L for isms@megatron.ietf.org; Thu, 23 Sep 2004 13:39:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03819 for ; Thu, 23 Sep 2004 13:39:21 -0400 (EDT) Message-Id: <200409231739.NAA03819@ietf.org> Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAXfl-0005Ls-OQ for isms@ietf.org; Thu, 23 Sep 2004 13:46:26 -0400 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc13) with SMTP id <20040923173850016000a835e>; Thu, 23 Sep 2004 17:38:51 +0000 From: "David B Harrington" To: "'Juergen Quittek'" , Subject: RE: [Isms] ISMS solution seslection procedure Date: Thu, 23 Sep 2004 13:38:46 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <1171138004.1095960180@[10.1.1.171]> Thread-Index: AcShhPAmDttZWG7YRvOIH9EV08iFUAADv9Ig X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit I prefer an evaluation team. I would like to see each proposal reviewed by a security expert and an SNMPv3 expert to consider compliance to best current practices. dbh _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Sep 23 13:56:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05002; Thu, 23 Sep 2004 13:56:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAXwo-0005jw-GM; Thu, 23 Sep 2004 14:04:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAXjv-0004f8-5X; Thu, 23 Sep 2004 13:50:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAVWq-0008Mb-NT for isms@megatron.ietf.org; Thu, 23 Sep 2004 11:29:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22900 for ; Thu, 23 Sep 2004 11:29:01 -0400 (EDT) Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103] helo=hosting.revelstone.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAVdb-00023J-QB for isms@ietf.org; Thu, 23 Sep 2004 11:36:04 -0400 Received: from localhost ([127.0.0.1] helo=dev.localdomain) by hosting.revelstone.com with smtp (Exim 4.42) id 1CAVWj-00053P-Ab; Thu, 23 Sep 2004 11:28:57 -0400 Date: Thu, 23 Sep 2004 11:28:57 -0400 From: Robert Story To: isms@ietf.org Subject: Re: [Isms] Why SNMPv3? [WG Review: Integrated Security Model for SNMP (isms)] Message-Id: <20040923112857.4e959de9@dev.localdomain> In-Reply-To: <20040923140834.GA2580@james> References: <200409221549.i8MFnmQ11501@netcore.fi> <20040923140834.GA2580@james> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.revelstone.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - revelstone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 23 Sep 2004 13:50:42 -0400 Cc: snmpv3@lists.tislabs.com X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit On Thu, 23 Sep 2004 16:08:34 +0200 Juergen wrote: JS> This goes back to a rather old discussion whether there are environments JS> where SNMP writes are used, how big these environments might be (I leave JS> it to you do define the metric) and whether the IETF should worry about JS> these environments. There are two camps, one arguing that SNMP writes JS> are just an illusion since nobody actually uses them. The other camp JS> claims that SNMP writes are a reality (or believes they will become a JS> reality once all the security issues have been solved). SNMP writes are a reality. I personally have developed at least 3 SNMP agents with write support that interface with existing proprietary control mechanisms. JS> To this end, there was never a real investigation to sort this out. It JS> would be more than interesting to collect packet traces from real-world JS> networks (and not just ISP IP networks since SNMP seems to be used quite JS> a bit in telco networks, cable networks, enterprise networks largely JS> based on IEEE 802 LANs, ATM networks, ...) All of the agents were for clients in the cable industry who were adding SNMP support under pressure from their customers. All used SNMP v1/v2c, relaying on a non-public network for access control. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Sep 23 14:22:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07174; Thu, 23 Sep 2004 14:22:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAYLh-0006Ia-77; Thu, 23 Sep 2004 14:29:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAY5z-00007r-M2; Thu, 23 Sep 2004 14:13:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAY2H-0007aM-AW for isms@megatron.ietf.org; Thu, 23 Sep 2004 14:09:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06064 for ; Thu, 23 Sep 2004 14:09:39 -0400 (EDT) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAY96-0005zH-Q9 for isms@ietf.org; Thu, 23 Sep 2004 14:16:45 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i8NI98A28126 for ; Thu, 23 Sep 2004 14:09:08 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Sep 2004 14:09:08 -0400 Message-ID: From: "Glenn Waters" To: isms@ietf.org Date: Thu, 23 Sep 2004 14:09:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Subject: [Isms] Archives X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0560086049==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0560086049== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4A198.69C273CE" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4A198.69C273CE Content-Type: text/plain The archive for this list seems broken at the moment. The archive link on this page https://www1.ietf.org/mailman/listinfo/isms leads to a "Page not found" and the archive link in the charter points to an archive that has no messages. I'm assuming the archive should have some contents as I have seen some mail on the list. Regards, /gww > -----Original Message----- > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] > Sent: Thursday, September 23, 2004 11:29 > To: isms@ietf.org > Cc: snmpv3@lists.tislabs.com > Subject: Re: [Isms] Why SNMPv3? [WG Review: Integrated Security Model > forSNMP (isms)] > > On Thu, 23 Sep 2004 16:08:34 +0200 Juergen wrote: > JS> This goes back to a rather old discussion whether there are > environments > JS> where SNMP writes are used, how big these environments might be (I > leave > JS> it to you do define the metric) and whether the IETF should worry > about > JS> these environments. There are two camps, one arguing that SNMP writes > JS> are just an illusion since nobody actually uses them. The other camp > JS> claims that SNMP writes are a reality (or believes they will become a > JS> reality once all the security issues have been solved). > > SNMP writes are a reality. I personally have developed at least 3 SNMP > agents > with write support that interface with existing proprietary control > mechanisms. > > JS> To this end, there was never a real investigation to sort this out. It > JS> would be more than interesting to collect packet traces from real- > world > JS> networks (and not just ISP IP networks since SNMP seems to be used > quite > JS> a bit in telco networks, cable networks, enterprise networks largely > JS> based on IEEE 802 LANs, ATM networks, ...) > > All of the agents were for clients in the cable industry who were adding > SNMP > support under pressure from their customers. > > All used SNMP v1/v2c, relaying on a non-public network for access control. > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms ------_=_NextPart_001_01C4A198.69C273CE Content-Type: text/html Content-Transfer-Encoding: quoted-printable Archives

The archive for this list seems broken at the = moment.

The archive link on this page https://www1.ietf.org/mailman/listinfo/isms leads = to a "Page not found" and the archive link in the charter = points to an archive that has no messages. I'm assuming the archive = should have some contents as I have seen some mail on the = list.

Regards, /gww

> -----Original Message-----
> From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ie= tf.org]
> Sent: Thursday, September 23, 2004 11:29
> To: isms@ietf.org
> Cc: snmpv3@lists.tislabs.com
> Subject: Re: [Isms] Why SNMPv3? [WG Review: = Integrated Security Model
> forSNMP (isms)]
>
> On Thu, 23 Sep 2004 16:08:34 +0200 Juergen = wrote:
> JS> This goes back to a rather old = discussion whether there are
> environments
> JS> where SNMP writes are used, how big = these environments might be (I
> leave
> JS> it to you do define the metric) and = whether the IETF should worry
> about
> JS> these environments. There are two camps, = one arguing that SNMP writes
> JS> are just an illusion since nobody = actually uses them.  The other camp
> JS> claims that SNMP writes are a reality = (or believes they will become a
> JS> reality once all the security issues = have been solved).
>
> SNMP writes are a reality. I personally have = developed at least 3 SNMP
> agents
> with write support that interface with existing = proprietary control
> mechanisms.
>
> JS> To this end, there was never a real = investigation to sort this out. It
> JS> would be more than interesting to = collect packet traces from real-
> world
> JS> networks (and not just ISP IP networks = since SNMP seems to be used
> quite
> JS> a bit in telco networks, cable networks, = enterprise networks largely
> JS> based on IEEE 802 LANs, ATM networks, = ...)
>
> All of the agents were for clients in the cable = industry who were adding
> SNMP
> support under pressure from their = customers.
>
> All used SNMP v1/v2c, relaying on a non-public = network for access control.
>
> = _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms=

------_=_NextPart_001_01C4A198.69C273CE-- --===============0560086049== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --===============0560086049==-- From isms-bounces@ietf.org Thu Sep 23 14:34:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08448; Thu, 23 Sep 2004 14:34:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAYWt-0006Xf-Tp; Thu, 23 Sep 2004 14:41:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAYHV-0004uA-6C; Thu, 23 Sep 2004 14:25:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAY9E-0002tn-Vb for isms@megatron.ietf.org; Thu, 23 Sep 2004 14:16:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06688 for ; Thu, 23 Sep 2004 14:16:51 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAYG3-00069v-Qs for isms@ietf.org; Thu, 23 Sep 2004 14:23:57 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 23 Sep 2004 14:32:42 -0400 X-BrightmailFiltered: true Received: from rtp-cse-133.cisco.com (rtp-cse-133.cisco.com [64.102.51.73]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8NIGF7A020556; Thu, 23 Sep 2004 14:16:16 -0400 (EDT) Received: from localhost (chelliot@localhost) by rtp-cse-133.cisco.com (8.11.7+Sun/8.11.6) with ESMTP id i8NIGFR16773; Thu, 23 Sep 2004 14:16:15 -0400 (EDT) Date: Thu, 23 Sep 2004 14:16:15 -0400 (EDT) From: Chris Elliott To: David B Harrington Subject: RE: [Isms] ISMS solution seslection procedure In-Reply-To: <200409231739.NAA03819@ietf.org> Message-ID: References: <200409231739.NAA03819@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 I agree, but I would add an operational expert to the team as well as the security and SNMPv3 expert. Chris. On Thu, 23 Sep 2004, David B Harrington wrote: > I prefer an evaluation team. I would like to see each proposal > reviewed by a security expert and an SNMPv3 expert to consider > compliance to best current practices. > > dbh > > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > Chris Elliott CCIE# 2013 | | Customer Diagnostic Engineer ||| ||| RTP, NC, USA ||||| ||||| 919-392-2146 .:|||||||||:|||||||||:. chelliot@cisco.com c i s c o S y s t e m s _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Sep 23 15:10:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12164; Thu, 23 Sep 2004 15:10:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAZ66-0007NN-CI; Thu, 23 Sep 2004 15:17:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAYoz-0006bC-0c; Thu, 23 Sep 2004 15:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAYcZ-0003FE-J3 for isms@megatron.ietf.org; Thu, 23 Sep 2004 14:47:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09317 for ; Thu, 23 Sep 2004 14:47:09 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAYjO-0006kG-D2 for isms@ietf.org; Thu, 23 Sep 2004 14:54:15 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 23 Sep 2004 11:57:48 +0000 X-BrightmailFiltered: true Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8NIjHwr011453; Thu, 23 Sep 2004 11:45:21 -0700 (PDT) Received: from kaushik-w2k02.cisco.com (dhcp-171-71-255-89.cisco.com [171.71.255.89]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AUD91232; Thu, 23 Sep 2004 11:44:45 -0700 (PDT) Message-Id: <6.0.0.22.0.20040923113759.06008310@mira-sjc5-a.cisco.com> X-Sender: kaushik@mira-sjc5-a.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 23 Sep 2004 11:45:17 -0700 To: Juergen Quittek From: Kaushik Narayan Subject: Re: [Isms] ISMS solution seslection procedure In-Reply-To: <1171138004.1095960180@[10.1.1.171]> References: <1171138004.1095960180@[10.1.1.171]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d I prefer an evaluation team. At 08:23 AM 9/23/2004, Juergen Quittek wrote: >Dear all, > >Welcome to the ISMS working group! > >We have a very ambitious schedule and need to start discussing how we want >to achieve our goal in time. > >Our major objective is selecting a solution for integrating SNMP with a >security infrastructure as described in the charter. The charter also >defines a submission deadline for solutions, but it does not specify the >selection process. This message is a first step towards an agreement on >the selection process. > >Basically, we have to evaluate all submitted solutions and then select one. >For the evaluation we need a list of evaluation criteria and evaluators. > >Wes already spent a lot of time on identifying criteria/requirements. >We should start with his list and discuss it on a separate email thread. > >Concerning the evaluators it can be useful to have a look at other WGs. >Similar selections were made in the SEAMOBY, IPFIX and MIDCOM >WGs. In the SEAMOBY WG the chairs evaluated proposed solutions, >in the IPFIX and MIDCOM WGs an evaluations team performed this >task. Since SEAMOBY decision ended up in a disaster (shutting down the >entire work item at the IETF) it might be a good idea to go the way >of IPFIX and MIDCOM where the decisions went reasonably well. >Of course we are free to go our own way and our experiences may be >completely different from the ones made in SEAMOBY, IPFIX and MIDCOM. > >So, please give us your opinion on the evaluators. Do you prefer > - the WG chairs > - an evaluation team > - others >??? > >The evaluators should prepare a written evaluation and give a recommendation. >Preferably the evaluation and recommendation should be available as an >Internet draft, see for example > > > > > >. > >Ideally, a first version of this draft (containing the final list of >evaluation criteria, but probably not yet any evaluation) would already >be posted by the deadline for submitting solutions. > >Then we need to hurry to get to a recommendation in November. > >Please send any comment, suggestion, opinion on the selection procedure. >And since little time is left, please send it rather soon than late. > >Thanks, > >Ken and Juergen > > > >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Sep 23 15:48:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15509; Thu, 23 Sep 2004 15:48:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAZh2-00086Q-5M; Thu, 23 Sep 2004 15:55:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAZZ3-0007s8-BW; Thu, 23 Sep 2004 15:47:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAZWh-0006md-8q for isms@megatron.ietf.org; Thu, 23 Sep 2004 15:45:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15229 for ; Thu, 23 Sep 2004 15:45:09 -0400 (EDT) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAZdX-00082f-V5 for isms@ietf.org; Thu, 23 Sep 2004 15:52:16 -0400 Received: from cmf.nrl.navy.mil (kh-dhcp-52.cmf.nrl.navy.mil [134.207.5.52]) (authenticated bits=0) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id i8NJj3gK019927; Thu, 23 Sep 2004 15:45:05 -0400 (EDT) Message-Id: <200409231945.i8NJj3gK019927@ginger.cmf.nrl.navy.mil> To: "Glenn Waters" Subject: Re: [Isms] Archives In-Reply-To: X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Thu, 23 Sep 2004 15:45:04 -0400 From: Ken Hornstein X-Spam-Score: () hits=0 User Authenticated X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 >The archive for this list seems broken at the moment. > >The archive link on this page https://www1.ietf.org/mailman/listinfo/isms >leads to a "Page not found" and the archive link in the charter points to an >archive that has no messages. I'm assuming the archive should have some >contents as I have seen some mail on the list. Glenn, Just as a FYI, I've notified the IETF webmaster of the problem (I get the same as you do). Hopefully it will get corrected soon; I'll notify everyone when the mailing list archive is functional. --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Sep 23 16:28:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20294; Thu, 23 Sep 2004 16:28:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAaJc-0001LN-7q; Thu, 23 Sep 2004 16:35:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAa63-0001YI-GC; Thu, 23 Sep 2004 16:21:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAZGt-0008Sj-8z for isms@megatron.ietf.org; Thu, 23 Sep 2004 15:28:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14302 for ; Thu, 23 Sep 2004 15:28:49 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAZNj-0007lB-L0 for isms@ietf.org; Thu, 23 Sep 2004 15:35:55 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 23 Sep 2004 12:28:55 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i8NJSh3c019860; Thu, 23 Sep 2004 12:28:44 -0700 (PDT) Received: from [192.168.1.103] (che-vpn-cluster-2-142.cisco.com [10.86.242.142]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALU19353; Thu, 23 Sep 2004 15:28:42 -0400 (EDT) In-Reply-To: <20040923121657.3312b5e9@dev.localdomain> References: <200409221549.i8MFnmQ11501@netcore.fi> <20040923140834.GA2580@james> <20040923121657.3312b5e9@dev.localdomain> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: [Isms] Why SNMPv3? [WG Review: Integrated Security Model for SNMP (isms)] Date: Thu, 23 Sep 2004 15:28:41 -0400 To: Robert Story X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 23 Sep 2004 16:21:41 -0400 Cc: isms@ietf.org, snmpv3@lists.tislabs.com X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit > On Thu, 23 Sep 2004 16:08:34 +0200 Juergen wrote: > JS> This goes back to a rather old discussion whether there are > environments > JS> where SNMP writes are used, how big these environments might be (I > leave > JS> it to you do define the metric) and whether the IETF should worry > about > JS> these environments. There are two camps, one arguing that SNMP > writes > JS> are just an illusion since nobody actually uses them. The other > camp > JS> claims that SNMP writes are a reality (or believes they will > become a > JS> reality once all the security issues have been solved). > > SNMP writes are a reality. I personally have developed at least 3 SNMP > agents > with write support that interface with existing proprietary control > mechanisms. Being a reality and actually being used are two different things. I too have developed numerous modules that are writable, but not many people use them. :P Like SNMP writes, Betamax is a reality for only the few that use it, but for the majority there are 1,000 reasons why they use something else. *) --Tom > JS> To this end, there was never a real investigation to sort this > out. It > JS> would be more than interesting to collect packet traces from > real-world > JS> networks (and not just ISP IP networks since SNMP seems to be used > quite > JS> a bit in telco networks, cable networks, enterprise networks > largely > JS> based on IEEE 802 LANs, ATM networks, ...) > > All of the agents were for clients in the cable industry who were > adding SNMP > support under pressure from their customers. > > All used SNMP v1/v2c, relaying on a non-public network for access > control. > > > -- > Robert Story; NET-SNMP Junkie > > > You are lost in a twisty maze of little standards, all different. > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Sep 23 16:50:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21803; Thu, 23 Sep 2004 16:50:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAaea-0001kG-P5; Thu, 23 Sep 2004 16:57:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAaN5-0001Qp-QD; Thu, 23 Sep 2004 16:39:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAaFj-0007gm-Fe for isms@megatron.ietf.org; Thu, 23 Sep 2004 16:31:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20561 for ; Thu, 23 Sep 2004 16:31:40 -0400 (EDT) Received: from adsl-64-165-72-146.dsl.scrm01.pacbell.net ([64.165.72.146] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAaMZ-0001RS-6B for isms@ietf.org; Thu, 23 Sep 2004 16:38:48 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 3AA2611D3AA; Thu, 23 Sep 2004 13:31:29 -0700 (PDT) To: Chris Elliott Subject: Re: [Isms] ISMS solution seslection procedure References: <200409231739.NAA03819@ietf.org> From: Wes Hardaker Organization: Sparta Date: Thu, 23 Sep 2004 13:31:29 -0700 In-Reply-To: (Chris Elliott's message of "Thu, 23 Sep 2004 14:16:15 -0400 (EDT)") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.5 (chayote, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c >>>>> On Thu, 23 Sep 2004 14:16:15 -0400 (EDT), Chris Elliott said: Chris> I agree, but I would add an operational expert to the team as Chris> well as the security and SNMPv3 expert. Oh, and they should be non-biased of course! That'll be the tricky part. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Sep 24 00:34:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20789; Fri, 24 Sep 2004 00:34:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAhtp-00018g-T9; Fri, 24 Sep 2004 00:41:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAhmF-0005ky-CW; Fri, 24 Sep 2004 00:33:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAhlL-0005fX-3C for isms@megatron.ietf.org; Fri, 24 Sep 2004 00:32:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20739 for ; Fri, 24 Sep 2004 00:32:47 -0400 (EDT) Received: from dcn236-44.dcn.davis.ca.us ([168.150.236.44] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAhsF-00017h-DA for isms@ietf.org; Fri, 24 Sep 2004 00:40:00 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 63CC311D3AA; Thu, 23 Sep 2004 21:32:46 -0700 (PDT) To: "Thomas D. Nadeau" Subject: Re: [Isms] Why SNMPv3? [WG Review: Integrated Security Model for SNMP (isms)] References: <200409221549.i8MFnmQ11501@netcore.fi> <20040923140834.GA2580@james> <20040923121657.3312b5e9@dev.localdomain> From: Wes Hardaker Organization: Sparta Date: Thu, 23 Sep 2004 21:32:46 -0700 In-Reply-To: (Thomas D. Nadeau's message of "Thu, 23 Sep 2004 15:28:41 -0400") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.5 (chayote, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: snmpv3@lists.tislabs.com, isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 >>>>> On Thu, 23 Sep 2004 15:28:41 -0400, "Thomas D. Nadeau" said: Thomas> Being a reality and actually being used are two different things. Thomas> I too have developed numerous modules that are writable, but not many Thomas> people use them. I sure get an awful lot of questions about an operation that supposedly isn't used. [note the recent ISMS survey results (see the proceedings) had about 1/5th of the responses saying they used SNMP for configuration] -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Sep 24 01:00:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22057; Fri, 24 Sep 2004 01:00:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAiJ9-0001W7-QV; Fri, 24 Sep 2004 01:07:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAi8o-0000Mx-WA; Fri, 24 Sep 2004 00:57:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAi6l-0008F6-1y for isms@megatron.ietf.org; Fri, 24 Sep 2004 00:54:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21771 for ; Fri, 24 Sep 2004 00:54:55 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAiDf-0001Pr-JY for isms@ietf.org; Fri, 24 Sep 2004 01:02:08 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 24 Sep 2004 01:10:56 -0400 X-BrightmailFiltered: true Received: from rtp-cse-133.cisco.com (rtp-cse-133.cisco.com [64.102.51.73]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8O4sO7A016074; Fri, 24 Sep 2004 00:54:25 -0400 (EDT) Received: from localhost (chelliot@localhost) by rtp-cse-133.cisco.com (8.11.7+Sun/8.11.6) with ESMTP id i8O4sOG23496; Fri, 24 Sep 2004 00:54:24 -0400 (EDT) Date: Fri, 24 Sep 2004 00:54:24 -0400 (EDT) From: Chris Elliott To: Wes Hardaker Subject: Re: [Isms] Why SNMPv3? [WG Review: Integrated Security Model for SNMP (isms)] In-Reply-To: Message-ID: References: <200409221549.i8MFnmQ11501@netcore.fi> <20040923140834.GA2580@james> <20040923121657.3312b5e9@dev.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: "Thomas D. Nadeau" , snmpv3@lists.tislabs.com, isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 We (Cisco Systems) sell, mostly to enterprises, a network management system (CiscoWorks) that requires SNMP write access for much of it's functionality and I have personally worked with many Fortune 100 companies that are using this NMS and allowing SNMP write access to their network devices, along with countless smaller companies. We also sell a large number of DOCSIS-compliant devices. DOCSIS requires SNMP write access for configuration and provisioning. We sell other network management systems into the service provider market that require SNMP write access to the managed devices. They continue to sell and be used. SNMP, with write access, is in use today in many environments. These customers typically are using this write access with insecure community strings and are securing access with access lists and private management networks. I believe that the advantages of using a secure protocol, such as SNMPv3, along with the ability to authenticate against existing user databases, will be easier to deploy and more secure than the existing methods. Chris. On Thu, 23 Sep 2004, Wes Hardaker wrote: > >>>>> On Thu, 23 Sep 2004 15:28:41 -0400, "Thomas D. Nadeau" said: > > Thomas> Being a reality and actually being used are two different things. > Thomas> I too have developed numerous modules that are writable, but not many > Thomas> people use them. > > I sure get an awful lot of questions about an operation that > supposedly isn't used. > > [note the recent ISMS survey results (see the proceedings) had about > 1/5th of the responses saying they used SNMP for configuration] > > -- > Wes Hardaker > Sparta > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > Chris Elliott CCIE# 2013 | | Customer Diagnostic Engineer ||| ||| RTP, NC, USA ||||| ||||| 919-392-2146 .:|||||||||:|||||||||:. chelliot@cisco.com c i s c o S y s t e m s _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Sep 27 13:19:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14117; Mon, 27 Sep 2004 13:19:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBzHZ-0001fQ-Db; Mon, 27 Sep 2004 13:27:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CByrt-0008Ej-Jf; Mon, 27 Sep 2004 13:00:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CByjJ-0007CA-SX for isms@megatron.ietf.org; Mon, 27 Sep 2004 12:52:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12332 for ; Mon, 27 Sep 2004 12:51:58 -0400 (EDT) Message-Id: <200409271651.MAA12332@ietf.org> Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CByqx-000170-Kc for isms@ietf.org; Mon, 27 Sep 2004 12:59:56 -0400 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc12) with SMTP id <2004092716512801200g057he>; Mon, 27 Sep 2004 16:51:29 +0000 From: "David B Harrington" To: "'Wes Hardaker'" , "'Chris Elliott'" Subject: RE: [Isms] ISMS solution seslection procedure Date: Mon, 27 Sep 2004 12:51:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: Thread-Index: AcShrFJGHR/EcIePS7qRlVTrWVw9UgDAVqUQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Greetings, I recommended that each proposal be reviewed for compliance to existing best current practices. I suggested this based on experience in the AAA and MIDCOM WGs. Those WHs spent a great deal of time deciding on the requirements to compare proposals against, and they needed to determine what would need to be changed to integrate each proposed protocol into the desired environment. I had in mind such "best current practices" as RFC3411, which places certain requirements on modules that will fit within an SNMPv3 engine. I think each proposal needs to be considered as to whether the proposed security model will work as is within the architecture, whether a proposed security model will require changes to the security mechanisms used to fit with the RFC3411 archtecture, or whether the architecture will need to change to accommodate the proposed solution. I know the charter says the existing SNMPv3 standard cannot be changed, but the framework is only a theoretical document based on the best knowledge available at the time it was written, and new protocols (e.g. 802.1x) and some paradigms of security management (e.g. RADIUS) have become much more widely-deployed since then, so I believe the architecure might need to be updated to accommodate proposed solutions that best meet operator needs. For example, BEEP could be considered, but it would probably require changes to BEEP to be able to pass information to the SNMP agent about the security principal, the specific authentication mechanism used within BEEP, and whether the message was authenticated and encrypted. If the BEEP proposal was treated as a transport mapping in the RFC3411 architecture, then the ASIs in RFC3411 might need to change to pass this information from the transport mapping module to the message module. Since BEEP was designed to be used with TCP, not UDP, then even if BEEP could be treated strictly as a message or security model, there would be a dependency on the transport model, and the current architecure doesn't have a mechanism to permit specifying such a dependency, so RFC3411 might need to be updated to accommodate this (or not). I expect that the security area has some written guidelines about the aspects that must be considered when integrating a security protocol with another protocol, that would be comparable to RFC3411's purpose in the SNMP world. But I don't know of a document that exists that documents operator best current practice, except the work being done in OPSEC, which is currently focused only on very large service provider requirements. What would an operational expert use as the guidelines to judge compliance to best current practices? dbh -----Original Message----- From: Wes Hardaker [mailto:hardaker@tislabs.com] Sent: Thursday, September 23, 2004 4:31 PM To: Chris Elliott Cc: David B Harrington; isms@ietf.org Subject: Re: [Isms] ISMS solution seslection procedure >>>>> On Thu, 23 Sep 2004 14:16:15 -0400 (EDT), Chris Elliott said: Chris> I agree, but I would add an operational expert to the team as Chris> well as the security and SNMPv3 expert. Oh, and they should be non-biased of course! That'll be the tricky part. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Sep 27 13:27:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14744; Mon, 27 Sep 2004 13:27:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBzPa-0001od-80; Mon, 27 Sep 2004 13:35:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBzCG-0001qI-2r; Mon, 27 Sep 2004 13:21:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBz8a-0001Fs-St for isms@megatron.ietf.org; Mon, 27 Sep 2004 13:18:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13829 for ; Mon, 27 Sep 2004 13:18:05 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBzGE-0001c1-SC for isms@ietf.org; Mon, 27 Sep 2004 13:26:04 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 3185411D3AC; Mon, 27 Sep 2004 10:18:01 -0700 (PDT) To: Subject: Re: [Isms] ISMS solution seslection procedure References: <200409271648.i8RGmakM010200@nutshell.tislabs.com> From: Wes Hardaker Organization: Sparta Date: Mon, 27 Sep 2004 10:18:00 -0700 In-Reply-To: <200409271648.i8RGmakM010200@nutshell.tislabs.com> (David B. Harrington's message of "Mon, 27 Sep 2004 12:51:26 -0400") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.5 (chayote, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a >>>>> On Mon, 27 Sep 2004 12:51:26 -0400, "David B Harrington" said: David> I know the charter says the existing SNMPv3 standard cannot be David> changed, but the framework is only a theoretical document based David> on the best knowledge available at the time it was written, and David> new protocols (e.g. 802.1x) and some paradigms of security David> management (e.g. RADIUS) have become much more widely-deployed David> since then, so I believe the architecure might need to be David> updated to accommodate proposed solutions that best meet David> operator needs. I think the ADs have been quite clear that we can't spend the time needed to do something like that. Additionally, it was put in the charter specifically so we couldn't change the architecture because we needed small additions in order to achieve faster deployment. I'm sure that by revamping the SNMPv3 signaling process we'd never hit the 6 month deadline and we'd have to get the charter rewritten as well (which I doubt is possible). -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Sep 27 13:45:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16061; Mon, 27 Sep 2004 13:45:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBzgf-00028X-OX; Mon, 27 Sep 2004 13:53:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBzQg-000302-9o; Mon, 27 Sep 2004 13:36:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBzKy-0002Vd-GQ for isms@megatron.ietf.org; Mon, 27 Sep 2004 13:30:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14947 for ; Mon, 27 Sep 2004 13:30:52 -0400 (EDT) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBzSd-0001rS-I8 for isms@ietf.org; Mon, 27 Sep 2004 13:38:51 -0400 Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated bits=0) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id i8RHUmOt014574 for ; Mon, 27 Sep 2004 13:30:48 -0400 (EDT) Message-Id: <200409271730.i8RHUmOt014574@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] ISMS solution seslection procedure In-Reply-To: X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Mon, 27 Sep 2004 13:30:48 -0400 From: Ken Hornstein X-Spam-Score: () hits=0 User Authenticated X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 >I think the ADs have been quite clear that we can't spend the time >needed to do something like that. That is my understanding as well. The deadline we've been given is a hard one, for better or for worse. --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Sep 27 17:30:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10460; Mon, 27 Sep 2004 17:30:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC3CH-0000ji-Rg; Mon, 27 Sep 2004 17:38:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC2JO-0006eQ-55; Mon, 27 Sep 2004 16:41:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAtAB-0003Ns-9N for isms@megatron.ietf.org; Fri, 24 Sep 2004 12:43:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24290 for ; Fri, 24 Sep 2004 12:43:12 -0400 (EDT) Received: from jive.softhome.net ([66.54.152.27]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CAtHA-0005YY-K2 for isms@ietf.org; Fri, 24 Sep 2004 12:50:31 -0400 Received: (qmail 17997 invoked by uid 417); 24 Sep 2004 15:24:51 -0000 Received: from charleston-.softhome.net (HELO softhome.net) (172.16.2.12) by shunt-smtp-out-0 with SMTP; 24 Sep 2004 15:24:51 -0000 Received: from XPNERICK ([132.70.218.240]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Fri, 24 Sep 2004 09:24:49 -0600 Message-ID: <003801c4a24a$8141cfb0$0401a8c0@ttitelecom.com> From: "EricLKlein" To: snmpv3@lists.tislabs.com, isms@ietf.org References: <200409221549.i8MFnmQ11501@netcore.fi> <20040923140834.GA2580@james> <20040923121657.3312b5e9@dev.localdomain> Subject: Re: [Isms] Why SNMPv3? [WG Review: Integrated Security Model for SNMP (isms)] Date: Fri, 24 Sep 2004 17:23:50 +0200 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.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 27 Sep 2004 16:41:28 -0400 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit I tend to agree with Chris, many service providers are starting to wake up to the lack of security in SNMP I and II, and have started requiring compliance in the NMS / OSS products that they want. SNMP III is the best solution for this so far and is important. Eric ----- Original Message ----- From: "Chris Elliott" To: "Wes Hardaker" Cc: "Thomas D. Nadeau" ; ; Sent: 24 September, 2004 6:54 AM Subject: Re: [Isms] Why SNMPv3? [WG Review: Integrated Security Model for SNMP (isms)] > We (Cisco Systems) sell, mostly to enterprises, a network management > system (CiscoWorks) that requires SNMP write access for much of it's > functionality and I have personally worked with many Fortune 100 companies > that are using this NMS and allowing SNMP write access to their network > devices, along with countless smaller companies. > > We also sell a large number of DOCSIS-compliant devices. DOCSIS requires > SNMP write access for configuration and provisioning. > > We sell other network management systems into the service provider market > that require SNMP write access to the managed devices. They continue to > sell and be used. > > SNMP, with write access, is in use today in many environments. These > customers typically are using this write access with insecure community > strings and are securing access with access lists and private management > networks. > > I believe that the advantages of using a secure protocol, such as SNMPv3, > along with the ability to authenticate against existing user databases, > will be easier to deploy and more secure than the existing methods. > > Chris. > > On Thu, 23 Sep 2004, Wes Hardaker wrote: > > > >>>>> On Thu, 23 Sep 2004 15:28:41 -0400, "Thomas D. Nadeau" said: > > > > Thomas> Being a reality and actually being used are two different things. > > Thomas> I too have developed numerous modules that are writable, but not many > > Thomas> people use them. > > > > I sure get an awful lot of questions about an operation that > > supposedly isn't used. > > > > [note the recent ISMS survey results (see the proceedings) had about > > 1/5th of the responses saying they used SNMP for configuration] > > > > -- > > Wes Hardaker > > Sparta > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > > Chris Elliott CCIE# 2013 | | > Customer Diagnostic Engineer ||| ||| > RTP, NC, USA ||||| ||||| > 919-392-2146 .:|||||||||:|||||||||:. > chelliot@cisco.com c i s c o S y s t e m s _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Sep 27 18:16:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15487; Mon, 27 Sep 2004 18:16:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC3um-000224-4E; Mon, 27 Sep 2004 18:24:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC3lS-0005gM-Of; Mon, 27 Sep 2004 18:14:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC3e6-0001TP-J2 for isms@megatron.ietf.org; Mon, 27 Sep 2004 18:06:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14023 for ; Mon, 27 Sep 2004 18:06:55 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC3ln-0001ii-Pw for isms@ietf.org; Mon, 27 Sep 2004 18:14:56 -0400 Received: from slb-av-01.boeing.com ([129.172.13.4]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id PAA26835; Mon, 27 Sep 2004 15:06:24 -0700 (PDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i8RM6N911839; Mon, 27 Sep 2004 15:06:23 -0700 (PDT) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 27 Sep 2004 15:06:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Why SNMPv3? [WG Review: Integrated Security Model for SNMP(isms)] Date: Mon, 27 Sep 2004 15:06:19 -0700 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDD823@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] Why SNMPv3? [WG Review: Integrated Security Model for SNMP(isms)] Thread-Index: AcSk2TCZZppPaVyYTTC/tcpkSae02AABNb8w From: "Fleischman, Eric" To: "EricLKlein" , , X-OriginalArrivalTime: 27 Sep 2004 22:06:20.0480 (UTC) FILETIME=[38241400:01C4A4DE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: quoted-printable However, some of those of us who want to use SNMPv3 USM have found it to = be operationally insecure and would like to have an approach for SNMP = that leverages existing key distribution systems (e.g., PKI, Kerberos, = etc.) already deployed within our infrastructures. -----Original Message----- From: EricLKlein [mailto:ericlklein@softhome.net] Sent: Friday, September 24, 2004 8:24 AM To: snmpv3@lists.tislabs.com; isms@ietf.org Subject: Re: [Isms] Why SNMPv3? [WG Review: Integrated Security Model for SNMP(isms)] I tend to agree with Chris, many service providers are starting to wake = up to the lack of security in SNMP I and II, and have started requiring compliance in the NMS / OSS products that they want. SNMP III is the best solution for this so far and is important. Eric ----- Original Message -----=20 From: "Chris Elliott" To: "Wes Hardaker" Cc: "Thomas D. Nadeau" ; ; Sent: 24 September, 2004 6:54 AM Subject: Re: [Isms] Why SNMPv3? [WG Review: Integrated Security Model = for SNMP (isms)] > We (Cisco Systems) sell, mostly to enterprises, a network management > system (CiscoWorks) that requires SNMP write access for much of it's > functionality and I have personally worked with many Fortune 100 = companies > that are using this NMS and allowing SNMP write access to their = network > devices, along with countless smaller companies. > > We also sell a large number of DOCSIS-compliant devices. DOCSIS = requires > SNMP write access for configuration and provisioning. > > We sell other network management systems into the service provider = market > that require SNMP write access to the managed devices. They continue = to > sell and be used. > > SNMP, with write access, is in use today in many environments. These > customers typically are using this write access with insecure = community > strings and are securing access with access lists and private = management > networks. > > I believe that the advantages of using a secure protocol, such as = SNMPv3, > along with the ability to authenticate against existing user = databases, > will be easier to deploy and more secure than the existing methods. > > Chris. > > On Thu, 23 Sep 2004, Wes Hardaker wrote: > > > >>>>> On Thu, 23 Sep 2004 15:28:41 -0400, "Thomas D. Nadeau" said: > > > > Thomas> Being a reality and actually being used are two different things. > > Thomas> I too have developed numerous modules that are writable, but = not many > > Thomas> people use them. > > > > I sure get an awful lot of questions about an operation that > > supposedly isn't used. > > > > [note the recent ISMS survey results (see the proceedings) had about > > 1/5th of the responses saying they used SNMP for configuration] > > > > -- > > Wes Hardaker > > Sparta > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > > Chris Elliott CCIE# 2013 | | > Customer Diagnostic Engineer ||| ||| > RTP, NC, USA ||||| ||||| > 919-392-2146 .:|||||||||:|||||||||:. > chelliot@cisco.com c i s c o S y s t e m s _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Sep 27 20:08:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24050; Mon, 27 Sep 2004 20:08:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC5f0-0004Ri-Bp; Mon, 27 Sep 2004 20:16:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC5RL-0001IS-74; Mon, 27 Sep 2004 20:01:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC5Jf-0000BO-V2 for isms@megatron.ietf.org; Mon, 27 Sep 2004 19:54:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22887 for ; Mon, 27 Sep 2004 19:53:56 -0400 (EDT) Message-Id: <200409272353.TAA22887@ietf.org> Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC5RO-00045d-IA for isms@ietf.org; Mon, 27 Sep 2004 20:01:58 -0400 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc12) with SMTP id <2004092723532601200qopebe>; Mon, 27 Sep 2004 23:53:26 +0000 From: "David B Harrington" To: "'Fleischman, Eric'" , "'EricLKlein'" , , Subject: RE: [Isms] Why SNMPv3? [WG Review: Integrated Security Model forSNMP(isms)] Date: Mon, 27 Sep 2004 19:53:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <5B58696DB20B9140AD20E0685C573A6404FDD823@xch-nw-09.nw.nos.boeing.com> Thread-Index: AcSk2TCZZppPaVyYTTC/tcpkSae02AABNb8wAAO0OjA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: 7bit X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: 7bit Hi EricF, operationally insecure? I hadn't heard this concern. Can you elaborate? dbh -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Fleischman, Eric Sent: Monday, September 27, 2004 6:06 PM To: EricLKlein; snmpv3@lists.tislabs.com; isms@ietf.org Subject: RE: [Isms] Why SNMPv3? [WG Review: Integrated Security Model forSNMP(isms)] However, some of those of us who want to use SNMPv3 USM have found it to be operationally insecure and would like to have an approach for SNMP that leverages existing key distribution systems (e.g., PKI, Kerberos, etc.) already deployed within our infrastructures. -----Original Message----- From: EricLKlein [mailto:ericlklein@softhome.net] Sent: Friday, September 24, 2004 8:24 AM To: snmpv3@lists.tislabs.com; isms@ietf.org Subject: Re: [Isms] Why SNMPv3? [WG Review: Integrated Security Model for SNMP(isms)] I tend to agree with Chris, many service providers are starting to wake up to the lack of security in SNMP I and II, and have started requiring compliance in the NMS / OSS products that they want. SNMP III is the best solution for this so far and is important. Eric ----- Original Message ----- From: "Chris Elliott" To: "Wes Hardaker" Cc: "Thomas D. Nadeau" ; ; Sent: 24 September, 2004 6:54 AM Subject: Re: [Isms] Why SNMPv3? [WG Review: Integrated Security Model for SNMP (isms)] > We (Cisco Systems) sell, mostly to enterprises, a network management > system (CiscoWorks) that requires SNMP write access for much of it's > functionality and I have personally worked with many Fortune 100 companies > that are using this NMS and allowing SNMP write access to their network > devices, along with countless smaller companies. > > We also sell a large number of DOCSIS-compliant devices. DOCSIS requires > SNMP write access for configuration and provisioning. > > We sell other network management systems into the service provider market > that require SNMP write access to the managed devices. They continue to > sell and be used. > > SNMP, with write access, is in use today in many environments. These > customers typically are using this write access with insecure community > strings and are securing access with access lists and private management > networks. > > I believe that the advantages of using a secure protocol, such as SNMPv3, > along with the ability to authenticate against existing user databases, > will be easier to deploy and more secure than the existing methods. > > Chris. > > On Thu, 23 Sep 2004, Wes Hardaker wrote: > > > >>>>> On Thu, 23 Sep 2004 15:28:41 -0400, "Thomas D. Nadeau" said: > > > > Thomas> Being a reality and actually being used are two different things. > > Thomas> I too have developed numerous modules that are writable, but not many > > Thomas> people use them. > > > > I sure get an awful lot of questions about an operation that > > supposedly isn't used. > > > > [note the recent ISMS survey results (see the proceedings) had about > > 1/5th of the responses saying they used SNMP for configuration] > > > > -- > > Wes Hardaker > > Sparta > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > > Chris Elliott CCIE# 2013 | | > Customer Diagnostic Engineer ||| ||| > RTP, NC, USA ||||| ||||| > 919-392-2146 .:|||||||||:|||||||||:. > chelliot@cisco.com c i s c o S y s t e m s _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Sep 27 20:18:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25210; Mon, 27 Sep 2004 20:18:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC5p9-0004kH-ED; Mon, 27 Sep 2004 20:26:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC5fU-0003J9-CA; Mon, 27 Sep 2004 20:16:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC5en-0003AD-9m for isms@megatron.ietf.org; Mon, 27 Sep 2004 20:15:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24894 for ; Mon, 27 Sep 2004 20:15:47 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC5mS-0004eQ-Sa for isms@ietf.org; Mon, 27 Sep 2004 20:23:48 -0400 Received: from slb-av-01.boeing.com ([129.172.13.4]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id TAA17540; Mon, 27 Sep 2004 19:15:11 -0500 (CDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i8S0F2921547; Mon, 27 Sep 2004 17:15:02 -0700 (PDT) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 27 Sep 2004 17:15:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Why SNMPv3? [WG Review: Integrated Security Model forSNMP(isms)] Date: Mon, 27 Sep 2004 17:15:00 -0700 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDD828@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] Why SNMPv3? [WG Review: Integrated Security Model forSNMP(isms)] Thread-Index: AcSk2TCZZppPaVyYTTC/tcpkSae02AABNb8wAAO0OjAAAJjbYA== From: "Fleischman, Eric" To: , "EricLKlein" , , X-OriginalArrivalTime: 28 Sep 2004 00:15:01.0448 (UTC) FILETIME=[32324C80:01C4A4F0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: quoted-printable X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Content-Transfer-Encoding: quoted-printable How can one securely distribute SNMPv3 passwords or keys associated with = human manager-to-SNMP agent access (i.e., privacy keys, authentication = keys)?=20 How can one get SNMPv3 authentication and privacy to be related to the = other authentication and privacy systems in that deployment (e.g., for = deployments seeking to do a common role-based access control) -- in = terms of common policy and consistent implementation? How can one get SNMPv3 to participate in generic defense in depth = systems common within the non-SNMP elements of the deployment (i.e., to = integrate SNMPv3 into the deployment's larger security systems)? -----Original Message----- From: David B Harrington [mailto:ietfdbh@comcast.net] Sent: Monday, September 27, 2004 4:53 PM To: Fleischman, Eric; 'EricLKlein'; snmpv3@lists.tislabs.com; isms@ietf.org Subject: RE: [Isms] Why SNMPv3? [WG Review: Integrated Security Model forSNMP(isms)] Hi EricF, operationally insecure? I hadn't heard this concern. Can you elaborate?=20 dbh=20 -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Fleischman, Eric Sent: Monday, September 27, 2004 6:06 PM To: EricLKlein; snmpv3@lists.tislabs.com; isms@ietf.org Subject: RE: [Isms] Why SNMPv3? [WG Review: Integrated Security Model forSNMP(isms)] However, some of those of us who want to use SNMPv3 USM have found it to be operationally insecure and would like to have an approach for SNMP that leverages existing key distribution systems (e.g., PKI, Kerberos, etc.) already deployed within our infrastructures. -----Original Message----- From: EricLKlein [mailto:ericlklein@softhome.net] Sent: Friday, September 24, 2004 8:24 AM To: snmpv3@lists.tislabs.com; isms@ietf.org Subject: Re: [Isms] Why SNMPv3? [WG Review: Integrated Security Model for SNMP(isms)] I tend to agree with Chris, many service providers are starting to wake up to the lack of security in SNMP I and II, and have started requiring compliance in the NMS / OSS products that they want. SNMP III is the best solution for this so far and is important. Eric ----- Original Message ----- From: "Chris Elliott" To: "Wes Hardaker" Cc: "Thomas D. Nadeau" ; ; Sent: 24 September, 2004 6:54 AM Subject: Re: [Isms] Why SNMPv3? [WG Review: Integrated Security Model for SNMP (isms)] > We (Cisco Systems) sell, mostly to enterprises, a network management > system (CiscoWorks) that requires SNMP write access for much of it's > functionality and I have personally worked with many Fortune 100 companies > that are using this NMS and allowing SNMP write access to their network > devices, along with countless smaller companies. > > We also sell a large number of DOCSIS-compliant devices. DOCSIS requires > SNMP write access for configuration and provisioning. > > We sell other network management systems into the service provider market > that require SNMP write access to the managed devices. They continue to > sell and be used. > > SNMP, with write access, is in use today in many environments. These > customers typically are using this write access with insecure community > strings and are securing access with access lists and private management > networks. > > I believe that the advantages of using a secure protocol, such as SNMPv3, > along with the ability to authenticate against existing user databases, > will be easier to deploy and more secure than the existing methods. > > Chris. > > On Thu, 23 Sep 2004, Wes Hardaker wrote: > > > >>>>> On Thu, 23 Sep 2004 15:28:41 -0400, "Thomas D. Nadeau" said: > > > > Thomas> Being a reality and actually being used are two different things. > > Thomas> I too have developed numerous modules that are writable, but not many > > Thomas> people use them. > > > > I sure get an awful lot of questions about an operation that > > supposedly isn't used. > > > > [note the recent ISMS survey results (see the proceedings) had about > > 1/5th of the responses saying they used SNMP for configuration] > > > > -- > > Wes Hardaker > > Sparta > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > > Chris Elliott CCIE# 2013 | | > Customer Diagnostic Engineer ||| ||| > RTP, NC, USA ||||| ||||| > 919-392-2146 .:|||||||||:|||||||||:. > chelliot@cisco.com c i s c o S y s t e m s _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms