[nmrg] Re: nmrgSecurity interaction?

Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h5UEvZ9F026910 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 30 Jun 2003 16:57:37 +0200 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h5UEvWO00535 for ; Mon, 30 Jun 2003 09:57:32 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jun 2003 16:57:30 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501ED5A91@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: j.schoenwaelder@iu-bremen.de, nmrg@ibr.cs.tu-bs.de Subject: RE: [nmrg] upcoming nmrg meeting Date: Mon, 30 Jun 2003 16:57:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: I plan to attend. Is it located close to where IETF is being held, or shoudl we switch hotels as well? Thanks, Bert Received: from merkur.iu-bremen.de (merkur.iu-bremen.de [212.201.44.27]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h5QF2j6V009850 for ; Thu, 26 Jun 2003 17:02:45 +0200 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 332911A937; Thu, 26 Jun 2003 17:02:45 +0200 (CEST) Received: from iu-bremen.de (unknown [212.201.47.15]) by merkur.iu-bremen.de (Postfix) with SMTP id 6F6C617AD8; Thu, 26 Jun 2003 17:02:44 +0200 (CEST) Received: (nullmailer pid 793 invoked by uid 1000); Thu, 26 Jun 2003 15:03:38 -0000 Date: Thu, 26 Jun 2003 17:03:38 +0200 From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de Message-ID: <20030626150338.GA780@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: nmrg@ibr.cs.tu-bs.de Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-IBRFilter-SpamReport: -6.4 () USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-6.4 required=5.0 tests=USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] meeting notes (colorado springs) Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Attached are the meeting minutes from the Colorado Springs meeting. Thanks to John Strassner for editing the raw material into these minutes. Please check the minutes and let us know by the end of this months whether there is something that needs to be changed. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="12thXNMRGXMeetingXMinutes-text.txt" 12th NMRG Meeting Minutes, 22-23 March, 2003 Location: Colorado Springs, Colorado, USA Host: Intelliden (John Strassner) Note-takers: John Strassner, Juergen Schoenwaelder Attendees: * Olivier Festor * David Harrington * James Hong * Torsten Klie * Emmanuel Nataf * George Pavlou * David Perkins * Aiko Pras * Phil Shafer * Juergen Schoenwaelder * Frank Strauss * John Strassner * Bert Wijnen The meeting was held in accordance with the published agenda, with some minor changes and additions. Thus, the revised agenda will be used as an outline for the notes. The Agenda is as follows: Saturday (2003-03-22) (13:00 - 17:00) * Welcome * Select note takers and minute producers * Status reports * Recent achievements * 11th meeting minutes * OID compression paper * ITU SG 4 input on SNMP over TCP * Latest IETF news (new/closed WGs, rumors and mysteries) * SMIng status report (F. Strauss, J. Schoenwaelder) * SMI -> XSD translation and gateway (T. Klie, F. Strauss) * Plans for dinner Sunday (2003-03-23) (09:00-12:00, 13:00-17:00) * Short summary of the Saturday meeting * Bert's input and comment on the latest IETF news * SMI -> XSD wrap-up discussion * Technical XMLCONF discussion (Phil) * Wrap up and action items * Plans for dinner Please note that on Tuesday, at IM03, there is an important discussion from 17:00-18:30. It covers the following two topics: * IAB research funding document feedback * Restructuring and refocus of the NMRG After a welcome from John (the host) and introductions of the participants, the meeting began. ITEM: Recent Achievements (under Status reports) * RFC 3430: Simple Network Management Protocol Over Transmission Control Protocol Transport Mapping. This was published December 2002. * RFC 3440: On the Difference between Information Models and Data Models. This was published January 2003 Both of these documents are available on the website and through the IETF repository. Regarding OID compression, Aiko and Juergen were going to collaborate and try and produce a paper. No date given for completion. ITU SG-4 input on SNMP over TCP document went to Bert. A university in Asia tried to implement it. Level of detail wasn't very precise, so Juergen wrote a response (copied the NMRG list) but hasn't received a reply to this yet. ITEM: Latest IETF news * SMIng and EOS working groups will be shut down very soon. * SNMP is going into maintenance mode. A working group may be chartered to do this, but it will be given one task at a time and if it fails to complete a task, then the working group will be shut down. The other approach is to have a design team reporting directly to the OPS ADs. It was restated that SNMP is not useful for configuring routers. A couple of operators from the cable and ATM community said that they use SNMP MIBs, at which point Randy narrowed this to routers running IP. * PIBs will no longer be allowed on the standards track. In fact, further PIB work is going to be discouraged. However, COPS-PR is on the standards track, so if it is to be released, they need to prove that people are using COPS-PR with some PIBs. * Readable MIBs are still required from WGs where applicable * Writable MIBs can be worked on, but are NOT required any longer. Note that there have been different interpretations of statements from various sources observed, making a precise interpretation of this statement impossible; group will ask Bert when he arrives. * XML configuration management working group renamed NetConf, and will be started soon. NetConf looks promising - readable MIBs are required, writable MIBs are optional. Some operators agreed to work on the NetConf document. Had gotten feedback that they needed to work on some underlying data model issues. * It is desired that operators co-chair OPS area working groups. This is likely to be enforced for the XML configuration management working group. * Wes thinks that SNMP fixes/evolution are still needed, even if XML might take over in the future, and in spite of the demise of the EOS and SMing working groups. Wes also thinks that SNMPv3 might benefit from a session based security model in order to integrate better with established authentication mechanisms. * Since PIBs and MIBs couldn't coexist, how can the data models for SNMP and NetConf coexist? (open question) * The following are notes from Dave, who attended the OPS area meeting: * AAA stuff: Bernard presented, said that AAA was being used by IEEE, 3GPP, and 3GPP2. 802.11 (wireless) has more of a strained relationship because they weren't sharing information with the IETF; this is perhaps going to be fixed soon. * Most people are reusing Radius instead of Diameter. No documents to do Key Distribution. IESG is holding up Diameter because security concerns haven't been addressed. * SIP is beginning to use Radius. SIP has pushed back against Diameter. SIPPING also is pushing back against Diameter. SIPPING is expressing interest in writing SNMP v3 MIBs for accounting. Cellular requirements are influencing Diameter. PPVPN is looking at using AAA. * Margaret reported on IPv6 Operations - they are focusing on coexistence, not transition. Currently analyzing scenarios for 3GPP and unmanaged networks; they want more input for Enterprise and ISP networks. They believe that both 3GPP and unmanaged networks need a dual stack. Hypothesis: the IETF is lacking an overall vision for how different efforts can cooperate and work together. Perhaps the NMRG could help by providing a technical vision that would help the ADs focus the various WGs. Other ideas were to develop a session based security model as well as a common bootstrap model. ITEM: SMIng Discussion * Since the SMIng WG is going to be closed down, these documents will be published by the NMRG. Olivier and Emmanuel developed a proxy agent which implements Juergen's and Frank's draft. They wanted to demonstrate the co-existence of SMIng and COPS-PR. * SMIng objects for usage by management applications that only operate on SMIng objects. * With SNMP, you can easily turn SNMP instance data into a set of SMIng objects. Might be possible to get the SMIng updates into the implementation. Note, however, that if there are no follow-on projects from industries or fora, this work might be stopped. * Dave Perkins asks how much semantic checking is being done, and whether there is a list of ambiguities. It would also be good to have the INRIA implementation consistent with the final SMIng documents. However, it is unlikely that libsmi will be upgraded to support the final SMIng document any time soon, since the INRIA implementation uses Java CC. * Action items: * Emmanuel will talk to Frank to get comments integrated into the current documents * Frank will contact COPS-PR mapping authors to see how we can update this document ITEM: SMI XSD translation and gateway * Torsten started discussion of this topic by using his IM presentation ("Towards XML-Oriented Internet Management"). Following are notes from his presentation: * SNMP Problems - a "low-level" technology, quite complicated, requires expensive experts. Also, it is difficult to move configuration between devices. Programming is done by side effect (e.g., set variables without clear semantics). XML may be the way out? Torsten's work depended on XML Schemata, since through that it could ensure the integrity of XML documents through formal grammars. Note that the "proprietary database of SNMP data" phrase on slide 4 causes some lively discussion. :) * Mapping MIB Definitions to XML Schema Definitions is inherently difficult. This is because there is no form for creating standardized instance data from SMI. There are also many differences between producing a database of SNMP data (from MIBs based on the SMI) versus producing an XML document (based on XSDs). Furthermore, it is important to note that there is not a standard interchange format to exchange instance data even if two devices support the same MIB. Thus, the approach is to follow the XML style as close as possible, but keep supporting automatic translations. This would save investments on MIB definitions and implementations. * It is desired (by the authors) to have multiple "contexts" per XML Document. Examples of contexts may be per agent (e.g., IP Address, hostname or port), per-agent communities, or multiple points in time. Each of these can be their own context tag. * Problem - there are security issues - for example, since everything is text based, how can you secure one community from the other? This is a topic for future work. * The authors have developed a four-level element nesting. They use XML Namespaces to Identify Modules. Each MIB is compiled to separate XML Schema that defines an associated namespace; imports from MIB modules are translated to imports of namespaces. Elements can be uniquely identified with namespace prefixes. * Slide 9 - the SMI is bad, in that you can change enum values per revision of the MIB, leading to ambiguous data. Hopefully the XML mapping won't allow this? * Some suggestions for improving the structure of the document were given, including the use of complex types and a better explanation of how XPath or XQuery would be used to search within the documents. * Applications of this are potentially very powerful, and include configuration management (moving configuration data between devices and managers), notification processing (post-processing notifications that are stored as XML documents); agent validation (validating agent implementations of MIBs); SNMP/XML gateway (translate HTTP requests on XML documents to SNMP operations) * The following are comments given to the authors by the group: * Dave Harrington asks whether storing communities in the XML is not a security issue. * Dave Perkins asks what is being done about different versions of MIB modules. The SMIv2 allows to change names of named numbers which means the value representation might legally change between different MIB module revisions. * There are corner cases of OCTET STRING display hints which are not reversible. (Juergen might be able to find an example in his mailing list archives.) * Some information is lost in the translation (descriptors of intermediate node, OID identities and constants). * Dave Perkins asked whether it was considered to move index values into an index element rather than using XML attributes. Furthermore, the xpath example misses namespaces and looks nicer than it would be if it were spelled out. * Aiko asks whether the xpath filter interpreter really belongs into the gateway or not better into the management application using the gateway. Dave Perkins says that data might be stored in the gateway and updated regularly by a poller so that time domain queries are possible. * Both Daves think more future work is needed. * Bert asks what Frank's experiences are with writing XML Schema definitions. DAY TWO Juergen gave a quick summary of yesterday's meeting for the new people arriving. Bert was asked for further clarification on his view on MIBs. Bert stated that writable objects for MIBs were no longer required, but if the working group deemed them appropriate, then they should be designed that way. Bert's concern is that operators are not using SNMP or COPS-PR - therefore, writeable objects and configurable MIBs are probably not appropriate. People expressed to Bert a feeling that constructing writable objects were discouraged. Bert responded that he was concerned that operators would not use writable objects; however, so long as the target audience needed writable objects, go ahead. This is why he used the word "discouraged". Bert thinks that he should probably make a clearer expression, perhaps through an I-D, defining this. Bert said that NetConf will likely be started. However, one of his issues is finding the proper chairs. One of the chairs MUST be an operator. Regarding delaying work on the data model, Bert still is not sure whether an additional working group focused on data modeling should be chartered or whether this work should be added into NetConf. Bert clarified that with respect to SMI fixes/evolution, they had tried very hard not to do SMI 2.1 because people had expressed the need for "more". However, SMIng has failed, so it appears that the best thing is to simply go to a working group focused on maintenance mode. We reviewed Torsten's paper again. It was observed that there needs to be a translation layer that will convert the MIB into the native objects required by the device. There is data that can be obtained from standard MIBs and even agents. However, there is no standard way to exchange or interoperate. ITEM: XMLCONF discussion * Phil starts with giving a presentation about XMLCONF. * Problem to solve directed at manual typing or usage of expect scripts. 50% of outages that triggered SLA violations at AOL were due to manual configuration errors. In addition, there is a fear that when an OS is upgraded, configurations will break in different ways. * Juniper has never had a customer request to enable SNMP writes. * Strategy - enable implementation to mirror native capabilities of the device. XML enables tight integration with CLI. Moreover, XML is all about data portability. XML works as conversion language between database and devices. * Phil's slide titled "The Real World" should really be called "The Ideal World". NetConf is the line that can enable the transport to the device. Juniper has very few customers that operate like the "ideal world" model where the authoritative information is kept in a central database and all changes have to be made in the central database to be pushed to the devices. * NextHop Technologies, Cisco, Laurel or Foundry, Wind River, Juniper, RiverStone, and Intelliden all have XML APIs. Feedback from the NMRG is that the draft appears to be too full of compromises (i.e., the optional features that really need to be mandatory). * Dave Perkins said that XMLCONF is very different because there is an explicit asynchronous notification channel which is bound to a session. Additional channels might be added to support distribution of binary software images or for retrieval of statistics. * George says that XMLCONF could be improved by looking more at existing management protocols. * Remember that currently, the main focus of NetConf is configuration. Quite a bit more work is required to turn it into a complete management protocol. * Dave Perkins explains on the white board why getting access to SNMP notifications is hard for management application writers. * Olivier asks whether there is a mechanism to subscribe to certain sets of notifications. Currently, XMLCONF does not have this capability. * Juergen makes a statement that design decisions seem to be made out of feelings rather than being based on hard facts. For example, is BEEP as a transport a good viable choice? Is the home grown RPC layer really better than any of the existing layers? * A lengthy discussion ensues about SOAP vs. XMLCONF RPC and BEEP vs. SSH/TLS and the various implications on the manager/agent side. There is a tension between what the best technology is (e.g., the ongoing BEEP, SOAP, WSDL, et. al. arguments) versus what technologies the operators are currently using. On the one hand, we are a research group. On the other hand, we need to stay relevant. ITEM: Action items * Emmanuel will talk to Frank to get comments integrated into the revised SMIng documents * Frank will contact COPS-PR mapping authors to see how they can update this document * Torsten's and Frank's slides will be made available on the NMRG web site * Aiko will finish the minutes of the last NMRG meeting this week! * Dave Perkins will explain what a common model for booting is before the IM 2003 NMRG meeting and try to document things in written words * Phil to send his slides to the NMRG * Documentation of compression etc. work (Aiko, Juergen) * John Strassner to produce final minutes from the notes taken ITEM: Possible future NMRG items * Work on the network management vision that some people think is missing * Develop a session based security mechanism that integrates with AAA * Develop a common model for booting * Investigate XMLCONF design decisions and their implications, such as protocol mappings and RPC mechanisms * Map XMLCONF onto SOAP and prove that it does work (or does not work) * Experiment with Web Services for management (IF-MIB done as Web Services), Web Services toolkits, and prototypes that enable comparison of different functionality between web services vs. current management approaches * How to manage IPv6 networks * Management of upcoming technologies (e.g., VPNs) * Disappearing management and increased dependability - reduce the amount of management that is required while increasing the dependability of our networks * Cooperative (peer-to-peer) management rather than hierarchical management The Meeting adjourned. --FCuugMFkClbJLl1L-- Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h5QBIr6V023660 for ; Thu, 26 Jun 2003 13:18:53 +0200 Received: from zeus.cs.utwente.nl (zeus.cs.utwente.nl [130.89.10.12]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with ESMTP id h5QBIoCf005048; Thu, 26 Jun 2003 13:18:50 +0200 (MET DST) Received: from ctit.utwente.nl (utip250 [130.89.12.39]) by zeus.cs.utwente.nl (8.12.9/8.12.9) with ESMTP id h5QBIll2009484; Thu, 26 Jun 2003 13:18:48 +0200 (MEST) Message-ID: <3EFAD699.6040508@ctit.utwente.nl> Date: Thu, 26 Jun 2003 13:18:49 +0200 From: Aiko Pras User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "nmrg@ibr.cs.tu-bs.de" CC: Aiko Pras Content-Type: multipart/mixed; boundary="------------060303020804080402080206" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) X-IBRFilter-SpamReport: -5.4 () TO_ADDRESS_EQ_REAL,USER_AGENT_MOZILLA_UA X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-5.8 required=5.0 tests=USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] Draft minutes of the 11th IRTF-NMRG meeting Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. --------------060303020804080402080206 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear all Attached you'll find the (draft) minutes of the 11th IRTF-NMRG meeting (September 2002, Osnabrueck). Since I'll go on holiday tomorrow, I'll check on the NMRG mailing list after I return if any textual improvements have been proposed. Bye Aiko --------------060303020804080402080206 Content-Type: text/plain; name="Draft_minutes_11th_NMRG_meeting.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="Draft_minutes_11th_NMRG_meeting.txt" 11th NMRG meeting Schlo� Osnabr�ck, Germany September 15-16, 2002 List of participants: 1. Randy Bush (ATT, USA) IETF Area Director 2. Olivier Festor (Loria, France) 3. Mario Jeckle (Daimler-Chrysler, Germany) W3C Web Service Architecture WG 4. Jean-Philippe Martin-Flatin (CERN, Switzerland) 5. Dave Perkins (Riverstone, USA) 6. Aiko Pras (University of Twente, Netherlands) 7. J�rgen Sch�nw�lder (University of Osnabr�ck, Germany) 8. Phil Shafer (Juniper Networks, USA) 9. Frank Strauss (Technical University of Braunschweig, Germany) 10. Margaret Wasserman (Windriver, USA) 11. Bert Wijnen (Lucent, Netherlands) IETF Area Director 1) Opening ---------- A number of guests were invited for this meeting. To know each other, the meeting started with the roll-call. Minutes: Frank and Juergen agreed to take notes, Aiko agreed to later turn these notes into meeting minutes. (Remark: after the meeting also Margaret gave her notes. Although the meeting minutes are based on Frank, Juergen and Margaret's notes, certain details have been omitted. Since all notes have been distributed over the NMRG mailing-list, readers interested in every detail should take a look at these notes.) Purpose of the meeting: At the last IRTF meeting in Pisa we discussed future directions in NM. At that meeting we agreed to organize a next meeting to discuss the merits of using web-services / XML for NM. In the meantime, the IAB has organized a workshop to discuss future directions for NM. At that workshop it was concluded that we should further investigate the use of XML for management. In addition, a BOF was organized at the Yokohama IETF to discuss the use of XML in device management. The purpose of this meeting is to discuss the advantages of using web-services / XML for management. Agenda: It was agreed to concentrate the first day on web-services, and the second on XML. 2) WEB-SERVICES --------------- Several topics related to web-services based management were discussed. Although we took the freedom to jump from topic to topic, the main conclusions of the discussion are summarized below. 2A) Presentations ---------------- To make the other attendees clear why someone believes that web- services will (not) become important for Internet management, every attendee was requested to give a short presentations. - Juergen: Does not believe in Web-Services in the interface between devices and management applications, because of complexity and performance issues and not really addressing the requirements such as transactions across devices. - Randy: Believes the problem is ill defined and Web-Services is more a technology looking for a problem. Randy thinks that distributed database technology has probably more in common with the real requirements. He also has concerns that UDDI has serious security issues. - Margaret: Margaret talks about layers in management systems and there might be some use of Web-Services at the higher layers. But they seem to be overkill at the management application - device interface. Web- Services might be useful for higher layers (such as service management layers). - Phil: Web-Services is too complex for the device interface. He wants to have a connection oriented, persistence technology. SOAP is considered too complex and has too many options. But in the end, he wants any RPC technology. - Mario: Mario says it was already hard to keep SOAP specifications not growing even faster. Web-Services are intended to bring business applications together and he believes Web-Services are easier to integrate than CORBA, DCE, ... - Bert: Bert is worried about interoperability, especially since XML is so easy to extend. He wants people to experiment first before actually trying to standardize something. He also does not think that Web-Services address the requirements. - Dave: Dave talks about the different viewpoints of mgmt app developers and device implementors. He believes that there should be different schemas for data exchange between management applications and between management applications and devices. In case of communication to the devices, he does not believe in XML and he believes that the schema must be forced (as with MIBs) and not provided individually by the devices (as with WSDL). - Frank: Looking at configurations in an XML document format is a big win. An XML advantage is that there are many tools readily available, you just have to use them. It is easy to plug things together while, with SNMP, many things have to be written from scratch. Also need to move to an RPC style interaction mechanism. - Olivier: Web-Services can play a role between management platforms and within management platforms. Representing configuration as XML documents is really helpful. Representation of meta data etc. is all available with XML. Believes that representation of additional semantic (e.g. relationships via RDF) is a big step forward. Olivier believes security is still missing. - Jean-Philippe (J.P.): SNMP is good for monitoring resource constraints devices. Today we need to do more. Open management exists only for monitoring resource constraints devices. For configuration J.P. proposes to use XML. Within management systems and between management systems, you are in a distributed system and you can use CORBA, Web-Services, ... (1) Web-Service standardization is faster then CORBA standardization (2) Better separation of protocol and data ... (3) Web-Services is trendy and should be used in/between management systems - Aiko: SNMP will not be further developed substantially. Distinction between networks and applications starts to disappear. SNMP is not going to solve the bigger problems (e.g., configuration management, higher-level service management, integration of network-, service-, and desktop-management). Web-Services is being implemented and will be available in every system and application. Network management or monitoring is not different than any other distributed applications. Web-Services will be universally available and easy to use. 2B) Scenarios ------------- A number of scenarios were identified in which web-services could play a role. To guide that discussion, the following picture was drawn: (--) ^ (DB)--- / \ NMS System (--) +---+ (High-level transactions) / \ / \ +---+ +---+ | | | | EMS System +---+ +---+ (Vendor-specific translation) | / \ | / \ +--+ +--+ +--+ | | | | | | Elements +--+ +--+ +--+ The picture allows to identify multiple layers of management: 1. Management of individual Elements: - Monitoring - Data collection (via polling or push model) - Exception Reporting - Fault management - Configuration - Initial Configuration - Modification - Northbound reporting (to higher layer managers) 2. Management of multiple Elements 3. Communication between (EMS/NMS) Managers 4. Integration with internal infrastructure: 5. Integration with external infrastructure: There was agreement that web-services will particularly be useful at the higher layers of the picture. There was disagreement whether web- services will also be useful for element management. We agreed that, although web-services might be reasonable for 4/5, these scenarios are outside the scope of this meeting. 2C) Key technologies for web-services ------------------------------------- With the help of Mario the following conclusions were drawn: SOAP - MUST UDDI - MAY sometimes be useful WSDL - SHOULD (closely related to XML Schema) WS Architecture - we do not know that this time XML RPC - NOT (is an alternative, and will be discussed tomorrow) XML Schema - SHOULD (closely related to WSDL) LDAP - NO (implementation detail) HTTP - Not necessarily (SOAP is transport independent, we need SOME transport protocol) DBMS - NO It is noted that there is a political issue with UDDI. MS and IBM have handed over UDDI to Oasis, so W3C is not doing its own work on discovery. The W3C architecture group will still need to reference a discovery mechanism. 2D) Granularity of WSDL primitives (operations) ----------------------------------------------- The following basic approaches were identified: 1. Coarse granularity, defining very simple WSDL methods. Examples of such methods are: Get and Set (WBEM of the DMTF takes this approach). The management data should be defined in XML schema. 2. Medium granularity, in which we have more extensive, but still a generic set of methods. Examples of such methods are: GetTable, Add, Delete, Action (a la CMIP), GetConfig, SetConfig (AKA dump & restore). Also in this case management data should be defined in XML schema. 3. Fine granularity, in which we define object-specific methods. Examples of such methods are: GetRoutingTable, GetIfInOctets. In this case there is no need for additional XML schema. One issue that influences the choice between these approaches, is the possibility to support vendor extensions and interoperability. With (1) and (2), vendor extensions can be accomplished in the XML schema. With (3) vendor extensions require extensibility features in the WSDL definitions. The question was raised how much interoperability we want to encourage. There is a trade-off between flexibility and interoperability. With XML schemas, extensibility is possible since you can add new stuff in new namespaces and you can mix several namespaces within an XML document. There was some feeling that we should allow extensibility of the data model (1 and 2), but not extensibility of the commands/operations (3). But even in case of approach 1 and 2, it may be complicated to extend the XML schemas underlying the WSDLs. For example, how to deal with major changes? What about versioning? Although versioning is part of the architecture, it will not happen to be in WSDL before 1.3. 2E) Transactions ---------------- For configuration management it is important to have support for transactions. The question was therefore raised whether WSDL includes support for transactions. Mario answered that that is not the case; transaction handling (called orchestration in W3C-speak) is defined as part of some proprietary protocols. Originally IBM defined WSFL, and MS XLANG. IBM and MS recently joined both proposals: BPEL. Within OASIS, there is a proposal for transaction support. Also W3C is thinking about establishing a working group on transactions. 2F) Instance data ----------------- In case of course granularity, the operations are defined in the WSDL file and the (management) information is defined in XML schema. Olivier brings up the issue of selecting specific information within an XML document, for example to isolate information related to a specific object instance (such as row 3 of the ifTable). One way of doing this would be to use XPATH (XQuery may also be possible). With XPATH, indexed information can be accessed using predicates. If, for example, we have: 1 ... 3 ... 4 ... The XPATH expression: system/interfaces/ifTable[row=3] returns the attribute values of that row (if we want its definition, we can use @row). XPATH also allows to specify multiple elements in the predicate part. 2G) Performance --------------- Since XML is verbose, web-services may require a non-trivial amount of bandwidth. If compression is used, bandwidth consumption can be reduced at the price of CPU cycles. Mario informs us of a study that shows that SOAP (with compression) performs well, provided the document is not too small (compression factors of 1:8 till 1:20 seem possible). Compared to SNMP, Dave is willing to accept a small factor of bandwidth increase (e.g. 2) but not a magnitude (e.g. 10) or more. Frank regards increased bandwidth and delay for infrequent operations to be tolerable, but not for small frequent requests/responses. Randy points out that, especially in case of out-of-band networks for management, bandwidth may remain to be a bottleneck. Compared to SNMP (over UDP), web-services have the advantage that more data can be packed into a single message. As a result, less interactions may be required, reducing the total time to retrieve bulk data. Although this may be an advantage in many cases, configuration management, which is one of the main topics to be solved, is usually not time-critical. Compared to SNMP, all attendees expect that web-services will put a stronger load on the system (unfortunately there are no studies that compare both approaches). In case of manager platforms, it may still be cheaper, however, to increase the processing power of that platform, compared to the costs of increasing bandwidth. In case of network elements, it may be expensive or even impossible to upgrade processors. The meeting felt that CPU consumption will remain to be an important issue. Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h5OGaEWt002548 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 24 Jun 2003 18:36:14 +0200 Received: from hansa.ibr.cs.tu-bs.de (strauss@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h5OGaESk013204; Tue, 24 Jun 2003 18:36:14 +0200 Received: (from strauss@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) id h5OGaEqh013201; Tue, 24 Jun 2003 18:36:14 +0200 From: Frank Strauss To: j.schoenwaelder@iu-bremen.de Cc: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] upcoming nmrg meeting References: <20030624125702.GB3442@iu-bremen.de> Date: 24 Jun 2003 18:36:14 +0200 In-Reply-To: <20030624125702.GB3442@iu-bremen.de> Message-ID: Lines: 9 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IBRFilter-SpamReport: -16.3 () IN_REP_TO,REFERENCES,USER_AGENT_GNUS_UA X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-16.2 required=5.0 tests=IN_REP_TO,REFERENCES,USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Hi! Juergen> What I need next is information about who is going to attend Juergen> and if you have any preferred topics to discuss. Please drop Juergen> me note, also if you are yet undecided. I am going to attend the meeting. -frank Received: from ctron-dnm.enterasys.com (ctron-dnm.enterasys.com [12.25.1.120]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h5OG22Ws026403 for ; Tue, 24 Jun 2003 18:02:02 +0200 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id MAA27092 for ; Tue, 24 Jun 2003 12:15:51 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma026212; Tue, 24 Jun 03 12:13:16 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2 with InterScan Messaging Security Suite; Tue, 24 Jun 2003 12:00:38 -0400 Received: from nhrocmbx1 ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 24 Jun 2003 12:00:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nmrg] upcoming nmrg meeting Date: Tue, 24 Jun 2003 12:00:38 -0400 Message-ID: <6D745637A7E0F94DA070743C55CDA9BAB8DC33@NHROCMBX1.ets.enterasys.com> Thread-Topic: [nmrg] upcoming nmrg meeting Thread-Index: AcM6UYhBSAZU7okPRiWUHrXtwixnSwAGC/WA From: "Harrington, David" To: , X-OriginalArrivalTime: 24 Jun 2003 16:00:38.0533 (UTC) FILETIME=[C149EB50:01C33A69] X-IBRFilter-SpamReport: -3.3 () QUOTED_EMAIL_TEXT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by agitator.ibr.cs.tu-bs.de id h5OG22Ws026403 X-Spam-Status: No, hits=-3.2 required=5.0 tests=QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: I plan to attend dbh > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Tuesday, June 24, 2003 8:57 AM > To: nmrg@ibr.cs.tu-bs.de > Subject: [nmrg] upcoming nmrg meeting > > > I am organizing the next NMRG meeting to be held on > Friday/Saturday after > the IETF meeting in Vienna as discussed before on this list. Our local > host is the Forschungszentrum Telekommunikation Wien (FTW) [a rough > translation would be something like telecommunication research center > Vienna]. I have asked our host to reserve a room for us from > 9:00-17:00 > on both days and I am sure they will do a good job for us. > > What I need next is information about who is going to attend and if > you have any preferred topics to discuss. Please drop me note, also > if you are yet undecided. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > -- > !! This message is brought to you via the `nmrg' mailing list. > !! Please do not reply to this message to unsubscribe. To > unsubscribe or adjust > !! your settings, send a mail message to > > !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg. > Received: from wanderer.hardakers.net (adsl-66-127-127-227.dsl.scrm01.pacbell.net [66.127.127.227]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h5OFW7M5018375 for ; Tue, 24 Jun 2003 17:32:07 +0200 Received: by wanderer.hardakers.net (Postfix, from userid 274) id 59F675729B; Tue, 24 Jun 2003 08:32:00 -0700 (PDT) To: nmrg@ibr.cs.tu-bs.de References: <20030624125702.GB3442@iu-bremen.de> 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: Sparta Date: Tue, 24 Jun 2003 08:32:00 -0700 In-Reply-To: <20030624125702.GB3442@iu-bremen.de> (Juergen Schoenwaelder's message of "Tue, 24 Jun 2003 14:57:02 +0200") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.5 (brussels sprouts, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IBRFilter-SpamReport: -16.3 () IN_REP_TO,REFERENCES,USER_AGENT_GNUS_UA X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-16.2 required=5.0 tests=IN_REP_TO,REFERENCES,USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] Re: nmrgupcoming nmrg meeting Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: >>>>> On Tue, 24 Jun 2003 14:57:02 +0200, Juergen Schoenwaelder said: Juergen> What I need next is information about who is going to attend Juergen> and if you have any preferred topics to discuss. Please drop Juergen> me note, also if you are yet undecided. I'll be attending for once. -- Wes Hardaker Sparta Received: from merkur.iu-bremen.de (merkur.iu-bremen.de [212.201.44.27]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h5OCuD4e032657 for ; Tue, 24 Jun 2003 14:56:13 +0200 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 33F131A8B7; Tue, 24 Jun 2003 14:56:13 +0200 (CEST) Received: from iu-bremen.de (Schoenwaelder.iuhb02.iu-bremen.de [212.201.49.166]) by merkur.iu-bremen.de (Postfix) with SMTP id 80F0617D64; Tue, 24 Jun 2003 14:56:12 +0200 (CEST) Received: (nullmailer pid 4205 invoked by uid 1000); Tue, 24 Jun 2003 12:57:02 -0000 Date: Tue, 24 Jun 2003 14:57:02 +0200 From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de Message-ID: <20030624125702.GB3442@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: nmrg@ibr.cs.tu-bs.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-IBRFilter-SpamReport: -6.4 () USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-6.4 required=5.0 tests=USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] upcoming nmrg meeting Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: I am organizing the next NMRG meeting to be held on Friday/Saturday after the IETF meeting in Vienna as discussed before on this list. Our local host is the Forschungszentrum Telekommunikation Wien (FTW) [a rough translation would be something like telecommunication research center Vienna]. I have asked our host to reserve a room for us from 9:00-17:00 on both days and I am sure they will do a good job for us. What I need next is information about who is going to attend and if you have any preferred topics to discuss. Please drop me note, also if you are yet undecided. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from wanderer.hardakers.net (adsl-66-127-127-227.dsl.scrm01.pacbell.net [66.127.127.227]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h5I0ErgA023022 for ; Wed, 18 Jun 2003 02:14:54 +0200 Received: by wanderer.hardakers.net (Postfix, from userid 274) id 867F857299; Tue, 17 Jun 2003 17:14:47 -0700 (PDT) To: "Harrington, David" Cc: "David T. Perkins" , References: <6D745637A7E0F94DA070743C55CDA9BA489570@NHROCMBX1.ets.enterasys.com> 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 Date: Tue, 17 Jun 2003 17:14:47 -0700 In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA489570@NHROCMBX1.ets.enterasys.com> (David Harrington's message of "Tue, 17 Jun 2003 13:23:29 -0400") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.5 (brussels sprouts, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IBRFilter-SpamReport: -16.3 () IN_REP_TO,REFERENCES,USER_AGENT_GNUS_UA X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-16.2 required=5.0 tests=IN_REP_TO,REFERENCES,USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] Re: nmrgSecurity interaction? Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: >>>>> On Tue, 17 Jun 2003 13:23:29 -0400, "Harrington, David" said: [sentences edited out of order on purpose] David> Even with an Inform, all tyhe receiver must do is acknowledge David> receipt of the message. Yes, but that would be a pretty useless notification receiver ;-). The point being is that a functional notification receiver will act on the incoming notification (if nothing else, but to log it. Possibly do more like send an email or pager alert or run some program or ...). When you start doing things like that, authorization security becomes critical. David> The authorization model at the receiver is simple - the David> receiver is not required to do anything with the data. This, IMHO, is what is broken from a security perspective. If a notification receiver is not supposed to do any authorization security checks then it must assume that whoever is sending it must be doing so securely. IE, notification receivers are not even supposed to make sure that the incoming request is at least authenticated? I hope you never get your notification receiver pegged with enough unauthenticated notifications that you have to turn your pager off for the day due to the DOS attack via unauthenticated requests. (note that a primary reason for doing a DOS attack even for a log would be to hide really important notifications in the middle of all the illegitimate notifications). -- Wes Hardaker Network Associates Laboratories Received: from postman.bayarea.net (postman.bayarea.net [205.219.84.13]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h5HIGBgA028147 for ; Tue, 17 Jun 2003 20:16:12 +0200 Received: from dperkins-nb2.dsperkins.com (shell4.BAYAREA.NET [209.128.82.1]) by postman.bayarea.net (8.12.8p1/8.12.8) with ESMTP id h5HIEibf029280; Tue, 17 Jun 2003 11:14:44 -0700 (PDT) Message-Id: <5.2.0.9.2.20030617104827.03896070@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 17 Jun 2003 11:08:35 -0700 To: "Harrington, David" , "Wes Hardaker" From: "David T. Perkins" Subject: RE: [nmrg] Re: nmrgSecurity interaction? Cc: In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA489570@NHROCMBX1.ets.enter asys.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_13405746==.ALT" X-IBRFilter-SpamReport: -8.5 () EMAIL_ATTRIBUTION,HTML_10_20,HTML_FONT_COLOR_BLUE,HTML_MESSAGE,IN_REP_TO,MAILTO_LINK X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-8.6 required=5.0 tests=EMAIL_ATTRIBUTION,HTML_10_20,HTML_FONT_COLOR_BLUE, HTML_MESSAGE,IN_REP_TO autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: --=====================_13405746==.ALT Content-Type: text/plain; charset="us-ascii" HI, David - I know the authorization model in SNMPv3. It's not whether or not one can code it. It's whether or not after applying (using it) on the agent that your management application can "work". It seemed like rule based applications might need "more information" to be able to run through the rules to get meaningful results. It's a question of how much info do you need on the incoming side of the inference/correlation engine, and then whether or not you need authorization rules on the output side of the inference/correlation engine. At 01:23 PM 6/17/2003 -0400, Harrington, David wrote: >Hi, > >There is a standardized authorization model for notifications in SNMPv3. > >Authorization should be defined relative to the data sensitivity, and the data is associated with the agent, not the manager. If the manager wants to add supplemental authorization/filtering rules it can, but the agent should know which notifications to send, what varbinds should be included (and not send the notification if the notification varbinds are not allowed), who the notifications go to, and where to send them. > >A notification with "out of view" varbinds does not get sent. See RFC3413, section 3.3 (2). > >The authorization model at the receiver is simple - the receiver is not required to do anything with the data. Even with an Inform, all tyhe receiver must do is acknowledge receipt of the message. > >dbh >-----Original Message----- >From: Wes Hardaker [mailto:wes@hardakers.net] >Sent: Monday, June 16, 2003 5:05 PM >To: David T. Perkins >Cc: nmrg@ibr.cs.tu-bs.de >Subject: [nmrg] Re: nmrgSecurity interaction? > >>>>>> On Mon, 16 Jun 2003 13:41:03 -0700, "David T. Perkins" said: > >David> Can a polled and an exception-based management approach use the >David> same authorization implementation? > >David> It sort of seems like the exception-based management approach must >David> have all of the authorization rules in the management platform, >David> and apply them after processing the event reports before the >David> results are provided to the user. > >Events are often different from requests, so they're hard to compare. >I've often been disappointed that no one has made a standardized >authorization model for SNMP notifications (especially when actions >are to be triggered by in incoming notification). > >They likely can use similar models (IE, similar filtering-concepts can >be used), but I'd suspect that they'd have to be rather different >otherwise. > >Consider a SNMP notification. If you remove the varbinds that are >"out-of-view" you may end up with an entirely different message than >was intended to be received. In fact, the removal of that information >may actually make the decision based on it do something really bad. > >Also, event-based management would definitely need to make >authorization decisions based on where it came from ("what address or >network"), not just who sent it ("dave"). You'd want different >actions to be triggered depending on where something came from. You >certainly wouldn't want a less-secure device to trigger an action that >affected the more secure devices. > >-- >Wes Hardaker >Network Associates Laboratories Regards, /david t. perkins --=====================_13405746==.ALT Content-Type: text/html; charset="us-ascii" HI,

David - I know the authorization model in SNMPv3. It's not whether or
not one can code it. It's whether or not after applying (using it)
on the agent that your management application can "work". It seemed
like rule based applications might need "more information" to be
able to run through the rules to get meaningful results. It's a
question of how much info do you need on the incoming side
of the inference/correlation engine, and then whether or not
you need authorization rules on the output side of the
inference/correlation engine.

At 01:23 PM 6/17/2003 -0400, Harrington, David wrote:

Hi,

There is a standardized authorization model for notifications in SNMPv3.

Authorization should be defined relative to the data sensitivity, and the data is associated with the agent, not the manager. If the manager wants to add supplemental authorization/filtering rules it can, but the agent should know which notifications to send, what varbinds should be included (and not send the notification if the notification varbinds are not allowed), who the notifications go to, and where to send them.

A notification with "out of view" varbinds does not get sent. See RFC3413, section 3.3 (2).

The authorization model at the receiver is simple - the receiver is not required to do anything with the data. Even with an Inform, all tyhe receiver must do is acknowledge receipt of the message.

dbh

-----Original Message-----

From: Wes Hardaker [mailto:wes@hardakers.net]

Sent: Monday, June 16, 2003 5:05 PM

To: David T. Perkins

Cc: nmrg@ibr.cs.tu-bs.de

Subject: [nmrg] Re: nmrgSecurity interaction?

>>>>> On Mon, 16 Jun 2003 13:41:03 -0700, "David T. Perkins" <dperkins@dsperkins.com> said:

David> Can a polled and an exception-based management approach use the

David> same authorization implementation?

David> It sort of seems like the exception-based management approach must

David> have all of the authorization rules in the management platform,

David> and apply them after processing the event reports before the

David> results are provided to the user.

Events are often different from requests, so they're hard to compare.

I've often been disappointed that no one has made a standardized

authorization model for SNMP notifications (especially when actions

are to be triggered by in incoming notification).

They likely can use similar models (IE, similar filtering-concepts can

be used), but I'd suspect that they'd have to be rather different

otherwise.

Consider a SNMP notification. If you remove the varbinds that are

"out-of-view" you may end up with an entirely different message than

was intended to be received. In fact, the removal of that information

may actually make the decision based on it do something really bad.

Also, event-based management would definitely need to make

authorization decisions based on where it came from ("what address or

network"), not just who sent it ("dave"). You'd want different

actions to be triggered depending on where something came from. You

certainly wouldn't want a less-secure device to trigger an action that

affected the more secure devices.

--

Wes Hardaker

Network Associates Laboratories

Regards,
/david t. perkins --=====================_13405746==.ALT-- Received: from ctron-dnm.enterasys.com (ctron-dnm.enterasys.com [12.25.1.120]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h5HHOpgA019270 for ; Tue, 17 Jun 2003 19:24:52 +0200 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id NAA06744 for ; Tue, 17 Jun 2003 13:38:34 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma005907; Tue, 17 Jun 03 13:36:04 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2 with InterScan Messaging Security Suite; Tue, 17 Jun 2003 13:23:30 -0400 Received: from nhrocmbx1 ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 17 Jun 2003 13:23:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C334F5.2B69A1F8" Subject: RE: [nmrg] Re: nmrgSecurity interaction? Date: Tue, 17 Jun 2003 13:23:29 -0400 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA489570@NHROCMBX1.ets.enterasys.com> Thread-Topic: [nmrg] Re: nmrgSecurity interaction? Thread-Index: AcM0Szks64xjAiUPQ0mfAitK/XvItwABzK/g From: "Harrington, David" To: "Wes Hardaker" , "David T. Perkins" Cc: X-OriginalArrivalTime: 17 Jun 2003 17:23:30.0065 (UTC) FILETIME=[2BA94010:01C334F5] X-IBRFilter-SpamReport: 1.6 (*) HTML_20_30,HTML_FONT_COLOR_BLUE,HTML_MESSAGE X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=1.3 required=5.0 tests=HTML_20_30,HTML_FONT_COLOR_BLUE,HTML_MESSAGE version=2.53 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------_=_NextPart_001_01C334F5.2B69A1F8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 There is a standardized authorization model for notifications in SNMPv3. = =20 Authorization should be defined relative to the data sensitivity, and = the data is associated with the agent, not the manager. If the manager = wants to add supplemental authorization/filtering rules it can, but the = agent should know which notifications to send, what varbinds should be = included (and not send the notification if the notification varbinds are = not allowed), who the notifications go to, and where to send them.=20 =20 A notification with "out of view" varbinds does not get sent. See = RFC3413, section 3.3 (2). =20 The authorization model at the receiver is simple - the receiver is not = required to do anything with the data. Even with an Inform, all tyhe = receiver must do is acknowledge receipt of the message. =20 dbh -----Original Message----- From: Wes Hardaker [mailto:wes@hardakers.net] Sent: Monday, June 16, 2003 5:05 PM To: David T. Perkins Cc: nmrg@ibr.cs.tu-bs.de Subject: [nmrg] Re: nmrgSecurity interaction? >>>>> On Mon, 16 Jun 2003 13:41:03 -0700, "David T. Perkins" = said: David> Can a polled and an exception-based management approach use the David> same authorization implementation? David> It sort of seems like the exception-based management approach = must David> have all of the authorization rules in the management platform, David> and apply them after processing the event reports before the David> results are provided to the user. Events are often different from requests, so they're hard to compare. I've often been disappointed that no one has made a standardized authorization model for SNMP notifications (especially when actions are to be triggered by in incoming notification). They likely can use similar models (IE, similar filtering-concepts can be used), but I'd suspect that they'd have to be rather different otherwise. Consider a SNMP notification. If you remove the varbinds that are "out-of-view" you may end up with an entirely different message than was intended to be received. In fact, the removal of that information may actually make the decision based on it do something really bad. Also, event-based management would definitely need to make authorization decisions based on where it came from ("what address or network"), not just who sent it ("dave"). You'd want different actions to be triggered depending on where something came from. You certainly wouldn't want a less-secure device to trigger an action that affected the more secure devices. -- Wes Hardaker Network Associates Laboratories -- !! This message is brought to you via the `nmrg' mailing list. !! Please do not reply to this message to unsubscribe. To unsubscribe or = adjust !! your settings, send a mail message to !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg. ------_=_NextPart_001_01C334F5.2B69A1F8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [nmrg] Re: nmrgSecurity interaction?

Hi,

There=20 is a standardized authorization model for notifications in SNMPv3.=20

Authorization should be defined relative to the data = sensitivity, and the=20 data is associated with the agent, not the manager. If the manager wants = to add=20 supplemental authorization/filtering rules it can, but the agent should = know=20 which notifications to send, what varbinds should be included (and not = send the=20 notification if the notification varbinds are not allowed), who the=20 notifications go to, and where to send = them.

A notification with "out of view" varbinds does not get = sent. See=20 RFC3413, section 3.3 (2).

The=20 authorization model at the receiver is simple - the receiver is not = required to=20 do anything with the data. Even with an Inform, all tyhe receiver must = do is=20 acknowledge receipt of the message.

dbh

-----Original Message-----
From: Wes Hardaker=20 [mailto:wes@hardakers.net]
Sent: Monday, June 16, 2003 5:05=20 PM
To: David T. Perkins
Cc:=20 nmrg@ibr.cs.tu-bs.de
Subject: [nmrg] Re: nmrgSecurity=20 interaction?

>>>>> On Mon, 16 Jun 2003 13:41:03 = -0700,=20 "David T. Perkins" <dperkins@dsperkins.com> = said:

David> Can a=20 polled and an exception-based management approach use the
David> = same=20 authorization implementation?

David> It sort of seems like = the=20 exception-based management approach must
David> have all of the=20 authorization rules in the management platform,
David> and apply = them=20 after processing the event reports before the
David> results are = provided to the user.

Events are often different from requests, = so=20 they're hard to compare.
I've often been disappointed that no one = has made=20 a standardized
authorization model for SNMP notifications = (especially when=20 actions
are to be triggered by in incoming = notification).

They=20 likely can use similar models (IE, similar filtering-concepts = can
be used),=20 but I'd suspect that they'd have to be rather=20 different
otherwise.

Consider a SNMP notification. If = you=20 remove the varbinds that are
"out-of-view" you may end up with an = entirely=20 different message than
was intended to be received. In fact, = the=20 removal of that information
may actually make the decision based on = it do=20 something really bad.

Also, event-based management would = definitely=20 need to make
authorization decisions based on where it came from = ("what=20 address or
network"), not just who sent it ("dave"). You'd = want=20 different
actions to be triggered depending on where something came = from. You
certainly wouldn't want a less-secure device to = trigger an=20 action that
affected the more secure devices.

--
Wes=20 Hardaker
Network Associates Laboratories
--
!! This message = is=20 brought to you via the `nmrg' mailing list.
!! Please do not reply = to this=20 message to unsubscribe. To unsubscribe or adjust
!! your settings, = send a=20 mail message to <nmrg-request@ibr.cs.tu-bs.de>
!! or look at = https://www.ib= r.cs.tu-bs.de/mailman/listinfo/nmrg.

------_=_NextPart_001_01C334F5.2B69A1F8-- Received: from wanderer.hardakers.net (adsl-66-127-127-227.dsl.scrm01.pacbell.net [66.127.127.227]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h5GL4ggA002375 for ; Mon, 16 Jun 2003 23:04:42 +0200 Received: by wanderer.hardakers.net (Postfix, from userid 274) id 6523E57299; Mon, 16 Jun 2003 14:04:31 -0700 (PDT) To: "David T. Perkins" Cc: nmrg@ibr.cs.tu-bs.de References: <5.2.0.9.2.20030616133600.05ff8950@127.0.0.1> 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 Date: Mon, 16 Jun 2003 14:04:31 -0700 In-Reply-To: <5.2.0.9.2.20030616133600.05ff8950@127.0.0.1> (David T. Perkins's message of "Mon, 16 Jun 2003 13:41:03 -0700") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.5 (brussels sprouts, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IBRFilter-SpamReport: -16.3 () IN_REP_TO,REFERENCES,USER_AGENT_GNUS_UA X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-16.2 required=5.0 tests=IN_REP_TO,REFERENCES,USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] Re: nmrgSecurity interaction? Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: >>>>> On Mon, 16 Jun 2003 13:41:03 -0700, "David T. Perkins" said: David> Can a polled and an exception-based management approach use the David> same authorization implementation? David> It sort of seems like the exception-based management approach must David> have all of the authorization rules in the management platform, David> and apply them after processing the event reports before the David> results are provided to the user. Events are often different from requests, so they're hard to compare. I've often been disappointed that no one has made a standardized authorization model for SNMP notifications (especially when actions are to be triggered by in incoming notification). They likely can use similar models (IE, similar filtering-concepts can be used), but I'd suspect that they'd have to be rather different otherwise. Consider a SNMP notification. If you remove the varbinds that are "out-of-view" you may end up with an entirely different message than was intended to be received. In fact, the removal of that information may actually make the decision based on it do something really bad. Also, event-based management would definitely need to make authorization decisions based on where it came from ("what address or network"), not just who sent it ("dave"). You'd want different actions to be triggered depending on where something came from. You certainly wouldn't want a less-secure device to trigger an action that affected the more secure devices. -- Wes Hardaker Network Associates Laboratories Received: from postman.bayarea.net (postman.bayarea.net [205.219.84.13]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h5GKpZgA032641 for ; Mon, 16 Jun 2003 22:51:35 +0200 Received: from dperkins-nb2.dsperkins.com (shell4.BAYAREA.NET [209.128.82.1]) by postman.bayarea.net (8.12.8p1/8.12.8) with ESMTP id h5GKpVbh011752 for ; Mon, 16 Jun 2003 13:51:34 -0700 (PDT) Message-Id: <5.2.0.9.2.20030616133600.05ff8950@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 16 Jun 2003 13:41:03 -0700 To: nmrg@ibr.cs.tu-bs.de From: "David T. Perkins" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] Security interaction? Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: HI, Here is an interesting question.... Can a polled and an exception-based management approach use the same authorization implementation? It sort of seems like the exception-based management approach must have all of the authorization rules in the management platform, and apply them after processing the event reports before the results are provided to the user. Has anyone thought about this? Regards, /david t. perkins Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h53A00oS007499 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 3 Jun 2003 12:00:00 +0200 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h53A00ru011471; Tue, 3 Jun 2003 12:00:00 +0200 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) id h53A00HC011468; Tue, 3 Jun 2003 12:00:00 +0200 Date: Tue, 3 Jun 2003 12:00:00 +0200 Message-Id: <200306031000.h53A00HC011468@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder CC: mrw@windriver.com To: nmrg@ibr.cs.tu-bs.de In-reply-to: <5.1.0.14.2.20030528160509.0448cdf8@mail.windriver.com> (message from Margaret Wasserman on Wed, 28 May 2003 16:05:57 -0400) Subject: Re: [nmrg] future meetings References: <5.1.0.14.2.20030528160509.0448cdf8@mail.windriver.com> X-IBRFilter-SpamReport: -9.9 () IN_REP_TO,REFERENCES X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-9.9 required=5.0 tests=IN_REP_TO,REFERENCES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: >>>>> Margaret Wasserman writes: Margaret> Did you make any decision about this? Looking at the feedback I received on this list and some private messages, I conclude the following: (a) We will not meet next to LANOMS 2003 in Brazil. Even though we have a nice offer to host such a meeting, I realize that the number of people who are actually able to go there is just too small. (b) For similar reasons, we will not meet next to APNOMS 2003 in Fukuoka, Japan. (c) I will organize a meeting next to the IETF in Vienna. I propose that we meet Friday/Saturday after the IETF. Depeding on the final IETF agenda, we might start on Friday morning or Friday at lunch time. (I prefer to start in the morning unless there is some serious conflict with an IETF WG meeting such as netconf.) (d) There seems to be interest to also meet next to DSOM in October. NEC offered to host such a meeting which will make things rather simple to organize. Since there is also the NOMS 2004 TPC meeting next to DSOM, I have no clear idea yet where to put an NMRG meeting slot. But since DSOM is still some time away, I sill just collect more input on from you in Vienna and electronically. So, bottom line: I plan to organize a meeting on Friday/Saturday after the IETF in Vienna. If some of you have ideas who might be interested to host such a meeting in Vienna, please let me know. ;-) /js -- Juergen Schoenwaelder International University Bremen Phone: +49 421 200 3587 P.O. Box 750 561, 28725 Bremen, Germany Fax: +49 421 200 3103