From owner-snmpv3@lists.tislabs.com Tue Apr 1 13:55:25 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 NAA07985 for ; Tue, 1 Apr 2003 13:55:25 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA02520 Tue, 1 Apr 2003 13:02:19 -0500 (EST) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155014839FA@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Snmpv3-wg (E-mail)" Cc: "Steve Bellovin (E-mail)" Subject: FW: Last Call: The AES Cipher Algorithm in the SNMP's User-based Security Model to Proposed Standard Date: Tue, 1 Apr 2003 20:05:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk FYI and possible reaction. Thanks, Bert -----Original Message----- From: Steve Moulton [mailto:moulton@snmp.com] Sent: vrijdag 28 maart 2003 18:28 To: iesg@ietf.org Cc: hecht@snmp.com; park@snmp.com Subject: RE: Last Call: The AES Cipher Algorithm in the SNMP's User-based Security Model to Proposed Standard Greetings, Developers at SNMP Research (namely Matt Hecht and Brian Park ) have encountered some issues with draft-blumenthal-aes-usm-05.txt that should be addressed before the document proceeds. 1) It would be very helpful to have a worked example, showing the construction of the initialization vector and the input and output of the encryption for a short message. This is very helpful in verifying an implementation before going to interoperability testing. It would be unnecessary to show key construction and localization steps, as those are very well covered in RFC3414. 2) In section 3.1.1, the text implies that the document specifying AES has not been published. Either I misunderstand http://www.nist.gov/aes, or it appears that the document has been published as FIPS 197. 3) Several editorial changes are noted below. Since FIPS 197 gives 192 and 256 bit encryption algorithms, it would have been helpful to have the document address the key extensions. I anticipate that there will be implementations using longer key lengths; addressing them in this document would help address interoperability. These concern aside, the developers feel that this is a useful and well-written document. Best Regards, Steve Moulton ---------------------------------------------------------------------- Note: I was unsure of the edit in section 1.3 below (changing "parameter s" to "parameters", but was unable to find a parameter "s" in FIPS 800-38B. --- /home6/moulton/ids/draft-blumenthal-aes-usm-05.txt Fri Mar 7 13:51:00 2003 +++ aes-draft-edits Thu Mar 27 17:18:02 2003 @@ -38,12 +38,12 @@ Abstract This document describes a symmetric encryption protocol that - supplement the protocols described in the User-based Security + supplements the protocols described in the User-based Security Model (USM), which is a Security Subsystem for version 3 of the Simple Network Management Protocol for use in the SNMP Architecture. The symmetric encryption protocol described in this document is based on the AES cipher algorithm, used in Cipher - FeedBack Mode (CFB), with key size of 128 bits. + FeedBack Mode (CFB), with a key size of 128 bits. Table of Contents @@ -102,7 +102,7 @@ USM based on the Advanced Encryption Standard. The major constraint is to maintain a complete interchangeability of - the new protocol defined on this memo with existing authentication + the new protocol defined in this memo with existing authentication and privacy protocols already defined in USM. For a given user, the AES-based privacy protocol MAY be used with @@ -125,8 +125,8 @@ If the authentication protocol defined for a user U at the authoritative SNMP engine E is one of the authentication protocols - defined on [RFC3414], the key localization is performed according to - the two steps process described in section 2.6 of [RFC3414]. + defined in [RFC3414], the key localization is performed according to + the two step process described in section 2.6 of [RFC3414]. 1.3 Password Entropy and Storage @@ -139,11 +139,11 @@ is vastly more probable that key guessing is the main threat. The following can be suggested with regard to the user password: - - Passwords lengths SHOULD be at least 12 bytes. + - Password lengths SHOULD be at least 12 bytes. - Password sharing SHOULD be limited so that passwords aren't shared among multiple SNMP users. - It is worth to remember that, as specified in [RFC3414], if user's + It is worth to remember that, as specified in [RFC3414], if a user's password is disclosed, then key localization will not help and network security may be compromised in this case. Therefore a user's password or non-localized key MUST NOT be stored on a managed @@ -235,15 +235,15 @@ Codebook (ECB), Cipher Block Chaining (CBC), Cipher Feedback (CFB), Output Feedback (OFB), and Counter (CTR). - The symmetric encryption protocol described in this memo use AES in - CFB mode with the parameter s set to 128 according to the definition + The symmetric encryption protocol described in this memo uses AES in + CFB mode with the parameters set to 128 according to the definition of CFB mode given in [AES-MODE]. This mode requires an Initialization Vector (IV) that is the same size as the block size of the cipher algorithm. 3.1.1.2 Key Size - In the encryption protocol described by this memo AES is used with + In the encryption protocol described by this memo AES is used with a key size of 128 bits. 3.1.1.3 Block Size and Padding @@ -254,7 +254,7 @@ 3.1.1.4 Rounds This parameter determines how many times a block is encrypted. The - encryption protocol described on this memo uses 10 rounds. + encryption protocol described in this memo uses 10 rounds. 3.1.2 Localized Key, AES Encryption Key and Initialization Vector @@ -262,8 +262,8 @@ [RFC3414], depends on the authentication protocol defined for that user U at the authoritative SNMP engine E. - The encryption protocol defined on this memo MUST be used with an - authentication protocol that generates a localized key with of at + The encryption protocol defined in this memo MUST be used with an + authentication protocol that generates a localized key with at least 128 bits. The authentication protocols described in [RFC3414] satisfy the requirement above. @@ -298,12 +298,12 @@ The 64-bit integer must be placed in the privParameters field to enable the receiving entity to compute the correct IV and to decrypt - the message. This 64-bit value is called "salt" in this document. + the message. This 64-bit value is called the "salt" in this document. See RFC 3414. 3.1.3 Data Encryption. - The data to be encrypted is treated as sequence of octets. + The data to be encrypted is treated as a sequence of octets. The data is encrypted in Cipher Feedback mode with the parameter s set to 128 according to the definition of CFB mode given in [AES- @@ -388,7 +388,9 @@ 3.2.4 Services provided by the AES Privacy Modules This section describes the inputs and outputs that the AES Privacy - modules expects and produces when the User-based Security module + modules expect and produce when the User-based Security module + -or- + module expects and produces when the User-based Security module invokes one of the AES Privacy modules for services. 3.2.4.1 Services for Encrypting Outgoing Data From owner-snmpv3@lists.tislabs.com Wed Apr 2 10:45:30 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 KAA14494 for ; Wed, 2 Apr 2003 10:45:30 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA05081 Wed, 2 Apr 2003 09:36:10 -0500 (EST) Message-ID: <3E52482A.4070908@india.adventnet.com> Date: Tue, 18 Feb 2003 20:20:18 +0530 From: Parasuraman Reply-To: parasuraman@india.adventnet.com Organization: AdventNet User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: snmpv3@lists.tislabs.com Subject: About password_to_key algorithm. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.4.1(snapshot 20020919) (mail-hub) Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, I came across a document/RFC long ago, that if the password is given repeatedly, then the key generated from it is the same. For example, the key generated for the passwords "test", "testtest", "testtesttest" are all the same. Can anyone of you, please point me to that concreate evidence. Thanks for your time and effort. Regards, R.Parasuraman. From owner-snmpv3@lists.tislabs.com Wed Apr 2 11:20:27 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 LAA15730 for ; Wed, 2 Apr 2003 11:20:27 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA05161 Wed, 2 Apr 2003 10:41:52 -0500 (EST) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501483C86@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: parasuraman@india.adventnet.com, snmpv3@lists.tislabs.com Subject: RE: About password_to_key algorithm. Date: Wed, 2 Apr 2003 17:35:24 +0200 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 If you check RFC3414, then you will see that the algorithm to generate the key will take the "password" or "passphrase" and repeat it as many times as needed to fill up a string of length 1,048,576 octets over which it runs MD5 or SHA in order to create the key. See page 78 of RFC3414 Now if you take pasword test and try to generate that string of length 1,048,576 octets, then you will find that the exact same string gets generated when you use testtest or testtesttest Hope that explains it, Thanks, Bert > -----Original Message----- > From: Parasuraman [mailto:parasuraman@india.adventnet.com] > Sent: dinsdag 18 februari 2003 15:50 > To: snmpv3@lists.tislabs.com > Subject: About password_to_key algorithm. > > > Hi all, > > I came across a document/RFC long ago, that if the password is given > repeatedly, then the key generated from it is the same. > For example, the key generated for the passwords "test", "testtest", > "testtesttest" are all the same. > > Can anyone of you, please point me to that concreate evidence. > > Thanks for your time and effort. > > Regards, > R.Parasuraman. > From owner-snmpv3@lists.tislabs.com Wed Apr 2 12:04:18 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 MAA18381 for ; Wed, 2 Apr 2003 12:04:17 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05257 Wed, 2 Apr 2003 11:09:00 -0500 (EST) Message-Id: <200304021538.h32FcAi10086@snowball.snmp.com> X-Mailer: exmh version 2.6.1 02/18/2003 with nmh-1.0.4 To: parasuraman@india.adventnet.com cc: snmpv3@lists.tislabs.com, moulton@snmp.com Subject: Re: About password_to_key algorithm. In-Reply-To: Message from Parasuraman of "Tue, 18 Feb 2003 20:20:18 +0530." <3E52482A.4070908@india.adventnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Apr 2003 10:38:10 -0500 From: Steve Moulton Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk On Tuesday, February 18 2003, Parasuraman wro te: > Hi all, > > I came across a document/RFC long ago, that if the password is given > repeatedly, then the key generated from it is the same. > For example, the key generated for the passwords "test", "testtest", > "testtesttest" are all the same. > > Can anyone of you, please point me to that concreate evidence. Check out RFC3414, Section 11.2, second paragraph. - Steve --- Steve Moulton SNMP Research, Inc voice: +1 865 573 1434 Sr Software Engineer 3001 Kimberlin Heights Rd. fax: +1 865 573 9197 moulton@snmp.com Knoxville, TN 37920-9716 USA http://www.snmp.com From owner-snmpv3@lists.tislabs.com Wed Apr 2 13:44:19 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 NAA22630 for ; Wed, 2 Apr 2003 13:44:18 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05748 Wed, 2 Apr 2003 12:56:30 -0500 (EST) Message-ID: <3E8B21C4.6040100@mg-soft.si> Disposition-Notification-To: Matjaz Vrecko Date: Wed, 02 Apr 2003 19:45:40 +0200 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> <3E8488B9.9070701@mg-soft.si> In-Reply-To: <3E8488B9.9070701@mg-soft.si> 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, As promised last week, MG-SOFT provides the updated SNMPv3 agent on-line in order to expose it for interoperability tests with other SNMPv3 implementations supporting USM module extended with the CFB-AES-128 privacy protocol, as specified in the draft-blumenthal-aes-usm-05.txt Internet draft. SNMPv3 security parameters for accessing the agent on the Internet are given on our web site at http://www.mg-soft.com/snmpv3.html So far we have successfully tested our implementation with Net-SNMP v5.0.8. MG-SOFT's WinSNMP development team is eager to receive any comments with respect to the behavior of the above mentioned SNMPv3 agent provided for interoperability tests. Best regards, Matjaz Matjaz Vrecko wrote: > 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 Wed Apr 2 18:21:42 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 SAA15329 for ; Wed, 2 Apr 2003 18:21:42 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06426 Wed, 2 Apr 2003 17:34:19 -0500 (EST) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501483CE5@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Matjaz Vrecko , "Snmpv3-wg (E-mail)" Subject: RE: FW: Last Call: The AES Cipher Algorithm in the SNMP's User-ba sed Security Model to Proposed Standard Date: Thu, 3 Apr 2003 00:37:59 +0200 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 Interesting.... So what have you used as the OID for the usmAesCfb128Protocol, cause in the I-D it is specified as { snmpPrivProtocols n } and you probably need a real number in order to test, no? Thanks, Bert > -----Original Message----- > From: Matjaz Vrecko [mailto:matjaz@mg-soft.si] > Sent: woensdag 2 april 2003 19:46 > 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 > > > Hello, > > As promised last week, MG-SOFT provides the updated SNMPv3 agent > on-line in order to expose it for interoperability tests with > other SNMPv3 implementations supporting USM module extended with > the CFB-AES-128 privacy protocol, as specified in the > draft-blumenthal-aes-usm-05.txt Internet draft. > > SNMPv3 security parameters for accessing the agent on the Internet > are given on our web site at http://www.mg-soft.com/snmpv3.html > > So far we have successfully tested our implementation with Net-SNMP > v5.0.8. MG-SOFT's WinSNMP development team is eager to receive any > comments with respect to the behavior of the above mentioned SNMPv3 > agent provided for interoperability tests. > > > Best regards, > > Matjaz > > > Matjaz Vrecko wrote: > > 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 Wed Apr 2 19:05:12 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 TAA18126 for ; Wed, 2 Apr 2003 19:05:12 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA06542 Wed, 2 Apr 2003 18:31:52 -0500 (EST) Date: Wed, 2 Apr 2003 15:33:03 -0800 (PST) From: Michael Kirkham To: "Wijnen, Bert (Bert)" cc: Matjaz Vrecko , "Snmpv3-wg (E-mail)" Subject: RE: FW: Last Call: The AES Cipher Algorithm in the SNMP's User-ba sed Security Model to Proposed Standard In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15501483CE5@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 The OID only matters for purposes of user creation/identification, no? SNMPv3/USM messages don't include information on the privacy protocol. On Thu, 3 Apr 2003, Wijnen, Bert (Bert) wrote: > Date: Thu, 3 Apr 2003 00:37:59 +0200 > From: "Wijnen, Bert (Bert)" > To: Matjaz Vrecko , > "Snmpv3-wg (E-mail)" > Subject: RE: FW: Last Call: The AES Cipher Algorithm in the SNMP's > User-ba sed Security Model to Proposed Standard > > Interesting.... So what have you used as the OID for > the usmAesCfb128Protocol, cause in the I-D it is > specified as { snmpPrivProtocols n } and you probably > need a real number in order to test, no? > > Thanks, > Bert > > > -----Original Message----- > > From: Matjaz Vrecko [mailto:matjaz@mg-soft.si] > > Sent: woensdag 2 april 2003 19:46 > > 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 > > > > > > Hello, > > > > As promised last week, MG-SOFT provides the updated SNMPv3 agent > > on-line in order to expose it for interoperability tests with > > other SNMPv3 implementations supporting USM module extended with > > the CFB-AES-128 privacy protocol, as specified in the > > draft-blumenthal-aes-usm-05.txt Internet draft. > > > > SNMPv3 security parameters for accessing the agent on the Internet > > are given on our web site at http://www.mg-soft.com/snmpv3.html > > > > So far we have successfully tested our implementation with Net-SNMP > > v5.0.8. MG-SOFT's WinSNMP development team is eager to receive any > > comments with respect to the behavior of the above mentioned SNMPv3 > > agent provided for interoperability tests. > > > > > > Best regards, > > > > Matjaz > > > > > > Matjaz Vrecko wrote: > > > 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 > > > -- Michael Kirkham www.muonics.com From owner-snmpv3@lists.tislabs.com Wed Apr 2 19:21:40 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 TAA18583 for ; Wed, 2 Apr 2003 19:21:40 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA06604 Wed, 2 Apr 2003 18:45:00 -0500 (EST) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501483CED@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Michael Kirkham , "Wijnen, Bert (Bert)" Cc: Matjaz Vrecko , "Snmpv3-wg (E-mail)" Subject: RE: FW: Last Call: The AES Cipher Algorithm in the SNMP's User-ba sed Security Model to Proposed Standard Date: Thu, 3 Apr 2003 01:48:20 +0200 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 Yep that is where they count. So you need to agree on such an OID in a usmUserTable entry in the usmUserPrivProtocol column in order to know that you indeed need to use this new privacy protocol/algorithm. Thanks, Bert > -----Original Message----- > From: Michael Kirkham [mailto:mikek@muonics.com] > Sent: donderdag 3 april 2003 1:33 > To: Wijnen, Bert (Bert) > Cc: Matjaz Vrecko; Snmpv3-wg (E-mail) > Subject: RE: FW: Last Call: The AES Cipher Algorithm in the SNMP's > User-ba sed Security Model to Proposed Standard > > > > The OID only matters for purposes of user creation/identification, no? > SNMPv3/USM messages don't include information on the privacy protocol. > > On Thu, 3 Apr 2003, Wijnen, Bert (Bert) wrote: > > > Date: Thu, 3 Apr 2003 00:37:59 +0200 > > From: "Wijnen, Bert (Bert)" > > To: Matjaz Vrecko , > > "Snmpv3-wg (E-mail)" > > Subject: RE: FW: Last Call: The AES Cipher Algorithm in the SNMP's > > User-ba sed Security Model to Proposed Standard > > > > Interesting.... So what have you used as the OID for > > the usmAesCfb128Protocol, cause in the I-D it is > > specified as { snmpPrivProtocols n } and you probably > > need a real number in order to test, no? > > > > Thanks, > > Bert > > > > > -----Original Message----- > > > From: Matjaz Vrecko [mailto:matjaz@mg-soft.si] > > > Sent: woensdag 2 april 2003 19:46 > > > 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 > > > > > > > > > Hello, > > > > > > As promised last week, MG-SOFT provides the updated SNMPv3 agent > > > on-line in order to expose it for interoperability tests with > > > other SNMPv3 implementations supporting USM module extended with > > > the CFB-AES-128 privacy protocol, as specified in the > > > draft-blumenthal-aes-usm-05.txt Internet draft. > > > > > > SNMPv3 security parameters for accessing the agent on the Internet > > > are given on our web site at http://www.mg-soft.com/snmpv3.html > > > > > > So far we have successfully tested our implementation > with Net-SNMP > > > v5.0.8. MG-SOFT's WinSNMP development team is eager to receive any > > > comments with respect to the behavior of the above > mentioned SNMPv3 > > > agent provided for interoperability tests. > > > > > > > > > Best regards, > > > > > > Matjaz > > > > > > > > > Matjaz Vrecko wrote: > > > > 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 > > > -- Michael Kirkham www.muonics.com From owner-snmpv3@lists.tislabs.com Thu Apr 3 09:56:01 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 JAA22024 for ; Thu, 3 Apr 2003 09:56:00 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA08829 Thu, 3 Apr 2003 09:04:12 -0500 (EST) Cc: "Snmpv3-wg (E-mail)" , "Steve Bellovin (E-mail)" Message-ID: <3E8B6D14.80104@bell-labs.com> Date: Wed, 02 Apr 2003 18:07:00 -0500 From: Uri Blumenthal Organization: Lucent Tehcnologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en, zh-cn, ru, de, he MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" Original-CC: "Snmpv3-wg (E-mail)" , "Steve Bellovin (E-mail)" Subject: Re: FW: Last Call: The AES Cipher Algorithm in the SNMP's User-based Security Model to Proposed Standard References: <7D5D48D2CAA3D84C813F5B154F43B155014839FA@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 Wijnen, Bert (Bert) wrote: > FYI and possible reaction. > > -----Original Message----- > From: Steve Moulton [mailto:moulton@snmp.com] > Subject: RE: Last Call: The AES Cipher Algorithm in the SNMP's > User-based Security Model to Proposed Standard > Developers at SNMP Research (namely Matt Hecht and > Brian Park ) have encountered some issues > with draft-blumenthal-aes-usm-05.txt that should be addressed before > the document proceeds. > > 1) It would be very helpful to have a worked example, showing > the construction of the initialization vector and > the input and output of the encryption for a short message. > This is very helpful in verifying an implementation before > going to interoperability testing. It would be unnecessary > to show key construction and localization steps, as those > are very well covered in RFC3414. Didn't want to delay the publication > 2) In section 3.1.1, the text implies that the document specifying > AES has not been published. Either I misunderstand > http://www.nist.gov/aes, or it appears that the document > has been published as FIPS 197. Thank you! You'r right, of course. Corrected. > 3) Several editorial changes are noted below. All the editorials have been taken care of - thanks a bunch!! > Since FIPS 197 gives 192 and 256 bit encryption algorithms, it would > have been helpful to have the document address the key extensions. I > anticipate that there will be implementations using longer > key lengths; addressing them in this document would help address > interoperability. 1. The algorithm seems to be less strong with 192-bit and 256-bit keys under Related Keys attack. Plus, key expansion/localisation will have to change to accomodate these modes. 2. It is preferable to use cipher block-length=key-length. 3. Not clear if there's demand for AES with 192 and 256-bit key. > Note: > > I was unsure of the edit in section 1.3 below (changing > "parameter s" to "parameters", but was unable to find a > parameter "s" in FIPS 800-38B. It's parameter S, the numer of feedback bits of CFB. It is there :-). Thanks! Regards, Uri. From owner-snmpv3@lists.tislabs.com Thu Apr 3 09:56:49 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 JAA22049 for ; Thu, 3 Apr 2003 09:56:49 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA08828 Thu, 3 Apr 2003 09:04:12 -0500 (EST) Message-ID: <3E8B529E.2020307@2003.joka.homelinux.org> Date: Wed, 02 Apr 2003 23:14:06 +0200 From: Jochen Katz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matjaz Vrecko Cc: "Snmpv3-wg (E-mail)" 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> <3E8488B9.9070701@mg-soft.si> <3E8B21C4.6040100@mg-soft.si> In-Reply-To: <3E8B21C4.6040100@mg-soft.si> 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 Hi, > So far we have successfully tested our implementation with Net-SNMP > v5.0.8. MG-SOFT's WinSNMP development team is eager to receive any > comments with respect to the behavior of the above mentioned SNMPv3 > agent provided for interoperability tests. I could contact your agent using the current SNMP++ with both sha / md5 and aes128. Regards, Jochen From owner-snmpv3@lists.tislabs.com Thu Apr 3 16:15:18 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 QAA14286 for ; Thu, 3 Apr 2003 16:15:18 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10219 Thu, 3 Apr 2003 15:22:42 -0500 (EST) Cc: "Wijnen, Bert (Bert)" , Matjaz Vrecko , "Snmpv3-wg (E-mail)" Message-ID: <3E8C946B.6000907@bell-labs.com> Date: Thu, 03 Apr 2003 15:07:07 -0500 From: Uri Blumenthal Organization: Lucent Tehcnologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en, zh-cn, ru, de, he MIME-Version: 1.0 To: Michael Kirkham Original-CC: "Wijnen, Bert (Bert)" , Matjaz Vrecko , "Snmpv3-wg (E-mail)" Subject: Re: FW: Last Call: The AES Cipher Algorithm in the SNMP's User-ba sed Security Model to Proposed Standard References: 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 Michael Kirkham wrote: > The OID only matters for purposes of user creation/identification, no? > SNMPv3/USM messages don't include information on the privacy protocol. Correct. But in order to be able to dymanically create USM user entries with AES privacy protocol, one still needs that OID. But if the entry was somehow manually configured (with some bogus value in the USM userTable, then the protocol implementation can be tested. > On Thu, 3 Apr 2003, Wijnen, Bert (Bert) wrote: >>Interesting.... So what have you used as the OID for >>the usmAesCfb128Protocol, cause in the I-D it is >>specified as { snmpPrivProtocols n } and you probably >>need a real number in order to test, no? >> >> >>>-----Original Message----- >>>From: Matjaz Vrecko [mailto:matjaz@mg-soft.si] >>>Sent: woensdag 2 april 2003 19:46 >>>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 >>> >>> >>>Hello, >>> >>>As promised last week, MG-SOFT provides the updated SNMPv3 agent >>>on-line in order to expose it for interoperability tests with >>>other SNMPv3 implementations supporting USM module extended with >>>the CFB-AES-128 privacy protocol, as specified in the >>>draft-blumenthal-aes-usm-05.txt Internet draft. >>> >>>SNMPv3 security parameters for accessing the agent on the Internet >>>are given on our web site at http://www.mg-soft.com/snmpv3.html >>> >>>So far we have successfully tested our implementation with Net-SNMP >>>v5.0.8. MG-SOFT's WinSNMP development team is eager to receive any >>>comments with respect to the behavior of the above mentioned SNMPv3 >>>agent provided for interoperability tests. >>> >>> >>>Best regards, >>> >>>Matjaz >>> >>> >>>Matjaz Vrecko wrote: >>> >>>>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 >>> >> > > -- > Michael Kirkham > www.muonics.com > From owner-snmpv3@lists.tislabs.com Thu Apr 3 17:00: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 RAA16552 for ; Thu, 3 Apr 2003 17:00:06 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10398 Thu, 3 Apr 2003 16:11:30 -0500 (EST) From: Keith McCloghrie Message-Id: <200304032114.NAA24741@cisco.com> Subject: Re: FW: Last Call: The AES Cipher Algorithm in the SNMP's User-ba To: uri@bell-labs.com (Uri Blumenthal) Date: Thu, 3 Apr 2003 13:14:23 -0800 (PST) Cc: bwijnen@lucent.com ("Wijnen, Bert (Bert)"), matjaz@mg-soft.si (Matjaz Vrecko), snmpv3@lists.tislabs.com ("Snmpv3-wg (E-mail)"), mikek@muonics.com (Michael Kirkham) In-Reply-To: <3E8C946B.6000907@bell-labs.com> from "Uri Blumenthal" at Apr 03, 2003 03:07:07 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 7bit It needn't be a "bogus value". It's (normally) undesirable and has the potential to cause confusion if two different OIDs are defined with the same meaning, but it's perfectly legal. Since no standard assignment is yet available, it's eminently reasonable for an enterprise to assign one from its own OID space if it needs it for immediate use. Keith. > Michael Kirkham wrote: > > The OID only matters for purposes of user creation/identification, no? > > SNMPv3/USM messages don't include information on the privacy protocol. > > Correct. > > But in order to be able to dymanically create USM user entries > with AES privacy protocol, one still needs that OID. > > But if the entry was somehow manually configured (with some bogus > value in the USM userTable, then the protocol implementation can > be tested. > > > On Thu, 3 Apr 2003, Wijnen, Bert (Bert) wrote: > >>Interesting.... So what have you used as the OID for > >>the usmAesCfb128Protocol, cause in the I-D it is > >>specified as { snmpPrivProtocols n } and you probably > >>need a real number in order to test, no? > >> > >> > >>>-----Original Message----- > >>>From: Matjaz Vrecko [mailto:matjaz@mg-soft.si] > >>>Sent: woensdag 2 april 2003 19:46 > >>>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 > >>> > >>> > >>>Hello, > >>> > >>>As promised last week, MG-SOFT provides the updated SNMPv3 agent > >>>on-line in order to expose it for interoperability tests with > >>>other SNMPv3 implementations supporting USM module extended with > >>>the CFB-AES-128 privacy protocol, as specified in the > >>>draft-blumenthal-aes-usm-05.txt Internet draft. > >>> > >>>SNMPv3 security parameters for accessing the agent on the Internet > >>>are given on our web site at http://www.mg-soft.com/snmpv3.html > >>> > >>>So far we have successfully tested our implementation with Net-SNMP > >>>v5.0.8. MG-SOFT's WinSNMP development team is eager to receive any > >>>comments with respect to the behavior of the above mentioned SNMPv3 > >>>agent provided for interoperability tests. > >>> > >>> > >>>Best regards, > >>> > >>>Matjaz > >>> > >>> > >>>Matjaz Vrecko wrote: > >>> > >>>>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 > >>> > >> > > > > -- > > Michael Kirkham > > www.muonics.com > > > From owner-snmpv3@lists.tislabs.com Fri Apr 4 06:13: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 GAA14217 for ; Fri, 4 Apr 2003 06:13:14 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA12054 Fri, 4 Apr 2003 05:22:00 -0500 (EST) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501484092@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Matjaz Vrecko , "Wijnen, Bert (Bert)" Cc: "Snmpv3-wg (E-mail)" Subject: RE: FW: Last Call: The AES Cipher Algorithm in the SNMP's User-ba sed Security Model to Proposed Standard Date: Fri, 4 Apr 2003 12:26:10 +0200 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 Inline > -----Original Message----- > From: Matjaz Vrecko [mailto:matjaz@mg-soft.si] > Sent: donderdag 3 april 2003 22:39 > To: Wijnen, Bert (Bert) > Cc: Snmpv3-wg (E-mail); matjaz@mg-soft.si > Subject: Re: FW: Last Call: The AES Cipher Algorithm in the SNMP's > User-based Security Model to Proposed Standard > > > Hello Bert, > > For the time being we assigned it as { snmpPrivProtocols 3 }. > That (in my view) is a NONO. You SHOULD NEVER use such non-allocated OIDs that are not under your control. As Keith pointed out... you better use some Enterprise OID under your entreprise branch. Thanks for explaining how things can work by people accessing your website. Pls change the OID. Bert > However, this is not relevant for establishing a successful SNMPv3 > communication between a remote SNMPv3 manager and our SNMPv3 agent. > When our agent receives an SNMPv3 PDU, it learns the userName from > the unencrypted part of the PDU. Then, through its internal USM > configuration table, the agent uniquely de-references used privacy > protocol and use it for decryption. > > All userNames and associated SNMPv3 secrets that our agent accepts > are available from http://www.mg-soft.com/snmpv3.html, and this is > where operators of remote SNMP managers can learn which encryption > protocol (and other 'secrets') must be used with which userName in > order to test the protocol interoperability between their and > MG-SOFT's implementation. > > > Best regards, > > Matjaz > > > Wijnen, Bert (Bert) wrote: > > Interesting.... So what have you used as the OID for > > the usmAesCfb128Protocol, cause in the I-D it is > > specified as { snmpPrivProtocols n } and you probably > > need a real number in order to test, no? > > > > Thanks, > > Bert > > > > > >>-----Original Message----- > >>From: Matjaz Vrecko [mailto:matjaz@mg-soft.si] > >>Sent: woensdag 2 april 2003 19:46 > >>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 > >> > >> > >>Hello, > >> > >>As promised last week, MG-SOFT provides the updated SNMPv3 agent > >>on-line in order to expose it for interoperability tests with > >>other SNMPv3 implementations supporting USM module extended with > >>the CFB-AES-128 privacy protocol, as specified in the > >>draft-blumenthal-aes-usm-05.txt Internet draft. > >> > >>SNMPv3 security parameters for accessing the agent on the Internet > >>are given on our web site at http://www.mg-soft.com/snmpv3.html > >> > >>So far we have successfully tested our implementation with Net-SNMP > >>v5.0.8. MG-SOFT's WinSNMP development team is eager to receive any > >>comments with respect to the behavior of the above mentioned SNMPv3 > >>agent provided for interoperability tests. > >> > >> > >>Best regards, > >> > >>Matjaz > >> > >> > >>Matjaz Vrecko wrote: > >> > >>>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-u sm-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 >> -- 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 Fri Apr 4 09:07: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 JAA22346 for ; Fri, 4 Apr 2003 09:07:45 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA12785 Fri, 4 Apr 2003 08:22:15 -0500 (EST) Message-ID: <3E8C9BE6.1010206@mg-soft.si> Disposition-Notification-To: Matjaz Vrecko Date: Thu, 03 Apr 2003 22:39:02 +0200 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)" CC: "Snmpv3-wg (E-mail)" , matjaz@mg-soft.si Subject: Re: FW: Last Call: The AES Cipher Algorithm in the SNMP's User-based Security Model to Proposed Standard References: <7D5D48D2CAA3D84C813F5B154F43B15501483CE5@nl0006exch001u.nl.lucent.com> In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15501483CE5@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, For the time being we assigned it as { snmpPrivProtocols 3 }. However, this is not relevant for establishing a successful SNMPv3 communication between a remote SNMPv3 manager and our SNMPv3 agent. When our agent receives an SNMPv3 PDU, it learns the userName from the unencrypted part of the PDU. Then, through its internal USM configuration table, the agent uniquely de-references used privacy protocol and use it for decryption. All userNames and associated SNMPv3 secrets that our agent accepts are available from http://www.mg-soft.com/snmpv3.html, and this is where operators of remote SNMP managers can learn which encryption protocol (and other 'secrets') must be used with which userName in order to test the protocol interoperability between their and MG-SOFT's implementation. Best regards, Matjaz Wijnen, Bert (Bert) wrote: > Interesting.... So what have you used as the OID for > the usmAesCfb128Protocol, cause in the I-D it is > specified as { snmpPrivProtocols n } and you probably > need a real number in order to test, no? > > Thanks, > Bert > > >>-----Original Message----- >>From: Matjaz Vrecko [mailto:matjaz@mg-soft.si] >>Sent: woensdag 2 april 2003 19:46 >>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 >> >> >>Hello, >> >>As promised last week, MG-SOFT provides the updated SNMPv3 agent >>on-line in order to expose it for interoperability tests with >>other SNMPv3 implementations supporting USM module extended with >>the CFB-AES-128 privacy protocol, as specified in the >>draft-blumenthal-aes-usm-05.txt Internet draft. >> >>SNMPv3 security parameters for accessing the agent on the Internet >>are given on our web site at http://www.mg-soft.com/snmpv3.html >> >>So far we have successfully tested our implementation with Net-SNMP >>v5.0.8. MG-SOFT's WinSNMP development team is eager to receive any >>comments with respect to the behavior of the above mentioned SNMPv3 >>agent provided for interoperability tests. >> >> >>Best regards, >> >>Matjaz >> >> >>Matjaz Vrecko wrote: >> >>>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 >> -- 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 Fri Apr 4 09:10: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 JAA22387 for ; Fri, 4 Apr 2003 09:10:53 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA12789 Fri, 4 Apr 2003 08:22:16 -0500 (EST) Message-ID: <3E8D63D3.4000406@mg-soft.si> Disposition-Notification-To: Matjaz Vrecko Date: Fri, 04 Apr 2003 12:52:03 +0200 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@mg-soft.si Subject: Re: FW: Last Call: The AES Cipher Algorithm in the SNMP's User-based Security Model to Proposed Standard References: <7D5D48D2CAA3D84C813F5B154F43B15501484092@nl0006exch001u.nl.lucent.com> In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15501484092@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, >>For the time being we assigned it as { snmpPrivProtocols 3 }. > > That (in my view) is a NONO. > You SHOULD NEVER use such non-allocated OIDs that are not under > your control. I understand. Note however that we have not published any MIB definition with that OID asignment. We have just used it as a hardcoded value, locally in our SNMPv3 implementation. So, I believe, no significant harm has been done. In spite of that, we will modify that internal assignment immediately. > As Keith pointed out... you better use some Enterprise OID > under your entreprise branch. We will do that. > Thanks for explaining how things can work by people accessing your > website. You're welcome. Best regards, Matjaz -- 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 Fri Apr 4 15:18:37 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 PAA06923 for ; Fri, 4 Apr 2003 15:18:37 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA13826 Fri, 4 Apr 2003 14:24:17 -0500 (EST) Message-ID: <00e801c2fae0$909509e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Snmpv3-wg \(E-mail\)" Cc: References: <7D5D48D2CAA3D84C813F5B154F43B155014839FA@nl0006exch001u.nl.lucent.com> <3E8B6D14.80104@bell-labs.com> Subject: Re: FW: Last Call: The AES Cipher Algorithm in the SNMP's User-based Security Model to Proposed Standard Date: Fri, 4 Apr 2003 11:29:51 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Hi - I've read earlier versions and provided comments to the authors. I think this is "good stuff" and would satisfy an important need. I have some minor comments on Purely editorial: Section 1.2: "two steps process" -> "two-step process" Section 3.1.2.1: "generates duplicate IV" -> "generates a duplicate IV" Section 3.1.3: "less than 128 bits" -> "fewer than 128 bits" Section 3.2.1: "wishes" -> "needs" (less anthropomorphic) At the ends of sentences, in some places the document has a single space, but in other places there are two spaces. Should be two spaces consistently. Technical: Section 2: This should be a free-standing module, importing snmpPrivProtocols from SNMP-FRAMEWORK-MIB. There is no need to treat this as a change to the snmpUsmMIB module. Randy From owner-snmpv3@lists.tislabs.com Sat Apr 5 08:48: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 IAA06300 for ; Sat, 5 Apr 2003 08:48:46 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA15907 Sat, 5 Apr 2003 07:47:15 -0500 (EST) Message-ID: <0fe401c2fb25$9e8eb6f0$5600a8c0@MIRELA> From: "Mirela Sechi Moretti Annoni Notare" To: Subject: IEEE MWCN'2003 - Call for Papers Date: Sat, 5 Apr 2003 00:42:46 -0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Virus-Scanned: by AMaViS perl-10 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 8bit Our apologies if you have received multiple copies. ****************************************** ****** CALL FOR PAPERS ******* ****************************************** IEEE MWCN'2003 The Fifth IEEE Conference on Mobile and Wireless Communications Networks Singapore in 27 - 29 October, 2003 http://www.icr.a-star.edu.sg/mwcn2003/ You are invited to submit original papers addressing topics in all areas of wireless communication systems and networks. Potential topics include, but are not limited to, the technical subject categories listed below: Management - Resource and Information Management - Pricing and Billing Issues Architecture - Convergence of Fixed and Mobile - Hybrid Communications System Devices - Low-Power End-Devices and Wireless Communications Security - Security in Mobile and Wireless Networks QoS - Adaptive Quality of Service Provisioning - End-to-end Quality of Service Mobility Support - Handoff Algorithms - IP and Mobility - Mobility and Connection Management in Heterogeneous Wireless Networks - Policy-based Mobility Management Applications - Personal Communications - Location and Context Management - Smart Media - Mobile Code - Mobile Ad-Hoc Networks Applications Access - Wireless IP - Wireless Multimedia Services - Wireless Local Loop (WLL) - Multiple Access Technology - Broadband Wireless Access Networking - Wireless Personal Area Networks - Wireless Local Area Networks - Mobility and Nomadic Computing - Analysis and Simulation of Mobile Network Protocols - Home Networking - Mobile Ad-hoc Networks and the Internet - Mobile Ad-Hoc Networking Routing - Satellite Networks The official language of the conference for submission of a paper and or an extended abstract and view graphs is English. This conference will identify the theoretical and actual problems that face designers of today's complex problems associated with mobile and wireless communications networks. The participants will show test results of experiments from building prototype systems, explore modeling and simulation tools as well as analytical methodologies and techniques for dealing with wireless systems. The objective of this event is to foster the exchange of information among researchers in this fast-moving field. The program will include presentations by distinguished researchers, speaking on recent advances in theory and practice. This conference also intends to bring together various mobile and wireless network systems developers to discuss the current status, technical challenges, standards, fundamental issues, and future services and applications in the form of workshops, business applications sessions and tutorials. It is also intended to provide a timely forum for exploratory research and practical contributions from North America, Europe, The Middle East, and the Far East. Guidelines for Submission Papers are invited on the conference theme and related topics. The original submission containing affiliation and full contact information of the authors should be addressed to the TPC chairs by the date indicated above based on the following instructions: Extended abstract should be in English, with no more than 1500 words and submitted to http://mwcn2003.lri.fr/REG-paper/ The paper should include an abstract of about 150 words, and must not exceed Accepted formats include Microsoft Word, PostScript and PDF. Authors must state that their paper have neither been published before nor currently being submitted elsewhere. The cover page must contain an abstract of about 150 words, name and affiliation of author(s) as well as the lead author's postal address, telephone number, fax number and e-mail. The language of the conference is English and papers must be in this language. Accepted papers will have to expanded into full paper to be distributed on the conference proceedings and or CD-ROMS, and will also be made available in the IEEExplore. Dates to Remember Deadline for submitting an extended abstract : May 5, 2003 Notification of acceptance: June 15, 2003 Papers received in camera ready form to MWCN 2003: July 1, 2003 Conference Date and place: 27-29 October, Singapore Organizing Committee Conference General Chair Dr. Guy Omidyar Institute for Communications Research, National University of Singapore Email:gomidyar@icr.a-star.edu.sg Conference Technical Program Chair Khaldoun Al-Agha Khaldoun Al Agha, LRI, University of Paris XI, France Email: alagha@lri.fr Conference Technical Program Co-chairs and area Coordinators Asia-Pacific: Boon Sain Yeo Institute for Communications Research, National University of Singapore Email: boonyeo@ieee.org North and South Americas: Azzedine Boukerche University of North Texas, USA Email: boukerche@cs.unt.edu Middle-East and Far East: Khaled Elsayed Cairo University, Egypt Email: khaled@ieee.org Tutorial, Workshop, Panel Chair Dr. Guy Omidyar Institute for Communications Research, National University of Singapore Email:gomidyar@icr.a-star.edu.sg Organizing Chair Ms Patricia Loh Institute for Infocomm Research, Singapore Email:patricia@i2r.a-star.edu.sg Finance Chair S Kunaselvam Institute for Communications Research, National University of Singapore Email:kuna@icr.a-star.edu.sg Conference Secretariat Please contact mwcn@i2r.a-star.edu.sg Web Chair Gek Hiong Tan Institute for Communications Research, National University of Singapore Email:tangh@icr.a-star.edu.sg Steering Committee Khaldoun Al Agha, LRI, University of Paris XI, France Mario Gerla, UCLA, USA Guy Omidyar, ICR-NUS, Singapore (Chair) Guy Pujolle, Université Paris 6, France Boon Sain Yeo, ICR-NUS, Singapore Technical Scientific Program Committee Hossam Afifi, INT, France Khaldoun Al Agha, LRI, University of Paris XI, France Hamid Aghvami, Kings College of London, UK André-Luc Beylot, IRIT, France Azzedine Boukerche, University of North Texas, US Andrew T. Campbell, Columbia University, USA Olga Casals, Universitat Politecnica de Catalunya, Spain Colin Chandler, Qualcomm Europe, France Francois Chin, Institute for Communications Research, NUS, Singapore Sajal K. Das, University Texas at Arlington, USA Khaled Elsayed, Cairo University, Egypt Markus Endler, IME/USP, Brazil Serge Fdida, Laboratoire d'informatique de Paris 6, France Afonso Ferreira, CNRS INRIA, France Adolf Finger, Technical University of Dresden, Germany Mario Gerla, UCLA, USA Martin Haardt, Ilmenau University of Technology, Germany Zygmunt J. Haas, Cornell University, USA Lajos Hanzo, University of Southampton, UK Jamshid Khun Jush, Ericsson, Germany Theo Kanter, Ericsson Research, Sweden Parviz Kermani, IBM Watson Research Center, USA Witold Krzymien, University of Alberta, Canada Xavier Lagrange, ENST Bretagne, France Khaled Ben Letaief, Hong Kong University, HK Antonio A. F. Loureiro, Federal University of Minas Gerais, Brazil Gerald Q. Maguire, Jr., KTH, Wireless Center, Sweden Jon W. Mark, University of Waterloo, Canada Geraldo Robson Mateus, Federal University of Minas Gerais, Brazil Marie-Jose Montpetit, Nokia, USA Mahmoud Naghshineh, IBM Watson Research Center, USA Ayman Naguib, Qualcomm, USA Mirela Sechi Moretti Annoni Notare, Barddal University, Brasil Guy Omidyar, Institute for Communications Research, NUS, Singapore Elena Pagani, Universita` degli Studi di Milano, Italy Kaveh Pahlavan, Worcester Polytechnic Institute, USA Gregory P. Pollini, Telecordia, USA Ramjee Prasad, Aalborg University, Denmark Guy Pujolle, Université Paris 6, France Christopher Rose, Associate Director, Rutgers WinLab, USA Elisabeth Royer, University of California, Santa Barbara Djamel Sadok, Universidade Federal de Pernambuco, Brazil Fabrizio Sestini, European Commission, Belgium Jan Slavik, Testcom, Czech Republic Kelvino S. Sousa, University of Toronto, Canada Cormac Sreenan, University College Cork, Ireland Sumei Sun, Institute for Communication Research, NUS, Singapore T.T. Tjhung, Institute for Communication Research, NUS, Singapore Guillaume Vivier, Motorola Labs, France Branimir Vojcic, George Washington University, USA Ivan Vukovic, Motorola, USA Adam Wolisz, Technische Universitat Berlin, Germany Boon Sain Yeo, Institute for Communication Research, NUS, Singapore Albert Zomaya, University of Sydney Australia From owner-snmpv3@lists.tislabs.com Sat Apr 5 11:52:43 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 LAA10797 for ; Sat, 5 Apr 2003 11:52:43 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16167 Sat, 5 Apr 2003 09:58:49 -0500 (EST) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501484214@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Snmpv3-wg (E-mail)" Subject: FW: Last Call: Textual Conventions for IPv6 Flow Label to Propos ed Standard Date: Sat, 5 Apr 2003 17:02:21 +0200 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 FYI and comment. Pls send comments to iesg/ietf mailing lists or send them to mibs@ops.ietf.org Thanks, Bert -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: zaterdag 5 april 2003 0:49 Subject: Last Call: Textual Conventions for IPv6 Flow Label to Proposed Standard The IESG has received a request from the Operations & Management Open Area Working Group to consider Textual Conventions for IPv6 Flow Label as a Proposed Standard. 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-5-4. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ops-ipv6-flowlabel-00.txt From owner-snmpv3@lists.tislabs.com Mon Apr 7 16:22:59 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 QAA04944 for ; Mon, 7 Apr 2003 16:22:59 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA22208 Mon, 7 Apr 2003 15:23:14 -0400 (EDT) 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: Coex Date: Mon, 7 Apr 2003 15:27:13 -0400 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA603107@NHROCMBX1.ets.enterasys.com> Thread-Topic: Last Call: Coex Thread-Index: AcL9O40cIu4h/w51QS6plZPCTw6VEA== From: "Harrington, David" To: "Snmpv3@Lists.Tislabs.Com (E-mail)" X-OriginalArrivalTime: 07 Apr 2003 19:27:14.0238 (UTC) FILETIME=[B17BE5E0:01C2FD3B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id PAA22205 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 8bit Hi, The Last Call on the Coexistence document is nearing closure. If you have any comments, please speak up now. Thanks, dbh David Harrington Network Management Architect Office of the CTO Enterasys Networks From owner-snmpv3@lists.tislabs.com Mon Apr 7 20:23: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 UAA11737 for ; Mon, 7 Apr 2003 20:23:06 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA23008 Mon, 7 Apr 2003 19:36:12 -0400 (EDT) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501484587@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Harrington, David" , "Snmpv3@Lists.Tislabs.Com (E-mail)" Subject: RE: Last Call: Coex Date: Tue, 8 Apr 2003 01:39:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Here are my comments. It is possible that Mike Heard had some of it included in his review comments. I think Mike's comments were good ones and we should fix accordingly. On page 16, first line, it seems that some text was lost. I think we need to change: to the value into to the value 'snmpTraps' as defined in RFC 3418 [RFC3418]. I see (In the MIB REVISION clause) Changed the name of 'snmpCommunityGroup' to a name conflict with the SNMPv2-MIB. Should that be: Changed the name of 'snmpCommunityGroup' to snmpCommunityTableGroup to avoid a name conflict with the SNMPv2-MIB. SAme in the revision log in appendix B. We may want to explain in the DESCRIPTION clause of snmpTrapCommunity why we have no SIZE restriction. Similar to what we did for snmpCommunityName (well, that is after the fixes from Mike). In the MIB module, when I read: OBJECT snmpCommunityName MIN-ACCESS read-create DESCRIPTION "Creation is not required." Then I think I do not understand. The MIN-ACCESS seems to say that creation in fact IS required, no? This also causes SMICng to bark with: W: f(coex.mi2), (478,32) MIN-ACCESS value identical to access specified for "snmpCommunityName" It seems to me that if we want to REQUIRE read-create, that we do not have to list the objects at all, do we? Thanks, Bert > -----Original Message----- > From: Harrington, David [mailto:dbh@enterasys.com] > Sent: maandag 7 april 2003 21:27 > To: Snmpv3@Lists.Tislabs.Com (E-mail) > Subject: Last Call: Coex > > > Hi, > > The Last Call on the Coexistence document is nearing closure. > If you have any comments, please speak up now. > > Thanks, > dbh > > David Harrington > Network Management Architect > Office of the CTO > Enterasys Networks > > From owner-snmpv3@lists.tislabs.com Mon Apr 7 20:31:09 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 UAA11958 for ; Mon, 7 Apr 2003 20:31:09 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA23052 Mon, 7 Apr 2003 19:43:14 -0400 (EDT) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501484588@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Harrington, David" , "Snmpv3@Lists.Tislabs.Com (E-mail)" Subject: RE: last call intent Date: Tue, 8 Apr 2003 01:46:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk I believe BCP is fine with me. Thanks, Bert > -----Original Message----- > From: Harrington, David [mailto:dbh@enterasys.com] > Sent: maandag 31 maart 2003 22:54 > To: Snmpv3@Lists.Tislabs.Com (E-mail) > Subject: last call intent > > > 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 > > From owner-snmpv3@lists.tislabs.com Tue Apr 15 09:50: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 JAA27455 for ; Tue, 15 Apr 2003 09:50:05 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA25358 Tue, 15 Apr 2003 08:49:42 -0400 (EDT) Reply-To: From: "manuel mendes" To: , , , , , , , , , , , , , , , , , , "'Ambient/WP Netw. Managent & Reconf.'" , , "'BGTA'" , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: IFIP I3E2003- Deadline Extended 21st April Date: Tue, 15 Apr 2003 07:28:32 -0300 Message-ID: <000a01c30339$dab17cf0$6d94aec8@jmm> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id GAA24868 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 8bit Our sincere apologies if you receive multiple copies. ##################################### I3E2003 C A L L F O R P A P E R S ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3rd IFIP International Conference on e-Commerce, e-Business and e-Government(I3E 2003) Sponsored by IFIP, international Federation for Information Processing September 21-24, 2003 Casa Grande Hotel, S“o Paulo, Guaruj·, BRAZIL ************************************************* Homepage http://www.cenpra.gov.br/I3E_conference ************************************************* + + + + + + + + + + + + + + + + + + + + + + ++ + Next important Dates!! + + ---------------------- + + + + Papers Deadline (extended):April 21st2003 + + Tutorial proposals due: 30th April 2003 + ++++++++++++++++++++++++++++++++++++++++++++++ This conference is the third IFIP conference on e-commerce, e-business, and e-government sponsored by the three committees TC6, TC8, and TC11. It provides a forum for users, engineers, and scientists in academia, industry, and government to present their latest findings in e-commerce, e-business, or e-government applications and the underlying technology to support those applications. Areas of particular interest include but are not limited to: eCommerce * Marketplaces, Portals, eHubs * B2B and ÝB2C models * Procurement, negotiations and dynamic pricing models (bidding, auctions) * Content management, ePayment systems * Agent-mediated electronic commerce * Case studies in electronic commerce * Consumer protection in electronic commerce * Costs and benefit aspects * Digital goods and products * Electronic commerce application fields eBusiness * Enterprise Portals * Innovative business models * Supply, Demand and Value chains * Business Process Re-engineering * Interorganizational systems, virtual organizations, and virtual markets * eCommunities * Workflow management and Collaboration * Management of dynamic collaborative networks * Complex adaptive and selforganising systems * Distributed work and knowledge flows in business networks * Business data exchange format and standards eGovernment * Digital cities, Digital regions, Rural networking * eGovernance and eInclusion, * Electronic Public Services for Citizens and enterprises:One-stop Government, Single-Window-Service, Seamless Government * E-Local administration * G2G, G2B, G2C and G2E models * Government Process Reengineering and redesigning cooperation within and between agencies * Frameworks and guidelines for e-Government * Transnational e-Government projects and standards * International and regional projects, case studies and international comparisons * Strategies, implementation policies and best practices Related Technical aspects * Technologies for interoperability and aplication integration * Information & communication OPEN platforms * User Mobility * Unified messaging * Agent and Grid technologies * Information retrieval and extraction and data mining * Knowledge Management * Security, privacy, Trustability * Smart Cards and biometrics * Digital signatures and Certificates * Standards for information interchange and processes, interoperability and semantic standardisation * Web Technologies: - Emerging Standards for Web Data (XML, XSL, RDF etc) - Semantic Web, Ontologies - Web data models and metadata - Knowledge discovery of Web data - Web data mining and analysis * E-(WEB) services - E-service location, selection, brokering - E-service composition, invocation and delivery - E-service monitoring, personalization, management and life cycle - XML-based protocols and description language - Service-based architectures and their underlying technology - Service-oriented application development - Standards for e-services Legal, social, cross-cultural issues * socio-economic research in the governance of networked organisations * e-government models and legal issues. * e-Inclusion * e-Democracy strategies, citizen participation in local public affairs * e-Governance tools for policymaking in governments and in policy networks * New organisational arrangements: ad-hoc co-operation and coalition between public agencies and public-private-partnerships * Institutional change and IT-driven modernisation of public governance structures * Intellectual property licensing * Reputation and trust mechanisms and issues MAIN TRACK, WORKSHOPS AND TUTORIALS *********************************** The conference will comprise several tracks with papers in the topics above and several workshops and tutorials dedicated to special topics. INFORMATION FOR AUTHORS *********************** Paper submissions should describe original work (not submitted or published elsewhere) and be 20 double-spaced pages in length. Submissions should include title, authors and a 150-word abstract as a front page, identify the author responsible for correspondence, incl. the authors name, mailing address, telephone and fax numbers, and e-mail address. The core paper should include the title only and no info about the authors. One of the authors of each paper must register and present the paper at the conference. The proceedings of the conference will be published by Kluwer Academic Publishers. Best papers are selected by the best paper award committee. Authors are requested to submit their manuscripts electronically as a Microsoft Word document, PDF, or in Postscript format. INFORMATION FOR WORKSHOPS AND TUTORIALS *************************************** Proposals for workshops should describe the title, scope and organizational structure. Workshop chairs are responsible for both organizing the review process and promotion of their workshop. Tutorial proposals should include the tutorial title, the names and a brief biography for each presenter (approximately half page) and a summary of the tutorial contents (approximately 1-2 pages . Proposals should be send electronically as Word or PDF files following the link at the conference homepage. INFORMATION FOR THE RESEARCH COLLOQUIUM AND POSTERS *************************************************** Research Colloquium offers PhD and Master students in themes related to I3E the opportunity to present and discuss their work with each other as well as a number of experienced international researchers. Students from all the I3E related disciplines are encouraged to apply, although numbers will be limited. Submissions should outline current research in progress and be no longer than 3 pages in length. An abstract and biographical note should be included. Poster submissions graphically illustrating original contributions on eCommerce, eBusiness and eGovernment are invited. Successful posters will be on show for the duration of the conference. Submissions should be comprised of a 2 page description of the theory, method, or technology the poster will illustrate. Final descriptions of posters will be included in the Conference Supplement. ******************** IMPORTANT DEADLINES ******************** Papers ------ Deadline: 21st April , 2003, Notification of acceptance: May 30th , 2003, Camera-ready papers:June 30th , 2003 Workshops --------- Deadline: 28th February 2003 (closed) Notification of acceptance: 28th March 2003, Camera-ready Material due: 31th July 2003 Tutorials --------- Deadline: 30th April 2003, Notification of acceptance:30th May 2003, Camera-ready material due: 31th July 2003 Posters ------- Deadline: 30th May 2003, Notification of acceptance: 27th June 2003, Camera-ready copy due: 31th July 2003 Research Colloquium ------------------- Deadline: 30th May 2003, Notification of acceptance: 27th Juni 2003, Camera-ready copy due: 31th July 2003 GENERAL INFORMATION ******************* Conference site for more information: http://www.cenpra.gov.br/I3E-conference ********* COMMITTEE ********* Honorary Chairs --------------- Prof. Dr. Radu Popescu Zeletin, FOKUS, De Dr. Arnaldo Madeira, State Government of S“o Paulo General Chair M. Mendes, mjmendes@bestway.com.br Programm Co-Chairs Reima Suomi, Reima.suomi@tukkk.fi Carlos Passos, carlos.passos@cenpra.gov.br Organizing Committee ******************** Organizing Co-Chairs Romildo Monte, romildo.monte@cenpra.gov.br Roberto Agune, ragune@sp.gov.br Workshops Chair, Clenio Figueiredo, clenio.salviano@cenpra.gov.br , Government Liaison Chairs, Agnaldo Lopes, alopes@sp.gov.br , MaurĚcio Moraes, mauriciomoraes@sp.gov.br Treasurer Chair Jarbas Cardoso, jarbas.cardoso@cenpra.gov.br, Tutorials Chair Clever Farias, cleverfarias@unisantos.edu.br , Industry Liaison Chair, Jorge Silva, jorge.silva@cenpra.gov.br , Publication Chair, Marcos Rodrigues, marcos.rodrigues@cenpra.gov.br , Posters Chair Luiz Camolesi, lcamole@unimep.br Publicity Chair Ronaldo Lemos, ronaldo.lemos@cenpra.gov.br Local Arrangements Chair Marta Rosatelli, rosatelli@unisantos.edu.br Hermes Senger, senger@unisantos.edu.br Research Colloqium Co-Chairs, FabrĚcio Silva, fabricio@unisantos.edu.br, Frederico de Freitas fred@unisantos.br Conference Secretary, Monica Berton,Ý monica.berton@cenpra.gov.br International Program Committee ******************************* J. M. Ad·n Coello, Unisantos, Brazil C. Ary Mendez, Univ. Punta Arenas, Chile D. Avison, Essec Bus. School, France M. Bichler, Univ. of Econ., Vienna, Austria L. M. Camarinha-Matos, Univ. Nova, Portugal W. Cellary, Univ. of Econ., Poznan, Polland N. Cerpa, Univ. of Talca, Chile Y. F. Chen, ATT, USA J. Cooper, UTP, Australia R. Debreceny, Nanyang Bus.School, Singapore A. Economides, Univ. of Macedonia, Greece M. Funabashi, Hitachi, Japan B. C.Glasson, Univ.of Notre Dame, Australia W. Golden, National Univ. Of Irland, Irland R. Grimm, TU Ilmenau, Germany F. Kamoun, ENSI, Tunis, Tunisia D. Khakhar, Lund University, Sweden C. Kirner, UNIMEP, Brazil A. Iyengar, Watson-IBM, USA W. Lamersdorf, Univ. of Hamburg, Germany R. Lee, Erasmus Uni., Rotterdam, Netherlands C. Linnhoff-Popien, Univ. of Munich, Germany T. Magedanz, IKV++, Berlin, Germany W. Meira, UFMG, Belo Horizonte, Brazil J. Miettinen, Finland A. Molina, Univ. of Edinburgh, UK J. Monteiro, Univ. Minho, Portugal V. Ouzounis, CEC-EU C. Passos, Cenpra, Brazil (Programm Co-Chair) H. Pohl, Univ. Appl. Sciences, Bonn, Germany R. Rabelo, UFSc, Florianopolis, Brazil K. Rannenberg, Goethe Univ, Germany B. Roberts, Kingston University, UK H. Rudin, Switzerland B. Schmidt, UNISG, Switzerland D. Schwabe, PUC-Rio, Brazil M. Singh, RMIT University, Australia J. Soto Mejia, Univ. Pereira, Colombia K. Stanoevska, Univ. St. Gallen, Switzerland C. Steinfield, Michigan State Univ., USA L. A.M. Strous, IFIP, Netherlands R. Suomi, Turku School of Econ., Finland P. Swatman, Univ. Koblenz, Germany S. Teufel, Freifourg University, Switzerland R. Traunmueller, UNI Linz, Austria A. Tsalgatidou, Univ. of Athens, Greece V. Tschammer, FhG FOKUS, Germany V. K. Tuunainen, Helsinki Sch. Econ., Finland M. Waidner, IBM, Z¸rich, Switerland H. Weigand, Univ. Tilburg, Netherlands H. Werthner, University of Trento, Italy J. Wielki, Poland H. D. Zimmermann, U. St. Gallen, Switzerland Y. Zhang, Univ. of South. Queensland, Australia IFIP STEERING COMMITTEE *********************** K. Bauknecht, CH B.C. Glasson, AUS D. Khakhar, S J. Miettinen, FIN J. Monteiro, PT H. Rudin, CH S. Teufel, CH V. Tschammer, D ************************** ORGANIZERS AND SUPPORTERS ************************** Organizers ---------- * CenPRA, Centro de Pesquisas Renato Archer, MinistČrio de CiÍncia e Tecnologia, Campinas (main organizer) * Unisantos, Universidade CatŰlica de Santos, Santos Supporters ---------- * IFIP, International Federation for Information Processing hosted by the three technical committees TC6, TC8, and TC11 (main supporter) * State Government of S.Paulo * SBC, Sociedade Brasileira de ComputaÁ“o * SBA, Sociedade Brasileira de Autom·tica ##################################### I3E2003 C A L L F O R P A P E R S ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3rd IFIP International Conference on e-Commerce, e-Business and e-Government(I3E 2003) Sponsored by IFIP, international Federation for Information Processing September 21-24, 2003 Casa Grande Hotel, S“o Paulo, Guaruj·, BRAZIL ************************************************* Homepage http://www.cenpra.gov.br/I3E_conference ************************************************* + + + + + + + + + + + + + + + + + + + + + + ++ + Next important Dates!! + + ---------------------- + + Workshop Proposals due: 28th February 2003 + + Papers Deadline (extended):April 21st2003 + + Tutorial proposals due: 30th April 2003 + ++++++++++++++++++++++++++++++++++++++++++++++ This conference is the third IFIP conference on e-commerce, e-business, and e-government sponsored by the three committees TC6, TC8, and TC11. It provides a forum for users, engineers, and scientists in academia, industry, and government to present their latest findings in e-commerce, e-business, or e-government applications and the underlying technology to support those applications. Areas of particular interest include but are not limited to: eCommerce * Marketplaces, Portals, eHubs * B2B and ÝB2C models * Procurement, negotiations and dynamic pricing models (bidding, auctions) * Content management, ePayment systems * Agent-mediated electronic commerce * Case studies in electronic commerce * Consumer protection in electronic commerce * Costs and benefit aspects * Digital goods and products * Electronic commerce application fields eBusiness * Enterprise Portals * Innovative business models * Supply, Demand and Value chains * Business Process Re-engineering * Interorganizational systems, virtual organizations, and virtual markets * eCommunities * Workflow management and Collaboration * Management of dynamic collaborative networks * Complex adaptive and selforganising systems * Distributed work and knowledge flows in business networks * Business data exchange format and standards eGovernment * Digital cities, Digital regions, Rural networking * eGovernance and eInclusion, * Electronic Public Services for Citizens and enterprises:One-stop Government, Single-Window-Service, Seamless Government * E-Local administration * G2G, G2B, G2C and G2E models * Government Process Reengineering and redesigning cooperation within and between agencies * Frameworks and guidelines for e-Government * Transnational e-Government projects and standards * International and regional projects, case studies and international comparisons * Strategies, implementation policies and best practices Related Technical aspects * Technologies for interoperability and aplication integration * Information & communication OPEN platforms * User Mobility * Unified messaging * Agent and Grid technologies * Information retrieval and extraction and data mining * Knowledge Management * Security, privacy, Trustability * Smart Cards and biometrics * Digital signatures and Certificates * Standards for information interchange and processes, interoperability and semantic standardisation * Web Technologies: - Emerging Standards for Web Data (XML, XSL, RDF etc) - Semantic Web, Ontologies - Web data models and metadata - Knowledge discovery of Web data - Web data mining and analysis * E-(WEB) services - E-service location, selection, brokering - E-service composition, invocation and delivery - E-service monitoring, personalization, management and life cycle - XML-based protocols and description language - Service-based architectures and their underlying technology - Service-oriented application development - Standards for e-services Legal, social, cross-cultural issues * socio-economic research in the governance of networked organisations * e-government models and legal issues. * e-Inclusion * e-Democracy strategies, citizen participation in local public affairs * e-Governance tools for policymaking in governments and in policy networks * New organisational arrangements: ad-hoc co-operation and coalition between public agencies and public-private-partnerships * Institutional change and IT-driven modernisation of public governance structures * Intellectual property licensing * Reputation and trust mechanisms and issues MAIN TRACK, WORKSHOPS AND TUTORIALS *********************************** The conference will comprise several tracks with papers in the topics above and several workshops and tutorials dedicated to special topics. INFORMATION FOR AUTHORS *********************** Paper submissions should describe original work (not submitted or published elsewhere) and be 20 double-spaced pages in length. Submissions should include title, authors and a 150-word abstract as a front page, identify the author responsible for correspondence, incl. the authors name, mailing address, telephone and fax numbers, and e-mail address. The core paper should include the title only and no info about the authors. One of the authors of each paper must register and present the paper at the conference. The proceedings of the conference will be published by Kluwer Academic Publishers. Best papers are selected by the best paper award committee. Authors are requested to submit their manuscripts electronically as a Microsoft Word document, PDF, or in Postscript format. INFORMATION FOR WORKSHOPS AND TUTORIALS *************************************** Proposals for workshops should describe the title, scope and organizational structure. Workshop chairs are responsible for both organizing the review process and promotion of their workshop. Tutorial proposals should include the tutorial title, the names and a brief biography for each presenter (approximately half page) and a summary of the tutorial contents (approximately 1-2 pages . Proposals should be send electronically as Word or PDF files following the link at the conference homepage. INFORMATION FOR THE RESEARCH COLLOQUIUM AND POSTERS *************************************************** Research Colloquium offers PhD and Master students in themes related to I3E the opportunity to present and discuss their work with each other as well as a number of experienced international researchers. Students from all the I3E related disciplines are encouraged to apply, although numbers will be limited. Submissions should outline current research in progress and be no longer than 3 pages in length. An abstract and biographical note should be included. Poster submissions graphically illustrating original contributions on eCommerce, eBusiness and eGovernment are invited. Successful posters will be on show for the duration of the conference. Submissions should be comprised of a 2 page description of the theory, method, or technology the poster will illustrate. Final descriptions of posters will be included in the Conference Supplement. ******************** IMPORTANT DEADLINES ******************** Papers ------ Deadline: March 28th , 2003, Notification of acceptance: May 2nd , 2003, Camera-ready papers:June 13th , 2003 Workshops --------- Deadline: 28th February 2003 Notification of acceptance: 28th March 2003, Camera-ready Material due: 31th July 2003 Tutorials --------- Deadline: 30th April 2003, Notification of acceptance:30th May 2003, Camera-ready material due: 31th July 2003 Posters ------- Deadline: 30th May 2003, Notification of acceptance: 27th June 2003, Camera-ready copy due: 31th July 2003 Research Colloquium ------------------- Deadline: 30th May 2003, Notification of acceptance: 27th Juni 2003, Camera-ready copy due: 31th July 2003 GENERAL INFORMATION ******************* Conference site for more information: http://www.cenpra.gov.br/I3E-conference ********* COMMITTEE ********* Honorary Chairs --------------- Prof. Dr. Radu Popescu Zeletin, FOKUS, De Dr. Arnaldo Madeira, State Government of S“o Paulo General Chair M. Mendes, mjmendes@bestway.com.br Programm Co-Chairs Reima Suomi, Reima.suomi@tukkk.fi Carlos Passos, carlos.passos@cenpra.gov.br Organizing Committee ******************** Organizing Co-Chairs Romildo Monte, romildo.monte@cenpra.gov.br Roberto Agune, ragune@sp.gov.br Workshops Chair, Clenio Figueiredo, clenio.salviano@cenpra.gov.br , Government Liaison Chairs, Agnaldo Lopes, alopes@sp.gov.br , MaurĚcio Moraes, mauriciomoraes@sp.gov.br Treasurer Chair Jarbas Cardoso, jarbas.cardoso@cenpra.gov.br, Tutorials Chair Clever Farias, cleverfarias@unisantos.edu.br , Industry Liaison Chair, Jorge Silva, jorge.silva@cenpra.gov.br , Publication Chair, Marcos Rodrigues, marcos.rodrigues@cenpra.gov.br , Posters Chair Luiz Camolesi, lcamole@unimep.br Publicity Chair Ronaldo Lemos, ronaldo.lemos@cenpra.gov.br Local Arrangements Chair Marta Rosatelli, rosatelli@unisantos.edu.br Hermes Senger, senger@unisantos.edu.br Research Colloqium Co-Chairs, FabrĚcio Silva, fabricio@unisantos.edu.br, Frederico de Freitas fred@unisantos.br Conference Secretary, Monica Berton,Ý monica.berton@cenpra.gov.br International Program Committee ******************************* J. M. Ad·n Coello, Unisantos, Brazil C. Ary Mendez, Univ. Punta Arenas, Chile D. Avison, Essec Bus. School, France M. Bichler, Univ. of Econ., Vienna, Austria L. M. Camarinha-Matos, Univ. Nova, Portugal W. Cellary, Univ. of Econ., Poznan, Polland N. Cerpa, Univ. of Talca, Chile Y. F. Chen, ATT, USA J. Cooper, UTP, Australia R. Debreceny, Nanyang Bus.School, Singapore A. Economides, Univ. of Macedonia, Greece M. Funabashi, Hitachi, Japan B. C.Glasson, Univ.of Notre Dame, Australia W. Golden, National Univ. Of Irland, Irland R. Grimm, TU Ilmenau, Germany F. Kamoun, ENSI, Tunis, Tunisia C. Kirner, UNIMEP, Brazil A. Iyengar, Watson-IBM, USA W. Lamersdorf, Univ. of Hamburg, Germany R. Lee, Erasmus Uni., Rotterdam, Netherlands C. Linnhoff-Popien, Univ. of Munich, Germany T. Magedanz, IKV++, Berlin, Germany W. Meira, UFMG, Belo Horizonte, Brazil J. Miettinen, Finland A. Molina, Univ. of Edinburgh, UK J. Monteiro, Univ. Minho, Portugal V. Ouzounis, CEC-EU C. Passos, Cenpra, Brazil (Programm Co-Chair) H. Pohl, Univ. Appl. Sciences, Bonn, Germany R. Rabelo, UFSc, Florianopolis, Brazil K. Rannenberg, Goethe Univ, Germany B. Roberts, Kingston University, UK H. Rudin, Switzerland B. Schmidt, UNISG, Switzerland D. Schwabe, PUC-Rio, Brazil M. Singh, RMIT University, Australia J. Soto Mejia, Univ. Pereira, Colombia K. Stanoevska, Univ. St. Gallen, Switzerland C. Steinfield, Michigan State Univ., USA L. A.M. Strous, IFIP, Netherlands R. Suomi, Turku School of Econ., Finland P. Swatman, Univ. Koblenz, Germany S. Teufel, Freifourg University, Switzerland R. Traunmueller, UNI Linz, Austria A. Tsalgatidou, Univ. of Athens, Greece V. Tschammer, FhG FOKUS, Germany V. K. Tuunainen, Helsinki Sch. Econ., Finland M. Waidner, IBM, Z¸rich, Switerland H. Weigand, Univ. Tilburg, Netherlands H. Werthner, University of Trento, Italy J. Wielki, Poland H. D. Zimmermann, U. St. Gallen, Switzerland Y. Zhang, Univ. of South. Queensland, Australia IFIP STEERING COMMITTEE *********************** K. Bauknecht, CH B.C. Glasson, AUS D. Khakhar, S J. Miettinen, FIN J. Monteiro, PT H. Rudin, CH S. Teufel, CH V. Tschammer, D ************************** ORGANIZERS AND SUPPORTERS ************************** Organizers ---------- * CenPRA, Centro de Pesquisas Renato Archer, MinistČrio de CiÍncia e Tecnologia, Campinas (main organizer) * Unisantos, Universidade CatŰlica de Santos, Santos Supporters ---------- * IFIP, International Federation for Information Processing hosted by the three technical committees TC6, TC8, and TC11 (main supporter) * State Government of S.Paulo * SBC, Sociedade Brasileira de ComputaÁ“o * SBA, Sociedade Brasileira de Autom·tica ______________________________________ Prof. Dr. Manuel de Jesus Mendes Home Phone: +55-19-32874003 Mobile Phone: +55-19-9604 5003 Mail Address: mjmendes@unimep.br mjmendes@bestway.com.br _______________________________________ From owner-snmpv3@lists.tislabs.com Tue Apr 15 15:28:44 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 PAA08948 for ; Tue, 15 Apr 2003 15:28:43 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA26941 Tue, 15 Apr 2003 14:23:22 -0400 (EDT) Message-ID: <0A11633F61BD9F40B43ABCC694004F93C8D086@zsc3c026.us.nortel.com> From: "David Levi" To: "Snmpv3@Lists.Tislabs.Com (E-mail)" Subject: coex doc update Date: Tue, 15 Apr 2003 08:54:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C30366.A184593E" Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk 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_000_01C30366.A184593E Content-Type: text/plain; charset="ISO-8859-1" Hi All, Attached is an updated coex document, this incorporates the latest comments from Mike and Bert. Note that I didn't bump up the version number and related comments, I just updated the text (since we are not publishing a new ID at the moment). -Dave ------_=_NextPart_000_01C30366.A184593E Content-Type: text/plain; name="coex.txt" Content-Disposition: attachment; filename="coex.txt" Content-Transfer-Encoding: quoted-printable Internet Draft Coexistence between SNMP versions 15 Apr = 2003 INTERNET-DRAFT Rob = Frye Vibrant = Solutions David B. = Levi Nortel = Networks Shawn A. = Routhier Integrated Systems = Inc. Bert = Wijnen Lucent = Technologies 15 Apr = 2003 Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. SNMPv3 Working Group Expires August 2003 [Page 1] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 Abstract 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. SNMPv3 Working Group Expires August 2003 [Page 2] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 Table Of Contents SNMPv3 Working Group Expires August 2003 [Page 3] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 Table Of Contents SNMPv3 Working Group Expires August 2003 [Page 4] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 1. Overview The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, termed the SNMP version 3 framework (SNMPv3), version 2 of the Internet-standard Network Management Framework, termed the SNMP version 2 framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in = this document are to be interpreted as described in RFC 2119 [RFC2119]. There are four general aspects of coexistence described in this document. Each of these is described in a separate section: - Conversion of MIB documents between SMIv1 and SMIv2 formats = is documented in section 2. - Mapping of notification parameters is documented in section = 3. - Approaches to coexistence between entities which support the various versions of SNMP in a multi-lingual network is documented in section 4. This section addresses the processing of protocol operations in multi-lingual implementations, as well as behaviour of proxy implementations. - The SNMPv1 Message Processing Model and Community-Based Security Model, which provides mechanisms for adapting SNMPv1 into the View-Based Access Control Model (VACM) [20], is documented in section 5 (this section also addresses the SNMPv2c Message Processing Model and Community-Based Security Model). 1.1. SNMPv1 SNMPv1 is defined by these documents: - STD 15, RFC 1157 [RFC1157] which defines the Simple Network Management Protocol (SNMPv1), the protocol used for network access to managed objects. - STD 16, RFC 1155 [RFC1155] which defines the Structure of Management Information (SMIv1), the mechanisms used for SNMPv3 Working Group Expires August 2003 [Page 5] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 describing and naming objects for the purpose of management. - STD 16, RFC 1212 [RFC1212] which defines a more concise description mechanism, which is wholly consistent with the SMIv1. - RFC 1215 [RFC1215] which defines a convention for defining Traps for use with the SMIv1. Note that throughout this document, the term 'SMIv1' is used. This term generally refers to the information presented in RFC 1155, RFC 1212, and RFC 1215. 1.2. SNMPv2 SNMPv2 is defined by these documents: - STD 58, RFC 2578 which defines Version 2 of the Structure of Management Information (SMIv2) [RFC2578]. - STD 58, RFC 2579 which defines common MIB "Textual Conventions" [RFC2579]. - STD 58, RFC 2580 which defines Conformance Statements and requirements for defining agent and manager capabilities [RFC2580]. - STD 62, RFC 3416 which defines the Protocol Operations used = in processing [RFC3416]. - STD 62, RFC 3417 which defines the Transport Mappings used = "on the wire" [RFC3417]. - STD 62, RFC 3418 which defines the basic Management Information Base for monitoring and controlling some basic common functions of SNMP entities [RFC3418]. Note that SMIv2 as used throughout this document refers to the first three documents listed above (RFCs 2578, 2579, and 2580). The following document augments the definition of SNMPv2: - RFC 1901 [RFC1901] is an Experimental definition for using SNMPv2 PDUs within a community-based message wrapper. This = is referred to throughout this document as SNMPv2c. SNMPv3 Working Group Expires August 2003 [Page 6] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 1.3. SNMPv3 SNMPv3 is defined by these documents: - STD 62, RFC 3411 which defines an Architecture for Describing SNMP Management Frameworks [RFC3411]. - STD 62, RFC 3412 which defines Message Processing and Dispatching [RFC3412]. - STD 62, RFC 3413 which defines various SNMP Applications [RFC3413]. - STD 62, RFC 3414 which defines the User-based Security Model (USM), providing for both Authenticated and Private (encrypted) SNMP messages [RFC3414]. - STD 62, RFC 3415 which defines the View-based Access Control Model (VACM), providing the ability to limit access to different MIB objects on a per-user basis [RFC3415]. SNMPv3 also uses the SNMPv2 definitions of RFCs 3416 through 3418 = and the SMIv2 definitions of 2578 through 2580 described above. Note that text throughout this document that refers to SNMPv2 PDU types and protocol operations applies to both SNMPv2c and SNMPv3. SNMPv3 Working Group Expires August 2003 [Page 7] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 2. SMI and Management Information Mappings The SMIv2 approach towards describing collections of managed objects is nearly a proper superset of the approach defined in the SMIv1. For example, both approaches use an adapted subset of ASN.1 [ASN1] = as the basis for a formal descriptive notation. Indeed, one might note that the SMIv2 approach largely codifies the existing practice for defining MIB modules, based on extensive experience with the SMIv1. The following sections consider the three areas: MIB modules, compliance statements, and capabilities statements. 2.1. MIB Modules MIB modules defined using the SMIv1 may continue to be used with protocol versions which use SNMPv2 PDUs. However, for SMIv1 MIB modules to conform to the SMIv2, the following changes SHALL be = made: 2.1.1. Object Definitions In general, conversion of a MIB module does not require the deprecation of the objects contained therein. If the definition of an object is truly inadequate for its intended purpose, the object SHALL be deprecated or obsoleted, otherwise deprecation is not required. (1) The IMPORTS statement MUST reference SNMPv2-SMI, instead of RFC1155-SMI and RFC-1212. (2) The MODULE-IDENTITY macro MUST be invoked immediately after any IMPORTs statement. (3) For any object with a SYNTAX clause value of Counter, the object MUST have the value of its SYNTAX clause changed to Counter32. (4) For any object with a SYNTAX clause value of Gauge, the object = MUST have the value of its SYNTAX clause changed to Gauge32, or Unsigned32 where appropriate. (5) For all objects, the ACCESS clause MUST be replaced by a = MAX-ACCESS clause. The value of the MAX-ACCESS clause SHALL be the same as that of the ACCESS clause unless some other value makes "protocol sense" as the maximal level of access for the object. In particular, object types for which instances can be explicitly created by a protocol set operation, SHALL have a MAX-ACCESS = clause SNMPv3 Working Group Expires August 2003 [Page 8] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 of "read-create". If the value of the ACCESS clause is "write- only", then the value of the MAX-ACCESS clause MUST be "read- write", and the DESCRIPTION clause SHALL note that reading this object will result in implementation-specific results. Note that in SMIv1, the ACCESS clause specifies the minimal required access, while in SMIv2, the MAX-ACCESS clause specifies the maximum = allowed access. This should be considered when converting an ACCESS = clause to a MAX-ACCESS clause. (6) For all objects, if the value of the STATUS clause is "mandatory" or "optional", the value MUST be replaced with "current", "deprecated", or "obsolete" depending on the current usage of such objects. (7) For any object not containing a DESCRIPTION clause, the object = MUST have a DESCRIPTION clause defined. (8) For any object corresponding to a conceptual row which does not have an INDEX clause, the object MUST have either an INDEX clause or an AUGMENTS clause defined. (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. The = 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. (10) For any object with a SYNTAX of NetworkAddress, the SYNTAX MUST be changed to IpAddress. Note that the use of NetworkAddress in new MIB documents is strongly discouraged (in fact, new MIB documents should be written using SMIv2, which does not define NetworkAddress). (11) For any object containing a DEFVAL clause with an OBJECT = IDENTIFIER value which is expressed as a collection of sub-identifiers, the value MUST be changed to reference a single ASN.1 identifier. = This may require defining a series of new administrative assignments (OBJECT IDENTIFIERS) in order to define the single ASN.1 identifier. (12) One or more OBJECT-GROUPS MUST be defined, and related objects = MUST be collected into appropriate groups. Note that SMIv2 requires = all OBJECT-TYPEs to be a member of at least one OBJECT-GROUP. SNMPv3 Working Group Expires August 2003 [Page 9] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 (13) For any non-columnar object that is instanced as if it were immediately subordinate to a conceptual row, the value of the STATUS clause of that object MUST be changed to "obsolete". (14) For any conceptual row object that is not immediately subordinate to a conceptual table, the value of the STATUS clause of that object (and all subordinate objects) MUST be changed to = "obsolete". Other changes are desirable, but not necessary: (1) Creation and deletion of conceptual rows is inconsistent using the SMIv1. The SMIv2 corrects this. As such, if the MIB module undergoes review early in its lifetime, and it contains conceptual tables which allow creation and deletion of conceptual rows, then the objects relating to those tables MAY be deprecated and = replaced with objects defined using the new approach. The approach based = on SMIv2 can be found in section 7 of RFC 2578 [RFC2578], and the RowStatus and StorageType TEXTUAL-CONVENTIONs are described in section 2 of RFC 2579 [RFC2579]. (2) For any object with an integer-valued SYNTAX clause, in which the corresponding INTEGER does not have a range restriction (i.e., the INTEGER has neither a defined set of named-number enumerations nor an assignment of lower- and upper-bounds on its value), the object SHOULD have the value of its SYNTAX clause changed to Integer32, = or have an appropriate range specified. (3) For any object with a string-valued SYNTAX clause, in which the corresponding OCTET STRING does not have a size restriction (i.e., the OCTET STRING has no assignment of lower- and upper-bounds on its length), the bounds for the size of the object SHOULD be defined. (4) All textual conventions informally defined in the MIB module = SHOULD be redefined using the TEXTUAL-CONVENTION macro. Such a change would not necessitate deprecating objects previously defined using an informal textual convention. (5) For any object which represents a measurement in some kind of units, a UNITS clause SHOULD be added to the definition of that object. (6) For any conceptual row which is an extension of another conceptual row, i.e., for which subordinate columnar objects both exist and are identified via the same semantics as the other conceptual row, an AUGMENTS clause SHOULD be used in place of the INDEX clause for the object corresponding to the conceptual row which is an SNMPv3 Working Group Expires August 2003 [Page 10] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 extension. 2.1.2. Trap and Notification Definitions If a MIB module is changed to conform to the SMIv2, then each occurrence of the TRAP-TYPE macro MUST be changed to a corresponding invocation of the NOTIFICATION-TYPE macro: (1) The IMPORTS statement MUST NOT reference RFC-1215 [RFC1215], and MUST reference SNMPv2-SMI instead. (2) The ENTERPRISE clause MUST be removed. (3) The VARIABLES clause MUST be renamed to the OBJECTS clause. (4) A STATUS clause MUST be added, with an appropriate value. = Normally the value should be 'current,' although 'deprecated' or 'obsolete' may be used as needed. (5) The value of an invocation of the NOTIFICATION-TYPE macro is an OBJECT IDENTIFIER, not an INTEGER, and MUST be changed = accordingly. Specifically, if the value of the ENTERPRISE clause is not 'snmp' then the value of the invocation SHALL be the value of the ENTERPRISE clause extended with two sub-identifiers, the first of which has the value 0, and the second has the value of the invocation of the TRAP-TYPE. If the value of the ENTERPRISE = clause is 'snmp', then the value of the invocation of the NOTIFICATION- TYPE macro SHALL be mapped in the same manner as described in section 3.1 in this document. (6) A DESCRIPTION clause MUST be added, if not already present. (7) One or more NOTIFICATION-GROUPs MUST be defined, and related notifications MUST be collected into those groups. Note that = SMIv2 requires that all NOTIFICATION-TYPEs be a member of at least one NOTIFICATION-GROUP. 2.2. Compliance Statements For those information modules which are "standards track", a corresponding invocation of the MODULE-COMPLIANCE macro and related OBJECT-GROUP and/or NOTIFICATION-GROUP macros MUST be included = within the information module (or in a companion information module), and any commentary text in the information module which relates to SNMPv3 Working Group Expires August 2003 [Page 11] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 compliance SHOULD be removed. Typically this editing can occur when the information module undergoes review. Note that a MODULE-COMPLIANCE statement is not required for a MIB document that is not on the standards track (for example, an enterprise MIB), though it may be useful in some circumstances to define a MODULE-COMPLIANCE statement for such a MIB document. 2.3. Capabilities Statements RFC 1303 [RFC1303] uses the MODULE-CONFORMANCE macro to describe an agent's capabilities with respect to one or more MIB modules. Converting such a description for use with the SMIv2 requires these changes: (1) The macro name AGENT-CAPABILITIES MUST be used instead of MODULE- CONFORMANCE. (2) The STATUS clause MUST be added, with a value of 'current'. (3) All occurrences of the CREATION-REQUIRES clause MUST either be omitted if appropriate, or be changed such that the semantics are consistent with RFC 2580 [RFC2580]. In order to ease coexistence, object groups defined in an SMIv1 compliant MIB module may be referenced by the INCLUDES clause of an invocation of the AGENT-CAPABILITIES macro: upon encountering a reference to an OBJECT IDENTIFIER subtree defined in an SMIv1 MIB module, all leaf objects which are subordinate to the subtree and have a STATUS clause value of mandatory are deemed to be INCLUDEd. (Note that this method is ambiguous when different revisions of an SMIv1 MIB have different sets of mandatory objects under the same subtree; in such cases, the only solution is to rewrite the MIB = using the SMIv2 in order to define the object groups unambiguously.) SNMPv3 Working Group Expires August 2003 [Page 12] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 3. Translating Notification Parameters This section describes how parameters used for generating notifications are translated between the format used for SNMPv1 notification protocol operations and the format used for SNMPv2 notification protocol operations. The parameters used to generate a notification are called 'notification parameters.' The format of parameters used for SNMPv1 notification protocol operations is referred to in this document as 'SNMPv1 notification parameters.' The format of parameters used for SNMPv2 notification protocol operations is referred to in this document as 'SNMPv2 notification parameters.' The situations where notification parameters MUST be translated are: - When an entity generates a set of notification parameters in = a particular format, and the configuration of the entity indicates that the notification must be sent using an SNMP message version that requires the other format for notification parameters. - When a proxy receives a notification that was sent using an SNMP message version that requires one format of notification parameters, and must forward the notification using an SNMP message version that requires the other format of = notification parameters. In addition, it MAY be desirable to translate notification = parameters in a notification receiver application in order to present notifications to the end user in a consistent format. Note that for the purposes of this section, the set of notification parameters is independent of whether the notification is to be sent as a trap or an inform. SNMPv1 notification parameters consist of: - An enterprise parameter (OBJECT IDENTIFIER). - An agent-addr parameter (NetworkAddress). - A generic-trap parameter (INTEGER). - A specific-trap parameter (INTEGER). - A time-stamp parameter (TimeTicks). SNMPv3 Working Group Expires August 2003 [Page 13] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 - A list of variable-bindings (VarBindList). SNMPv2 notification parameters consist of: - A sysUpTime parameter (TimeTicks). This appears in the first variable-binding in an SNMPv2-Trap-PDU or InformRequest-PDU. - An snmpTrapOID parameter (OBJECT IDENTIFIER). This appears = in the second variable-binding in an SNMPv2-Trap-PDU or InformRequest-PDU, and is equal to the value portion of that variable-binding (not the name portion, as both the name and value are OBJECT IDENTIFIERs). - A list of variable-bindings (VarBindList). This refers to = all but the first two variable-bindings in an SNMPv2-Trap-PDU or InformRequest-PDU. 3.1. Translating SNMPv1 Notification Parameters to SNMPv2 Notification Parameters The following procedure describes how to translate SNMPv1 notification parameters into SNMPv2 notification parameters: (1) The SNMPv2 sysUpTime parameter SHALL be taken directly from the SNMPv1 time-stamp parameter. (2) If the SNMPv1 generic-trap parameter is 'enterpriseSpecific(6)', the SNMPv2 snmpTrapOID parameter SHALL be the concatenation of the SNMPv1 enterprise parameter and two additional sub-identifiers, '0', and the SNMPv1 specific-trap parameter. SNMPv3 Working Group Expires August 2003 [Page 14] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 (3) If the SNMPv1 generic-trap parameter is not 'enterpriseSpecific(6)', the SNMPv2 snmpTrapOID parameter SHALL be the corresponding trap as defined in section 2 of RFC 3418 [RFC3418]: generic-trap parameter snmpTrapOID.0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 0 1.3.6.1.6.3.1.1.5.1 (coldStart) 1 1.3.6.1.6.3.1.1.5.2 (warmStart) 2 1.3.6.1.6.3.1.1.5.3 (linkDown) 3 1.3.6.1.6.3.1.1.5.4 (linkUp) 4 1.3.6.1.6.3.1.1.5.5 (authenticationFailure) 5 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss) (4) The SNMPv2 variable-bindings SHALL be the SNMPv1 = variable-bindings. In addition, if the translation is being performed by a proxy in order to forward a received trap, three additional variable- bindings will be appended, if these three additional variable- bindings do not already exist in the SNMPv1 variable-bindings. = The name portion of the first additional variable binding SHALL = contain snmpTrapAddress.0, and the value SHALL contain the SNMPv1 agent- addr parameter. The name portion of the second additional = variable binding SHALL contain snmpTrapCommunity.0, and the value SHALL contain the value of the community-string field from the received SNMPv1 message which contained the SNMPv1 Trap-PDU. The name portion of the third additional variable binding SHALL contain snmpTrapEnterprise.0 [RFC3418], and the value SHALL be the SNMPv1 enterprise parameter. 3.2. Translating SNMPv2 Notification Parameters to SNMPv1 Notification Parameters The following procedure describes how to translate SNMPv2 notification parameters into SNMPv1 notification parameters: (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 SNMPv3 Working Group Expires August 2003 [Page 15] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 to the value 'snmpTraps' as defined in RFC 3418 [RFC3418]. - If the SNMPv2 snmpTrapOID parameter is not one of the = standard traps as defined in RFC 3418 [RFC3418], then the SNMPv1 enterprise parameter SHALL be determined from the SNMPv2 snmpTrapOID parameter as follows: - If the next-to-last sub-identifier of the snmpTrapOID value is zero, then the SNMPv1 enterprise SHALL be the SNMPv2 snmpTrapOID value with the last 2 sub-identifiers removed, otherwise - If the next-to-last sub-identifier of the snmpTrapOID value is non-zero, then the SNMPv1 enterprise SHALL be = the SNMPv2 snmpTrapOID value with the last sub-identifier removed. (2) The SNMPv1 agent-addr parameter SHALL be determined based on the situation in which the translation occurs. - If the translation occurs within a notification originator application, and the notification is to be sent over IP, the SNMPv1 agent-addr parameter SHALL be set to the IP address of the SNMP entity in which the notification originator resides. If the notification is to be sent over some other transport, the SNMPv1 agent-addr parameter SHALL be set to 0.0.0.0. - If the translation occurs within a proxy application, the proxy must attempt to extract the original source of the notification from the variable-bindings. If the SNMPv2 variable-bindings contains a variable binding whose name is snmpTrapAddress.0, the agent-addr parameter SHALL be set to the value of that variable binding. Otherwise, the SNMPv1 agent-addr parameter SHALL be set to 0.0.0.0. (3) If the SNMPv2 snmpTrapOID parameter is one of the standard traps = as defined in RFC 3418 [RFC3418], the SNMPv1 generic-trap parameter SHALL be set as follows: snmpTrapOID.0 parameter generic-trap = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1.3.6.1.6.3.1.1.5.1 (coldStart) 0 1.3.6.1.6.3.1.1.5.2 (warmStart) 1 1.3.6.1.6.3.1.1.5.3 (linkDown) 2 1.3.6.1.6.3.1.1.5.4 (linkUp) 3 1.3.6.1.6.3.1.1.5.5 (authenticationFailure) 4 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss) 5 SNMPv3 Working Group Expires August 2003 [Page 16] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 Otherwise, the SNMPv1 generic-trap parameter SHALL be set to 6. (4) If the SNMPv2 snmpTrapOID parameter is one of the standard traps = as defined in RFC 3418 [RFC3418], the SNMPv1 specific-trap parameter SHALL be set to zero. Otherwise, the SNMPv1 specific-trap parameter SHALL be set to the last sub-identifier of the SNMPv2 snmpTrapOID parameter. (5) The SNMPv1 time-stamp parameter SHALL be taken directly from the SNMPv2 sysUpTime parameter. (6) The SNMPv1 variable-bindings SHALL be the SNMPv2 variable-bindings (and note that the SNMPv2 variable-bindings do not include the variable-bindings containing sysUpTime.0, snmpTrapOID.0). Note, however, that if the SNMPv2 variable-bindings contain any objects whose type is Counter64, the translation to SNMPv1 notification parameters cannot be performed. In this case, the notification cannot be encoded in an SNMPv1 packet (and so the notification cannot be sent using SNMPv1, see section 4.2.3 and section 4.3). SNMPv3 Working Group Expires August 2003 [Page 17] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 4. Approaches to Coexistence in a Multi-lingual Network There are two basic approaches to coexistence in a multi-lingual network, multi-lingual implementations and proxy implementations. Multi-lingual implementations allow elements in a network to communicate with each other using an SNMP version which both = elements support. This allows a multi-lingual implementation to communicate with any mono-lingual implementation, regardless of the SNMP version supported by the mono-lingual implementation. Proxy implementations provide a mechanism for translating between SNMP versions using a third party network element. This allows network elements which support only a single, but different, SNMP version to communicate with each other. Proxy implementations are also useful for securing communications over an insecure link = between two locally secure networks. 4.1. SNMPv1 and SNMPv2 Access to MIB Data Throughout section 4., this document refers to 'SNMPv1 Access to MIB Data' and 'SNMPv2 Access to MIB Data'. These terms refer to the = part of an SNMP agent which actually accesses instances of MIB objects, and which actually initiates generation of notifications. Differences between the two types of access to MIB data are: - Error-status values generated. - Generation of exception codes. - Use of the Counter64 data type. - The format of parameters provided when a notification is generated. SNMPv1 access to MIB data may generate SNMPv1 error-status values, will never generate exception codes nor use the Counter64 data type, and will provide SNMPv1 format parameters for generating notifications. Note also that SNMPv1 access to MIB data will actually never generate a readOnly error (a noSuchName error would always occur in the situation where one would expect a readOnly error). SNMPv2 access to MIB data may generate SNMPv2 error-status values, may generate exception codes, may use the Counter64 data type, and will provide SNMPv2 format parameters for generating notifications. Note that SNMPv2 access to MIB data will never generate readOnly, SNMPv3 Working Group Expires August 2003 [Page 18] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 noSuchName, or badValue errors. Note that a particular multi-lingual implementation may choose to implement all access to MIB data as SNMPv2 access to MIB data, and perform the translations described herein for SNMPv1-based transactions. Further, note that there is no mention of 'SNMPv3 access to MIB = data' in this document, as SNMPv3 uses SNMPv2 PDU types and protocol operations. 4.2. Multi-lingual implementations This approach requires an entity to support multiple SNMP message versions. Typically this means supporting SNMPv1, SNMPv2c, and SNMPv3 message versions. The behaviour of various types of SNMP applications which support multiple message versions is described in the following sections. This approach allows entities which support multiple SNMP message versions to coexist with and communicate with entities which support only a single SNMP message version. 4.2.1. Command Generator A command generator must select an appropriate message version when sending requests to another entity. One way to achieve this is to consult a local database to select the appropriate message version. In addition, a command generator MUST 'downgrade' GetBulk requests = to GetNext requests when selecting SNMPv1 as the message version for an outgoing request. This is done by simply changing the operation = type to GetNext, ignoring any non-repeaters and max-repetitions values, and setting error-status and error-index to zero. 4.2.2. Command Responder A command responder must be able to deal with both SNMPv1 and SNMPv2 access to MIB data. There are three aspects to dealing with this. = A command responder must: - Deal correctly with SNMPv2 access to MIB data that returns a Counter64 value while processing an SNMPv1 message, SNMPv3 Working Group Expires August 2003 [Page 19] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 - Deal correctly with SNMPv2 access to MIB data that returns = one of the three exception values while processing an SNMPv1 message, and - Map SNMPv2 error codes returned from SNMPv2 access to MIB = data into SNMPv1 error codes when processing an SNMPv1 message. Note that SNMPv1 error codes SHOULD NOT be used without any change when processing SNMPv2c or SNMPv3 messages, except in the case of proxy forwarding. Also, SNMPv1 access to MIB data SHOULD NOT be = used when processing SNMPv2c or SNMPv3 messages. In the case of proxy forwarding, for backwards compatibility, SNMPv1 error codes may be used without any change in a forwarded SNMPv2c or SNMPv3 message. 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.2.2.1. Handling Counter64 The SMIv2 [RFC2578] defines one new syntax that is incompatible with SMIv1. This syntax is Counter64. All other syntaxes defined by SMIv2 are compatible with SMIv1. The impact on multi-lingual command responders is that they MUST NOT ever return a variable binding containing a Counter64 value in a response to a request that was received using the SNMPv1 message version. Multi-lingual command responders SHALL take the approach that object instances whose type is Counter64 are implicitly excluded from view when processing an SNMPv1 message. So: - On receipt of an SNMPv1 GetRequest-PDU containing a variable binding whose name field points to an object instance of type Counter64, a GetResponsePDU SHALL be returned, with an error- status of noSuchName and the error-index set to the variable binding that caused this error. - On an SNMPv1 GetNextRequest-PDU, any object instance which contains a syntax of Counter64 SHALL be skipped, and the next accessible object instance that does not have the syntax of Counter64 SHALL be retrieved. If no such object instance exists, then an error-status of noSuchName SHALL be returned, and the error-index SHALL be set to the variable binding that SNMPv3 Working Group Expires August 2003 [Page 20] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 caused this error. - Any SNMPv1 request which contains a variable binding with a Counter64 value is ill-formed, so the foregoing rules do not apply. If that error is detected, a response SHALL NOT be returned, since it would contain a copy of the ill-formed variable binding. Instead, the offending PDU SHALL be discarded and the counter snmpInASNParseErrs SHALL be incremented. 4.2.2.2. Mapping SNMPv2 Exceptions SNMPv2 provides a feature called exceptions, which allow an SNMPv2 Response PDU to return as much management information as possible, even when an error occurs. However, SNMPv1 does not support exceptions, and so an SNMPv1 Response PDU cannot return any management information, and can only return an error-status and an error-index value. When an SNMPv1 request is received, a command responder MUST check any variable bindings returned using SNMPv2 access to MIB data for exception values, and convert these exception values into SNMPv1 error codes. The type of exception that can be returned when accessing MIB data and the action taken depends on the type of SNMP request. - For a GetRequest, a noSuchObject or noSuchInstance exception may be returned. - For a GetNextRequest, an endOfMibView exception may be returned. - No exceptions will be returned for a SetRequest, and a GetBulkRequest should only be received in an SNMPv2c or = SNMPv3 message, so these request types may be ignored when mapping exceptions. Note that when a response contains multiple exceptions, it is an implementation choice as to which variable binding the error-index should reference. SNMPv3 Working Group Expires August 2003 [Page 21] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 4.2.2.2.1. Mapping noSuchObject and noSuchInstance A noSuchObject or noSuchInstance exception generated by an SNMPv2 access to MIB data indicates that the requested object instance can not be returned. The SNMPv1 error code for this condition is noSuchName, and so the error-status field of the response PDU SHALL be set to noSuchName. Also, the error-index field SHALL be set to the index of the variable binding for which an exception occurred = (if there is more than one then it is an implementation decision as to which is used), and the variable binding list from the original request SHALL be returned with the response PDU. 4.2.2.2.2. Mapping endOfMibView When an SNMPv2 access to MIB data returns a variable binding containing an endOfMibView exception, it indicates that there are no object instances available which lexicographically follow the object in the request. In an SNMPv1 agent, this condition normally results in a noSuchName error, and so the error-status field of the response PDU SHALL be set to noSuchName. Also, the error-index field SHALL be set to the index of the variable binding for which an exception occurred (if there is more than one then it is an implementation decision as to which is used), and the variable binding list from = the original request SHALL be returned with the response PDU. 4.2.2.3. Processing An SNMPv1 GetRequest When processing an SNMPv1 GetRequest, the following procedures MUST be followed when using an SNMPv2 access to MIB data. When such an access to MIB data returns response data using SNMPv2 syntax and error-status values, then: (1) If the error-status is anything other than noError, - The error status SHALL be translated to an SNMPv1 = error-status using the table in section 4.4, "Error Status Mappings". - The error-index SHALL be set to the position (in the original request) of the variable binding that caused the = error-status. - The variable binding list of the response PDU SHALL be made exactly the same as the variable binding list that was SNMPv3 Working Group Expires August 2003 [Page 22] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 received in the original request. (2) If the error-status is noError, the variable bindings SHALL be checked for any SNMPv2 exception (noSuchObject or noSuchInstance) or an SNMPv2 syntax that is unknown to SNMPv1 (Counter64). If there are any such variable bindings, one of those variable bindings SHALL be selected (it is an implementation choice as to which is selected), and: - The error-status SHALL be set to noSuchName, - The error-index SHALL be set to the position (in the variable binding list of the original request) of the selected = variable binding, and - The variable binding list of the response PDU SHALL be = exactly the same as the variable binding list that was received in = the original request. (3) If there are no such variable bindings, then: - The error-status SHALL be set to noError, - The error-index SHALL be set to zero, and - The variable binding list of the response SHALL be composed from the data as it is returned by the access to MIB data. 4.2.2.4. Processing An SNMPv1 GetNextRequest When processing an SNMPv1 GetNextRequest, the following procedures MUST be followed when SNMPv2 access to MIB data is used as part of processing the request. There may be repetitive accesses to MIB = data to try to find the first object which lexicographically follows each of the objects in the request. This is implementation specific. These procedures are followed only for data returned when using SNMPv2 access to MIB data. Data returned using SNMPv1 access to MIB data may be treated in the normal manner for an SNMPv1 request. First, if the access to MIB data returns an error-status of anything other than noError: (1) The error status SHALL be translated to an SNMPv1 error-status using the table in section 4.4, "Error Status Mappings". SNMPv3 Working Group Expires August 2003 [Page 23] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 (2) The error-index SHALL be set to the position (in the original request) of the variable binding that caused the error-status. (3) The variable binding list of the response PDU SHALL be exactly the same as the variable binding list that was received in the = original request. Otherwise, if the access to MIB data returns an error-status of noError: (1) Any variable bindings containing an SNMPv2 syntax of Counter64 SHALL be considered to be not in view, and MIB data SHALL be accessed as many times as is required until either a value other than Counter64 is returned, or an error or endOfMibView exception occurs. (2) If there is any variable binding that contains an SNMPv2 exception endOfMibView (if there is more than one then it is an implementation decision as to which is chosen): - The error-status SHALL be set to noSuchName, - The error-index SHALL be set to the position (in the variable binding list of the original request) of the variable binding that returned such an SNMPv2 exception, and - The variable binding list of the response PDU SHALL be = exactly the same as the variable binding list that was received in = the original request. (3) If there are no such variable bindings, then: - The error-status SHALL be set to noError, - The error-index SHALL be set to zero, and - The variable binding list of the response SHALL be composed from the data as it is returned by the access to MIB data. 4.2.2.5. Processing An SNMPv1 SetRequest When processing an SNMPv1 SetRequest, the following procedures MUST be followed when using SNMPv2 access to MIB data. When such MIB access returns response data using SNMPv2 syntax and SNMPv3 Working Group Expires August 2003 [Page 24] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 error-status values, and the error-status is anything other than noError, then: - The error status SHALL be translated to an SNMPv1 = error-status using the table in section 4.4, "Error Status Mappings". - The error-index SHALL be set to the position (in the original request) of the variable binding that caused the = error-status. - The variable binding list of the response PDU SHALL be made exactly the same as the variable binding list that was received in the original request. 4.2.3. Notification Originator A notification originator must be able to translate between SNMPv1 notification parameters and SNMPv2 notification parameters in order to send a notification using a particular SNMP message version. If = a notification is generated using SNMPv1 notification parameters, and configuration information specifies that notifications be sent using SNMPv2c or SNMPv3, the notification parameters must be translated to SNMPv2 notification parameters. Likewise, if a notification is generated using SNMPv2 notification parameters, and configuration information specifies that notifications be sent using SNMPv1, the notification parameters must be translated to SNMPv1 notification parameters. In this case, if the notification cannot be translated (due to the presence of a Counter64 type), it will not be sent using SNMPv1. When a notification originator generates a notification, using parameters obtained from the SNMP-TARGET-MIB and SNMP-NOTIFICATION- MIB, if the SNMP version used to generate the notification is = SNMPv1, the PDU type used will always be a TrapPDU, regardless of whether = the value of snmpNotifyType is trap(1) or inform(2). Note also that access control and notification filtering are performed in the usual manner for notifications, regardless of the SNMP message version to be used when sending a notification. The parameters for performing access control are found in the usual manner (i.e., from inspecting the SNMP-TARGET-MIB and SNMP- NOTIFICATION-MIB). In particular, when generating an SNMPv1 Trap, = in order to perform the access check specified in [RFC3413], section 3.3, bullet (3), the notification originator may need to generate a value for snmpTrapOID.0 as described in section 3.1, bullets (2) and (3) of this document. If the SNMPv1 notification parameters being SNMPv3 Working Group Expires August 2003 [Page 25] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 used were previously translated from a set of SNMPv2 notification parameters, this value may already be known, in which case it need not be generated. 4.2.4. Notification Receiver There are no special requirements of a notification receiver. However, an implementation may find it useful to allow a higher = level application to request whether notifications should be delivered to = a higher level application using SNMPv1 notification parameter or SNMPv2 notification parameters. The notification receiver would = then translate notification parameters when required in order to present = a notification using the desired set of parameters. 4.3. Proxy Implementations A proxy implementation may be used to enable communication between entities which support different SNMP message versions. This is accomplished in a proxy forwarder application by performing translations on PDUs. These translations depend on the PDU type, = the SNMP version of the packet containing a received PDU, and the SNMP version to be used to forward a received PDU. The following = sections describe these translations. In all cases other than those = described below, the proxy SHALL forward a received PDU without change, = subject to size constraints as defined in section 5.3 (Community MIB) of = this document. Note that in the following sections, 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, regardless of the PDU type or direction. 4.3.1. Upstream Version Greater Than Downstream Version - If a GetBulkRequest-PDU is received and must be forwarded using the SNMPv1 message version, the proxy forwarder SHALL act as if the non-repeaters and max-repetitions fields were both set to 0, and SHALL set the tag of the PDU to GetNextRequest-PDU. - If a GetResponse-PDU is received whose error-status field has a value of 'tooBig', and the message will be forwarded using the SNMPv2c or SNMPv3 message version, and the original SNMPv3 Working Group Expires August 2003 [Page 26] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 request received by the proxy was not a GetBulkRequest-PDU, the proxy forwarder SHALL remove the contents of the variable-bindings field and ensure that the error-index field is set to 0 before forwarding the response. - If a GetResponse-PDU is received whose error-status field has a value of 'tooBig,' and the message will be forwarded using the SNMPv2c or SNMPv3 message version, and the original request received by the proxy was a GetBulkRequest-PDU, the proxy forwarder SHALL re-send the forwarded request (which would have been altered to be a GetNextRequest-PDU) with all but the first variable-binding removed. The proxy forwarder SHALL only re-send such a request a single time. If the resulting GetResponse-PDU also contains an error-status field with a value of 'tooBig,' then the proxy forwarder SHALL remove the contents of the variable-bindings field, and = change the error-status field to 'noError', and ensure that the error-index field is set to 0 before forwarding the response. Note that if the original request only contained a single variable-binding, the proxy may skip re-sending the request and simply remove the variable-bindings and change the error- status to 'noError.' Further note that, while it might have been possible to fit more variable bindings if the proxy only re-sent the request multiple times, and stripped only a = single variable binding from the request at a time, this is deemed too expensive. The approach described here preserves the behaviour of a GetBulkRequest as closely as possible, without incurring the cost of re-sending the request multiple times. - If a Trap-PDU is received, and will be forwarded using the SNMPv2c or SNMPv3 message version, the proxy SHALL apply the translation rules described in section 3, and SHALL forward the notification as an SNMPv2-Trap-PDU. Note that when an SNMPv1 agent generates a message containing a Trap-PDU which is subsequently forwarded by one or more proxy forwarders using SNMP versions other than SNMPv1, the community string and agent-addr fields from the original message generated by the SNMPv1 agent will be preserved through the use of the snmpTrapAddress and snmpTrapCommunity objects. 4.3.2. Upstream Version Less Than Downstream Version - If a GetResponse-PDU is received in response to a GetRequest- PDU (previously generated by the proxy) which contains SNMPv3 Working Group Expires August 2003 [Page 27] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 variable-bindings of type Counter64 or which contain an = SNMPv2 exception code, and the message would be forwarded using the SNMPv1 message version, the proxy MUST generate an alternate response PDU consisting of the request-id and variable bindings from the original SNMPv1 request, containing a noSuchName error-status value, and containing an error-index value indicating the position of the variable-binding containing the Counter64 type or exception code. - If a GetResponse-PDU is received in response to a GetNextRequest-PDU (previously generated by the proxy) which contains variable-bindings that contain an SNMPv2 exception code, and the message would be forwarded using the SNMPv1 message version, the proxy MUST generate an alternate = response PDU consisting of the request-id and variable bindings from the original SNMPv1 request, containing a noSuchName error- status value, and containing an error-index value indicating the position of the variable-binding containing the exception code. - If a GetResponse-PDU is received in response to a GetNextRequest-PDU (previously generated by the proxy) which contains variable-bindings of type Counter64, the proxy MUST re-send the entire GetNextRequest-PDU, with the following modifications. For any variable bindings in the received GetResponse which contained Counter64 types, the proxy substitutes the object names of these variable bindings for the corresponding object names in the previously-sent GetNextRequest. The proxy MUST repeat this process until no Counter64 objects are returned. Note that an implementation may attempt to optimize this process of skipping Counter64 objects. One approach to such an optimization would be to replace the last sub-identifier of the object names of varbinds containing a Counter64 type with 65535 if that sub- identifier is less than 65535, or with 4294967295 if that sub-identifier is greater than 65535. This approach should skip multiple instances of the same Counter64 object, while maintaining compatibility with some broken agent implementations (which only use 16-bit integers for sub- identifiers). Deployment Hint: The process of repeated GetNext requests used by a proxy when Counter64 types are returned can be expensive. When deploying a proxy, this can be avoided by configuring the target agents to which the proxy forwards requests in a manner such that any objects of type Counter64 are in fact not-in-view for the principal that the proxy is SNMPv3 Working Group Expires August 2003 [Page 28] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 using when communicating with these agents. However, when using such a configuration, one should be careful to use a different principal for communicating with the target agent when an incoming SNMPv2c or SNMPv3 request is received, to ensure that objects of type Counter64 are properly returned. - If a GetResponse-PDU is received which contains an SNMPv2 error-status value of wrongValue, wrongEncoding, wrongType, wrongLength, inconsistentValue, noAccess, notWritable, noCreation, inconsistentName, resourceUnavailable, commitFailed, undoFailed, or authorizationError, and the message would be forwarded using the SNMPv1 message version, the error-status value is modified using the mappings in section 4.4. - If an SNMPv2-Trap-PDU is received, and will be forwarded = using the SNMPv1 message version, the proxy SHALL apply the translation rules described in section 3, and SHALL forward the notification as a Trap-PDU. Note that if the translation fails due to the existence of a Counter64 data-type in the received SNMPv2-Trap-PDU, the trap cannot be forwarded using SNMPv1. - If an InformRequest-PDU is received, any configuration information indicating that it would be forwarded using the SNMPv1 message version SHALL be ignored. An = InformRequest-PDU can only be forwarded using the SNMPv2c or SNMPv3 message version. The InformRequest-PDU may still be forwarded if there is other configuration information indicating that it should be forwarded using SNMPv2c or SNMPv3. SNMPv3 Working Group Expires August 2003 [Page 29] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 4.4. Error Status Mappings The following tables shows the mappings of SNMPv1 error-status = values into SNMPv2 error-status values, and the mappings of SNMPv2 error- status values into SNMPv1 error-status values. SNMPv1 error-status SNMPv2 error-status = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D noError noError tooBig tooBig noSuchName noSuchName badValue badValue genErr genErr SNMPv2 error-status SNMPv1 error-status = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D noError noError tooBig tooBig genErr genErr wrongValue badValue wrongEncoding badValue wrongType badValue wrongLength badValue inconsistentValue badValue noAccess noSuchName notWritable noSuchName noCreation noSuchName inconsistentName noSuchName resourceUnavailable genErr commitFailed genErr undoFailed genErr authorizationError noSuchName Whenever the SNMPv2 error-status value of authorizationError is translated to an SNMPv1 error-status value of noSuchName, the value of snmpInBadCommunityUses MUST be incremented. SNMPv3 Working Group Expires August 2003 [Page 30] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 5. Message Processing Models and Security Models In order to adapt SNMPv1 (and SNMPv2c) into the SNMP architecture, the following Message Processing (MP) models are defined in this document: - The SNMPv1 Message Processing Model - The SNMPv1 Community-Based Security Model - The SNMPv2c Message Processing Model - The SNMPv2c Community-Based Security Model In most respects, the SNMPv1 Message Processing Model and the = SNMPv2c Message Processing Model are identical, and so these are not discussed independently in this document. Differences between the two models are described as required. Similarly, the SNMPv1 Community-Based Security Model and the SNMPv2c Community-Based Security Model are nearly identical, and so are not discussed independently. Differences between these two models are also described as required. 5.1. Mappings The SNMPv1 (and SNMPv2c) Message Processing Model and Security Model require mappings between parameters used in SNMPv1 (and SNMPv2c) messages, and the version independent parameters used in the SNMP architecture [RFC3411]. The parameters which MUST be mapped consist of the SNMPv1 (and SNMPv2c) community name, and the SNMP = securityName and contextEngineID/contextName pair. A MIB module (the SNMP- COMMUNITY-MIB) is provided in this document in order to perform = these mappings. This MIB provides mappings in both directions, that is, a community name may be mapped to a securityName, contextEngineID, and contextName, or the combination of securityName, contextEngineID, = and contextName may be mapped to a community name. 5.2. The SNMPv1 MP Model and SNMPv1 Community-based Security Model The SNMPv1 Message Processing Model handles processing of SNMPv1 messages. The processing of messages is handled generally in the same manner as described in RFC 1157 [RFC1157], with differences and clarifications as described in the following sections. The SnmpMessageProcessingModel value for SNMPv1 is 0 (the value for SNMPv3 Working Group Expires August 2003 [Page 31] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 SNMPv2c is 1). 5.2.1. Processing An Incoming Request In RFC 1157 [RFC1157], section 4.1, item (3) for an entity which receives a message, states that various parameters are passed to the 'desired authentication scheme.' The desired authentication scheme in this case is the SNMPv1 Community-Based Security Model, which = will be called using the processIncomingMsg ASI. The parameters passed = to this ASI are: - The messageProcessingModel, which will be 0 (or 1 for SNMPv2c). - The maxMessageSize, which should be the maximum size of a message that the receiving entity can generate (since there = is no such value in the received message). - The securityParameters, which consist of the community string and the message's source and destination transport domains = and addresses. - The securityModel, which will be 1 (or 2 for SNMPv2c). - The securityLevel, which will be noAuthNoPriv. - The wholeMsg and wholeMsgLength. The Community-Based Security Model will attempt to select a row in the snmpCommunityTable. This is done by performing a search through the snmpCommunityTable in lexicographic order. The first entry for which the following matching criteria are satisfied will be = selected: - The community string is equal to the snmpCommunityName value. - If the snmpCommunityTransportTag is an empty string, it is ignored for the purpose of matching. If the snmpCommunityTransportTag is not an empty string, the transportDomain and transportAddress from which the message was received must match one of the entries in the snmpTargetAddrTable selected by the snmpCommunityTransportTag value. The snmpTargetAddrTMask object is used as described = in section 5.3 when checking whether the transportDomain and transportAddress matches a entry in the snmpTargetAddrTable. SNMPv3 Working Group Expires August 2003 [Page 32] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 If no such entry can be found, an authentication failure occurs as described in RFC 1157 [RFC1157], and the snmpInBadCommunityNames counter is incremented. The parameters returned from the Community-Based Security Model are: - The securityEngineID, which will always be the local value of snmpEngineID.0. - The securityName, which will be the value of snmpCommunitySecurityName from the selected row in the snmpCommunityTable. - The scopedPDU. Note that this parameter will actually = consist of three values, the contextSnmpEngineID (which will be the value of snmpCommunityContextEngineID from the selected entry in the snmpCommunityTable), the contextName (which will be = the value of snmpCommunityContextName from the selected entry in the snmpCommunityTable), and the PDU. These must be separate values, since the first two do not actually appear in the message. - The maxSizeResponseScopedPDU, which will be derived using the minimum of the maxMessageSize above, and the value of snmpTargetAddrMMS of the selected row in the snmpTargetAddrTable. If no such entry was selected, then = this value will be derived from the maxMessageSize only. - The securityStateReference, which MUST contain the community string from the original request. The appropriate SNMP application will then be called (depending on the value of the contextEngineID and the request type in the PDU) using the processPdu ASI. The parameters passed to this ASI are: - The messageProcessingModel, which will be 0 (or 1 for SNMPv2c). - The securityModel, which will be 1 (or 2 for SNMPv2c). - The securityName, which was returned from the call to processIncomingMsg. - The securityLevel, which is noAuthNoPriv. - The contextEngineID, which was returned as part of the ScopedPDU from the call to processIncomingMsg. SNMPv3 Working Group Expires August 2003 [Page 33] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 - The contextName, which was returned as part of the ScopedPDU from the call to processIncomingMsg. - The pduVersion, which should indicate an SNMPv1 version PDU (if the message version was SNMPv2c, this would be an SNMPv2 version PDU). - The PDU, which was returned as part of the ScopedPDU from the call to processIncomingMsg. - The maxSizeResponseScopedPDU which was returned from the call to processIncomingMsg. - The stateReference which was returned from the call to processIncomingMsg. The SNMP application should process the request as described previously in this document. Note that access control is applied by an SNMPv3 command responder application as usual. The parameters as passed to the processPdu ASI will be used in calls to the isAccessAllowed ASI. 5.2.2. Generating An Outgoing Response There is no special processing required for generating an outgoing response. However, the community string used in an outgoing = response must be the same as the community string from the original request. The original community string MUST be present in the securityStateReference information of the original request. 5.2.3. Generating An Outgoing Notification In a multi-lingual SNMP entity, the parameters used for generating notifications will be obtained by examining the SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB. These parameters will be passed to the = SNMPv1 Message Processing Model using the sendPdu ASI. The SNMPv1 Message Processing Model will attempt to locate an appropriate community string in the snmpCommunityTable based on the parameters passed to the sendPdu ASI. This is done by performing a search through the snmpCommunityTable in lexicographic order. The first entry for = which the following matching criteria are satisfied will be selected: SNMPv3 Working Group Expires August 2003 [Page 34] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 - The securityName must be equal to the snmpCommunitySecurityName value. - The contextEngineID must be equal to the snmpCommunityContextEngineID value. - The contextName must be equal to the snmpCommunityContextName value. - If the snmpCommunityTransportTag is an empty string, it is ignored for the purpose of matching. If the snmpCommunityTransportTag is not an empty string, the transportDomain and transportAddress must match one of the entries in the snmpTargetAddrTable selected by the snmpCommunityTransportTag value. If no such entry can be found, the notification is not sent. Otherwise, the community string used in the outgoing notification will be the value of the snmpCommunityName column of the selected row. 5.2.4. Proxy Forwarding Of Requests In a proxy forwarding application, when a received request is to be forwarded using the SNMPv1 Message Processing Model, the parameters used for forwarding will be obtained by examining the SNMP-PROXY-MIB and the SNMP-TARGET-MIB. These parameters will be passed to the SNMPv1 Message Processing Model using the sendPdu ASI. The SNMPv1 Message Processing Model will attempt to locate an appropriate community string in the snmpCommunityTable based on the parameters passed to the sendPdu ASI. This is done by performing a search through the snmpCommunityTable in lexicographic order. The first entry for which the following matching criteria are satisfied will = be selected: - The securityName must be equal to the snmpCommunitySecurityName value. - The contextEngineID must be equal to the snmpCommunityContextEngineID value. - The contextName must be equal to the snmpCommunityContextName value. If no such entry can be found, the proxy forwarding application SNMPv3 Working Group Expires August 2003 [Page 35] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 should follow the procedure described in RFC 3413 [RFC3413], section 3.5.1.1, item (2). This procedure states that the snmpProxyDrops counter [RFC3418] is incremented, and that a Response-PDU is generated by calling the Dispatcher using the returnResponsePdu abstract service interface. 5.3. The SNMP Community MIB Module The SNMP-COMMUNITY-MIB contains objects for mapping between = community strings and version-independent SNMP message parameters. In addition, this MIB provides a mechanism for performing source = address validation on incoming requests, and for selecting community strings based on target addresses for outgoing notifications. These two features are accomplished by providing a tag in the snmpCommunityTable which selects sets of entries in the snmpTargetAddrTable [RFC3413]. In addition, the SNMP-COMMUNITY-MIB augments the snmpTargetAddrTable with a transport address mask value and a maximum message size value. These values are used only where explicitly stated. In cases where the snmpTargetAddrTable is used without mention of these augmenting values, the augmenting values should be ignored. The mask value, snmpTargetAddrTMask, allows selected entries in the snmpTargetAddrTable to specify multiple addresses (rather than just = a single address per entry). This would typically be used to specify = a subnet in an snmpTargetAddrTable rather than just a single address. The mask value is used to select which bits of a transport address must match bits of the corresponding instance of snmpTargetAddrTAddress, in order for the transport address to match = a particular entry in the snmpTargetAddrTable. The value of an instance of snmpTargetAddrTMask must always be an OCTET STRING whose length is either zero or the same as that of the corresponding instance of snmpTargetAddrTAddress. 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 its value MUST = be ignored. When checking whether a transport address matches an entry in the snmpTargetAddrTable, if the value of snmpTargetAddrTMask is a zero- SNMPv3 Working Group Expires August 2003 [Page 36] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 length OCTET STRING, the mask value is ignored, and the value of snmpTargetAddrTAddress must exactly match a transport address. Otherwise, each bit of each octet in the snmpTargetAddrTMask value corresponds to the same bit of the same octet in the snmpTargetAddrTAddress value. For bits that are set in the snmpTargetAddrTMask value (i.e., bits equal to 1), the corresponding bits in the snmpTargetAddrTAddress value must match the bits in a transport address. If all such bits match, the transport address is matched by that snmpTargetAddrTable entry. Otherwise, the transport address is not matched. The maximum message size value, snmpTargetAddrMMS, is used to determine the maximum message size acceptable to another SNMP entity when the value cannot be determined from the protocol. SNMP-COMMUNITY-MIB DEFINITIONS ::=3D BEGIN IMPORTS IpAddress, MODULE-IDENTITY, OBJECT-TYPE, Integer32, snmpModules FROM SNMPv2-SMI RowStatus, StorageType FROM SNMPv2-TC SnmpAdminString, SnmpEngineID FROM SNMP-FRAMEWORK-MIB SnmpTagValue, snmpTargetAddrEntry FROM SNMP-TARGET-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; snmpCommunityMIB MODULE-IDENTITY LAST-UPDATED "200304090000Z" -- 09 Mar 2003, midnight ORGANIZATION "SNMPv3 Working Group" CONTACT-INFO "WG-email: snmpv3@lists.tislabs.com Subscribe: majordomo@lists.tislabs.com In msg body: subscribe snmpv3 Co-Chair: Russ Mundy SPARTA, Inc Postal: 7075 Samuel Morse Drive SNMPv3 Working Group Expires August 2003 [Page 37] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 Columbia, MD 21045 USA EMail: mundy@tislabs.com Phone: +1 410-872-1515 Co-Chair: David Harrington Enterasys Networks Postal: 35 Industrial Way P. O. Box 5005 Rochester, New Hampshire 03866-5005 USA EMail: dbh@enterasys.com Phone: +1 603-337-2614 Co-editor: Rob Frye Vibrant Solutions Postal: 2711 Prosperity Ave Fairfax, Virginia 22031 USA E-mail: rfrye@vibrant-1.com Phone: +1-703-270-2000 Co-editor: David B. Levi Nortel Networks Postal: 3505 Kesterwood Drive Knoxville, Tennessee 37918 E-mail: dlevi@nortelnetworks.com Phone: +1 423 686 0432 Co-editor: Shawn A. Routhier Integrated Systems Inc. Postal: 333 North Ave 4th Floor Wakefield, Massachusetts 01880 E-mail: sar@epilogue.com Phone: +1 781 245 0804 Co-editor: Bert Wijnen Lucent Technologies Postal: Schagen 33 3461 GL Linschoten Netherlands Email: bwijnen@lucent.com Phone: +31-348-480-685 " DESCRIPTION "This MIB module defines objects to help support SNMPv3 Working Group Expires August 2003 [Page 38] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 coexistence between SNMPv1, SNMPv2c, and SNMPv3. Copyright (C) The Internet Society (2003) This version of this MIB module is part of RFC xxxx; see the RFC itself for full legal notices." -- -- RFC-editor: replace xxxx with the actual RFC -- number & remove this notice -- REVISION "200304090000Z" -- 09 Mar 2003 DESCRIPTION "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. 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 a name conflict with the SNMPv2-MIB. Updated DESCRIPTION of snmpCommunityName. Updated DESCRIPTION of snmpTrapCommunity. Added snmpCommunityMIBFullCompliance. This version published as RFC xxxx." -- -- RFC-editor: replace xxxx with the actual RFC -- number & remove this notice -- REVISION "200003060000Z" -- 6 Mar 2000 DESCRIPTION "This version published as RFC 2576." ::=3D { snmpModules 18 } -- Administrative assignments = ************************************ snmpCommunityMIBObjects OBJECT IDENTIFIER ::=3D { snmpCommunityMIB 1 } SNMPv3 Working Group Expires August 2003 [Page 39] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 snmpCommunityMIBConformance OBJECT IDENTIFIER ::=3D { snmpCommunityMIB 2 } -- -- The snmpCommunityTable contains a database of community -- strings. This table provides mappings between community -- strings, and the parameters required for View-based Access -- Control. -- snmpCommunityTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpCommunityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of community strings configured in the SNMP engine's Local Configuration Datastore (LCD)." ::=3D { snmpCommunityMIBObjects 1 } snmpCommunityEntry OBJECT-TYPE SYNTAX SnmpCommunityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular community string." INDEX { IMPLIED snmpCommunityIndex } ::=3D { snmpCommunityTable 1 } SnmpCommunityEntry ::=3D SEQUENCE { snmpCommunityIndex SnmpAdminString, snmpCommunityName OCTET STRING, snmpCommunitySecurityName SnmpAdminString, snmpCommunityContextEngineID SnmpEngineID, snmpCommunityContextName SnmpAdminString, snmpCommunityTransportTag SnmpTagValue, snmpCommunityStorageType StorageType, snmpCommunityStatus RowStatus } snmpCommunityIndex OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The unique index value of a row in this table." ::=3D { snmpCommunityEntry 1 } SNMPv3 Working Group Expires August 2003 [Page 40] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 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)." ::=3D { snmpCommunityEntry 2 } snmpCommunitySecurityName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "A human readable string representing the corresponding value of snmpCommunityName in a Security Model independent format." ::=3D { snmpCommunityEntry 3 } snmpCommunityContextEngineID OBJECT-TYPE SYNTAX SnmpEngineID MAX-ACCESS read-create STATUS current DESCRIPTION "The contextEngineID indicating the location of the context in which management information is accessed when using the community string specified by the corresponding instance of snmpCommunityName. The default value is the snmpEngineID of the entity in which this object is instantiated." ::=3D { snmpCommunityEntry 4 } snmpCommunityContextName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The context in which management information is accessed when using the community string specified by the corresponding instance of snmpCommunityName." DEFVAL { ''H } -- the empty string ::=3D { snmpCommunityEntry 5 } SNMPv3 Working Group Expires August 2003 [Page 41] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 snmpCommunityTransportTag OBJECT-TYPE SYNTAX SnmpTagValue MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies a set of transport endpoints which are used in two ways: - to specify the transport endpoints from which an SNMP entity will accept management requests, and - to specify the transport endpoints to which a notification may be sent using the community string matching the corresponding instance of snmpCommunityName. In either case, if the value of this object has zero-length, transport endpoints are not checked when either authenticating messages containing this community string, nor when generating notifications. The transports identified by this object are specified in the snmpTargetAddrTable. Entries in that table whose snmpTargetAddrTagList contains this tag value are identified. If a management request containing a community string that matches the corresponding instance of snmpCommunityName is received on a transport endpoint other than the transport endpoints identified by this object the request is deemed unauthentic. When a notification is to be sent using an entry in this table, if the destination transport endpoint of the notification does not match one of the transport endpoints selected by this object, the notification is not sent." DEFVAL { ''H } -- the empty string ::=3D { snmpCommunityEntry 6 } snmpCommunityStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row in the snmpCommunityTable. Conceptual rows having the value 'permanent' need not allow write-access to any columnar object in the row." ::=3D { snmpCommunityEntry 7 } SNMPv3 Working Group Expires August 2003 [Page 42] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 snmpCommunityStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row in the snmpCommunityTable. An entry in this table is not qualified for activation until instances of all corresponding columns have been initialized, either through default values, or through Set operations. The snmpCommunityName and snmpCommunitySecurityName objects must be explicitly = set. There is no restriction on setting columns in this table when the value of snmpCommunityStatus is active(1)." ::=3D { snmpCommunityEntry 8 } -- -- The snmpTargetAddrExtTable -- snmpTargetAddrExtTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpTargetAddrExtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of mask and maximum message size (mms) values associated with the snmpTargetAddrTable. The snmpTargetAddrExtTable augments the snmpTargetAddrTable with a transport address mask value and a maximum message size value. The transport address mask allows entries in the snmpTargetAddrTable to define a set of addresses instead of just a single address. The maximum message size value allows the maximum message size of another SNMP entity to be configured for use in SNMPv1 (and SNMPv2c) transactions, where the message format does not specify a maximum message size." ::=3D { snmpCommunityMIBObjects 2 } snmpTargetAddrExtEntry OBJECT-TYPE SYNTAX SnmpTargetAddrExtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular mask and mms value." SNMPv3 Working Group Expires August 2003 [Page 43] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 AUGMENTS { snmpTargetAddrEntry } ::=3D { snmpTargetAddrExtTable 1 } SnmpTargetAddrExtEntry ::=3D SEQUENCE { snmpTargetAddrTMask OCTET STRING, snmpTargetAddrMMS Integer32 } snmpTargetAddrTMask OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-create STATUS current DESCRIPTION "The mask value associated with an entry in the snmpTargetAddrTable. The value of this object must have the same length as the corresponding instance of snmpTargetAddrTAddress, or must have length 0. An attempt to set it to any other value will result in an inconsistentValue error. The value of this object allows an entry in the snmpTargetAddrTable to specify multiple addresses. The mask value is used to select which bits of a transport address must match bits of the corresponding instance of snmpTargetAddrTAddress, in order for the transport address to match a particular entry in the snmpTargetAddrTable. Bits which are 1 in the mask value indicate bits in the transport address which must match bits in the snmpTargetAddrTAddress value. Bits which are 0 in the mask indicate bits in the transport address which need not match. If the length of the mask is 0, the mask should be treated as if all its bits were 1 and its length were equal to the length of the corresponding value of snmpTargetAddrTable. This object may not be modified while the value of the corresponding instance of snmpTargetAddrRowStatus is active(1). An attempt to set this object in this case will result in an inconsistentValue error." DEFVAL { ''H } ::=3D { snmpTargetAddrExtEntry 1 } snmpTargetAddrMMS OBJECT-TYPE SYNTAX Integer32 (0|484..2147483647) MAX-ACCESS read-create STATUS current SNMPv3 Working Group Expires August 2003 [Page 44] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 DESCRIPTION "The maximum message size value associated with an entry in the snmpTargetAddrTable. Note that a value of 0 = means that the maximum message size is unknown." DEFVAL { 484 } ::=3D { snmpTargetAddrExtEntry 2 } -- -- The snmpTrapAddress and snmpTrapCommunity objects are included -- in notifications that are forwarded by a proxy, which were -- originally received as SNMPv1 Trap messages. -- snmpTrapAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The value of the agent-addr field of a Trap PDU which is forwarded by a proxy forwarder application using an SNMP version other than SNMPv1. The value of this object SHOULD contain the value of the agent-addr field from the original Trap PDU as generated by an SNMPv1 agent." ::=3D { snmpCommunityMIBObjects 3 } snmpTrapCommunity OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The value of the community string field of an SNMPv1 message containing a Trap PDU which is forwarded by a a proxy forwarder application using an SNMP version other than SNMPv1. The value of this object SHOULD contain the value of the community string field from the original SNMPv1 message containing a Trap PDU as generated by an SNMPv1 agent. 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)." ::=3D { snmpCommunityMIBObjects 4 } -- Conformance Information ************************************** snmpCommunityMIBCompliances OBJECT IDENTIFIER SNMPv3 Working Group Expires August 2003 [Page 45] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 ::=3D { snmpCommunityMIBConformance 1 = } snmpCommunityMIBGroups OBJECT IDENTIFIER ::=3D { snmpCommunityMIBConformance 2 = } -- Compliance statements snmpCommunityMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP engines which implement the SNMP-COMMUNITY-MIB." MODULE -- this module MANDATORY-GROUPS { snmpCommunityTableGroup } OBJECT snmpCommunityName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT snmpCommunitySecurityName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT snmpCommunityContextEngineID MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT snmpCommunityContextName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT snmpCommunityTransportTag MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT snmpCommunityStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT snmpCommunityStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::=3D { snmpCommunityMIBCompliances 1 } snmpProxyTrapForwardCompliance MODULE-COMPLIANCE STATUS current SNMPv3 Working Group Expires August 2003 [Page 46] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 DESCRIPTION "The compliance statement for SNMP engines which contain a proxy forwarding application which is capable of forwarding SNMPv1 traps using SNMPv2c or SNMPv3." MODULE -- this module MANDATORY-GROUPS { snmpProxyTrapForwardGroup } ::=3D { snmpCommunityMIBCompliances 2 } snmpCommunityMIBFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP engines which implement the SNMP-COMMUNITY-MIB with full read-create access." MODULE -- this module MANDATORY-GROUPS { snmpCommunityTableGroup } ::=3D { snmpCommunityMIBCompliances 3 } snmpCommunityTableGroup OBJECT-GROUP OBJECTS { snmpCommunityName, snmpCommunitySecurityName, snmpCommunityContextEngineID, snmpCommunityContextName, snmpCommunityTransportTag, snmpCommunityStorageType, snmpCommunityStatus, snmpTargetAddrTMask, snmpTargetAddrMMS } STATUS current DESCRIPTION "A collection of objects providing for configuration of community strings for SNMPv1 (and SNMPv2c) usage." ::=3D { snmpCommunityMIBGroups 1 } snmpProxyTrapForwardGroup OBJECT-GROUP OBJECTS { snmpTrapAddress, snmpTrapCommunity } STATUS current DESCRIPTION "Objects which are used by proxy forwarding applications when translating traps between SNMP versions. These are SNMPv3 Working Group Expires August 2003 [Page 47] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 used to preserve SNMPv1-specific information when translating to SNMPv2c or SNMPv3." ::=3D { snmpCommunityMIBGroups 3 } END SNMPv3 Working Group Expires August 2003 [Page 48] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 6. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances = of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification = can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. SNMPv3 Working Group Expires August 2003 [Page 49] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 7. Acknowledgments This document is the result of the efforts of the SNMPv3 Working Group. The design of the SNMP-COMMUNITY-MIB incorporates work done by the authors of SNMPv2*: Jeff Case (SNMP Research, Inc.) David Harrington (Enterasys Networks) David Levi (Nortel Networks) Brian O'Keefe (Hewlett Packard) Jon Saperia (IronBridge Networks, Inc.) Steve Waldbusser (International Network Services) SNMPv3 Working Group Expires August 2003 [Page 50] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 8. Security Considerations Although SNMPv1 and SNMPv2 do not provide any security, allowing community names to be mapped into securityName/contextName provides the ability to use view-based access control to limit the access of unsecured SNMPv1 and SNMPv2 operations. In fact, it is important = for network administrators to make use of this capability in order to avoid unauthorized access to MIB data that would otherwise be = secure. When a proxy implementation translates messages between SNMPv1 (or SNMPv2c) and SNMPv3, there may be a loss of security. For example, an SNMPv3 message received using authentication and privacy which is subsequently forwarded using SNMPv1 will lose the security benefits of using authentication and privacy. Careful configuration of proxies is required to address such situations. One approach to = deal with such situations might be to use an encrypted tunnel. There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: - The snmpCommunityTable allows creation and deletion of community strings, which is potentially a serious security hole. Access to this table should be greatly restricted, preferably by only allowing write access using SNMPv3 VACM = and USM, with authentication and privacy. - The snmpTargetAddrExtTable contains write-able objects which may also be considered sensitive, and so access to it should be restricted as well. Some of the readable objects in this MIB module (i.e., objects with = a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: - The snmpCommunityTable has the potential to expose community strings which provide access to more information than that which is available using the usual 'public' community string. For this reason, a security administrator may wish to limit SNMPv3 Working Group Expires August 2003 [Page 51] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 accessibility to objects in the snmpCommunityTable, and in particular, to make it inaccessible when using the 'public' community string. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the = objects in this MIB module. It is RECOMMENDED that implementers consider the security features = as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. SNMPv3 Working Group Expires August 2003 [Page 52] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 9. References 9.1. Normative References [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification = of Management Information for TCP/IP-based internets"", STD16, RFC 1155, May 1990. [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD15, RFC 1157, May 1990. [RFC1212] McCloghrie, K., and M. Rose, Editors, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC1215] Rose, M. T., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [RFC1303] McCloghrie, K., and M. Rose, "A Convention for Describing SNMP-based Agents", RFC 1303, February 1992. [RFC1901] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based = SNMPv2", RFC 1901, January 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", RFC 2578, STD 58, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", RFC 2579, STD 58, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", RFC 2580, STD 58, April 1999. [RFC3411] Harrington, D., Wijnen, B., "An Architecture for Describing SNMP Management Frameworks", STD 62, RFC 3414, December 2002. [RFC3412] Case, J., Harrington, D., Wijnen, B., "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002. SNMPv3 Working Group Expires August 2003 [Page 53] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 [RFC3413] Levi, D., Meyer, P., Stewart, B., "SNMP Applications", STD 62, RFC 3413, December 2002. [RFC3414] Blumenthal, U., Wijnen, B., "The User-Based Security Model for Version 3 of the Simple Network Management Protocol (SNMP)", STD 62, RFC 3414, December 2002. [RFC3415] Wijnen, B., Presuhn, R., McCloghrie, K., "View-based Access Control Model for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. [RFC3416] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the = Simple Network Management Protocol (SNMPv2)", STD 62, RFC 3416, December 2002. [RFC3417] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", STD 62, RFC 3417, December 2002. [RFC3418] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", STD 62, RFC 3418, December 2002. [ASN1] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for = Standardization. International Standard 8824, (December, 1987). 9.2. Informative References [RFC1908] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, ] "Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework", RFC 1908, January 1996. [RFC2089] Levi, D., Wijnen, B., "Mapping SNMPv2 onto SNMPv1 within a bi-lingual SNMP agent", RFC 2089, January 1997. [RFC2576] Frye, R., Levi, D., Routhier, S., Wijnen, B., "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", RFC 2576, May 1999. SNMPv3 Working Group Expires August 2003 [Page 54] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. SNMPv3 Working Group Expires August 2003 [Page 55] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 10. Editor's Addresses Rob Frye Vibrant Solutions 2711 Prosperity Ave Fairfax, Virginia 22031 U.S.A. Phone: +1 703 270 2000 EMail: rfrye@vibrant-1.com David B. Levi Nortel Networks 3505 Kesterwood Drive Knoxville, TN 37918 U.S.A. Phone: +1 423 686 0432 EMail: dlevi@nortelnetworks.com Shawn A. Routhier Integrated Systems Inc. 333 North Ave 4th Floor Wakefield MA 01880 U.S.A. Phone: + 1 781 245 0804 EMail: sar@epilogue.com Bert Wijnen Lucent Technologies Schagen 33 3461 GL Linschoten Netherlands Phone: +31 348 480 685 EMail: bwijnen@lucent.com SNMPv3 Working Group Expires August 2003 [Page 56] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 A. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph = are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. SNMPv3 Working Group Expires August 2003 [Page 57] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 B. Change Log 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. SNMPv3 Working Group Expires August 2003 [Page 58] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 - 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 and snmpTrapCommunity to clarify why the object has no size restriction. SNMPv3 Working Group Expires August 2003 [Page 59] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 - 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. B.2. Changes Between RFC 1908 and RFC 2576 - Editorial changes to comply with current RFC requirements. - Added/updated copyright statements. - Added Intellectual Property section. - Replaced old introduction with complete new introduction/overview. - Added content for the Security Considerations Section. - Updated References to current documents. - Updated text to use current SNMP terminology. - Added coexistence for/with SNMPv3. - Added description for SNMPv1 and SNMPv2c Message Processing Models and SNMPv1 and SNMPv2c Community-based Security = Models. - Added snmpCommunityMIB so that SNMPv1 and SNMPv2 community strings can be mapped into the SNMP Version Independent parameters which can then be used for access control using = the SNMPv3 Working Group Expires August 2003 [Page 60] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 standard SNMPv3 View-based Access Control Model and the snmpVacmMIB. - Added two MIB objects such that when an SNMPv1 notification (trap) must be converted into an SNMPv2 notification we add those two objects in order to preserve information about the address and community of the originating SNMPv1 agent. - Included (and extended) from RFC 2089 the SNMPv2 to SNMPv1 mapping within a multi-lingual SNMP Engine. - Use keywords from RFC 2119 to describe requirements for compliance. - Changed/added some rules for converting a MIB module from SMIv1 to SMIv2. - Extended and improved the description of Proxy Forwarder behaviour when multiple SNMP versions are involved. SNMPv3 Working Group Expires August 2003 [Page 61] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 Table Of Contents 1 Overview ..................................................... = 5 1.1 SNMPv1 ..................................................... = 5 1.2 SNMPv2 ..................................................... = 6 1.3 SNMPv3 ..................................................... = 7 2 SMI and Management Information Mappings ...................... = 8 2.1 MIB Modules ................................................ = 8 2.1.1 Object Definitions ....................................... = 8 2.1.2 Trap and Notification Definitions ........................ = 11 2.2 Compliance Statements ...................................... = 11 2.3 Capabilities Statements .................................... = 12 3 Translating Notification Parameters .......................... = 13 3.1 Translating SNMPv1 Notification Parameters to SNMPv2 Notification Parameters ................................... = 14 3.2 Translating SNMPv2 Notification Parameters to SNMPv1 Notification Parameters ................................... = 15 4 Approaches to Coexistence in a Multi-lingual Network ......... = 18 4.1 SNMPv1 and SNMPv2 Access to MIB Data ....................... = 18 4.2 Multi-lingual implementations .............................. = 19 4.2.1 Command Generator ........................................ = 19 4.2.2 Command Responder ........................................ = 19 4.2.2.1 Handling Counter64 ..................................... = 20 4.2.2.2 Mapping SNMPv2 Exceptions .............................. = 21 4.2.2.2.1 Mapping noSuchObject and noSuchInstance .............. = 22 4.2.2.2.2 Mapping endOfMibView ................................. = 22 4.2.2.3 Processing An SNMPv1 GetRequest ........................ = 22 4.2.2.4 Processing An SNMPv1 GetNextRequest .................... = 23 4.2.2.5 Processing An SNMPv1 SetRequest ........................ = 24 4.2.3 Notification Originator .................................. = 25 4.2.4 Notification Receiver .................................... = 26 4.3 Proxy Implementations ...................................... = 26 4.3.1 Upstream Version Greater Than Downstream Version ......... = 26 4.3.2 Upstream Version Less Than Downstream Version ............ = 27 4.4 Error Status Mappings ...................................... = 30 5 Message Processing Models and Security Models ................ = 31 5.1 Mappings ................................................... = 31 5.2 The SNMPv1 MP Model and SNMPv1 Community-based Security Model ..................................................... = 31 5.2.1 Processing An Incoming Request ........................... = 32 5.2.2 Generating An Outgoing Response .......................... = 34 5.2.3 Generating An Outgoing Notification ...................... = 34 5.2.4 Proxy Forwarding Of Requests ............................. = 35 5.3 The SNMP Community MIB Module .............................. = 36 6 Intellectual Property ........................................ = 49 7 Acknowledgments .............................................. = 50 SNMPv3 Working Group Expires August 2003 [Page 62] =0C Internet Draft Coexistence between SNMP versions 15 Apr = 2003 8 Security Considerations ...................................... = 51 9 References ................................................... = 53 9.1 Normative References ....................................... = 53 9.2 Informative References ..................................... = 54 10 Editor's Addresses .......................................... = 56 A. Full Copyright Statement .................................... = 57 B. Change Log .................................................. = 58 B.1. Changes From RFC 2576 ..................................... = 58 B.2. Changes Between RFC 1908 and RFC 2576 ..................... = 60 SNMPv3 Working Group Expires August 2003 [Page 63] =0C ------_=_NextPart_000_01C30366.A184593E-- From owner-snmpv3@lists.tislabs.com Wed Apr 16 02:37:54 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 CAA19940 for ; Wed, 16 Apr 2003 02:37:54 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA29284 Wed, 16 Apr 2003 01:51:15 -0400 (EDT) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Tue, 15 Apr 2003 22:55:06 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: "Snmpv3@Lists.Tislabs.Com (E-mail)" Subject: Re: coex doc update In-Reply-To: <0A11633F61BD9F40B43ABCC694004F93C8D086@zsc3c026.us.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk On Tue, 15 Apr 2003, David Levi wrote: > Attached is an updated coex document, this incorporates the latest > comments from Mike and Bert. Note that I didn't bump up the version > number and related comments, I just updated the text (since we are > not publishing a new ID at the moment). I just went over the changes (relative to the latest I-D) and it looks good to me. Thanks //cmh From owner-snmpv3@lists.tislabs.com Wed Apr 16 14:34:40 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 OAA11285 for ; Wed, 16 Apr 2003 14:34:40 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01702 Wed, 16 Apr 2003 13:36:36 -0400 (EDT) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Wed, 16 Apr 2003 10:40:15 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: "Snmpv3@Lists.Tislabs.Com (E-mail)" Subject: Re: coex doc update In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk On Tue, 15 Apr 2003, C. M. Heard wrote: > On Tue, 15 Apr 2003, David Levi wrote: > > Attached is an updated coex document, this incorporates the latest > > comments from Mike and Bert. Note that I didn't bump up the version > > number and related comments, I just updated the text (since we are > > not publishing a new ID at the moment). > > I just went over the changes (relative to the latest I-D) and it > looks good to me. Oops, I missed one thing -- On Tue, 8 Apr 2003, Wijnen, Bert (Bert) wrote: > I see (In the MIB REVISION clause) > Changed the name of 'snmpCommunityGroup' to a name > conflict with the SNMPv2-MIB. > Should that be: > Changed the name of 'snmpCommunityGroup' to > snmpCommunityTableGroup to avoid a name conflict > with the SNMPv2-MIB. This error still needs to be fixed before a new I-D is submitted (it was fixed in the revision log in appendix B). Sorry about that. //cmh From owner-snmpv3@lists.tislabs.com Mon Apr 21 20:35:17 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 UAA10085 for ; Mon, 21 Apr 2003 20:35:17 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA19957 Mon, 21 Apr 2003 19:35:49 -0400 (EDT) To: Uri Blumenthal , kzm@cisco.com, fmaino@andiamo.com Cc: Bert Wijnen , "Snmpv3-wg (E-mail)" Subject: Re: FW: Last Call: The AES Cipher Algorithm in the SNMP's User-based Security Model to Proposed Standard From: Wes Hardaker X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Organization: Network Associates Laboratories References: <7D5D48D2CAA3D84C813F5B154F43B1550137B9D2@nl0006exch001u.nl.lucent.com> Date: Mon, 21 Apr 2003 16:39:22 -0700 In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550137B9D2@nl0006exch001u.nl.lucent.com> ("Wijnen, Bert's message of "Wed, 26 Mar 2003 00:04:48 +0100") Message-ID: User-Agent: Gnus/5.090017 (Oort Gnus v0.17) XEmacs/21.5 (brussels sprouts, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk >>>>> On Wed, 26 Mar 2003 00:04:48 +0100, "Wijnen, Bert (Bert)" said: Bert> SNMPv3 supporters, pls review and post your comments (if any)as Bert> requested. Bert> Statements of: I have read it and think it is "good stuff" are Bert> welcome too "good stuff" (but needs a fair amount of editing). I implemented an earlier version of the draft in 2 packages and it's still compliant with the most current (though the implementation I based my work on also supported the 192 and 256 versions of the same algorithm. I have a number of commends/questions/concerns/editorial-catches, which I'll list here (I've removed all the editorial catches that other people already made. IMHO, the entire document needs to be re-proofread by all the authors especially after all the grammatical changes that people have caught and found): Concerns/Questions/Comments: - 1.1: The 3rd paragraph says the AES privacy protocol MAY be used with the authentication protocols in ... RFC3414. Obviously, it may be used with more (future-defined) protocols as well and you may want to change the wording to reflect this. You do mention it later in the document, however, but if you're going to cover it in both places you should have them both state the same thing (and the first statement made of this type should always be the most informative). - 1.3: My are you recommending that a 12 byte [should be "octets by the way] minimum password be used (don't get me wrong, I agree that longer is better). Was 12 chosen arbitrarily (as opposed to 16 or 24 or ...)? I guess the real question is that if RFC3414 says 8 bytes is enough for DES, then you should offer a reason why 12 is needed for AES (of course neither 8 nor 12 come anywhere near the potential entropy of a truly random key). (Actually, the entropy of the authentication algorithms is more critical in my mind). - 1.3: I'd used the word "prohibited" instead of "limited" with respect to password sharing. - 1.3: I'd add a 3rd bullet: "Implementations SHOULD support the use of randomly generated master keys as a superior form of security." or something like that. Truly the entropy in a password sucks, so I'd at least recommend the use of true random keys when possible. - 2: This really needs a full MIB definition, not just a segment. This section and the segment seems to imply that RFC3414 is going to be modified and have this stuck in it? I don't think that would fly. - 3.1: "The secret value is shared by all SNMP engines authorized to originate messages on behalf of the appropriate user." This is not true and is a bad statement to make from security prospective. 1) The key has nothing to do with authorization, and the wording choices seems to imply that it might. 2) The key dose *not* need to be shared with engines that may only need to send noAuthNoPriv or authNoPriv messages. Your sentence implies that all engines using the given user should have the privacy key, which is not true and implies a greater secrecy sharing that is needed for some situations. - 3.1.1.2 - 3.1.1.4: if these are standard sizes suggested by [AES-MODE], say so in the document. - 3.1.2: "of the generating SNMP engine's 32-bit snmpEngineBoots, the SNMP engine's 32-bit snmpEngineTime, and a lcal 64 bit integer". This is not correct. "generating SNMP engine" should be "authoritative SNMP engine". Since management applications will not be transmitting their (local) boots/time values, and the entire IV is not transmitted you must use the boots and time values that are always known to both parties. This means only the authoritative engine's boots/time values can be used unless you change the contents of the msgPrivacyParameters to include the full IV (which, of course, I don't recommend for octet-saving reasons). - 3.1.2: "An implementation can use any method to vary the value of the IV ..." IV => integer. Since the boots and time are not put into the privacy field, only the integer can be varied in an arbitrary manner. - 3.1.2: I'd put in a note mentioning that multiple managers communicating with a single authoritative engine within a second can cause a duplicate IV to be used if they both (accidentally) use the same 64 bit integer value [the probability of such a problem is low, though birthday statistics drop this a bit more. I posted an analysis of this a few months ago.]. - 3.1.3, 3.1.4: an ASCII diagram would be nice for the people that aren't familiar with CFB mode (if you're going to describe it then you might as well generate the diagrams for it). - 3.2.1: you also need to know the authorization algorithm for the user, since it's used to generate the localized key. And you might as well throw in the encryption algorithm just to check that it's the right one ;-) - 4: You should mention key entropy here since you talk about it earlier. Additionally, I'd refer the reader to RFC3414 explicitly since the USM specific implications are there. - 4: you reference [CRYTPO-B] as a document that describes the need for a unique IV value. However, I don't think that document is the right reference. That document describes plain-text analysis and attacks of DES when operating in CBC mode. CFB mode, which is used by your document, is quite different from CBC mode in its use of an IV and thus I don't think the statements made in that paper about unique IV requirements properly support your statements within your own document. [since the author of the paper in question is also the reviewing security AD, maybe he'll have further comments on the subject?]. Editorial ('*' pairs mark changed parts of sentences): - General: You use "Symmetric Encryption Protocol" in many places. Why is it capitalized? It really shouldn't be, IMO. The same goes fore "Cipher Algorithm". - 1. remove the ()s around the word "initial". - 1. "Model, however, allows" (add the commas) - 1.1 protocol for *the* USM based - 1.3: It is worth *remembering* that ... password *or non-localized key* is disclosed ... - 1.3: the sentence suffix "in this case" isn't needed. - 3: alternative to the *DES* privacy protocol - 3.1: of the message that *will* be encrypted *in an SNMP message*. - 3.1.1: contain description*s* of the revlevent - 3.1.2: satisfy *this* requirement *[above]*. - 3.1.3, 3.1.4: "r is less *than* or equal to 128" - 3.2.1: MUST be *greater than or equal to* 128 bits (earlier you stated that you strip off the first 128 bits of a longer key, but here you state that a 128 bit length is mandatory). - 3.2.2 privacy key is *[delete normally]* different - 3.2.2, 3.2.3: for readability, I'd either use a English phrase for both of these or use msgPrivacyParameters for 3.2.4. - 3.2.4.1, 3.2.4.2: passes the *(localized)* secret key - 3.3: for the AES privacy protocol *for SNMP's User-based Security Model* - 3.3.1 step 1: *en*cryptKey (which is the full name the ASI has in the argument list). - 3.3.2 step 3: *de*cryptKey (ditto) -- Wes Hardaker Network Associates Laboratories From owner-snmpv3@lists.tislabs.com Mon Apr 28 11:15:09 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 LAA04090 for ; Mon, 28 Apr 2003 11:15:08 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00471 Mon, 28 Apr 2003 10:21:51 -0400 (EDT) Message-ID: <09cf01c30cf9$f99f42e0$5600a8c0@MIRELA> From: "Mirela Sechi Moretti Annoni Notare" To: Subject: 5th IEEE MWCN'2003 - Call for Papers Date: Sun, 27 Apr 2003 17:03:40 -0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Virus-Scanned: by AMaViS perl-10 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 8bit Our apologies if you have received multiple copies. ****************************************** ****** CALL FOR PAPERS ******* ****************************************** IEEE MWCN'2003 The Fifth IEEE Conference on Mobile and Wireless Communications Networks Singapore in 27 - 29 October, 2003 http://www.icr.a-star.edu.sg/mwcn2003/ You are invited to submit original papers addressing topics in all areas of wireless communication systems and networks. Potential topics include, but are not limited to, the technical subject categories listed below: Management - Resource and Information Management - Pricing and Billing Issues Architecture - Convergence of Fixed and Mobile - Hybrid Communications System Devices - Low-Power End-Devices and Wireless Communications Security - Security in Mobile and Wireless Networks QoS - Adaptive Quality of Service Provisioning - End-to-end Quality of Service Mobility Support - Handoff Algorithms - IP and Mobility - Mobility and Connection Management in Heterogeneous Wireless Networks - Policy-based Mobility Management Applications - Personal Communications - Location and Context Management - Smart Media - Mobile Code - Mobile Ad-Hoc Networks Applications Access - Wireless IP - Wireless Multimedia Services - Wireless Local Loop (WLL) - Multiple Access Technology - Broadband Wireless Access Networking - Wireless Personal Area Networks - Wireless Local Area Networks - Mobility and Nomadic Computing - Analysis and Simulation of Mobile Network Protocols - Home Networking - Mobile Ad-hoc Networks and the Internet - Mobile Ad-Hoc Networking Routing - Satellite Networks The official language of the conference for submission of a paper and or an extended abstract and view graphs is English. This conference will identify the theoretical and actual problems that face designers of today's complex problems associated with mobile and wireless communications networks. The participants will show test results of experiments from building prototype systems, explore modeling and simulation tools as well as analytical methodologies and techniques for dealing with wireless systems. The objective of this event is to foster the exchange of information among researchers in this fast-moving field. The program will include presentations by distinguished researchers, speaking on recent advances in theory and practice. This conference also intends to bring together various mobile and wireless network systems developers to discuss the current status, technical challenges, standards, fundamental issues, and future services and applications in the form of workshops, business applications sessions and tutorials. It is also intended to provide a timely forum for exploratory research and practical contributions from North America, Europe, The Middle East, and the Far East. Guidelines for Submission Papers are invited on the conference theme and related topics. The original submission containing affiliation and full contact information of the authors should be addressed to the TPC chairs by the date indicated above based on the following instructions: Extended abstract should be in English, with no more than 1500 words and submitted to http://mwcn2003.lri.fr/REG-paper/ The paper should include an abstract of about 150 words, and must not exceed Accepted formats include Microsoft Word, PostScript and PDF. Authors must state that their paper have neither been published before nor currently being submitted elsewhere. The cover page must contain an abstract of about 150 words, name and affiliation of author(s) as well as the lead author's postal address, telephone number, fax number and e-mail. The language of the conference is English and papers must be in this language. Accepted papers will have to expanded into full paper to be distributed on the conference proceedings and or CD-ROMS, and will also be made available in the IEEExplore. Dates to Remember Deadline for submitting an extended abstract : May 5, 2003 Notification of acceptance: June 15, 2003 Papers received in camera ready form to MWCN 2003: July 1, 2003 Conference Date and place: 27-29 October, Singapore Organizing Committee Conference General Chair Dr. Guy Omidyar Institute for Communications Research, National University of Singapore Email:gomidyar@icr.a-star.edu.sg Conference Technical Program Chair Khaldoun Al-Agha Khaldoun Al Agha, LRI, University of Paris XI, France Email: alagha@lri.fr Conference Technical Program Co-chairs and area Coordinators Asia-Pacific: Boon Sain Yeo Institute for Communications Research, National University of Singapore Email: boonyeo@ieee.org North and South Americas: Azzedine Boukerche University of North Texas, USA Email: boukerche@cs.unt.edu Middle-East and Far East: Khaled Elsayed Cairo University, Egypt Email: khaled@ieee.org Tutorial, Workshop, Panel Chair Dr. Guy Omidyar Institute for Communications Research, National University of Singapore Email:gomidyar@icr.a-star.edu.sg Organizing Chair Ms Patricia Loh Institute for Infocomm Research, Singapore Email:patricia@i2r.a-star.edu.sg Finance Chair S Kunaselvam Institute for Communications Research, National University of Singapore Email:kuna@icr.a-star.edu.sg Conference Secretariat Please contact mwcn@i2r.a-star.edu.sg Web Chair Gek Hiong Tan Institute for Communications Research, National University of Singapore Email:tangh@icr.a-star.edu.sg Steering Committee Khaldoun Al Agha, LRI, University of Paris XI, France Mario Gerla, UCLA, USA Guy Omidyar, ICR-NUS, Singapore (Chair) Guy Pujolle, Université Paris 6, France Boon Sain Yeo, ICR-NUS, Singapore Technical Scientific Program Committee Hossam Afifi, INT, France Khaldoun Al Agha, LRI, University of Paris XI, France Hamid Aghvami, Kings College of London, UK André-Luc Beylot, IRIT, France Azzedine Boukerche, University of North Texas, US Andrew T. Campbell, Columbia University, USA Olga Casals, Universitat Politecnica de Catalunya, Spain Colin Chandler, Qualcomm Europe, France Francois Chin, Institute for Communications Research, NUS, Singapore Sajal K. Das, University Texas at Arlington, USA Khaled Elsayed, Cairo University, Egypt Markus Endler, IME/USP, Brazil Serge Fdida, Laboratoire d'informatique de Paris 6, France Afonso Ferreira, CNRS INRIA, France Adolf Finger, Technical University of Dresden, Germany Mario Gerla, UCLA, USA Martin Haardt, Ilmenau University of Technology, Germany Zygmunt J. Haas, Cornell University, USA Lajos Hanzo, University of Southampton, UK Jamshid Khun Jush, Ericsson, Germany Theo Kanter, Ericsson Research, Sweden Parviz Kermani, IBM Watson Research Center, USA Witold Krzymien, University of Alberta, Canada Xavier Lagrange, ENST Bretagne, France Khaled Ben Letaief, Hong Kong University, HK Antonio A. F. Loureiro, Federal University of Minas Gerais, Brazil Gerald Q. Maguire, Jr., KTH, Wireless Center, Sweden Jon W. Mark, University of Waterloo, Canada Geraldo Robson Mateus, Federal University of Minas Gerais, Brazil Marie-Jose Montpetit, Nokia, USA Mahmoud Naghshineh, IBM Watson Research Center, USA Ayman Naguib, Qualcomm, USA Mirela Sechi Moretti Annoni Notare, Barddal University, Brasil Guy Omidyar, Institute for Communications Research, NUS, Singapore Elena Pagani, Universita` degli Studi di Milano, Italy Kaveh Pahlavan, Worcester Polytechnic Institute, USA Gregory P. Pollini, Telecordia, USA Ramjee Prasad, Aalborg University, Denmark Guy Pujolle, Université Paris 6, France Christopher Rose, Associate Director, Rutgers WinLab, USA Elisabeth Royer, University of California, Santa Barbara Djamel Sadok, Universidade Federal de Pernambuco, Brazil Fabrizio Sestini, European Commission, Belgium Jan Slavik, Testcom, Czech Republic Kelvino S. Sousa, University of Toronto, Canada Cormac Sreenan, University College Cork, Ireland Sumei Sun, Institute for Communication Research, NUS, Singapore T.T. Tjhung, Institute for Communication Research, NUS, Singapore Guillaume Vivier, Motorola Labs, France Branimir Vojcic, George Washington University, USA Ivan Vukovic, Motorola, USA Adam Wolisz, Technische Universitat Berlin, Germany Boon Sain Yeo, Institute for Communication Research, NUS, Singapore Albert Zomaya, University of Sydney, Australia From owner-snmpv3@lists.tislabs.com Mon Apr 28 11:21:21 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 LAA04278 for ; Mon, 28 Apr 2003 11:21:20 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00493 Mon, 28 Apr 2003 10:22:53 -0400 (EDT) To: snmpv3@lists.tislabs.com Subject: CfP: Distributed Applications and Interoperable Systems (DAIS2003) Message-Id: <20030428132336.EB36D90EE4@bruecke.ivs.cs.tu-berlin.de> Date: Mon, 28 Apr 2003 15:23:36 +0200 (CEST) From: dncr@ivs.tu-berlin.de (dncr) Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Apologies if you receive this more than once. Please redistribute this Call for Papers among interested colleagues. Thank you! ------------------------------------------------------------------------------- Call for paper Fourth International IFIP Working Conference on Distributed Applications and Interoperable Systems DAIS 2003 19-21 November 2003, Paris, France to be held in conjunction with FMOODS'03 International Conference on Formal Methods for Open Object-based Distributed Applications Systems http://fedconf.enst.fr/ A call for tutorials common to FMOODS and DAIS and a call for workshops will be issued separately. The ubiquitous explosion of the Internet and the fast proliferation of distributed computing involving all kinds of computing devices create a unique challenge. Innovative solutions are required for the development, implementation and operation of distributed applications in complex IT environments full of diversity and heterogeneity. Following the evolution of the field, DAIS'03 will focus on models, technologies and platforms for reconfigurable, scalable and adaptable distributed applications. DAIS'03 will provide a forum for researchers, application and platform service vendors and users, to review, discuss and learn about new approaches, concepts and experiences in the fields of distributed computing. DAIS'03 will include talks by invited speakers, full technical paper sessions, and work-in-progress presentations. Tutorial proposals are also encouraged. Conference themes: In keeping with the focus on models, technologies and platforms for reconfigurable, scalable and adaptable distributed applications, and in addition to its traditional themes, DAIS especially encourages original unpublished papers addressing the following topics: - new/extended software architectures and frameworks for reconfiguration and adaptation including component-based approaches (e.g. CORBA Components, EJB, .NET), - modelling, specifying, monitoring and management of context-aware and adaptive applications, - support for reconfiguration, self-organisation and autonomic behaviour in new/existing distributed platforms (e.g. CORBA, J2EE, .NET, WebServices), - integration of multi-agent distributed decision-making, - application environments that exploit characteristics of specific technologies (e.g. grid computing, mobile and wireless), - issues in enterprise-wide and large-scale application reconfiguration, - semantic interoperability and semantic web services. Submissions: DAIS'2003 seeks submissions for: - Full technical papers in no more than 12 pages (approximately 6000 words); - Work-in-progress papers, describing on-going work and interim results, in no more than 5 pages. All papers must be original, unpublished, and not submitted simultaneously for publication elsewhere. They will be refereed by the Program Committee. Accepted full papers will be published by Springer Verlag in the LNCS series. A call for tutorials common to FMOODS and DAIS and a call for workshops will be issued separately. Submission method: Electronic submission in PDF format using the Springer LNCS style (see http://www.springer.de/comp/lncs/authors.html). Submission dates: - Deadline for full paper submissions: June 2, 2003 - Deadline for work-in-progress papers: June 15, 2003 - Notification of acceptance: July 25, 2003 - Final versions: September 1st, 2003 - Conference dates : 17th to 21st November 2003 General chair: Jean-Bernard Stefani (INRIA) Publicity Chair: Kurt Geihs (TU Berlin) Tutorial chair: Sylvie Vignes (ENST) PC Chairs: Isabelle Demeure (ENST), Daniel Hagimont (INRIA) Program Committee: M.Ahamed, Georgia Tech, USA N.Alonistioti, University of Athens, Greece S.Baker, IONA, Ireland Y.Berbers, Katholieke Universiteit Leuven, Belgium A. Beugnard, ENST Brittany, France V.Cahill, Trinity College Dublin, Ireland R.Campbell, UIUC, USA N. Davies Lancaster University UK and University of Arizona, USA F.Eliassen, University of Oslo, Norway K.Geihs, TU Berlin, Germany P.Honeyman, CITI, University of Michigan, USA. J.Indulska, University of Queensland, Australia E.Jul, DIKU, Denmark H.Koenig, BTU Cottbus, Germany F.Kordon, LIP6, France S.Krakowiak, University of Grenoble, France H.Krumm, University of Dortmund, Germany L.Kutvonen, University of Helsinki, Finland W.Lamersdorf, University of Hamburg, Germany D.Lea, SUNY Oswego, USA P.Linington, University of Kent, UK C.Linnhoff-Popien, University of Munich, Germany P.Merle, INRIA, France G.Muller, Ecole des Mines de Nantes, France E.Najm, ENST, France L.Pautet, ENST, France K.Raymond, DSTC, Australia A.Schill, TU Dresden, Germany D.Schmidt, University of California, Irvine, USA S.Shrivastava, University of Newcastle, UK J-J.Vandewalle, GemPlus, France From owner-snmpv3@lists.tislabs.com Mon Apr 28 11: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 LAA04523 for ; Mon, 28 Apr 2003 11:26:14 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00465 Mon, 28 Apr 2003 10:20:50 -0400 (EDT) Message-ID: <09d001c30cf9$facdd7d0$5600a8c0@MIRELA> From: "Mirela Sechi Moretti Annoni Notare" To: Subject: 6th ACM MSWiM'2003 - Call for Papers Date: Sun, 27 Apr 2003 17:03:57 -0300 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Virus-Scanned: by AMaViS perl-10 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 7bit ============ Our apologies if you have received multiple copies. ============ CALL FOR PAPERS 6th ACM MSWiM 2003 The Sixth International Workshop on Modeling, Analysis and Simulation of Wireless and Mobile Systems (Jointly with ACM MobiCom 2003, September 14-19) September 19, 2003 San Diego, CA, USA http://www.cs.unibo.it/mswim2003/ MSWiM is intended to provide an international forum for the discussion and presentation of original ideas, recent results and achievements by researchers, students, and systems developers on issues and challenges related to mobile and wireless systems. Authors are encouraged to submit both theoretical and practical results of significance on all aspects of modeling, analysis and simulation of mobile computing and wireless networks. Topics of interest include, but are not limited to: * Performance evaluation and modeling of mobile and wireless communication networks * Simulation and analysis of wireless protocols and mobile computing systems * Integrated simulation and measurement based evaluation of mobile and wireless systems * Survivability and reliability evaluation and modeling * RF channel capacity modeling and analysis * Design methodologies for wireless systems * Network support for QoS provisioning in wireless and mobile networks * Modeling and analysis of wireless Internet access * Traffic measurements and models for audio, video, multimedia, and WWW services * New simulation languages and tools for wireless systems * Database management systems and mobile computing (location-based queries, wireless data caching, mobile transactions) * Wireless data dissemination (broadcasting and indexing techniques) * Pervasive computing and ad hoc networking * Wireless PANs, LANs * Sensor networks * Mobile agents support for wireless networks PAPER SUBMISSION AND PUBLICATION High-quality original papers are solicited. Papers must be unpublished and must not be submitted for publication elsewhere. All papers will be reviewed by Technical Program Committee members and other experts active in the field to ensure high quality and relevance to the conference. Paper length should not exceed 20 pages. Only Postscript and PDF formats are accepted. Papers must be submitted electronically through the EDAS system. For paper submission, please follow the submission instructions at: http://www.cs.unibo.it/mswim2003/ Accepted papers will appear in the conference proceedings published by by ACM CS-press. A Special Issue with ACM/Baltzer MONET/WINET will be planned which will contain selected papers from MSWiM. IMPORTANT DATES Full papers due: June 5, 2003 Notification: July 15, 2003 Camera Ready due: TBD Organizing Committee General Chair Rassul Ayani Department of Microelectronics and Information Technology Royal Institute of Technology (KTH) Email: rassul@it.kth.se Program Co-Chairs Carla-Fabiana Chiasserini Dipartimento di Elettronica, Politecnico di Torino, Italy Email: chiasserini@polito.it Hossam Hassanein Department of Computing and Information Science Queen's University Email: Hossam@cs.queensu.ca Publicity Co-Chairs Luciano Bononi Universita' di Bologna, Bologna, Italy Email: bononi@cs.unibo.it Helen Karatza Aristotle University of Thessaloniki, Thessaloniki, Greece Email: karatza@csd.auth.gr Mirela Sechi Moretti Annoni Notare Barddal University, Florianopolis, SC Brazil Email: mirela@barddal.br Program Committee Anand Balachandran, University of California at San Diego, USA Simonetta Balsamo, Universita' Ca' Foscari di Venezia, Italy Luciano Bononi, Universita' di Bologna, Bologna, Italy Azzedine Boukerche, University of North Texas, USA Lorenzo Casaccia, Qualcomm, San Diego, USA Xiuzhen Cheng, George Washington University, USA Carla-Fabiana Chiasserini, Politecnico di Torino, Italy Marco Conti, IIT - CNR, Italy Teresa A. Dahlberg, University of North Carolina at Charlotte, USA Sajal K. Das, University of Texas at Arlington, USA Juan Carlos De Martin, Politecnico di Torino, Italy Alois Ferscha, Johannes Kepler University of Linz, Austria Vincenzo Grassi, Universita' di Roma Tor Vergata, Italy Mohsen Guizani, Western Michigan University, USA Fredrik Gunnarsson, Ericsson Research, Sweden Hossam Hassanein, Queen's University, Canada Sumi Helal, University of Florida, USA Helen Karatza, Aristotle University of Thessaloniki, Greece Yi-Bing Lin, Academia Sinica, Taipei, Taiwan Michela Meo, Politecnico di Torino, Italy Pavan Nugehalli, University of California at San Diego, USA Mohamed Ould-Khaoua, University of Glasgow, UK Mirela Sechi Moretti Annoni Notare, Barddal University, Brazil Krishna M. Sivalingam, University of Maryland Baltimore County, USA Vikram Srinivasan, University of California at San Diego, USA Dirk Staehle, University of Wurzburg, Germany Mineo Takai, University of California at Los Angeles, USA David Tipper, University of Pittsburgh, USA Phuoc Tran-Gia, University of Wurzburg, Germany Albert Y. Zomaya, University of Sydney, AU Steering Committee Chair Azzedine Boukerche, University of North texas, USA Advisory Board Committee Azzedine Boukerche, University of North texas, USA Sajal K. Das, University of Texas at Arlington, USA Lorenzo Donatiello, Universita' di Bologna, Italy Jason Yi-Bing Lin, National Chiao-Tung University, Taiwan William C.Y. Lee, AirTouch Inc. Registration Chair Tom Jacob, University of North texas, USA Webmaster and System Co-Chairs Luciano Bononi, University of Bologna, Italy Email: bononi@cs.unibo.it Maurizio Munafo', Politecnico di Torino, Italy Email: munafo@polito.it From owner-snmpv3@lists.tislabs.com Mon Apr 28 15:12:19 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 PAA11426 for ; Mon, 28 Apr 2003 15:12:19 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01295 Mon, 28 Apr 2003 14:19:25 -0400 (EDT) Message-ID: <3EAD71B7.2090309@juniper.net> Date: Mon, 28 Apr 2003 11:23:51 -0700 From: Daniel Chuang Organization: Juniper User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Bert Wijnen CC: "Snmpv3-wg (E-mail)" 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> 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 Hi, everyone, >>>>>>On Wed, 26 Mar 2003 00:04:48 +0100, "Wijnen, Bert (Bert)" said: >>>>>> > >Bert> SNMPv3 supporters, pls review and post your comments (if any)as >Bert> requested. > >Bert> Statements of: I have read it and think it is "good stuff" are >Bert> welcome too > I have one simple question on this draft, why the aes cfb mode is chosen instead of cbc mode ? thanks, Daniel From owner-snmpv3@lists.tislabs.com Mon Apr 28 16:56:19 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 QAA14327 for ; Mon, 28 Apr 2003 16:56:19 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01583 Mon, 28 Apr 2003 15:55:09 -0400 (EDT) Cc: Bert Wijnen , "Snmpv3-wg (E-mail)" Message-ID: <3EAD8673.7070000@bell-labs.com> Date: Mon, 28 Apr 2003 15:52:19 -0400 From: Uri Blumenthal Organization: Lucent Tehcnologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en, zh-cn, ru, de, he MIME-Version: 1.0 To: Daniel Chuang Original-CC: Bert Wijnen , "Snmpv3-wg (E-mail)" 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> <3EAD71B7.2090309@juniper.net> 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 Daniel Chuang wrote: > I have one simple question on this draft, why the aes cfb mode is chosen > instead of cbc mode ? Because of its properties, of course. 1. Preserves the size of the plaintext (CBC would increase it). 2. Has error propagation within one block (like CBC). 3. Has chaining dependency (reordering ciphertext blocks affects decryption, like CBC). 4. Uses AES crypto engine in Encryption mode only (no need to implement AES_decrypt).