From owner-snmpv3@lists.tislabs.com Mon Mar 3 12:26:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03969 for ; Mon, 3 Mar 2003 12:26:14 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA21327 Mon, 3 Mar 2003 11:22:58 -0500 (EST) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Sat, 1 Mar 2003 23:59:05 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: WG IETF snmpv3 Subject: Re: coex draft In-Reply-To: <0A11633F61BD9F40B43ABCC694004F93C8CE63@zsc3c026.us.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-2133786286-432624069-1046591640=:7701" Content-ID: Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---2133786286-432624069-1046591640=:7701 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: On Fri, 28 Feb 2003, David Levi wrote: > Here is a change-bar version of the new coex draft (this is not > the official version). This will be submitted tomorrow to the > ID editor. Also, I've attached a list of responses to the lists > of proposed changes. I've gone over the changes in this version and I'd like to thank the editors for all their hard work. However, there are still a few small things wrong that I feel should be corrected before the document will be ready for last call. They are listed below, and in an attachment there is a suggestion for a re-ordering of the change log that I think will be helpful to future readers. Regards, Mike Heard [#1] The following text in Section 2.1.1 has a grammatical error: (9) If any INDEX clause contains a reference to an object with a syntax of NetworkAddress, then a new object MUST be created and placed in this INDEX clause immediately preceding the object whose syntax is NetworkAddress. This new object MUST have a syntax of INTEGER, it MUST be not-accessible, and its value MUST always be 1. This | effect of this, and the preceding bullet, is to allow one to | convert a MIB module in SMIv1 format | to one in SMIv2 format, and then use it with the SNMPv1 protocol with no impact to existing SNMPv1 agents and managers. Fix: s/This effect of this,/The effect of this,/ [#2] There is probably an error in the nroff source that caused the last line (marked X) of the following bullet in Section 3.2 to be lost: (1) The SNMPv1 enterprise parameter SHALL be determined as follows: - If the SNMPv2 snmpTrapOID parameter is one of the standard traps as defined in RFC 3418 [RFC3418], then the SNMPv1 | enterprise parameter SHALL be | set to the value of the variable-binding in the SNMPv2 variable-bindings whose name is snmpTrapEnterprise.0 if that variable-binding exists. If it does not exist, the SNMPv1 | enterprise parameter SHALL be set to the value | 'snmpTraps' as defined in RFC 3418 [RFC3418]. X Fix: re-arrange the nroff source so that the opening single quote of 'snmpTraps' does not appear at the beginning of a line. [#3] The following text at the end of Section 4.2.2 (which used to be 4.1.2) appears to have been edited incorrectly. The text says: The following sections describe the behaviour of a command responder application which supports multiple SNMP message versions, and which | uses some SNMPv2 access to MIB data when processing an SNMPv2c or | SNMPv3 message. | However, the "changes.txt" attachment said this: % > I believe it would be easier to follow if the introduction to % > section 4.1.2 stated up front, that the rest of the section % > referred purely to SNMPv2 access to MIB data in response to % > an SNMPv1 request. % % Changed the text at the end of the section to state this. It is suggested that the paragraph in question should read like this: The following sections describe the behaviour of a command responder application which supports multiple SNMP message versions, and which | uses SNMPv2 access to MIB data when processing an SNMPv1 message. | [#4] The first paragraph of Section 4.2.2.1 has an incorrect reference: The SMIv2 [RFC2579] defines one new syntax that is incompatible with | SMIv1. This syntax is Counter64. All other syntaxes defined by SMIv2 are compatible with SMIv1. Fix: s/[RFC2579]/[RFC2578]/ [#5] The following text in Section 5.3 has a grammatical error: Note that the snmpTargetAddrTMask object is only used where explicitly stated. In particular, it is not used when generating notifications (i.e., when generating notifications, entries in the snmpTargetAddrTable only specify individual addresses). If use of | the snmpTargetAddrTMask object is not mentioned in text describing | matching addresses in the snmpTargetAddrTable, then it's value MUST | be ignored. | Fix: s/it's/its/ [#6] The most recent REVISION clause fails to document the following changes: - the update to the DESCRIPTION clause of snmpCommunityName; - the addition of snmpCommunityMIBFullCompliance. [#7] The following clarification in the definition of snmpCommunityName does not appear to be correct: snmpCommunityName OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-create STATUS current DESCRIPTION "The community string for which a row in this table represents a configuration. Although there is no SIZE | restriction specified on this object, in practice, we do | not expect people to use community names that are too | long to cause the OID for an instance of this object to | be more than 128 sub-identifiers. If they get longer, | they may not be supported by (currently) existing SNMP | engines." | ::= { snmpCommunityEntry 2 } The revised description is written as if snmpCommunityName were being used as an index, which is not the case (the index for this table is snmpCommunityIndex, which is limited to 32 octets). The following alternate wording is suggested: snmpCommunityName OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-create STATUS current DESCRIPTION "The community string for which a row in this table represents a configuration. There is no SIZE constraint | specified for this object because RFC 1157 does not | impose any explicit limitation on the length of community | strings (their size is constrained indirectly by the | SNMP message size). | ::= { snmpCommunityEntry 2 } [#8] The DESCRIPTION sub-clause of the following OBJECT clause of the snmpCommunityMIBFullCompliance statement does not match the MIN-ACCESS: OBJECT snmpCommunityName + MIN-ACCESS read-create + DESCRIPTION "Creation is not required." + Fix: s/is not required/is required/ [#9] There are several omissions from the change log (and one error that appears to be the result of an nroff source line that starts with a single quote). In addition, the somewhat randon order in which the changes are listed makes it hard for someone (e.g., and implementor of RFC 2576) to audit the changes and see what the differences are. The following diff contains suggestions for additions and corrections; a completely re-ordered change log with all of these fixes follows in the subsequent attachment. *************** *** 3230,3237 **** --- 3230,3240 ---- Section numbers below refer to the old section numbers from RFC 2576. Some section numbers have changed since RFC 2576. + - Changed "MUST" to "SHOULD" in item (3) of the first list in + Section 2.1.1 to since unconstrained INTEGER is not actually + illegal in SMIv2. - Changed "SHOULD" to "MUST" in item (13) of the first list in Section 2.1.1 to clarify that collecting related objects into groups is required when translating a MIB module from SMIv1 to *************** *** 3247,3260 **** --- 3250,3266 ---- - In the second bullet of the last part of Section 3 listing the SNMPv2 notification parameters, clarified that the snmpTrapOID parameter refers to the value portion (not the name portion) of the second variable-binding, and changed the wording in the text under bullet (1) of Section 3.2 from "the snmpTrapOID" to "the snmpTrapOID value" to emphasize this point. + - In bullet (6) of Section 3.2 emphasized that the SNMPv2 + variable-bindings do not include sysUpTime.0 an snmpTrapOID.0. + - In Section 4.2 clarified that the 'Upstream Version' refers to the version used between the command generator or notification receiver and the proxy, and the 'Downstream Version' refers to the version used between the proxy and the command responder or notification originator. RFC 2576 neglected to mention the notification receiver and notification originator. *************** *** 3261,3270 **** - In Section 4.2.1 clarified that the error-index field must be set to zero in a translated GetResponse-PDU with an error- ! status of 'tooBig'. ! - In Section 5.2.1 clarified that the scopedPDU's ! contextSnmpEngineID and contextName values come from the ! selected entry in the snmpCommunityTable. - Added Section 5.2.4 on Proxy Forwarding Of Requests. --- 3267,3283 ---- - In Section 4.2.1 clarified that the error-index field must be set to zero in a translated GetResponse-PDU with an error- ! status of 'tooBig' and made explicit the rationale for retrying ! a GetBulkRequest-PDU only once. ! - In Section 5.2.1 clarified that the securityName value and the ! scopedPDU's contextSnmpEngineID and contextName values come ! from the selected entry in the snmpCommunityTable. Also ! clarified how maxSizeResponseScopedPDU is determined and that ! securityStateReference must contain the community string of ! the original request. - Added Section 5.2.4 on Proxy Forwarding Of Requests. + - In Section 5.3 clarified that snmpTargetAddrTMask is to be + ignored whenever its use is not explicitly called for. + *************** *** 3287,3296 **** - Updated the description of `snmpTargetAddrMMS' to clarify that a value of 0 means that the maximum message size is unknown. ! - Changed the name of 'snmpCommunityGroup' to a name conflict ! with the SNMPv2-MIB. - Divided references into Normative References and Informative Reference and updated them to point to current documents. --- 3300,3310 ---- - Updated the description of `snmpTargetAddrMMS' to clarify that a value of 0 means that the maximum message size is unknown. ! - Changed the name of 'snmpCommunityGroup' ! to 'snmpCommunityTableGroup' in order to ! resolve a name conflict with the SNMPv2-MIB. - Divided references into Normative References and Informative Reference and updated them to point to current documents. *************** *** 3300,3307 **** --- 3314,3333 ---- - Re-organized bullets in section 2.1.1 to improve clarity. + - In Section 4.1.2 added text noting that SNMPv1 access to MIB + data SHOULD NOT be used when processing SNMPv2c or SNMPv3 + messages and re-worded final paragraph to note that the + sub-sections that follow are concerned solely with command + responders that use SNMPv2 access to MIB data while processing + an SNMPv1 request. + - Re-worded first bullet, section 4.2.1, to make it more readable. + + - Added text to the Deployment Hint in Section 4.2.2 to clarify + that different principals should be used for SNMPv1 requests + and SNMPv2/v3c requests if for SNMPv1 requests a principal for + which Counter64 objects are not-in-view is used. - Added text to abstract about conversion of MIBs from SMIv1 to SMIv2. ---2133786286-432624069-1046591640=:7701 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="cl.txt" Content-ID: Content-Description: re-ordered change log Content-Disposition: INLINE B.1. Changes From RFC 2576 Section numbers below refer to the old section numbers from RFC 2576. Some section numbers have changed since RFC 2576. - Added text to abstract about conversion of MIBs from SMIv1 to SMIv2. - Added note at end of section 1.3 that all discussion of SNMPv2 PDU types and protocol operations applies to both SNMPv2c and SNMPv3. - Added text at end of section 1.4 to clarify that there is no such thing as 'SNMPv3 access to MIB data,' as SNMPv3 just uses SNMPv2 PDU types and protocol operations. - Moved section 1.4 to the beginning of section 4. - Changed "MUST" to "SHOULD" in item (3) of the first list in Section 2.1.1 to since unconstrained INTEGER is not actually illegal in SMIv2. - Changed "SHOULD" to "MUST" in item (13) of the first list in Section 2.1.1 to clarify that collecting related objects into groups is required when translating a MIB module from SMIv1 to SMIv2. - Re-organized bullets in section 2.1.1 to improve clarity. - Changed "SHOULD" to "MUST" in items (1) and (2) of Section 2.3 since those updates are indeed required when translating a capabilities statement from the language defined by RFC 1303 into SMIv2. - In the second bullet of the last part of Section 3 listing the SNMPv2 notification parameters, clarified that the snmpTrapOID parameter refers to the value portion (not the name portion) of the second variable-binding, and changed the wording in the text under bullet (1) of Section 3.2 from "the snmpTrapOID" to "the snmpTrapOID value" to emphasize this point. - In bullet (6) of Section 3.2 emphasized that the SNMPv2 variable-bindings do not include sysUpTime.0 an snmpTrapOID.0. - In Section 4.2 clarified that the 'Upstream Version' refers to the version used between the command generator or notification receiver and the proxy, and the 'Downstream Version' refers to the version used between the proxy and the command responder or notification originator. RFC 2576 neglected to mention the notification receiver and notification originator. - In Section 4.1.2 added text noting that SNMPv1 access to MIB data SHOULD NOT be used when processing SNMPv2c or SNMPv3 messages and re-worded final paragraph to note that the sub-sections that follow are concerned solely with command responders that use SNMPv2 access to MIB data while processing an SNMPv1 request. - Re-worded first bullet, section 4.2.1, to make it more readable. - In Section 4.2.1 clarified that the error-index field must be set to zero in a translated GetResponse-PDU with an error- status of 'tooBig' and made explicit the rationale for retrying a GetBulkRequest-PDU only once. - Added text to the Deployment Hint in Section 4.2.2 to clarify that different principals should be used for SNMPv1 requests and SNMPv2/v3c requests if for SNMPv1 requests a principal for which Counter64 objects are not-in-view is used. - In Section 5.2.1 clarified that the securityName value and the scopedPDU's contextSnmpEngineID and contextName values come from the selected entry in the snmpCommunityTable. Also clarified how maxSizeResponseScopedPDU is determined and that securityStateReference must contain the community string of the original request. - Added Section 5.2.4 on Proxy Forwarding Of Requests. - In Section 5.3 clarified that snmpTargetAddrTMask is to be ignored whenever its use is not explicitly called for. - Updated the LAST-UPDATED, CONTACT-INFO, and REVISION clauses and added a copyright notice to the DESCRIPTION clause of the MIB module's MODULE-IDENTITY invocation. - Added text to DESCRIPTION of snmpCommunityName to clarify why the object has no size restriction. - Updated the description of snmpCommunityTransportTag to make it consistent with the rest of the document. - Updated the description of `snmpTargetAddrMMS' to clarify that a value of 0 means that the maximum message size is unknown. - Changed the name of 'snmpCommunityGroup' to 'snmpCommunityTableGroup' in order to resolve a name conflict with the SNMPv2-MIB. - Added compliance statement to SNMP-COMMUNITY-MIB for full read-create compliance. - Divided references into Normative References and Informative Reference and updated them to point to current documents. - Inserted current year into all copyright notices. - Corrected various typographical and grammatical errors. ---2133786286-432624069-1046591640=:7701-- From owner-snmpv3@lists.tislabs.com Thu Mar 6 08:54:46 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14655 for ; Thu, 6 Mar 2003 08:54:46 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA03940 Thu, 6 Mar 2003 07:50:05 -0500 (EST) Message-Id: <200303061129.GAA03442@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: snmpv3@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-snmpv3-coex-v2-03.txt Date: Thu, 06 Mar 2003 06:29:07 -0500 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SNMP Version 3 Working Group of the IETF. Title : Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework Author(s) : R. Frye, D. Levine, S. Routhier, B. Wijnen Filename : draft-ietf-snmpv3-coex-v2-03.txt Pages : 60 Date : 2003-3-5 The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, (SNMPv3), version 2 of the Internet-standard Network Management Framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1). This document also describes how to convert MIB modules from SMIv1 format to SMIv2 format. This document obsoletes RFC 2576. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-snmpv3-coex-v2-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-snmpv3-coex-v2-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-snmpv3-coex-v2-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-5141238.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpv3-coex-v2-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpv3-coex-v2-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-5141238.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-snmpv3@lists.tislabs.com Thu Mar 6 21:57:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25131 for ; Thu, 6 Mar 2003 21:57:22 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA05835 Thu, 6 Mar 2003 21:06:34 -0500 (EST) Message-Id: <200303061420.JAA15909@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: snmpv3@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-snmpv3-coex-v2-03.txt Date: Thu, 06 Mar 2003 09:20:46 -0500 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SNMP Version 3 Working Group of the IETF. Title : Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework Author(s) : R. Frye, D. Levi, S. Routhier, B. Wijnen Filename : draft-ietf-snmpv3-coex-v2-03.txt Pages : 60 Date : 2003-3-5 The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, (SNMPv3), version 2 of the Internet-standard Network Management Framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1). This document also describes how to convert MIB modules from SMIv1 format to SMIv2 format. This document obsoletes RFC 2576. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-snmpv3-coex-v2-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-snmpv3-coex-v2-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-snmpv3-coex-v2-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-6093757.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpv3-coex-v2-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpv3-coex-v2-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-6093757.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-snmpv3@lists.tislabs.com Sat Mar 22 08:53:50 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25983 for ; Sat, 22 Mar 2003 08:53:50 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA29929 Sat, 22 Mar 2003 08:07:16 -0500 (EST) Date: Sat, 22 Mar 2003 05:07:04 -0800 (PST) From: Michael Kirkham To: snmpv3@lists.tislabs.com Subject: A slight flaw in the order of operations in USM Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Well, "slight flaw" may be too strong of a wording, but it's a tiny thorn that would be simple enough to fix in the future, with little negative consequence: I would suggest that step 3.2(7) (timeliness checking) of RFC 3414 ought to come after step 3.2(8) (decryption) -- at least the part where the out-of-time-window error is returned to the calling module. The reason being that RFC 3412 requires the PDU type, if it can be determined, to override the settings of the 'reportable' flag. If an implementation follows this order to the letter, and receives an authPriv request from another implementation that erroneously neglects to set the reportable flag, then time synchronization will fail, where it would otherwise succeed had the PDU simply been decrypted first, because the PDU type will be unknown. The only negative consequence that I can think of for decrypting prior to timeliness checking is some additional CPU load/processing time for out-of-time-window messages, which would probably only matter in the case of a DOS attack via replay flood. Alternately, the notInTimeWindows report should always be sent, regardless of the state of the reportable flag, if the message indicates that the processing engine is authoritative by way of the msgAuthoritativeEngineID parameter. Like I said, it's only a slight flaw -- only one that would affect a non-authoritative engine with a bug in its flag settings -- but I thought it worth noting, if only because it might cause a new implementor to scratch their head for a while if they find that time synchronization works with authNoPriv but not with authPriv. -- Michael Kirkham www.muonics.com From owner-snmpv3@lists.tislabs.com Sat Mar 22 14:27:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02169 for ; Sat, 22 Mar 2003 14:27:36 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA00888 Sat, 22 Mar 2003 13:47:22 -0500 (EST) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501272667@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Michael Kirkham , snmpv3@lists.tislabs.com Subject: RE: A slight flaw in the order of operations in USM Date: Sat, 22 Mar 2003 19:50:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk [speaking as a technical contributor] So... you seem to be saying we should go "out of our way" to try and deal with an SnmpEngine that basically has incorrectly encoded the message? It seems to me that ervything works great for messages that are correctly encoded, and one that is incorrectly encoded might get an error (that potentially could have passed if we had done the sequence differently). I don't think we want to make such a change to a STD level document. Had this been brought up at the PS level... we could have considered it. Thanks, Bert > -----Original Message----- > From: Michael Kirkham [mailto:mikek@muonics.com] > Sent: zaterdag 22 maart 2003 14:07 > To: snmpv3@lists.tislabs.com > Subject: A slight flaw in the order of operations in USM > > > > Well, "slight flaw" may be too strong of a wording, but it's > a tiny thorn > that would be simple enough to fix in the future, with little negative > consequence: > > I would suggest that step 3.2(7) (timeliness checking) of RFC > 3414 ought > to come after step 3.2(8) (decryption) -- at least the part where the > out-of-time-window error is returned to the calling module. > The reason > being that RFC 3412 requires the PDU type, if it can be determined, to > override the settings of the 'reportable' flag. If an implementation > follows this order to the letter, and receives an authPriv > request from > another implementation that erroneously neglects to set the reportable > flag, then time synchronization will fail, where it would otherwise > succeed had the PDU simply been decrypted first, because the > PDU type will > be unknown. > > The only negative consequence that I can think of for > decrypting prior to > timeliness checking is some additional CPU load/processing time for > out-of-time-window messages, which would probably only matter > in the case > of a DOS attack via replay flood. > > Alternately, the notInTimeWindows report should always be > sent, regardless > of the state of the reportable flag, if the message indicates that the > processing engine is authoritative by way of the > msgAuthoritativeEngineID > parameter. > > Like I said, it's only a slight flaw -- only one that would affect a > non-authoritative engine with a bug in its flag settings -- > but I thought > it worth noting, if only because it might cause a new implementor to > scratch their head for a while if they find that time synchronization > works with authNoPriv but not with authPriv. > > -- > Michael Kirkham > www.muonics.com > From owner-snmpv3@lists.tislabs.com Sat Mar 22 18:02:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06803 for ; Sat, 22 Mar 2003 18:02:44 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01235 Sat, 22 Mar 2003 17:20:58 -0500 (EST) Date: Sat, 22 Mar 2003 14:20:44 -0800 (PST) From: Michael Kirkham To: "Wijnen, Bert (Bert)" cc: snmpv3@lists.tislabs.com Subject: RE: A slight flaw in the order of operations in USM In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15501272667@nl0006exch001u.nl.lucent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Nah, I'm not so much suggesting a change to the STD level document as I am (1) making a suggestion to implementors for a possibly better way to deal with such a situation and (2) mentioning it in case there is ever another revision to the document, then people could be aware of it (in which case it could be made a suggestion, but not a requirement). Yes, it's unfortunate I didn't several years ago. I only noticed when doing my second engine implementation recently. Or perhaps I just forgot. ;) On Sat, 22 Mar 2003, Wijnen, Bert (Bert) wrote: > Date: Sat, 22 Mar 2003 19:50:55 +0100 > From: "Wijnen, Bert (Bert)" > To: Michael Kirkham , snmpv3@lists.tislabs.com > Subject: RE: A slight flaw in the order of operations in USM > > [speaking as a technical contributor] > So... you seem to be saying we should go "out of our way" > to try and deal with an SnmpEngine that basically has > incorrectly encoded the message? > > It seems to me that ervything works great for messages that > are correctly encoded, and one that is incorrectly encoded > might get an error (that potentially could have passed > if we had done the sequence differently). > > I don't think we want to make such a change to a STD level > document. Had this been brought up at the PS level... > we could have considered it. > > > Thanks, > Bert > > > -----Original Message----- > > From: Michael Kirkham [mailto:mikek@muonics.com] > > Sent: zaterdag 22 maart 2003 14:07 > > To: snmpv3@lists.tislabs.com > > Subject: A slight flaw in the order of operations in USM > > > > > > > > Well, "slight flaw" may be too strong of a wording, but it's > > a tiny thorn > > that would be simple enough to fix in the future, with little negative > > consequence: > > > > I would suggest that step 3.2(7) (timeliness checking) of RFC > > 3414 ought > > to come after step 3.2(8) (decryption) -- at least the part where the > > out-of-time-window error is returned to the calling module. > > The reason > > being that RFC 3412 requires the PDU type, if it can be determined, to > > override the settings of the 'reportable' flag. If an implementation > > follows this order to the letter, and receives an authPriv > > request from > > another implementation that erroneously neglects to set the reportable > > flag, then time synchronization will fail, where it would otherwise > > succeed had the PDU simply been decrypted first, because the > > PDU type will > > be unknown. > > > > The only negative consequence that I can think of for > > decrypting prior to > > timeliness checking is some additional CPU load/processing time for > > out-of-time-window messages, which would probably only matter > > in the case > > of a DOS attack via replay flood. > > > > Alternately, the notInTimeWindows report should always be > > sent, regardless > > of the state of the reportable flag, if the message indicates that the > > processing engine is authoritative by way of the > > msgAuthoritativeEngineID > > parameter. > > > > Like I said, it's only a slight flaw -- only one that would affect a > > non-authoritative engine with a bug in its flag settings -- > > but I thought > > it worth noting, if only because it might cause a new implementor to > > scratch their head for a while if they find that time synchronization > > works with authNoPriv but not with authPriv. > > > > -- > > Michael Kirkham > > www.muonics.com > > > -- Michael Kirkham www.muonics.com From owner-snmpv3@lists.tislabs.com Mon Mar 24 14:16:08 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29488 for ; Mon, 24 Mar 2003 14:16:07 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA07495 Mon, 24 Mar 2003 13:22:56 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: A slight flaw in the order of operations in USM Date: Mon, 24 Mar 2003 13:26:55 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA88C03E@NHROCMBX1.ets.enterasys.com> Thread-Topic: A slight flaw in the order of operations in USM Thread-Index: AcLweiszKWms8MYzSoW1C4rbwjbBvgBt/g7Q From: "Harrington, David" To: "Michael Kirkham" , X-OriginalArrivalTime: 24 Mar 2003 18:26:55.0987 (UTC) FILETIME=[F30E1C30:01C2F232] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id NAA07492 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 8bit Hi Mike, I am in a meeting, so don't have access to the documents right now ;-) I think your approach is not consistent with the high-level design goals of snmpv3. The reason we have the flags in the header is so the PDU format can be independent of header processing, i.e. different PDU types could be used and the header processing doesn't need to know the details of the PDU format. Your approach requires the header processing sections to look into the PDU and interpret the contents/format to determine the operations type. That means the header processing must know just which type of PDU is encapsulated in the message, and that is not desirable for snmpv3. dbh > -----Original Message----- > From: Michael Kirkham [mailto:mikek@muonics.com] > Sent: Saturday, March 22, 2003 6:07 AM > To: snmpv3@lists.tislabs.com > Subject: A slight flaw in the order of operations in USM > > > > Well, "slight flaw" may be too strong of a wording, but it's > a tiny thorn > that would be simple enough to fix in the future, with little negative > consequence: > > I would suggest that step 3.2(7) (timeliness checking) of RFC > 3414 ought > to come after step 3.2(8) (decryption) -- at least the part where the > out-of-time-window error is returned to the calling module. > The reason > being that RFC 3412 requires the PDU type, if it can be determined, to > override the settings of the 'reportable' flag. If an implementation > follows this order to the letter, and receives an authPriv > request from > another implementation that erroneously neglects to set the reportable > flag, then time synchronization will fail, where it would otherwise > succeed had the PDU simply been decrypted first, because the > PDU type will > be unknown. > > The only negative consequence that I can think of for > decrypting prior to > timeliness checking is some additional CPU load/processing time for > out-of-time-window messages, which would probably only matter > in the case > of a DOS attack via replay flood. > > Alternately, the notInTimeWindows report should always be > sent, regardless > of the state of the reportable flag, if the message indicates that the > processing engine is authoritative by way of the > msgAuthoritativeEngineID > parameter. > > Like I said, it's only a slight flaw -- only one that would affect a > non-authoritative engine with a bug in its flag settings -- > but I thought > it worth noting, if only because it might cause a new implementor to > scratch their head for a while if they find that time synchronization > works with authNoPriv but not with authPriv. > > -- > Michael Kirkham > www.muonics.com > > From owner-snmpv3@lists.tislabs.com Mon Mar 24 18:15:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09166 for ; Mon, 24 Mar 2003 18:15:15 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA08237 Mon, 24 Mar 2003 17:32:07 -0500 (EST) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550137B719@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Harrington, David" , Michael Kirkham , snmpv3@lists.tislabs.com Subject: RE: A slight flaw in the order of operations in USM Date: Mon, 24 Mar 2003 23:35:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Good point Dave. We did indeed discuss this quite extensively a few years back. It is coming back into my mind. Thanks, Bert > -----Original Message----- > From: Harrington, David [mailto:dbh@enterasys.com] > Sent: maandag 24 maart 2003 19:27 > To: Michael Kirkham; snmpv3@lists.tislabs.com > Subject: RE: A slight flaw in the order of operations in USM > > > Hi Mike, > > I am in a meeting, so don't have access to the documents right now ;-) > > I think your approach is not consistent with the high-level > design goals > of snmpv3. The reason we have the flags in the header is so the PDU > format can be independent of header processing, i.e. > different PDU types > could be used and the header processing doesn't need to know > the details > of the PDU format. > > Your approach requires the header processing sections to look into the > PDU and interpret the contents/format to determine the > operations type. > That means the header processing must know just which type of PDU is > encapsulated in the message, and that is not desirable for snmpv3. > > dbh > > > -----Original Message----- > > From: Michael Kirkham [mailto:mikek@muonics.com] > > Sent: Saturday, March 22, 2003 6:07 AM > > To: snmpv3@lists.tislabs.com > > Subject: A slight flaw in the order of operations in USM > > > > > > > > Well, "slight flaw" may be too strong of a wording, but it's > > a tiny thorn > > that would be simple enough to fix in the future, with > little negative > > consequence: > > > > I would suggest that step 3.2(7) (timeliness checking) of RFC > > 3414 ought > > to come after step 3.2(8) (decryption) -- at least the part > where the > > out-of-time-window error is returned to the calling module. > > The reason > > being that RFC 3412 requires the PDU type, if it can be > determined, to > > override the settings of the 'reportable' flag. If an > implementation > > follows this order to the letter, and receives an authPriv > > request from > > another implementation that erroneously neglects to set the > reportable > > flag, then time synchronization will fail, where it would otherwise > > succeed had the PDU simply been decrypted first, because the > > PDU type will > > be unknown. > > > > The only negative consequence that I can think of for > > decrypting prior to > > timeliness checking is some additional CPU load/processing time for > > out-of-time-window messages, which would probably only matter > > in the case > > of a DOS attack via replay flood. > > > > Alternately, the notInTimeWindows report should always be > > sent, regardless > > of the state of the reportable flag, if the message > indicates that the > > processing engine is authoritative by way of the > > msgAuthoritativeEngineID > > parameter. > > > > Like I said, it's only a slight flaw -- only one that would affect a > > non-authoritative engine with a bug in its flag settings -- > > but I thought > > it worth noting, if only because it might cause a new implementor to > > scratch their head for a while if they find that time > synchronization > > works with authNoPriv but not with authPriv. > > > > -- > > Michael Kirkham > > www.muonics.com > > > > > From owner-snmpv3@lists.tislabs.com Mon Mar 24 19:39:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11422 for ; Mon, 24 Mar 2003 19:39:45 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA08461 Mon, 24 Mar 2003 19:01:49 -0500 (EST) Date: Mon, 24 Mar 2003 16:00:55 -0800 (PST) From: Michael Kirkham To: "Harrington, David" cc: snmpv3@lists.tislabs.com Subject: RE: A slight flaw in the order of operations in USM In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA88C03E@NHROCMBX1.ets.enterasys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk > Your approach requires the header processing sections to look into the > PDU and interpret the contents/format to determine the operations type. > That means the header processing must know just which type of PDU is > encapsulated in the message, and that is not desirable for snmpv3. Yes, this is true (well, my approach "suggests" looking into the PDU to interpret...), although it's true anyway, with or without the approach. The MPD document requires that the PDU type, if it is known/has been determined, overrides the state of the 'reportable' flag. ie.: The reportableFlag is a secondary aid in determining whether a Report PDU MUST be sent. It is only used in cases where the PDU portion of a message cannot be decoded, due to, for example, an incorrect encryption key. If the PDU can be decoded, the PDU type forms the basis for decisions on sending Report PDUs. [RFC 3412, $6.4] So basically what I'm saying is, since the PDU portion of the message can in fact be decoded if you just decrypt it before timeliness checking, then you may as well go ahead and do so, even though you are not required to do so by the literal order of operations. -- Michael Kirkham www.muonics.com From owner-snmpv3@lists.tislabs.com Tue Mar 25 18:46:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11469 for ; Tue, 25 Mar 2003 18:46:06 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA12081 Tue, 25 Mar 2003 18:01:04 -0500 (EST) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550137B9D2@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Snmpv3-wg (E-mail)" Subject: FW: Last Call: The AES Cipher Algorithm in the SNMP's User-based Security Model to Proposed Standard Date: Wed, 26 Mar 2003 00:04:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk SNMPv3 supporters, pls review and post your comments (if any)as requested. Statements of: I have read it and think it is "good stuff" are welcome too Thanks, Bert -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: dinsdag 25 maart 2003 20:52 Subject: Last Call: The AES Cipher Algorithm in the SNMP's User-based Security Model to Proposed Standard The IESG has received a request to consider The AES Cipher Algorithm in the SNMP's User-based Security Model as a Proposed Standard. This has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-4-25. Files can be obtained via http://www.ietf.org/internet-drafts/draft-blumenthal-aes-usm-05.txt From JDITWZumF@chem.northwestern.edu Wed Mar 26 14:25:38 2003 Received: from 24.130.249.240 (c-24-130-249-240.we.client2.attbi.com [24.130.249.240]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08480 for ; Wed, 26 Mar 2003 14:25:37 -0500 (EST) Date: Wed, 26 Mar 2003 14:25:37 -0500 (EST) X-SpamLevel: RKTAe--1750535478 Received: from 85.55.36.170 (HELO inia.cls.org) (85.55.36.170) by lists.tax.org with ESMTP id for ; Wed, 5 Mar 2003 02:03:11 -0600 X-Mailer: Microsoft Outlook Express 5.00.2919.6600 Message-Id: <4.7.7.1629421116.Ur7MJAN9@geneva.dnsvault.com> To: "snmpv3-archive@lists.ietf.org" From: "Mitsuko Carroway" Subject: snmpv3-archive@lists.ietf.org Have sex tonight, guaranteed Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="==S1uqC7QbNXOi" 9b0FfpjODV8kDIiU2sdE0Gb6Dwntkaewyi5pfPqEKqrF6 37ceb7efa4aa4a00a3efa4b67cb9c9cd e4bacb2164d6a0b0e854703d1e78a395 while proceeding with its overly-aggressive business practices. --==S1uqC7QbNXOi Content-Type: text/plain; charset="us-ascii"; format=flowed vIl5b7hz9a2R2G2CY4Fl4MeyTXDiRaSvXirJQ4cbNjs4VDuq8jJtmmGaQUqf1QQ7DZc6iY7xjKCBZPZSgrM4sVtGwZv4A3eEMXbF6IUfu9gJaoBEdPaFh9kJZb8GWpza1j9v1BZDTRVnkmiRzJZlqbIdY8RPoMbnY7rVfhs6MjVsuZIVxNTtSMFGD00NO5UGACatRrK4cX0Rdv6NMkOFNPtllqDc11DkZYqNUD4fR562Ffu2xaEQ8vwMuvQdYIQUi5AgMExTyPJvYvUJhZpVUrfk6M6M8Js6lisiJzRHnOJT4ndlR3PThdOwwmUIq5Z2tGB0wVOyUbuzcKzCuJ5zXaeen7yPH7rOcRy1DUs5l59EjEvfD6VDavla0BcclwgXw9z2dvWQ7sQENg7OV5bcZEhaZSnkUSc23B0Ka42nnWMODqetR3hpQAo8Zs6a6Lf5EJc6euL3efCaffhoPdBXujg8C4zZYNwiG3PLixYVG35iACZ0O2tUPcQW it runs on Windows 95, 98, 2000, ME, and XP.) "Fear of light is what phobia? "Photophobia" --==S1uqC7QbNXOi Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 Cgo8aHRtbD4KPGhlYWQ+PC9oZWFkPgo8Ym9keSBiZ2NvbG9yPSIjRkZGRkZGIj4KPGJyPgpI ZWxsbyBzbm1wdjMtYXJjaGl2ZUBsaXN0cy5pZXRmLm9yZyw8YnI+CjwhLS1jMlZlZGVpS0F6 VDctLT5XPCEtLTd1ai0tPmFuPCEtLUpkcUVaS1RWN1QwUnQtLT50ZWQ8IS0tckJaUHlnTFpI SUpoR0lIVlNxLS0+IHRvPCEtLXdpVTJ2QTRqZ0wyb085aVlMbHp0aS0tPiBzaDwhLS1MYldp dVd2bWlocTBVOGdEVUUzemVLNE9VYm1tLS0+b3cgPCEtLVkwY0lKRmlPNElkMDV1WXp3b3Vm VWdVcWN0OC0tPnlvdTwhLS1rblNVRkZqZFVIdEVZRGJyLS0+IDwhLS00U214eWtLZ0ZsZjBx ZXdtZFEyUjQtLT50aGk8IS0tNnVFM2pMdHcwMUpqR0U0eEV2T3pvai0tPnMuIDwhLS1TcGll ZlJ3d3FpVkxDbmNXVzhGU083dy0tPldvPCEtLWNJeU1TdDdvZUh3SWJXaVZNUFBwa05VLS0+ cmtpPCEtLXNBRjcwUEJRWDdMUUJxbnpuQXRNNlhORmRzTEgtLT5uZyA8IS0td0RJZDlpMlk0 cHlhLS0+Zm9yPCEtLWo0S2l4alMtLT4gdGg8IS0tYy0tPm91PCEtLWU2ZmIyaXUzV0M3LS0+ c2FuPCEtLVFxZEM3ZnpNSzEwMVBQZnB5SEstLT5kczwhLS1UcndZdHN2emJwdkZ3SEQ3aVF2 aVgzQ1M5eC0tPiBvZjwhLS0yakJWRExmNm5lVEctLT4gbWU8IS0tM2xkbEs4ZjJXLS0+biwg aTwhLS14R1owMk5CLS0+dCc8IS0tZ0lUWUp1ZVNaLS0+cyBwPCEtLXkwZUpHVTVQby0tPnJl dDwhLS00Z1hvdWZSMXZqSi0tPnR5IDwhLS0wb3YySGU2bi0tPmNvbzwhLS1tcC0tPmwgLTwh LS0xdUhHQjd1S255Nlh6QVE0OC0tPi0gYzwhLS1BQW9DQnZNSFlkUlktLT5oZWM8IS0tUFIt LT5rIGk8IS0tQjdya1Q3dTcwd09hVXgtLT50IDwhLS1wLS0+b3V0PCEtLUwySGRxRnBLLS0+ Ljxicj4KPGJyPgo8Y2VudGVyPgo8IS0tNTI0MDY2Mjk2LS0+PCEtLXhtR1pMSERiQ3pUTzlj SlpWT0pocEtaLS0+CjxjZW50ZXI+PGEgaHJlZj0iaHR0cDovL2FkdWx0d2VicGFzc2hvc3Rp bmcub3JnL3h4eGRhdGUiPjxpbWcgYm9yZGVyPTAgYWx0PSIiIHNyYz0iaHR0cDovL2FkdWx0 d2VicGFzc2hvc3Rpbmcub3JnL3h4eGRhdGUvZ2QxLnBocD9lPXNubXB2My1hcmNoaXZlQGxp c3RzLmlldGYub3JnIj48L2E+PC9jZW50ZXI+CjwhLS0xNDA1OTEyMTAzLS0+PCEtLTE2ODkw MjgzMTktLT48IS0tOTQyNDIwODg3LS0+PCEtLTIyY3FVbUVhQ0l5aFNkd1hRQXd0ZkN2UHVB Rmd5Zm9ENWhZd1lZejh5NE03NWZ4aDd0ZjFpMUtZQkxrNm0yVC0tPgo8IS0tCjMxCiAgICAg ICAgICB0byBrbm93IHRoZSBzZWNyZXQgb2YgbXkgcG93ZXIsIHJhbGx5IHRoZSBtYXNzZXMg dG8gcmViZWxsaW9uLAoiSGUgZGlzY292ZXJlZCB0aGUgR3JhbmQgQ2FueW9uPyIgIkZyYW5j aXNjbyBDb3JvbmFkbyIKIldoYXQgaXMgdGhlIG5hbWUgb2YgYSBzbWFsbCBjb21wdXRlciBp bnRyb2R1Y2VkIGluIDE5NzUgYnkgTWljcm8gSW5zdHJ1bWVudGF0aW9uIFRlbGVtZXRyeSBT eXN0ZW1zIG9mIE5ldyBNZXhpY28/IiAiQWx0YWlyIDg4MDAiCgotLT4KPC9ib2R5PjwvaHRt bD4KCg== --==S1uqC7QbNXOi-- From owner-snmpv3@lists.tislabs.com Fri Mar 28 13:37:53 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11333 for ; Fri, 28 Mar 2003 13:37:52 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21206 Fri, 28 Mar 2003 12:40:26 -0500 (EST) Message-ID: <3E8488B9.9070701@mg-soft.si> Disposition-Notification-To: Matjaz Vrecko Date: Fri, 28 Mar 2003 18:39:05 +0100 From: Matjaz Vrecko Reply-To: Matjaz Vrecko Organization: MG-SOFT Corp. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en, sl MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" , "Snmpv3-wg (E-mail)" CC: Matjaz Vrecko Subject: Re: FW: Last Call: The AES Cipher Algorithm in the SNMP's User-based Security Model to Proposed Standard References: <7D5D48D2CAA3D84C813F5B154F43B1550137B9D2@nl0006exch001u.nl.lucent.com> In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550137B9D2@nl0006exch001u.nl.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hello Bert, This week MG-SOFT implemented AES and, according to Uri's draft, sucesfully extended the USM module in our SNMPv3 engine. Early next week we will make available our SNMPv3 agent on-line on the Internet for interoperability tests with other implementations (once the agent will be on-line, I will post exact access parameters). Best regards till then, Matjaz Wijnen, Bert (Bert) wrote: > SNMPv3 supporters, > pls review and post your comments (if any)as requested. > > Statements of: I have read it and think it is "good stuff" > are welcome too > > Thanks, > Bert > > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org] > Sent: dinsdag 25 maart 2003 20:52 > Subject: Last Call: The AES Cipher Algorithm in the SNMP's User-based > Security Model to Proposed Standard > > > > The IESG has received a request to consider The AES Cipher Algorithm in > the SNMP's User-based Security Model > as a Proposed Standard. This has been reviewed in the IETF but is not > the product of an IETF Working Group. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2003-4-25. > > Files can be obtained via http://www.ietf.org/internet-drafts/draft-blumenthal-aes-usm-05.txt > > -- Matjaz Vrecko MG-SOFT Corporation, Strma ulica 8, SI-2000 Maribor, Slovenia Internet: http://www.mg-soft.si/ E-mail: Phone: +386 2 2506565, Fax: +386 2 2506566 From owner-snmpv3@lists.tislabs.com Mon Mar 31 14:30:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20039 for ; Mon, 31 Mar 2003 14:30:39 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA29031 Mon, 31 Mar 2003 13:40:57 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: last call Date: Mon, 31 Mar 2003 13:44:41 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA6030D1@NHROCMBX1.ets.enterasys.com> Thread-Topic: last call Thread-Index: AcL3tbH0xTSeY/j6SVuXnttNFLO5og== From: "Harrington, David" To: "Snmpv3@Lists.Tislabs.Com (E-mail)" X-OriginalArrivalTime: 31 Mar 2003 18:44:41.0348 (UTC) FILETIME=[96F38C40:01C2F7B5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id NAA29022 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 8bit Hi, Now that everybody has had a chance to relax after the IETF meeting, it is time to do some work. This message officially starts the SNMPv3 WG Last Call for the coex document, as published in ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-snmpv3-coex-v2-03.txt. There have already been some comments made, and the editors will update the document and post it for WG review prior to submission of the document to the IESG. Let me point out that we have already done a last call, and the current document includes most of the requested changes. We are trying to finalize the document for publication as an RFC. We want to finalize the document PRIOR to the editors' 48-hour review. In keeping with the IETF general consensus of the desirability of open processes and transparency, the SNMPv3 WG chairs want all changes to be made in a process that is fully open to the WG and not done in closed-session, such as the 48-hour editor review. Since every change request can potentially force us to do another last call to make sure nobody objects to the change, please limit your comments to those things that are needed to make the document "good enough" for implementors to use as guidelines to create interoperable implementations. Please refrain from comments that are seeking "perfection" rather than useability, so we can finish the last call process and submit the document for publication. Thanks, dbh --- David Harrington dbh@enterasys.com co-chair, IETF SNMPv3 WG From owner-snmpv3@lists.tislabs.com Mon Mar 31 16:29:08 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25487 for ; Mon, 31 Mar 2003 16:29:08 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA29496 Mon, 31 Mar 2003 15:50:10 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: last call intent Date: Mon, 31 Mar 2003 15:54:11 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA6030DB@NHROCMBX1.ets.enterasys.com> Thread-Topic: last call intent Thread-Index: AcL3x8j1FaVLzamnS0G1+0BY0mGJWA== From: "Harrington, David" To: "Snmpv3@Lists.Tislabs.Com (E-mail)" X-OriginalArrivalTime: 31 Mar 2003 20:54:11.0423 (UTC) FILETIME=[AE46E6F0:01C2F7C7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id PAA29493 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 8bit Hi, A question arose. Let me answer it: The chairs believe consensus has been reached to submit the coex document for BCP status. If you have a strong objection to this decision, please speak up with detailed reasons. dbh David Harrington Network Management Architect Office of the CTO Enterasys Networks