From daemon Mon Nov 17 17:40:24 1997 Delivery-Date: Mon, 17 Nov 1997 17:50:49 -0500 Return-Path: daemon Received: (from daemon@localhost) by ietf.org (8.8.7/8.8.7a) id RAA22900 for ietf-outbound.10@ietf.org; Mon, 17 Nov 1997 17:39:46 -0500 (EST) Received: from bbnplanet.com (mail.bbnplanet.com [198.114.157.21]) by ietf.org (8.8.7/8.8.7a) with SMTP id RAA22757; Mon, 17 Nov 1997 17:34:26 -0500 (EST) Received: from hlin.bbnplanet.com by mail.bbnplanet.com id aa15686; 17 Nov 97 17:30 EST Message-Id: <3.0.3.32.19971117172131.00726694@pobox3.bbn.com> X-Sender: hlin@pobox3.bbn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 17 Nov 1997 17:21:31 -0500 To: fred@cisco.com, Harald Alvestrand , Keith Moore , jcurran@bbn.com, ietf@ietf.org, solo@bbn.com, ietf-web@ietf.org From: Herbert Lin Subject: Request for IETF Work Group Meeting Cc: cclingen@tis.com, grall@tis.com, marvind@tis.com, ishikawa@tis.com, mwittig@mail.cybg.com, lbrown@mail.cybg.com, anadkarni@raptor.com, rmoorman@raptor.com, dlancaster@raptor.com, Thomas.Oeser@mch.sni.de, nir@checkpoint.com, dorit@checkpoint.com, poornima@us.checkpoint.com, tari@us.checkpoint.com, udi@checkpoint.com, hlin@bbnplanet.com, hding@bbnplanet.com, sseltser@bbnplanet.com, jbrooks@bbn.com, Jack Danahy , laube@bbnplanet.com, dchouinard@ideal.jf.intel.com, eff@checkpoint.com, jjones@tis.com, fred@cisco.com, Harald Alvestrand , Keith Moore , jcurran@bbn.com, solo@bbn.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_879823291==_" --=====================_879823291==_ Content-Type: text/plain; charset="us-ascii" Fred, Harald, Keith, John, and Dave, I am writing this request on the behalf of industry leading firewall vendors (Check Point, TIS, CyberGuard, Raptor, Intel, SNI)and managed security service provides (GTE/BBN) for your approval of a new IETF Working Group and its meeting in the 40th IETF Meeting in Washington DC. We had met together in the 39th IETF meeting in Munich and started our BOF session. Since then, we also have met 5 times on the teleconference or face-to-face in our private meetings. The attached documents are the results of our meetings: 1. the Firewall MIB Working Group chater document 2. the Firewall MIB RFC: draft-ietf-fireall-mib-19.txt Please approve our application and help us set up an official place under the Application Areas in the IETF. Thank you for your help. Best Regards, Herbert Lin --=====================_879823291==_ Content-Type: application/msword; charset="us-ascii" Content-Disposition: attachment; filename="Firewall MIB Charter.doc" {\rtf1\ansi \deff4\deflang1033{\fonttbl{\f1\froman\fcharset2\fprq2 Symbol;}{\f4\froman\fcharset0\fprq2 Times New Roman;}{\f11\fmodern\fcharset0\fprq1 Courier New;}}{\colortbl;\red0\green0\blue0;\red0\green0\blue255; \red0\green255\blue255;\red0\green255\blue0;\red255\green0\blue255;\red255\green0\blue0;\red255\green255\blue0;\red255\green255\blue255;\red0\green0\blue128;\red0\green128\blue128;\red0\green128\blue0;\red128\green0\blue128;\red128\green0\blue0; \red128\green128\blue0;\red128\green128\blue128;\red192\green192\blue192;}{\stylesheet{\widctlpar \f4\fs20 \snext0 Normal;}{\*\cs10 \additive Default Paragraph Font;}{\s15\sb100\sa100\keepn\nowidctlpar \b\f4\fs48\kerning36 \sbasedon0\snext0 H1;}{ \s16\sb100\sa100\keepn\nowidctlpar \b\f4\fs36 \sbasedon0\snext0 H2;}{\*\cs17 \additive\ul\cf2 \sbasedon10 Hyperlink;}{\*\cs18 \additive\ul\cf12 \sbasedon10 FollowedHyperlink;}}{\info{\title }{\author .}{\operator .}{\creatim\yr1997\mo8\dy12\hr7\min49} {\revtim\yr1997\mo11\dy17\hr16\min45}{\printim\yr1997\mo8\dy13\hr17\min9}{\version2}{\edmins2}{\nofpages2}{\nofwords535}{\nofchars3055}{\*\company CyberGuard Corporation}{\vern57443}}\widowctrl\ftnbj\aenddoc\hyphcaps0\formshade \fet0\sectd \linex0\endnhere {\*\pnseclvl1\pnucrm\pnstart1\pnindent720\pnhang{\pntxta .}}{\*\pnseclvl2\pnucltr\pnstart1\pnindent720\pnhang{\pntxta .}}{\*\pnseclvl3\pndec\pnstart1\pnindent720\pnhang{\pntxta .}}{\*\pnseclvl4\pnlcltr\pnstart1\pnindent720\pnhang {\pntxta )}}{\*\pnseclvl5\pndec\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta )}}{\*\pnseclvl6\pnlcltr\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta )}}{\*\pnseclvl7\pnlcrm\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta )}}{\*\pnseclvl8 \pnlcltr\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta )}}{\*\pnseclvl9\pnlcrm\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta )}}\pard\plain \s15\sb100\sa100\keepn\nowidctlpar \b\f4\fs48\kerning36 {\lang1024 {\*\do\dobxcolumn\dobypara\dodhgt8192 \dpline\dpptx0\dppty0\dpptx9360\dppty1\dpx-1800\dpy486\dpxsize9360\dpysize1\dplinesolid\dplinecor212\dplinecog212\dplinecob212\dplinew35}} \par Firewall MIB (fwmib) \par \pard\plain \widctlpar \f4\fs20 Last Modified: 17-Nov-97 {\b \par }\pard\plain \s16\sb100\sa100\keepn\nowidctlpar \b\f4\fs36 Chair(s):{\fs20 \par Herbert Lin \par }Applications Area Director(s): \par \pard\plain \widctlpar \f4\fs20 {\b Keith Moore \par Harald Alvestrand \par \par }(Note: The actual IETF area which this work group will be part of is TBD) \par \pard\plain \s16\sb100\sa100\keepn\nowidctlpar \b\f4\fs36 Mailing Lists: \par \pard\plain \widctlpar \f4\fs20 General Discussion: send e-mail to hlin@bbn.com to get/add-on the mailing list\line To Subscribe: send e-mail to hlin@bbn.com to get/add-on the mailing list \line Archive: TBS {\b \par }\pard\plain \s16\sb100\sa100\keepn\nowidctlpar \b\f4\fs36 Description of Working Group: \par \pard\plain \widctlpar \f4\fs20 The Firewall MIB Working Group is chartered to define a set of managed objects for the monitoring of firewalls in an IP only network. Specifically, these managed objects will focus on providing information about the security (including traps to report abo ut unusual events), health (including status information such as up, down, or degraded) and performance (including resource utilization) of firewalls. The current scope of this working group is to provide information for the purpose of monitoring firewall activity from an enterprise management console. The purpose of this MIB is not to replicate all firewall audit information e.g. suspicio us activity monitoring entities would probably require audit information which would not be provided as part of this MIB. \par Items expected to be addressed: \par {\pntext\pard\plain\f1\fs20 \'b7\tab}\pard \fi-360\li1080\widctlpar\tx1080{\*\pn \pnlvlblt\pnf1\pnstart1\pnindent360\pnhang{\pntxtb \'b7}}Monitor a variety of information that is visible to a firewall (this includes identifying informatio n to be monitored and addressing the correlation between such information) \par {\pntext\pard\plain\f1\fs20 \'b7\tab}Categorizing information \par {\pntext\pard\plain\f1\fs20 \'b7\tab}Unique style of reporting this information \par {\pntext\pard\plain\f1\fs20 \'b7\tab}Identification of information to be monitored \par {\pntext\pard\plain\f1\fs20 \'b7\tab}Creation of MIB objects that can be used on a variety of firewalls to obtain the information identified \par {\pntext\pard\plain\f1\fs20 \'b7\tab}Identification of traps which carry some of the objects \par {\pntext\pard\plain\f1\fs20 \'b7\tab}Discussion of possible implementation issues for support of the objects defined (i.e., in order to determine whether it is feasible to include the object in the MIB). \par \pard \li1080\widctlpar \par \pard \widctlpar The working group will only concern itself with the specification of MIB objects in the management areas defined above. It will not undertake to define details of implementation such as programming API's for the access to this information. \par \page The activities of the working group include the following steps. \par {\pntext\pard\plain\fs20 1.\tab}\pard \fi-360\li360\widctlpar\tx360{\*\pn \pnlvlbody\pndec\pnstart1\pnindent360\pnhang{\pntxta .}}Identify the basic components of Firewall MIB \par {\pntext\pard\plain\fs20 2.\tab}Provide detailed descriptions of the basic components \par {\pntext\pard\plain\fs20 3.\tab}Identify the mechanics of how basic components can be combined to produce new components (complex components). \par {\pntext\pard\plain\fs20 4.\tab}Identify complex components \par {\pntext\pard\plain\fs20 5.\tab}Define relationships between components \par {\pntext\pard\plain\fs20 6.\tab}Define a detailed firewall MIB \par {\pntext\pard\plain\fs20 7.\tab}Review of overall Firewall MIB architecture \par {\pntext\pard\plain\fs20 8.\tab}Submit to IETF standards track (including RFC documents and reference implementations) \par {\pntext\pard\plain\fs20 9.\tab}Address schedule for Firewall MIB review and changes. \par {\pntext\pard\plain\fs20 10.\tab}Discussion/presentation of reference implementation issues \par \pard \widctlpar \par \pard\plain \s16\sb100\sa100\keepn\nowidctlpar \b\f4\fs36 Goals and Milestones: \par \trowd \cellx1109\cellx1390\cellx9359 \pard\plain \widctlpar\intbl \f4\fs20 Aug 97\cell \~\~\cell Initial meeting, BOF Munich IETF.\cell \pard \widctlpar\intbl \row \trowd \cellx1109\cellx1390\cellx9359 \pard \widctlpar\intbl Aug 97\cell \cell Setup Firewall MIB charter\cell \pard \widctlpar\intbl \row \pard \widctlpar\intbl Sept 97\cell \cell Create initial Internet-Draft\cell \pard \widctlpar\intbl \row \pard \widctlpar\intbl Oct 97\cell \cell Review revised draft\cell \pard \widctlpar\intbl \row \pard \widctlpar\intbl Nov 97\cell \~\~\cell Post initial Internet-Draft of the Firewall MIB\cell \pard \widctlpar\intbl \row \pard \widctlpar\intbl Nov 97\cell \~\~\cell Reference Implementation of SNMP Agents based on the initial Internet-Draft of the Firewall MIB\cell \pard \widctlpar\intbl \row \pard \widctlpar\intbl Dec 97\cell \~\~\cell Meet at Washington DC IETF.\cell \pard \widctlpar\intbl \row \pard \widctlpar\intbl Dec 97\cell \~\~\cell Conduct Interoperatability Testing and review Internet-Draft in the 40{\super th} IETF Meeting\cell \pard \widctlpar\intbl \row \pard \widctlpar\intbl Jan 98\cell \~\~\cell Post revised Internet-Draft.\cell \pard \widctlpar\intbl \row \pard \widctlpar\intbl Feb 98\cell \~\~\cell Issue final Internet-Draft.\cell \pard \widctlpar\intbl \row \trowd \cellx1109\cellx1390\cellx9359 \pard \widctlpar\intbl Feb 98\cell \~\~\cell Submit Intern et-Draft to IESG for consideration as a Proposed Standard.\cell \pard \widctlpar\intbl \row \pard\plain \s16\sb100\sa100\keepn\nowidctlpar \b\f4\fs36 Internet-Drafts: \par \pard\plain \widctlpar \f4\fs20 Firewall MIB (121,539 bytes) : See attached {\f11 } \par \pard\plain \s16\sb100\sa100\keepn\nowidctlpar \b\f4\fs36 No Request For Comments \par \pard\plain \widctlpar \f4\fs20 {\lang1024 {\*\do\dobxcolumn\dobypara\dodhgt8193\dpline\dpptx0\dppty0\dpptx9360\dppty1\dpx0\dpy240\dpxsize9360\dpysize1\dplinesolid\dplinecor212\dplinecog212\dplinecob212\dplinew35}} \par {\i IETF Secretariat - Please send questions, comments, and/or suggestions to } ietf-web@ietf.org. \par {\lang1024 \par }\pard \widctlpar\pvpara\posnegx-73\posy616\absh345\absw480\dxfrtext180\dfrmtxtx180\dfrmtxty0 {\lang1024 {\pict\wmetafile8\picw847\pich609\picwgoal480\pichgoal345 010009000003000100000000de00000000000400000003010800050000000b0200000000050000000c02170020000400000007010400de000000430f2000cc000000170020000000000017002000000000002800000020000000170000000100040000000000700100000000000000000000020000000200000000000000b1 99830011111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111001111111111111111111111111111100011111111111111111111111111110000111111111111111111111111111000000000000001111111111111111100000000000000001111111 11111111000000000000000000111111111111111000000000000000000111111111111111000000000000000000111111111111111000011111111111111111111111111111000111111110000011111111111111111001111111100000111111111111111111111111111000001111111111111111111111111110000011 11111111111111111111111110000011111111111111111111111111100000111111111111111111111111111000001111111111111111111111111110000011111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111104000000070101000300 000000000000000000000000} \par }{\lang1024 {\pict\wmetafile8\picw847\pich609\picwgoal480\pichgoal345 010009000003000100000000de00000000000400000003010800050000000b0200000000050000000c02170020000400000007010400de000000430f2000cc000000170020000000000017002000000000002800000020000000170000000100040000000000700100000000000000000000020000000200000000000000b1 99830011111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111001111111111111111111111111111100011111111111111111111111111110000111111111111111111111111111000000000000001111111111111111100000000000000001111111 11111111000000000000000000111111111111111000000000000000000111111111111111000000000000000000111111111111111000011111111111111111111111111111000111111110000011111111111111111001111111100000111111111111111111111111111000001111111111111111111111111110000011 11111111111111111111111110000011111111111111111111111111100000111111111111111111111111111000001111111111111111111111111110000011111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111104000000070101000300 000000000000000000000000}}{\lang1024 \par }\pard \widctlpar \par \par \par Return to working group directory. \par Return to IETF home page. \par \par \par \par } --=====================_879823291==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="draft-ietf-fireall-mib-19.txt" Internet Engineering Task Force C. Grall INTERNET-DRAFT Trusted Information Systems Expires 24 May 1998 24 November 1997 Firewall Management Information Base Status of this Memo This document is an Internet-Draft. 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." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for monitoring firewall devices. Table of Contents 1. The Network Management Framework The Internet-standard Network Management Framework consists of three components. They are: RFC 1902 [4] which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. Grall [Page 1] Internet-Draft Firewall MIB 24 November 1997 STD 17, RFC 1213 [5] defines MIB-II, the core set of managed objects for the Internet suite of protocols. RFC 1157 [6] and RFC 1905 [7] which define two versions of the pro- tocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Within a given MIB module, objects are defined using RFC 1902's OBJECT-TYPE macro. At a minimum, each object has a name, a syntax, an access-level, and an implementation- status. The name is an object identifier, an administratively assigned name, which specifies an object type. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the object descriptor, to also refer to the object type. The syntax of an object type defines the abstract data structure corresponding to that object type. The ASN.1[9] language is used for this purpose. However, RFC 1155[3] purposely restricts the ASN.1 con- structs which may be used. These restrictions are explicitly made for simplicity. 2. Overview This document specifies a working draft of a Management Information Base (MIB) definition intended for use in monitoring firewall systems with network management protocols in TCP/IP-based internets. All object identifiers defined herein are under the private enterprises MIB tree. This positioning would change if and when this MIB is adopted as stan- dard. This MIB is currently under review and revision by Internet security management service providers. There will be at least two independent reference implementations by the time this document reaches the Internet Standard status. Furthermore, the immediate use of this MIB is focused on the generation and interpretation of TRAP-signaled events and on querying specific MIB objects. Grall [Page 2] Internet-Draft Firewall MIB 24 November 1997 2.1. Textual Conventions Several new data types are introduced including Utf8String, EventTypeUn- itTC, and ProtocolUnitTC. 2.1.1. Utf8String The Utf8String textual convention is used for all string variables. 2.1.2. EventTypeUnitTC This textual convention enumerates many kinds of common events that may happen on a firewall. The list represents error conditions, unusual events, and normal activities. 2.1.3. ProtocolUnitTC This textual convention is an enumeration of the most common protocols used with TCP/IP-based network firewalls. 2.2. Structure of MIB The objects are arranged into the following groups: - service identifiers (service) - firewall event variables and logs (fwevent) - firewall status and statistics data (fwquery) - firewall traps (fwtrap) These groups are the basic units of conformance. If a firewall imple- ments a group, then it should implement all objects in that group. The fwevent, fwquery and fwtrap groups are optional. If the fwtrap group is implemented, the fwevent group must also be implemented. The services group must be implemented if any of the other groups are implemented. These groups are defined to provide a means of assigning object identif- iers, and to provide a method for managed agents to know which objects they must implement. Grall [Page 3] Internet-Draft Firewall MIB 24 November 1997 2.2.1. The Service Identifiers Group The service group defines object identifiers (OIDs) for classes of ser- vices and particular services handled by firewalls. These OIDs are used as values in variables in other groups of the MIB to designate a ser- vice. 2.2.2. The Firewall Event Variables and Logs Group The fwevent group defines tables for logging events that take place on the firewall. Management stations are notified of the events via traps from the fwtrap group. 2.2.3. The Status and Statistics Group The fwquery group contains status and statistic information. It includes version information for the firewall and its modules, status information for firewall services, and statistics measured by firewall modules. 2.2.4. The Firewall Traps Group The fwtrap group defines the traps that a firewall can send. 3. Monitoring of Firewall Devices The scope of the MIB defined here is to provide information for the pur- pose of monitoring firewall activity. The objects defined here provide information about urgent events, security, health and status, and per- formance of a firewall. This information is provided in two ways, via traps and through objects that must be queried. The traps also have associated information that can be queried. It is worth noting areas this MIB is not meant to address. It is not meant to replicate all firewall audit information or perform all of a firewall's logging. The information provided by the MIB objects is not necessarily all the information needed for a full audit capability. For example, suspicious monitoring entities would probably require audit information which should not be provided as part of this MIB. The MIB is also not meant to be used for configuring a firewall. There are many varieties of firewalls on the market and therefore many different ways to configure them. This MIB does not have any variables related to con- figuration items and currently does not have any variables with write permission. So, SETs are not supported. Grall [Page 4] Internet-Draft Firewall MIB 24 November 1997 This section provides details on the expected use of the objects defined in section "Definitions" below. It also presents some implementation issues. 3.1. Events Many of the objects in the MIB are related to events on the firewall. An event as far as this MIB is concerned is what a trap is created for, and what is stored in the event logs. An event can represent the activity of a single user on the firewall, the status of a program on the firewall, or a collection of firewall activities. It is up to the firewall vendor to decide what activities on the firewall are represented as events in the MIB. In order to provide a common set of events for MIB users and management status, the MIB includes an enumeration of event type, EventTypeUnitTC. The list includes the most common events that happen on a firewall. The comments included in the list describe the firewall activities each entry is meant to represent. It is understood that the list will prob- ably not represent all possible events any particular firewall may report on and there are generic entries that can be used for these cases. While the MIB's main purpose is to report about "unusual" events on a firewall, it was felt that the MIB should not disallow reporting related to "normal" events. Items are included in EventTypeUnitTC to represent "normal", "okay", "good", and "up" activities and conditions. A firewall vender can then choose to report any kind of activity through MIB events. For example, a firewall could equate a MIB event with an audited event and report on all firewall activity with the MIB. 3.1.1. Event Logs and Traps The fwevent group defines a set of log tables for storing information about events. The fwtrap group defines a set of traps for reporting about the events that have been recorded in the logs. These two groups are meant to work together. Although it is possible to implement the fwevent group without any trap support, this is not the purpose of the logs in the fwevent group. The event logs are represented by a set of tables. There is a basic table that holds information common to every event, and there are other tables that contain different sets of detailed information. Figure 1 provides a conceptual view of the tables. The basic table points to one of the MIB detail tables by table OID and row index. The basic table also (optionally) points to a firewall vendor defined details table. Grall [Page 5] Internet-Draft Firewall MIB 24 November 1997 details table basic table entries ------------------------ ---------------------------| | | |index | | | |time | | | |source | | | |type | /| | |description | / ------------------------ | | / |details table OID |--/ |details table index |-/ | | |vendor details table OID |-\ vendor details table |vendor details table index|--\ ------------------------ ---------------------------- \ | | \ | | \| | | | ------------------------ Figure 1: Conceptual view of event log tables. When an event (see section "Events") occurs on the firewall, the basic table information is collected and, based on the event, a details table is chosen and its information is collected as well. This information is stored on the firewall and a trap from the fwtrap group is sent. The trap contains the same information contained in the basic table. The management station then has the option to query the firewall and ask for the rows from the tables specified in the trap. Which trap is sent depends on the details table chosen. For the type1NetEventsLogTable, type2NetEventsLogTable, and type3NetEventsLogTable details tables use the networkEventTrap trap. For the healthEventsLogTable details table, use the healthEventTrap. For the managementEventsLogTable details table use the managemen- tEventTrap. Since the trap contains the EventTypeUnitTC and EventDescription values for the event, a user or management station can use these values to make decisions on whether the event details are useful or not. The retrieval of the details can be automated for many management stations. Appendix A contains some configuration and script examples for some of the more popular management tools. Grall [Page 6] Internet-Draft Firewall MIB 24 November 1997 3.1.2. Details Table Use The MIB defines five log tables to record details about an event. Each table includes a different set of information. Multiple tables were defined rather than have one large table to lower the likelihood that queries (and traps) would have many unneeded or undefined values. The MIB does not dictate which details table must be used for recording a particular event. In order to ease management station configuration this section lists the preferred details table for each of the sets of event in EventTypeUnitTC. The following lists each of the sets from the EventTypeUnitTC and the preferred details table used: EventTypeUnitTC set Details Table ------------------------------------------------ other [any] hardware healthEventsLogTable system healthEventsLogTable fwmodule healthEventsLogTable mgmt managementEventsLogTable logging healthEventsLogTable routing type1NetEventsLogTable packet type1NetEventsLogTable encryption type2NetEventsLogTable network type2NetEventsLogTable protocol healthEventsLogTable service healthEventsLogTable configuration healthEventsLogTable access type3NetEventsLogTable authentication type3NetEventsLogTable attack type3NetEventsLogTable contentInspection type3NetEventsLogTable debug healthEventsLogTable test healthEventsLogTable 3.1.3. Trap Flooding Under normal network conditions, one should not see many traps sent by a firewall to a management station. There is a potential for a large number of traps to be sent by a firewall implementing this MIB. This depends on how the firewall maps activities to events and how many of a particular event can occur in a short time. The MIB has no variables related to controlling which traps are sent or to limit the number of Grall [Page 7] Internet-Draft Firewall MIB 24 November 1997 traps sent [@?@ if this turns out to be a widespread problem after ini- tial reference implementation testing, it will be addressed in a later draft of this MIB]. To provide firewall and SNMP management user some control it is sug- gested that agent implementation provide some on/off configuration options for the events a firewall will report about. Whether and how to implement this and the granularity of the configuration control is beyond the scope of this document. 3.1.4. Thresholds It was stated earlier that a particular firewall vendor defines what a MIB event is on their firewall. It is expected that some MIB events will actually represent a set of activities on the firewall. For exam- ple, EventTypeUnitTC has an event called login attempts. What is not specified by the MIB is how many attempts happened before the event was handled by the SNMP agent. Individual thresholds for controlling which firewall activities are represented as events in the MIB or for controlling which events should generate traps are not specified in this MIB. Some activities are unin- teresting when they occur occasionally, but more interesting when they are more frequent. Firewall vendors decide which activities have thres- holds and what kind of thresholds are available. 3.1.5. Log Tables All of the log tables defined in the fwevent group are used and indexed in the same way. This section addresses some implementation issues to consider. The MIB does not dictate how the tables are implemented, just how the values of the variables in a table row are used. 3.1.5.1. Table Size and Index Value Table size is an implementation specific matter. Each table has an index variable to uniquely identify a row in the table. The index is assigned beginning with 1 when the table is created and increases by one with each new log entry. Table creation will generally happen at firewall system reboot, but may happen at any time (eg., when the firewall's SNMP agent is restarted). [@?@ comments received relate to preventing loss of the table informa- tion between reboots, is this desired?] Grall [Page 8] Internet-Draft Firewall MIB 24 November 1997 The agent may choose to delete the rows of a table as needed. This may be due to lack of space for the entries or due to other reasons (eg., the entries are too old). A query to the table cannot assume anything about the table's size of whether a particular index value in the table is valid or not. Deletion of rows in the table may be based on age (ie., the smallest valid index is deleted) or based on some other scheme (eg., the priority of the event is lower than other events in the log). The MIB does not place any requirements on which rows may or may not be deleted. Each log table has a corresponding '...LogTableLastValidRow' object. This variable can be used to obtain the index value of the last (or newest) valid row in the table Since the index value starts at 1 and monotonically increases with each new entry, one can see how many events have been recorded since the creation of the table by obtaining this variable. 3.1.5.2. Entry Order The MIB places no requirements on the order of entries in the log tables. The order of entries in a table will not necessarily be in the same order as the traps that arrive at the management station. The order of the entries in the basicEventsLogTable will not necessarily be in order by the basicEventTime value. 3.1.5.3. MIB Walks There is a concern that for implementations that choose to use a large log table size (eg., 300 entries), that a MIB walk into the log table will take a long time and will not necessarily be what the MIB walker had in mind. For the log tables defined in the fwevent group (not the tables in the fwquery group) the implementation may not return the first valid row of the table, but instead may choose to return another row. The row chosen may be, for instance, only 20 rows before the last valid row. The default behavior will be to return the first valid row. In particular, a GET NEXT on the '...LogTableLastValidRow' object will return the '...EventLogIndex' variable. The value of the index will be implementation defined. The value will be the index of a valid row in the table, but whether that is the first valid row of the tenth from the last is firewall specific. [@?@ to walk through the whole table, should we provide a '...LogTableFirstValidRow' object?] Grall [Page 9] Internet-Draft Firewall MIB 24 November 1997 4. Conventions The following conventions are used throughout the Firewall MIB. Good Packets Good packets are error-free packets that have a valid frame length. For example, on Ethernet, good packets are error-free packets that are between 64 octets long and 1518 octets long. They follow the form defined in IEEE 802.3 section 3.2.all. Bad Packets Bad packets are packets that have proper framing and are therefore recognized as packets, but contain errors within the packet or have an invalid length. For example, on Ethernet, bad packets have a valid preamble and SFD, but have a bad CRC, or are either shorter than 64 octets or longer than 1518 octets. 5. Definitions Grall [Page 10] Internet-Draft Firewall MIB 24 November 1997 -- This document specifies a working draft of a Management Information -- Base (MIB) definition intended for use in managing firewall systems -- with network management protocols in TCP/IP-based internets. -- The object identifiers defined are used to identify -- firewall entities such as the firewall services, packet filtering, -- operating system services, etc. -- In addition to traps, there are a number of variables which -- could be queried by the management station in this MIB related to -- the firewall resources, firewall statistics, etc. -- Firewall Event Scheme -- The event scheme used in the design of the trap messages is one based -- on the idea of providing notification that an exceptional event occurred -- and that the details can be queried from the firewall. -- Event Examples -- The following examples are included to illustrate the use of object -- identifiers and additional trap variables in a TRAP to describe a -- firewall event. -- eg 1: -- Event: a telnet proxy running on a firewall system 199.94.211.1, is -- configured to deny access to users not connecting from a network, say -- 199.94.200.0. When denying access to a user coming from 199.94.222.2, -- the proxy service might generate the following trap. -- The trap type is set to 6 (enterprise specific). A specific trap of -- type 1 (networkEventTrap) is chosen to best describe this event. The -- networkEventTrap includes variables to point to the basicEventsTable -- and the type3NetLogEventDetailsTable. -- -- For this specific event the details table describes the entity making -- the connection attempt and why the attempt failed. -- TRAP networkEventTrap: -- trap type = 6 (enterprise specific) -- enterprise specific type = 1 (networkEventTrap) -- -- @?@ fix.... -- trap and basicEventsLogTable: -- basicEventLogIndex = INTEGER (217) -- basicEventTime = TimeStamp Grall [Page 11] Internet-Draft Firewall MIB 24 November 1997 -- basicEventSource = IpAddress (199.94.211.1) -- basicEventType = -- basicEventDescription = String ("XXX") -- basicEventDetails = OID (type3NetEventDetailsTable) -- basicEventDetailsIndex = INTEGER (16) -- basicEventVendorPrivateDetails = OID (NULL) -- basicEventVendorPrivateIndex = 0 -- -- type3NetEventDetailsTable -- type3NetEventDetailIndex = INTEGER (16) -- type3NetEventProtocol = TCP (1) -- type3NetEventSrcIpAddress = IpAddress (199.94.222.2) -- type3NetEventMappedSrcIPAddress = IpAddress (NULL) -- type3NetEventDstIPAddress = IpAddress (NULL) -- type3NetEventMappedDstIPAddress = IpAddress (NULL) -- type3NetEventSrcIPPort = INTEGER (3333) -- type3NetEventMappedSrcIPPort = INTEGER (NULL) -- type3NetEventDstIPPort = INTEGER (23) -- type3NetEventMappedSrcIPort = INTEGER (NULL) -- type3NetEventGenericService = OBJECT IDENTIFIER (spfw.service.svcLogin) -- type3NetEventServiceInformation = String ("tn-gw") -- type3NetEventAuthdEntity = String ("unknown") -- type3NetEventRuleID = INTEGER (27, eg., the config. file line number) -- type3NetEventActionReason = String ("source IP address denied") -- -- eg 2: -- Event: A machine (say 199.123.23.17) sent an ICMP redirect packet to -- the firewall. -- The trap type is set to 6 (enterprise specific). A specific trap of -- type 1 (networkEventTrap) is chosen to best describe this login event. -- TRAP networkEventTrap -- trap type = 6 (enterprise specific) -- enterprise specific type = 1 (networkEventTrap) -- -- @?@ fix... -- -- trap and basicEventsTable: -- basicEventLogIndex = INTEGER (376) -- basicEventTime = TimeStamp -- basicEventSource = IpAddress (199.94.211.1) -- basicEventType = -- basicEventDescription = String ("XXX") -- basicEventDetails = OID (type1NetEventDetailsTable) -- basicEventDetailsIndex = INTEGER (76) Grall [Page 12] Internet-Draft Firewall MIB 24 November 1997 -- basicEventVendorPrivateDetails = OID (NULL) -- -- type1NetEventDetailsTable: -- type1NetEventDetailID = INTEGER (76) -- type1NetEventProtocol = icmp -- type1NetEventSrcIPAddress = IpAddress (201.213.64.65) -- type1NetEventMappedSrcIPAddress = IpAddress (NULL) -- type1NetEventDstIPAddress = IpAddress (199.94.211.1) -- type1NetEventMappedDstIPAddress = IpAddress (NULL) -- type1NetEventICMPCommand = redirect (5) -- eg 3: -- Event: a service on the firewall is misconfigured. The firewall has an -- http service and the system administrator configured it to run on port -- 8000. But there is already another service running on port 8000. The -- http gateway cannot bind to the port. -- The trap type is set to 6 (enterprise specific). A specific trap of -- type 2 (healthEventTrap) is chosen to best describe the reboot event. -- TRAP processTrap: -- trap type = 6 (enterprise specific) -- enterprise specific type = 2 (healthEventTrap) -- -- restTBD -- eg 4: -- Event: the firewall configuration is changed. -- The trap type is set to 6 (enterprise specific). A specific trap of -- type 3 (managementEventTrap) chosen to best describe the reboot event. -- TRAP processTrap: -- trap type = 6 (enterprise specific) -- enterprise specific type = 3 (managementEventTrap) -- -- rest TBD FireWallMIB DEFINITIONS ::= BEGIN -- SUBTREE: 1.3.6.1.4.1.14.3.9 -- iso.org.dod.internet.private.enterprises.bbn.products.spfw Grall [Page 13] Internet-Draft Firewall MIB 24 November 1997 IMPORTS OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, IpAddress, enterprises, Counter32 FROM SNMPv2-SMI TEXTUAL-CONVENTION, TimeStamp FROM SNMPv2-TC; fwMIB MODULE-IDENTITY LAST-UPDATED "9711061800Z" ORGANIZATION "GTE Corporation & Trusted Information Systems Inc." CONTACT-INFO "Comments should be sent to @?@ fwmib@xxx.com.... @?@ Modify as needed... Herbert Lin Tel: +1-617-873-5920 E-mail: hlin@bbn.com Cindy Grall Tel: +1-310-737-1744 E-mail: grall@tis.com Dave Chouihard Tel: +1-503-264-7481 E-mail: dchouihard@ibeam.intel.com Dorit Dor Tel: 972-3-613-1833 (Israel) E-mail: dorit@checkpoint.com Mike Wittig Tel: +1-954-973-5059 E-mail: mwittig@mail.cybg.com Thomas Oeser Tel: +49-89-636-47537 E-mail: Thomas.Oeser@mch.sni.de " DESCRIPTION "The MIB module for entities implementing firewalls." Grall [Page 14] Internet-Draft Firewall MIB 24 November 1997 --@?@ what's the correct value here??? ::= { enterprises 600 } -- textual conventions Utf8String ::= TEXTUAL-CONVENTION DISPLAY-HINT "255a" STATUS current DESCRIPTION "To facilitate internationalization, this TC represents information taken from the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 character encoding scheme described in RFC 2044 [11]. For strings in 7-bit US-ASCII, there is no impact since the UTF-8 representation is identical to the US-ASCII encoding." SYNTAX OCTET STRING (SIZE (0..255)) -- -- The following list of event types is meant to enumerate the most common -- events that happen on a firewall. -- -- The list is organized into sets of common events. Each set has an -- initial entry to designate the set. The next two events in a set are -- meant to represent generic "okay"/"good"/"up" conditions and generic -- "error"/"failed"/"down" conditions. The rest of the events in a set -- represent more detailed events (either good or bad). The sets will -- probably not represent all the possible events on every firewall, but -- they are meant to be a good representation of events. If an event -- just does not fit any of the sets, then use the 'other' choices. -- EventTypeUnitTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Enumeration of types of events on the firewall" SYNTAX INTEGER { -- Undefined Events other(0), -- the event type is not in this list otherOkay(1), -- a normal event occurred otherError(2), -- an error event occurred unknown(3), -- could not determine the event type -- Hardware problems hardware(100), Grall [Page 15] Internet-Draft Firewall MIB 24 November 1997 hardwareOkay(101), hardwareError(102), hardwareOverTemperature(103), hardwareDiskUseHigh(104), hardwareTestFailed(105), hardwareBusy(106), hardwareNoMedia(107), -- a device doesn't have its needed media hardwareCpuUsageHigh(108), -- the CPU usage is high -- Operating system problems system(200), systemUp(201), systemError(202), systemDown(203), -- reported by an agent on another machine systemBooting(204), -- systemRebooting(205), -- the firewall is going down and coming back up systemHalting(206), -- the firewall is going down sustemBackup(207), -- processing has switched to the backup sustemNoBackup(208), -- there is no backup to switch to systemNoMemory(209), systemNoBuffers(210), systemSyscallFailed(211), systemHighLoad(212), systemSwapLarge(213), -- -- Events about the basic health of the firewall or particular modules fwmodule(300), fwmoduleUp(301), -- the module is up fwmoduleError(302), fwmoduleDown(303), -- the module is down fwmoduleStarting(304), -- the module is coming up fwmoduleExiting(305), fwmoduleRestarting(306), fwmoduleLicenseExceeded(307), -- Management events, these are events related to overall management -- tasks on the firewall. For example, the configuration is being -- changed or a patch has been applied. This is from the perspective -- of the firewall, it is not a remote mgmt tool reporting on the -- activities it is doing. mgmt(400), mgmtOkay(401), -- a normal management event mgmtError(402), -- an error while performing firewall -- management functions mgmtNoResponse(403), -- the firewall expected and received no -- response from a mgmt tool mgmtReadConfigLocal(404), -- configuration information has been -- read Grall [Page 16] Internet-Draft Firewall MIB 24 November 1997 mgmtReadConfigRemote(405), -- configuration information has been -- uploaded to a remote mgmt tool mgmtLoadedConfigLocal(406), -- a local mgmt tool loaded/applied a -- new config mgmtLoadedConfigRemote(407), -- a remote mgmt tool loaded/applied a -- new config. mgmtPatch(408), -- This event is used by the patching mechanism to -- record what it patched. The genericService OID -- would be the patching tool and the mgmtObjManaged -- in the mgmtEventLogEntry would be the service -- OID patched. This would not be used by the -- service being patched. This alleviates the -- confusion when the patching mechanism is patched. -- Log file events logging(500), loggingUp(501), -- logging is functioning normally loggingError(502), -- the logging facility had an error loggingStarting(503), -- the log daemon was started loggingExiting(504), -- the log daemon is exiting loggingRestarting(505), -- the log daemon was restarted loggingDown(506), -- the log daemon is not running loggingFileSwitched(507), -- logging switched to another file loggingFileFull(508), -- the log file/partition is full loggingFileOverwrite(509), -- the log file is being overwritten loggingFileMessagesLost(510), -- messages have been lost loggingStopped(511), -- logging is stopped until other -- problems are resolved (eg., space is -- free'd) -- Routing events routing(600), routingOkay(601), routingError(602), routingNoRouteToHost(603), routingICMPRedirect(604), -- Packet handling packet(700), packetAccepted(701), -- accepted the packet packetError(702), -- unknown error with packet packetDropped(703), -- dropped packets (eg., internal buffer is full), -- didn't even look at them, they could be -- good or bad... packetInvalid(704), -- these are "bad" packets, see section x.x packetIgnored(705), -- the packet was not meant for the firewall packetRejected(706), -- rejected packets based on rule(s) packetForwarded(707), -- forwarded packets based on rule(s) Grall [Page 17] Internet-Draft Firewall MIB 24 November 1997 packetEncrypted(708), -- En(De)cryption events encryption(800), -- generic/successful event encryptionUp(801), --encryption is functioning encryptionError(802), -- there was an encryption error encryptionDown(803), encryptionEncryptFailed(804), encryptionDecryptFailed(805), -- Network events network(900), networkUp(901), networkError(902), networkDown(903), networkCollision(904), networkDuplicateAddress(905), networkMyAddressInUse(906), networkNetUnreachable(907), networkStarting(908), networkRestarting(909), networkHostUnreachable(910), networkNoResponse(911), -- protocol related events protocol(1000), -- an event related to a protocol supported protocolEnabled(1001), protocolError(1002), protocolDisabled(1003), -- the requested protocol is disabled protocolNoDaemon(1004), -- there is no daemon for this protocol -- Service connection/network connectivity events connection(1100), -- a generic connection event connectionAccepted(1101), connectionError(1102), connectionDropped(1103), connectionClosed(1104), connectionTimedout(1105), connectionRefused(1106), connectionReset(1107), connectionNoResponse(1108), -- Service operation events, for daemons/proxies/etc. service(1200), serviceUp(1201), serviceError(1202), serviceDown(1203), serviceStarting(1204), Grall [Page 18] Internet-Draft Firewall MIB 24 November 1997 serviceExiting(1205), serviceRestarting(1206), -- Configuration events, represent errors or problems with the -- configuration for the system or a service. configuration(1300), configurationOkay(1301), configurationError(1302), -- an error in processing the configuration configurationBadConfig(1303), -- the config provided is corrupt, -- invalid, or incomplete configurationArgumentError(1304), -- wrong arguments were provided configurationPortInUse(1305), configurationNoData(1306), -- the required data was not provided -- Access access(1400), accessGranted(1401), -- a service allowed use based on all its checks accessError(1402), accessDenied(1403), -- a client was denied use of a service accessDeniedSource(1404), -- client denied based on its source IP accessDeniedPolicy(1405), -- client denied based on the sec. policy accessDeniedUser(1406), -- client denied based on the userid accessDeniedDest(1407), -- client denied based on the destination IP accessDeniedDestPort(1408), -- client denied based on dest. port accessDeniedFileRead(1409), -- the policy denied read access to a file accessDeniedFileWrite(1410), -- the policy denied write access to -- a file accessDeniedNetworkInterface(1411), -- the policy denied access to a -- particular net. int. accessDeniedDevice(1412), -- the policy denied access to a device -- Authentication and login events authentication(1500), authenticationSucceeded(1501), -- a user had a successful auth authenticationError(1502), -- error while auth'ing authenticationFailed(1503), -- a user failed an auth authenticationSucceededPriv(1504), -- a user logged in with or -- gained privilege authenticationFailedPrivileged(1505), -- user failed to gain/login -- with privilege authenticationFailedMulti(1506), -- multiple failed auth attempts -- by a user -- Security attack events, these represent events that could -- be or that indicate a security attack is taking place on the -- firewall attack(1600), attackNone(1601), Grall [Page 19] Internet-Draft Firewall MIB 24 November 1997 attackDenialOfService(1602), attackPing(1603), -- a ping of death attack attackPacketForward(1604), -- attackSYNFlood(1605), -- a TCP SYN flood attack attackIPSpoof(1606), -- an IP address is being spoofed attackPortScan(1607), -- a port scan is/has taken place attackNameSpoof(1608), -- a name service (eg., DNS) name is spoofed -- Content inspection events, these events just report that -- something was found. The details entry in for the event can -- report on what was found (eg., virus, company private info., -- etc), what it was found in (eg., html, win32 executable, e-mail), -- and what was done with it (eg., the quarantine location). contentInspection(1700), contentInspectionOkay(1701), -- the check of the content was okay, -- nothing "bad" found contentInspectionError(1702), -- there was an error while checking -- content contentInspectionFound(1703), -- found something contentInspectionFoundCleaned(1704), -- found something and cleaned -- the content of it contentInspectionFoundRejected(1705), -- found something and threw -- the content away contentInspectionFoundSaved(1706), -- found something and saved the -- content in quarantine -- Debugging event debug(1800), debugOkay(1801), debugError(1802), debugOn(1803), -- debugging mode is on/was turned on debugOff(1804), -- debugging mode is off/was turned off -- Testing events test(1900), testPassed(1901), -- a test passed testFailed(1902), -- a test failed testNoResponse(1903) -- there was no response for running a test } ProtocolUnitTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Enumeration of network protocols commonly used on firewalls." SYNTAX INTEGER { Grall [Page 20] Internet-Draft Firewall MIB 24 November 1997 tcp(1), udp(2), icmp(3), ip(4), ipsec(5), igmp(6), arp(7), ggp(8), egp(9), rip(10), other(11) } -- This fwmib is divided into four main groups. The first, spfw.service, -- Service identifiers, defines OIDs used by other areas of the MIB. The -- second, spfw.fwevent, Event variables and logs, is described briefly -- above in the trap examples text. Third main group is spfw.fwquery, -- the set of variables for queries. For a firewall this set is read only. -- The fourth group, spfw.fwtrap, defines the traps for notification of -- extraordinary events on the firewall. -- -- There is also a group for specifying MIB conformance as described in -- RFC1444, "Conformance Statements for version 2 of the Simple Network -- Management Protocol (SNMPv2)". bbn OBJECT IDENTIFIER ::= { enterprises 14 } products OBJECT IDENTIFIER ::= { bbn 3 } spfw OBJECT IDENTIFIER ::= { products 9 } -- -- service group -- -- The service group defines OIDs that are used by other parts of the MIB. -- The OIDs are used by traps to designate the generic service type -- causing the trap. Expect this list to change occasionally as new service -- types emerge in the network/firewall community. Once a service type -- is in use by two or more firewall vendors it can be considered for -- inclusion in the services group. This change is treated as any other -- update to the MIB and will be included during a revision cycle. -- This list does not differentiate between a local service (eg., local -- login into the firewall via telnet) and a proxied service (eg., use of -- a telnet application gateway). This information can be provided in a -- string, since each use of these OIDs in a MIB variable (usually as -- part of a table entry) has a corresponding description or information -- variable. -- Use of these OIDs in the MIB variables: Grall [Page 21] Internet-Draft Firewall MIB 24 November 1997 -- -- If a new service emerges that is not in the MIB yet, but that has been -- assigned a port number or other identifying number, then it can be -- represented by choosing the appropriate service category and using the -- assigned number. For example, a new service called Foo Protocol (fp) -- is the latest rage on the Internet. It is a multi-media protocol and -- has been assigned port number XXX. The OID used to represent the -- service would be spfw.service.svcMultimedia.XXX. The corresponding -- information variable can provide the protocol name. -- -- If the firewall supports a service or protocol that is very unique or -- specific to that firewall, then the OID used to represent the service -- will include that vendor's enterprise number. For example, the Foo -- firewall has a Bar service. The firewall company's enterprise number -- is ZZZ and they have chosen W to represent the Bar service. The -- OID used would be spfw.service.svcOther.ZZZ.W It is the vendor's -- responsibility to publish definitions of the numbers used. -- -- In any of the cases above where a service listed below cannot be used, -- the service can be further described with the serviceInformation object. -- -- The numbers assigned in the list correspond, when possible, to the -- assigned port number for a protocol or other assigned number as -- appropriate (eg., the protocol number for IP protocols). -- -- Alternatively a vendor can define an OID in their enterprise tree and -- use that value for genericService. It is the vendor's responsibility -- to publish these OIDs. -- service OBJECT IDENTIFIER ::= { spfw 1 } -- represents the firewall as a whole, useful when statistics or events -- apply to the whole firewall device -- svcFirewall OBJECT IDENTIFIER ::= { service 1 } -- svcOther OBJECT IDENTIFIER ::= { service 2 } -- svcFileTransfer OBJECT IDENTIFIER ::= { service 3 } ftp OBJECT IDENTIFIER ::= { svcFileTransfer 21 } tftp OBJECT IDENTIFIER ::= { svcFileTransfer 69 } ftps OBJECT IDENTIFIER ::= { svcFileTransfer 990 } -- ftp over ssl -- svcLogin OBJECT IDENTIFIER ::= { service 4 } Grall [Page 22] Internet-Draft Firewall MIB 24 November 1997 login OBJECT IDENTIFIER ::= { svcLogin 1 } -- a login/su program telnet OBJECT IDENTIFIER ::= { svcLogin 23 } rlogin OBJECT IDENTIFIER ::= { svcLogin 513 } telnets OBJECT IDENTIFIER ::= { svcLogin 992 } -- telnet over ssl -- svcRemoteExecution OBJECT IDENTIFIER ::= { service 5 } sunRPC OBJECT IDENTIFIER ::= { svcRemoteExecution 111 } rsh OBJECT IDENTIFIER ::= { svcRemoteExecution 514 } xserver OBJECT IDENTIFIER ::= { svcRemoteExecution 6000 } -- svcWeb OBJECT IDENTIFIER ::= { service 6 } gopher OBJECT IDENTIFIER ::= { svcWeb 70 } http OBJECT IDENTIFIER ::= { svcWeb 80 } pointcast OBJECT IDENTIFIER ::= { svcWeb 90 } https OBJECT IDENTIFIER ::= { svcWeb 443 } -- also know as shttp -- svcMail OBJECT IDENTIFIER ::= { service 7 } sendmail OBJECT IDENTIFIER ::= { svcMail 1 } smtp OBJECT IDENTIFIER ::= { svcMail 25 } pop2 OBJECT IDENTIFIER ::= { svcMail 109 } pop3 OBJECT IDENTIFIER ::= { svcMail 110 } smtps OBJECT IDENTIFIER ::= { svcMail 465 } -- smtp over ssl pop3s OBJECT IDENTIFIER ::= { svcMail 995 } -- pop3 over ssl -- svcNews OBJECT IDENTIFIER ::= { service 8 } nntp OBJECT IDENTIFIER ::= { svcNews 119 } nntps OBJECT IDENTIFIER ::= { svcNews 563 } -- nntp over ssl -- svcMultimedia OBJECT IDENTIFIER ::= { service 9 } irc OBJECT IDENTIFIER ::= { svcMultimedia 194 } talk OBJECT IDENTIFIER ::= { svcMultimedia 517 } ircs OBJECT IDENTIFIER ::= { svcMultimedia 994 } -- irc over ssl streamworks OBJECT IDENTIFIER ::= { svcMultimedia 1558 } h323 OBJECT IDENTIFIER ::= { svcMultimedia 1718 } netShow OBJECT IDENTIFIER ::= { svcMultimedia 1755 } vDOLive OBJECT IDENTIFIER ::= { svcMultimedia 7000 } realAV OBJECT IDENTIFIER ::= { svcMultimedia 7070 } -- svcDatabase OBJECT IDENTIFIER ::= { service 10 } dbSybas OBJECT IDENTIFIER ::= { svcDatabase 1 } dbInformix OBJECT IDENTIFIER ::= { svcDatabase 3 } dbOracle OBJECT IDENTIFIER ::= { svcDatabase 66 } -- or 150? Grall [Page 23] Internet-Draft Firewall MIB 24 November 1997 dbMSsql OBJECT IDENTIFIER ::= { svcDatabase 1433 } -- these are the current thing that are checked for nowadays, eg., there -- are products or engines that scan for what's below svcContentInspection OBJECT IDENTIFIER ::= { service 11 } virus OBJECT IDENTIFIER ::= { svcContentInspection 1 } certificate OBJECT IDENTIFIER ::= { svcContentInspection 2 } -- eg., Java, Active-X programLanguage OBJECT IDENTIFIER ::= { svcContentInspection 3 } -- eg., company private dirtyWord OBJECT IDENTIFIER ::= { svcContentInspection 4 } -- svcDirectory OBJECT IDENTIFIER ::= { service 12 } nis OBJECT IDENTIFIER ::= { svcDirectory 1 } dns OBJECT IDENTIFIER ::= { svcDirectory 53 } netbiosns OBJECT IDENTIFIER ::= { svcDirectory 137 } netbiosdgm OBJECT IDENTIFIER ::= { svcDirectory 138 } netbiosssn OBJECT IDENTIFIER ::= { svcDirectory 139 } ldap OBJECT IDENTIFIER ::= { svcDirectory 389 } wins OBJECT IDENTIFIER ::= { svcDirectory 1512 } -- svcOperatingSystem OBJECT IDENTIFIER ::= { service 13 } inetd OBJECT IDENTIFIER ::= { svcOperatingSystem 1 } cron OBJECT IDENTIFIER ::= { svcOperatingSystem 2 } kernel OBJECT IDENTIFIER ::= { svcOperatingSystem 3 } fileSystem OBJECT IDENTIFIER ::= { svcOperatingSystem 4 } printer OBJECT IDENTIFIER ::= { svcOperatingSystem 515 } -- svcManagement OBJECT IDENTIFIER ::= { service 14 } mgmtTool OBJECT IDENTIFIER ::= { svcManagement 1 } patchTool OBJECT IDENTIFIER ::= { svcManagement 2 } snmp OBJECT IDENTIFIER ::= { svcManagement 161 } -- svcEncryption OBJECT IDENTIFIER ::= { service 15 } ipsec OBJECT IDENTIFIER ::= { svcEncryption 1 } vpn OBJECT IDENTIFIER ::= { svcEncryption 2 } kerberos OBJECT IDENTIFIER ::= { svcEncryption 88 } isakmp OBJECT IDENTIFIER ::= { svcEncryption 500 } -- svcPacketFilter OBJECT IDENTIFIER ::= { service 16 } -- network address translation svcNAT OBJECT IDENTIFIER ::= { service 17 } Grall [Page 24] Internet-Draft Firewall MIB 24 November 1997 -- svcAuthentication OBJECT IDENTIFIER ::= { service 18 } password OBJECT IDENTIFIER ::= { svcAuthentication 1 } skey OBJECT IDENTIFIER ::= { svcAuthentication 2 } -- Digital Pathways snk OBJECT IDENTIFIER ::= { svcAuthentication 3 } -- Enigma Logics silvercard OBJECT IDENTIFIER ::= { svcAuthentication 4 } crytocard OBJECT IDENTIFIER ::= { svcAuthentication 5 } -- Digital Pathways server dss OBJECT IDENTIFIER ::= { svcAuthentication 6 } -- Enigma Logics safeword OBJECT IDENTIFIER ::= { svcAuthentication 7 } vasco OBJECT IDENTIFIER ::= { svcAuthentication 8 } apop OBJECT IDENTIFIER ::= { svcAuthentication 9 } secureID OBJECT IDENTIFIER ::= { svcAuthentication 755 } -- svcLog OBJECT IDENTIFIER ::= { service 19 } syslog OBJECT IDENTIFIER ::= { svcLog 514 } -- svcTime OBJECT IDENTIFIER ::= { service 20 } time OBJECT IDENTIFIER ::= { svcTime 37 } ntp OBJECT IDENTIFIER ::= { svcTime 123 } timed OBJECT IDENTIFIER ::= { svcTime 525 } -- svcGroupware OBJECT IDENTIFIER ::= { service 21 } exchange OBJECT IDENTIFIER ::= { svcGroupware 1 } -- Microsoft lotusNotes OBJECT IDENTIFIER ::= { svcGroupware 1352 } -- svcHardware OBJECT IDENTIFIER ::= { service 22 } memory OBJECT IDENTIFIER ::= { svcHardware 1 } disk OBJECT IDENTIFIER ::= { svcHardware 2 } power OBJECT IDENTIFIER ::= { svcHardware 3 } netinterface OBJECT IDENTIFIER ::= { svcHardware 4 } tape OBJECT IDENTIFIER ::= { svcHardware 5 } controller OBJECT IDENTIFIER ::= { svcHardware 6 } -- svcQuery OBJECT IDENTIFIER ::= { service 23 } whois OBJECT IDENTIFIER ::= { svcQuery 43 } finger OBJECT IDENTIFIER ::= { svcQuery 79 } ident OBJECT IDENTIFIER ::= { svcQuery 113 } -- svcFileShare OBJECT IDENTIFIER ::= { service 24 } Grall [Page 25] Internet-Draft Firewall MIB 24 November 1997 nfsStatus OBJECT IDENTIFIER ::= { svcFileShare 1110 } nfs OBJECT IDENTIFIER ::= { svcFileShare 2049 } -- mainly used in the module and statistics tables to designate that -- information applies to the protocol class chosen svcProtocol OBJECT IDENTIFIER ::= { service 25 } icmp OBJECT IDENTIFIER ::= { svcProtocol 1 } igmp OBJECT IDENTIFIER ::= { svcProtocol 2 } tcp OBJECT IDENTIFIER ::= { svcProtocol 6 } udp OBJECT IDENTIFIER ::= { svcProtocol 17 } ip OBJECT IDENTIFIER ::= { svcProtocol 255 } -- -- The firewall event group -- -- The firewall event group defines a set of variables and tables used to -- log and track extraordinary firewall events. The tables are filled in -- when an event occurs and then trap is sent referencing the filled in -- row. -- For any particular event up to three tables will be referenced. The -- general event information will go into one table and the details are -- placed in another. A third vendor defined table can also be used. -- There is only one table defined for general information. -- The table chosen for event details depends on the event type and the -- set of detailed information available at the time the event took place. -- The general table has a value to point to the table and row containing -- the event's details. A trap is sent once the relevant tables are -- filled in. The trap contains pointers to the tables used. -- A management station can wait for a trap to get details on an event. -- Alternatively the management station can query the objects in this -- group at any time to retrieve event information. fwevent OBJECT IDENTIFIER ::= { spfw 2 } -- @?@ define, if possible, the tables that should be used for the events -- from the EventTypeUnitTC... -- -- BASIC EVENTS LOG -- -- This group defines the basic table containing information that is -- logged for every event on the firewall. The table is defined along -- with one variable to obtain the index value of the last valid row in -- the table. To obtain the first valid index value, query the table -- (via GETNEXT) for the first entry in the table. Grall [Page 26] Internet-Draft Firewall MIB 24 November 1997 -- -- The index of the last valid row also indicates the total number of -- events logged in the table since reboot. -- basicEventsLog OBJECT IDENTIFIER ::= { fwevent 1 } basicEventsLogTableLastValidRow OBJECT-TYPE SYNTAX INTEGER(1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The index value of the last valid row in the basicEventsLogTable." ::= { basicEventsLog 1 } basicEventsLogTable OBJECT-TYPE SYNTAX SEQUENCE OF BasicEventsLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of basic data for firewall events." ::= { basicEventsLog 2 } basicEventsLogEntry OBJECT-TYPE SYNTAX BasicEventsLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing general information about an event." INDEX { basicEventLogIndex } ::= { basicEventsLogTable 1 } BasicEventsLogEntry ::= SEQUENCE { basicEventLogIndex INTEGER(1..2147483647), basicEventTime TimeStamp, basicEventSource IpAddress, basicEventType EventTypeUnitTC, basicEventDescription Utf8String, basicEventDetailsTable OBJECT IDENTIFIER, basicEventDetailsTableIndex INTEGER(1..2147483647), basicEventVendorPrivateDetailsTable OBJECT IDENTIFIER, Grall [Page 27] Internet-Draft Firewall MIB 24 November 1997 basicEventVendorPrivateDetailsTableIndex INTEGER(1..2147483647) } basicEventLogIndex OBJECT-TYPE SYNTAX INTEGER(1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "An index that uniquely identifies an entry in the log table. These indices are assigned beginning with 1 and increase by one with each new log entry. The agent may choose to delete the instances of basicEventEntry as required because of lack of memory. It is an implementation specific matter as to when this deletion may occur and as to which log entries are deleted." ::= { basicEventsLogEntry 1 } basicEventTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The time that the Events occurred." ::= { basicEventsLogEntry 2 } basicEventSource OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address of the firewall entity where the event occurred, the IP address of entity. If there are two or more IP addresses there is no guarantee which IP address will be used." ::= { basicEventsLogEntry 3 } basicEventType OBJECT-TYPE SYNTAX EventTypeUnitTC MAX-ACCESS read-only STATUS current DESCRIPTION Grall [Page 28] Internet-Draft Firewall MIB 24 November 1997 "What type of event this is." ::= { basicEventsLogEntry 4 } basicEventDescription OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "An (optional) description of the event." ::= { basicEventsLogEntry 5 } basicEventDetailsTable OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "A pointer to the table containing details about this event. It will be one of the tables defined in this MIB. One of type1NetEventsLogTable, type2NetEventsLogTable, type3NetEventsLogTable, healthEventsLogTable, managementEventsLogTable." ::= { basicEventsLogEntry 6 } basicEventDetailsTableIndex OBJECT-TYPE SYNTAX INTEGER(1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "Index of a row in the table referenced by basicEventsLogDetails." ::= { basicEventsLogEntry 7 } basicEventVendorPrivateDetailsTable OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "This value is vendor defined. Generally this will be a pointer to a table and row containing vendor specific details about this event. It is up to firewall vendor to define how Grall [Page 29] Internet-Draft Firewall MIB 24 November 1997 this value should be interpreted and to publish this information." ::= { basicEventsLogEntry 8 } basicEventVendorPrivateDetailsTableIndex OBJECT-TYPE SYNTAX INTEGER(1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "Index of a row in the table referenced by basicEventsLogVendorPrivateDetails." ::= { basicEventsLogEntry 9 } -- TYPE 1 NETWORK EVENTS LOG -- -- A details log table with minimal information, can be used to record events -- at the IP level. -- type1NetEventsLog OBJECT IDENTIFIER ::= { fwevent 2 } type1NetEventsLogTableLastValidRow OBJECT-TYPE SYNTAX INTEGER(1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The index value of the last valid row in the type1NetEventsLogTable." ::= { type1NetEventsLog 1 } type1NetEventsLogTable OBJECT-TYPE SYNTAX SEQUENCE OF Type1NetEventsLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of detailed data for IP type events." ::= { type1NetEventsLog 2 } type1NetEventsLogEntry OBJECT-TYPE SYNTAX Type1NetEventsLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Grall [Page 30] Internet-Draft Firewall MIB 24 November 1997 "An entry in the table, containing detailed information about an event." INDEX { type1NetEventLogIndex } ::= { type1NetEventsLogTable 1 } Type1NetEventsLogEntry ::= SEQUENCE { type1NetEventLogIndex INTEGER(1..2147483647), type1NetEventProtocol ProtocolUnitTC, type1NetEventSrcIpAddress IpAddress, type1NetEventMappedSrcIpAddress IpAddress, type1NetEventDstIpAddress IpAddress, type1NetEventMappedDstIpAddress IpAddress, type1NetEventICMPCommand INTEGER, type1NetEventGenericService OBJECT IDENTIFIER, type1NetEventServiceInformation Utf8String, type1NetEventActionReason Utf8String } type1NetEventLogIndex OBJECT-TYPE SYNTAX INTEGER(1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "An index that uniquely identifies an entry in the log table. These indices are assigned beginning with 1 and increase by one with each new log entry. The agent may choose to delete the instances of basicEventEntry as required because of lack of memory. It is an implementation specific matter as to when this deletion may occur and as to which log entries are deleted." ::= { type1NetEventsLogEntry 1 } type1NetEventProtocol OBJECT-TYPE SYNTAX ProtocolUnitTC MAX-ACCESS read-only STATUS current DESCRIPTION "Enumeration of possible network protocols." ::= { type1NetEventsLogEntry 2 } type1NetEventSrcIpAddress OBJECT-TYPE Grall [Page 31] Internet-Draft Firewall MIB 24 November 1997 SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Source IP address as provided in an IP packet." ::= { type1NetEventsLogEntry 3 } type1NetEventMappedSrcIpAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Source IP address after network address translation has been applied." ::= { type1NetEventsLogEntry 4 } type1NetEventDstIpAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Destination IP address as provided in an IP packet or by a service user." ::= { type1NetEventsLogEntry 5 } type1NetEventMappedDstIpAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Destination IP address after network address translation has been applied." ::= { type1NetEventsLogEntry 6 } type1NetEventICMPCommand OBJECT-TYPE SYNTAX INTEGER { echoreply(0), destunreach(3), sourcequench(4), redirect(5), Grall [Page 32] Internet-Draft Firewall MIB 24 November 1997 echo(8), timeexceeded(11), paramprob(12), timestamp(13), timestampreply(14), mask(17), maskreply(18), traceroute(30), notICMP(41) } MAX-ACCESS read-only STATUS current DESCRIPTION "Enumeration of the most common types of ICMP packets, the numbers used above represent the ICMP Type number currently assigned by IANA." ::= { type1NetEventsLogEntry 7 } type1NetEventGenericService OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The identification of the type of service notifying about the event. This value may be chosen from the spfw.service or vendor specific trees. The description in serviceInformation can be used to designate a particular service from within this service type." ::= { type1NetEventsLogEntry 8 } type1NetEventServiceInformation OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "Specific service information. This can be used to designate the particular service within a genericService type and/or it can designate whether the service is a local service or a gateway service. For example, if the value for genericService is service.svcLogin.telnet, then the string provided might be 'local telnet'." ::= { type1NetEventsLogEntry 9 } Grall [Page 33] Internet-Draft Firewall MIB 24 November 1997 type1NetEventActionReason OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "A detailed description of the reason the ruleAction took place. Could be a copy of the rule used." ::= { type1NetEventsLogEntry 10 } -- TYPE 2 NETWORK EVENTS LOG -- -- A details table with more than minimal information, it can be used to -- record events at the transport level or when the service is not known. type2NetEventsLog OBJECT IDENTIFIER ::= { fwevent 3 } type2NetEventsLogTableLastValidRow OBJECT-TYPE SYNTAX INTEGER(1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The index value of the last valid row in the type2NetEventsLogTable." ::= { type2NetEventsLog 1 } type2NetEventsLogTable OBJECT-TYPE SYNTAX SEQUENCE OF Type2NetEventsLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of detailed data for transport events." ::= { type2NetEventsLog 2 } type2NetEventsLogEntry OBJECT-TYPE SYNTAX Type2NetEventsLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing detailed information about an event." Grall [Page 34] Internet-Draft Firewall MIB 24 November 1997 INDEX { type2NetEventLogIndex } ::= { type2NetEventsLogTable 1 } Type2NetEventsLogEntry ::= SEQUENCE { type2NetEventLogIndex INTEGER(1..2147483647), type2NetEventProtocol ProtocolUnitTC, type2NetEventSrcIpAddress IpAddress, type2NetEventMappedSrcIpAddress IpAddress, type2NetEventDstIpAddress IpAddress, type2NetEventMappedDstIpAddress IpAddress, type2NetEventSrcIpPort INTEGER(0..65535), type2NetEventMappedSrcIpPort INTEGER(0..65535), type2NetEventDstIpPort INTEGER(0..65535), type2NetEventMappedDstIpPort INTEGER(0..65535), type2NetEventGenericService OBJECT IDENTIFIER, type2NetEventServiceInformation Utf8String, type2NetEventRuleID INTEGER(0..65535), type2NetEventActionReason Utf8String } type2NetEventLogIndex OBJECT-TYPE SYNTAX INTEGER(1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "An index that uniquely identifies an entry in the log table. These indices are assigned beginning with 1 and increase by one with each new log entry. The agent may choose to delete the instances of basicEventEntry as required because of lack of memory. It is an implementation specific matter as to when this deletion may occur and as to which log entries are deleted." ::= { type2NetEventsLogEntry 1 } type2NetEventProtocol OBJECT-TYPE SYNTAX ProtocolUnitTC MAX-ACCESS read-only STATUS current DESCRIPTION "Enumeration of possible network protocols." ::= { type2NetEventsLogEntry 2 } type2NetEventSrcIpAddress OBJECT-TYPE Grall [Page 35] Internet-Draft Firewall MIB 24 November 1997 SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Source IP address as provided in an IP packet." ::= { type2NetEventsLogEntry 3 } type2NetEventMappedSrcIpAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Source IP address after network address translation has been applied." ::= { type2NetEventsLogEntry 4 } type2NetEventDstIpAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Destination IP address as provided in an IP packet or by a service user." ::= { type2NetEventsLogEntry 5 } type2NetEventMappedDstIpAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Destination IP address after network address translation has been applied." ::= { type2NetEventsLogEntry 6 } type2NetEventSrcIpPort OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION Grall [Page 36] Internet-Draft Firewall MIB 24 November 1997 "Source UDP/TCP port as provided in an IP packet." ::= { type2NetEventsLogEntry 7 } type2NetEventMappedSrcIpPort OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "Source UDP/TCP port after any port translation or change has been applied." ::= { type2NetEventsLogEntry 8 } type2NetEventDstIpPort OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "Destination UDP/TCP port as provided in an IP packet or by a service user." ::= { type2NetEventsLogEntry 9 } type2NetEventMappedDstIpPort OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "Destination UDP/TCP port after any port translation or change has been applied." ::= { type2NetEventsLogEntry 10 } type2NetEventGenericService OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The identification of the type of service notifying about the event. This value may be chosen from the spfw.service or vendor specific trees. The description in serviceInformation can be used to designate a particular service from within this service type." Grall [Page 37] Internet-Draft Firewall MIB 24 November 1997 ::= { type2NetEventsLogEntry 11 } type2NetEventServiceInformation OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "Specific service information. This can be used to designate the particular service within a genericService type and/or it can designate whether the service is a local service or a gateway service. For example, if the value for genericService is service.svcLogin.telnet, then the string provided might be 'local telnet'." ::= { type2NetEventsLogEntry 12 } type2NetEventRuleID OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "Integer representation of rule identifier. How to interpret the number provided is defined by the firewall vendor." ::= { type2NetEventsLogEntry 13 } type2NetEventActionReason OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "A detailed description of the reason the ruleAction took place. Could be a copy of the rule used." ::= { type2NetEventsLogEntry 14 } -- TYPE 3 NETWORK EVENTS LOG -- -- A details table with a large amount of information. It can be used to -- record details for events at the application level. type3NetEventsLog OBJECT IDENTIFIER ::= { fwevent 4 } Grall [Page 38] Internet-Draft Firewall MIB 24 November 1997 type3NetEventsLogTableLastValidRow OBJECT-TYPE SYNTAX INTEGER(1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The index value of the last valid row in the type3NetEventsLogTable." ::= { type3NetEventsLog 1 } type3NetEventsLogTable OBJECT-TYPE SYNTAX SEQUENCE OF Type3NetEventsLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of detailed data for transport events." ::= { type3NetEventsLog 2} type3NetEventsLogEntry OBJECT-TYPE SYNTAX Type3NetEventsLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing detailed information about an event." INDEX { type3NetEventLogIndex } ::= { type3NetEventsLogTable 1 } Type3NetEventsLogEntry ::= SEQUENCE { type3NetEventLogIndex INTEGER(1..2147483647), type3NetEventProtocol ProtocolUnitTC, type3NetEventSrcIpAddress IpAddress, type3NetEventMappedSrcIpAddress IpAddress, type3NetEventDstIpAddress IpAddress, type3NetEventMappedDstIpAddress IpAddress, type3NetEventSrcIpPort INTEGER(0..65535), type3NetEventMappedSrcIpPort INTEGER(0..65535), type3NetEventDstIpPort INTEGER(0..65535), type3NetEventMappedDstIpPort INTEGER(0..65535), type3NetEventGenericService OBJECT IDENTIFIER, type3NetEventServiceInformation Utf8String, type3NetEventAuthdEntity Utf8String, type3NetEventRuleID INTEGER(0..65535), type3NetEventActionReason Utf8String Grall [Page 39] Internet-Draft Firewall MIB 24 November 1997 } type3NetEventLogIndex OBJECT-TYPE SYNTAX INTEGER(1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "An index that uniquely identifies an entry in the log table. These indices are assigned beginning with 1 and increase by one with each new log entry. The agent may choose to delete the instances of basicEventEntry as required because of lack of memory. It is an implementation specific matter as to when this deletion may occur and as to which log entries are deleted." ::= { type3NetEventsLogEntry 1 } type3NetEventProtocol OBJECT-TYPE SYNTAX ProtocolUnitTC MAX-ACCESS read-only STATUS current DESCRIPTION "Enumeration of possible network protocols." ::= { type3NetEventsLogEntry 2 } type3NetEventSrcIpAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Source IP address as provided in an IP packet." ::= { type3NetEventsLogEntry 3 } type3NetEventMappedSrcIpAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Source IP address after network address translation has been applied." Grall [Page 40] Internet-Draft Firewall MIB 24 November 1997 ::= { type3NetEventsLogEntry 4 } type3NetEventDstIpAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Destination IP address as provided in an IP packet or by a service user." ::= { type3NetEventsLogEntry 5 } type3NetEventMappedDstIpAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Destination IP address after network address translation has been applied." ::= { type3NetEventsLogEntry 6 } type3NetEventSrcIpPort OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "Source UDP/TCP port as provided in an IP packet." ::= { type3NetEventsLogEntry 7 } type3NetEventMappedSrcIpPort OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "Source UDP/TCP port after any port translation or change has been applied." ::= { type3NetEventsLogEntry 8 } type3NetEventDstIpPort OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-only Grall [Page 41] Internet-Draft Firewall MIB 24 November 1997 STATUS current DESCRIPTION "Destination UDP/TCP port as provided in an IP packet or by a service user." ::= { type3NetEventsLogEntry 9 } type3NetEventMappedDstIpPort OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "Destination UDP/TCP port after any port translation or change has been applied." ::= { type3NetEventsLogEntry 10 } type3NetEventGenericService OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The identification of the type of service notifying about the event. This value may be chosen from the spfw.service or vendor specific trees. The description in serviceInformation can be used to designate a particular service from within this service type." ::= { type3NetEventsLogEntry 11 } type3NetEventServiceInformation OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "Specific service information. This can be used to designate the particular service within a genericService type and/or it can designate whether the service is a local service or a gateway service. For example, if the value for genericService is service.svcLogin.telnet, then the string provided might be 'local telnet'." ::= { type3NetEventsLogEntry 12 } Grall [Page 42] Internet-Draft Firewall MIB 24 November 1997 type3NetEventAuthdEntity OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "A userid, username, processid or other identifier for the entity using the service. If there is no such information then 'none' may be provided." ::= { type3NetEventsLogEntry 13 } type3NetEventRuleID OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "INTEGER representation of a rule identifier. How to interpret the number provided is defined by the firewall vendor. Eg., it may represent a configuration line number in a file, or a rule number in a table." ::= { type3NetEventsLogEntry 14 } type3NetEventActionReason OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "A detailed description of the reason the ruleAction took place. Could be a copy of the rule used." ::= { type3NetEventsLogEntry 15 } -- HEALTH EVENTS LOG -- -- This table is used for events related to the firewall's health and -- status. The events can be for hardware or software resources. healthEventsLog OBJECT IDENTIFIER ::= { fwevent 5 } healthEventsLogTableLastValidRow OBJECT-TYPE SYNTAX INTEGER(1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION Grall [Page 43] Internet-Draft Firewall MIB 24 November 1997 "The index value of the last valid row in the healthEventsLogTable." ::= { healthEventsLog 1 } healthEventsLogTable OBJECT-TYPE SYNTAX SEQUENCE OF HealthEventsLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of detailed data for firewall health events." ::= { healthEventsLog 2 } healthEventsLogEntry OBJECT-TYPE SYNTAX HealthEventsLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing detailed information about a health event." INDEX { healthEventLogIndex } ::= { healthEventsLogTable 1 } HealthEventsLogEntry ::= SEQUENCE { healthEventLogIndex INTEGER(1..2147483647), healthEventResourceType OBJECT IDENTIFIER, healthEventResourceDetails Utf8String, healthEventProblemDetail Utf8String } healthEventLogIndex OBJECT-TYPE SYNTAX INTEGER(1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "An index that uniquely identifies an entry in the log table. These indices are assigned beginning with 1 and increase by one with each new log entry. The agent may choose to delete the instances of basicEventEntry as required because of lack of memory. It is an implementation specific matter as to when this deletion may occur and as to which log entries are deleted." Grall [Page 44] Internet-Draft Firewall MIB 24 November 1997 ::= { healthEventsLogEntry 1 } healthEventResourceType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The identification of the type of resource notifying about the problem. This value may be chosen from the spfw.service or vendor specific trees. The description in ResourceDetails can be used to designate a particular service from within this service type." ::= { healthEventsLogEntry 2 } healthEventResourceDetails OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "Specific resource information. This can be used to designate the particular service within a resourceType OID." ::= { healthEventsLogEntry 3 } healthEventProblemDetail OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "Details on the problem being reported. Used if more detail is needed to interpret resourceStatus." ::= { healthEventsLogEntry 5 } -- MANAGEMENT EVENTS LOG -- -- This table is used for reporting events related to management of the -- firewall. managementEventsLog OBJECT IDENTIFIER ::= { fwevent 6 } managementEventsLogTableLastValidRow OBJECT-TYPE SYNTAX INTEGER(1..2147483647) Grall [Page 45] Internet-Draft Firewall MIB 24 November 1997 MAX-ACCESS read-only STATUS current DESCRIPTION "The index value of the last valid row in the managementEventsLogTable." ::= { managementEventsLog 1 } managementEventsLogTable OBJECT-TYPE SYNTAX SEQUENCE OF ManagementEventsLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of detailed data for firewall management events." ::= { managementEventsLog 2 } managementEventsLogEntry OBJECT-TYPE SYNTAX ManagementEventsLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing detailed information about a management event." INDEX { managementEventLogIndex } ::= { managementEventsLogTable 1 } ManagementEventsLogEntry ::= SEQUENCE { managementEventLogIndex INTEGER(1..2147483647), managementEventSubjectName Utf8String, managementEventSubjectAction EventTypeUnitTC, managementEventActionDetail Utf8String, managementEventObjectManaged OBJECT IDENTIFIER } managementEventLogIndex OBJECT-TYPE SYNTAX INTEGER(1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "An index that uniquely identifies an entry in the log table. These indices are assigned beginning with 1 and increase by one with each Grall [Page 46] Internet-Draft Firewall MIB 24 November 1997 new log entry. The agent may choose to delete the instances of basicEventEntry as required because of lack of memory. It is an implementation specific matter as to when this deletion may occur and as to which log entries are deleted." ::= { managementEventsLogEntry 1 } managementEventSubjectName OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "The userid, processid, or other unique information that designates which subject is causing the management event event." ::= { managementEventsLogEntry 2 } managementEventSubjectAction OBJECT-TYPE SYNTAX EventTypeUnitTC MAX-ACCESS read-only STATUS current DESCRIPTION "What a subject did on the firewall." ::= { managementEventsLogEntry 3 } managementEventActionDetail OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "Details on the management event based on the subjectAction chosen." ::= { managementEventsLogEntry 4 } managementEventObjectManaged OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The identification of the type of resource begin managed. Grall [Page 47] Internet-Draft Firewall MIB 24 November 1997 This value may be chosen from the spfw.service or vendor specific trees. The description in managementEventSubjectActionDetail can be used to designate a particular service from within this service type." ::= { managementEventsLogEntry 5 } -- -- fwquery group -- -- The query group defines status and statistical data at the firewall. -- The data included here concentrates on variables not covered by -- other MIBs. -- All data is designated as read-only. Changes to a firewall's -- configuration or any of the data here is assumed to take place via -- a different channel. -- We encourage the firewall to support MIB-II for resource information -- when possible. To that extent, this query group does not include any -- objects that are covered by MIB-II. fwquery OBJECT IDENTIFIER ::= { spfw 3 } firewall OBJECT IDENTIFIER ::= { fwquery 1 } resource OBJECT IDENTIFIER ::= { fwquery 2 } statistic OBJECT IDENTIFIER ::= { fwquery 3 } -- The firewall product related queries fwProductName OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "The product name of the firewall." ::= { firewall 1 } fwVersionMajor OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "The major version of the firewall as a whole." ::= { firewall 2 } Grall [Page 48] Internet-Draft Firewall MIB 24 November 1997 fwVersionMinor OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "The minor version of the firewall as a whole." ::= { firewall 3 } fwOSName OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "The specific vendor's name for the operating system the firewall is running on. For Unix type operating systems this would usually be the output from 'uname -s'. For other operating systems...@?@???" ::= { firewall 4 } fwOSVersion OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "The specific vendor's version for the operating system the firewall is running on. For Unix type operating systems this would usually be the output from 'uname -r'. For other operating systems...@?@???" ::= { firewall 5 } -- The firewall module table is used to provide additional version and -- status information for firewall modules. The definition of a module -- is vendor specific. At the least the firewall should provide one row -- for this table to represent the firewall as a whole (ie, the -- value used for fwModuleType would be services.svcFirewall). For values -- in this table that the firewall module does not support (eg., the -- module does not support serial numbers), the value used would be -- "NULL". fwModuleTable OBJECT-TYPE SYNTAX SEQUENCE OF FwModuleEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Grall [Page 49] Internet-Draft Firewall MIB 24 November 1997 "Table of firewall Module entries that provide version and status information." ::= { firewall 6 } fwModuleEntry OBJECT-TYPE SYNTAX FwModuleEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing information about a module." INDEX { fwModuleType } ::= { fwModuleTable 1 } FwModuleEntry ::= SEQUENCE { fwModuleType OBJECT IDENTIFIER, fwModuleInformation Utf8String, fwModuleVersion Utf8String, fwModulePatchLevel Utf8String, fwModuleLicenseKey Utf8String, fwModuleSerialNumber Utf8String, fwModuleCfgID Utf8String, fwModuleCfgDate TimeStamp, fwModuleCfgState INTEGER } fwModuleType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "Firewall module type. This can be an OID from the services group, or the vendor can choose to define OIDs in their enterprise group." ::= { fwModuleEntry 1 } fwModuleInformation OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "Detailed information to designate the specific firewall module or service based on the type chosen for fwModuleType." Grall [Page 50] Internet-Draft Firewall MIB 24 November 1997 ::= { fwModuleEntry 2 } fwModuleVersion OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "Module Version." ::= { fwModuleEntry 3 } fwModulePatchLevel OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "Module Patch Level." ::= { fwModuleEntry 4 } fwModuleLicenseKey OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "Module license key" ::= { fwModuleEntry 5 } fwModuleSerialNumber OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "Module serial number." ::= { fwModuleEntry 6 } fwModuleCfgID OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION Grall [Page 51] Internet-Draft Firewall MIB 24 November 1997 "Module configuration ID." ::= { fwModuleEntry 7 } fwModuleCfgDate OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "Module configuration date." ::= { fwModuleEntry 8 } fwModuleCfgState OBJECT-TYPE SYNTAX INTEGER { inprogress(1), done(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Enumeration of the state the module's configuration is in." ::= { fwModuleEntry 9 } -- The resource information related queries, this table is for -- providing the status of the resources on the firewall. Resources -- can include hardware or software modules on the firewall. resourceTable OBJECT-TYPE SYNTAX SEQUENCE OF ResourceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of firewall resource entries" ::= { resource 1 } resourceEntry OBJECT-TYPE SYNTAX ResourceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Grall [Page 52] Internet-Draft Firewall MIB 24 November 1997 "An entry in the table, containing information about a resource." INDEX { resourceType } ::= { resourceTable 1 } ResourceEntry ::= SEQUENCE { resourceType OBJECT IDENTIFIER, resourceInformation Utf8String, resourceStatus EventTypeUnitTC } resourceType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "Resource type. This can be an OID from the services group, or the vendor can choose to define OIDs in their enterprise group." ::= { resourceEntry 1 } resourceInformation OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "Detailed information to designate the specific firewall resource or service based on the type chosen for resourceType. See appendix XX for suggested values in this field." ::= { resourceEntry 2 } resourceStatus OBJECT-TYPE SYNTAX EventTypeUnitTC MAX-ACCESS read-only STATUS current DESCRIPTION "Enumeration of firewall resource status/events. This list applies to hardware and software resources provided and used by the firewall." ::= { resourceEntry 3 } Grall [Page 53] Internet-Draft Firewall MIB 24 November 1997 -- The statistic related queries -- This group contains several tables, each table can be used to provide -- the indicated statistics for any firewall resource or service. The tables -- all contain rows for (and are indexed by) each service that the statistic -- applies to. -- -- The tables in this group can be used to provide statistics on: -- -- packet level data (packetStatTable) -- service level data (fwStatTable) -- -- The packetStatTable includes variables to record the number of packets -- handled by the firewall in various ways. -- @?@ complete... -- -- In all the tables, for any Counter32 objects that are not supported, -- a value of "0" is returned. packetStatTable OBJECT-TYPE SYNTAX SEQUENCE OF PacketStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of firewall packet statistic entries." ::= { statistic 1 } packetStatEntry OBJECT-TYPE SYNTAX PacketStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing information about a statistic." INDEX { packetStatServiceType } ::= { packetStatTable 1 } PacketStatEntry ::= SEQUENCE { packetStatServiceType OBJECT IDENTIFIER, packetStatServiceDetail Utf8String, packetsAccepted Counter32, packetsDropped Counter32, packetsEncrypted Counter32, packetsInvalid Counter32, Grall [Page 54] Internet-Draft Firewall MIB 24 November 1997 packetsIgnore Counter32, packetsRejected Counter32, packetsForwarded Counter32 } packetStatServiceType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The identification of the type of service notifying about the event. This value may be chosen from the spfw.service or vendor specific trees. The description in packetStatServiceDetail can be used to designate a particular service from within this service type." ::= { packetStatEntry 1 } packetStatServiceDetail OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "Specific service information. This can be used to further designate the particular service." ::= { packetStatEntry 2 } packetsAccepted OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets accepted." ::= { packetStatEntry 3 } packetsDropped OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets dropped." Grall [Page 55] Internet-Draft Firewall MIB 24 November 1997 ::= { packetStatEntry 4 } packetsEncrypted OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets encrypted." ::= { packetStatEntry 5 } packetsInvalid OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of bad (see section 4.0) packets received." ::= { packetStatEntry 6 } packetsIgnore OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of bad (see section 4.0) packets received." ::= { packetStatEntry 7 } packetsRejected OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets rejected." ::= { packetStatEntry 8 } packetsForwarded OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets forwarded." Grall [Page 56] Internet-Draft Firewall MIB 24 November 1997 ::= { packetStatEntry 9 } -- The Firewall Statistics Table Definition -- -- This table can be used to provide the statistics -- for any firewall resource or service. This table contains rows for -- (and are indexed by) each service that the statistic applies to -- and by the type of statistic. -- -- This table can be used to provide statistics on any of the events -- that are also reported via traps, as well as any other events included -- in EventTypeUnitTC. For example to report on: -- -- - procotol or connection type data -- @?@ ex. here... -- - application type data -- @?@ ex. here... -- -- The table contains a column to provide details about the statistic -- being reported on. So for example if the statistic is for a particular -- user, this can be provided in the fwStatisticDescription. fwStatTable OBJECT-TYPE SYNTAX SEQUENCE OF FwStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of firewall statistic entries." ::= { statistic 2 } fwStatEntry OBJECT-TYPE SYNTAX FwStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing information about a firewall statistic." INDEX { fwStatServiceType, fwStatType } ::= { fwStatTable 1 } FwStatEntry ::= SEQUENCE { fwStatServiceType OBJECT IDENTIFIER, fwStatServiceInformation Utf8String, Grall [Page 57] Internet-Draft Firewall MIB 24 November 1997 fwStatType EventTypeUnitTC, fwStatValue Counter32, fwStatDescription Utf8String, fwStatStartTime TimeStamp, fwStatElapsedTime Counter32 } fwStatServiceType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The identification of the type of service notifying about the event. This value may be chosen from the spfw.service or vendor specific trees. The description in fwStatServiceInformation can be used to designate a particular service from within this service type." ::= { fwStatEntry 1 } fwStatServiceInformation OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "Specific service information. This can be used to designate the particular service." ::= { fwStatEntry 2 } fwStatType OBJECT-TYPE SYNTAX EventTypeUnitTC MAX-ACCESS read-only STATUS current DESCRIPTION "The type of statistic this row is reporting on. This along with fwStatServiceType provides a unique index into the table." ::= { fwStatEntry 3 } fwStatValue OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION Grall [Page 58] Internet-Draft Firewall MIB 24 November 1997 "A count of fwStatType events." ::= { fwStatEntry 4 } fwStatDescription OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "A more detailed description of the statistic provided in case the fwStatType does not give a good indication of what the count in fwStatValue represents." ::= { fwStatEntry 5 } fwStatStartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The time the statistic gathering for this particular statistic was started." ::= { fwStatEntry 6 } fwStatElapsedTime OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The elapsed time in seconds since fwStatStartTime that this particular statistic was collected." ::= { fwStatEntry 7 } -- -- fwtrap group -- -- The fwtrap group defines the trap types that a firewall may -- send. fwtrap OBJECT IDENTIFIER ::= { spfw 4 } Grall [Page 59] Internet-Draft Firewall MIB 24 November 1997 -- Traps are defined using the conventions in SNMPv2-SMI -- -- The networkEventTrap is used for events related to the network -- operation in the firewall. This includes packet screening events and -- serviceevents. Thetrap contains OID and row indexes of both the -- details table and the vendor private table. Then the management -- station can choose to access the event details without having to query -- the base table. networkEventTrap NOTIFICATION-TYPE OBJECTS { basicEventLogIndex, basicEventTime, basicEventSource, basicEventType, basicEventDescription, basicEventDetailsTable, basicEventDetailsTableIndex, basicEventVendorPrivateDetailsTable, basicEventVendorPrivateDetailsTableIndex } STATUS current DESCRIPTION "Network event notification from network components" ::= { fwtrap 1 } -- Example use: see introduction. -- The healthEventTrap is used for events related to configuration problems, -- resource problems, service problems, and system problems. healthEventTrap NOTIFICATION-TYPE OBJECTS { basicEventLogIndex, basicEventTime, basicEventSource, basicEventType, basicEventDescription, basicEventDetailsTable, basicEventDetailsTableIndex, basicEventVendorPrivateDetailsTable, basicEventVendorPrivateDetailsTableIndex } STATUS current DESCRIPTION Grall [Page 60] Internet-Draft Firewall MIB 24 November 1997 "Notification on events concerning the status and health of the firewall" ::= { fwtrap 2 } -- Example use: see introduction. -- The managementEventTrap is for events that relate to configuration -- changes, operating system changes, and patches to components on the -- firewall. managementEventTrap NOTIFICATION-TYPE OBJECTS { basicEventLogIndex, basicEventTime, basicEventSource, basicEventType, basicEventDescription, basicEventDetailsTable, basicEventDetailsTableIndex, basicEventVendorPrivateDetailsTable, basicEventVendorPrivateDetailsTableIndex } STATUS current DESCRIPTION "Notification of a configuration related event." ::= { fwtrap 3 } -- Example use: see introduction. -- conformance information, see RFC1444 spfwConformance OBJECT IDENTIFIER ::= { spfw 5 } fwCompliances OBJECT IDENTIFIER ::= { spfwConformance 1 } fwGroups OBJECT IDENTIFIER ::= { spfwConformance 2 } -- compliance statements fwCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities which implement the Firewall MIB." Grall [Page 61] Internet-Draft Firewall MIB 24 November 1997 MODULE -- this module GROUP basicEventsLogGroup DESCRIPTION "If the firewall will be sending traps, then the basicEventsLog group is mandatory." ::= { fwCompliances 1 } -- units of conformance basicEventsLogGroup OBJECT-GROUP OBJECTS { basicEventsLogTableLastValidRow, basicEventLogIndex, basicEventTime, basicEventSource, basicEventType, basicEventDescription, basicEventDetailsTable, basicEventDetailsTableIndex, basicEventVendorPrivateDetailsTable, basicEventVendorPrivateDetailsTableIndex } STATUS current DESCRIPTION "A collection of objects allowing the description of events occurring on a firewall." ::= { fwGroups 1 } otherEventsLogGroup OBJECT-GROUP OBJECTS { type1NetEventsLogTableLastValidRow, type1NetEventLogIndex, type1NetEventProtocol, type1NetEventSrcIpAddress, type1NetEventMappedSrcIpAddress, type1NetEventDstIpAddress, type1NetEventMappedDstIpAddress, type1NetEventICMPCommand, type1NetEventGenericService, type1NetEventServiceInformation, type1NetEventActionReason, type2NetEventsLogTableLastValidRow, type2NetEventLogIndex, type2NetEventProtocol, type2NetEventSrcIpAddress, type2NetEventMappedSrcIpAddress, type2NetEventDstIpAddress, type2NetEventMappedDstIpAddress, type2NetEventSrcIpPort, type2NetEventMappedSrcIpPort, type2NetEventDstIpPort, type2NetEventMappedDstIpPort, type2NetEventRuleID, type2NetEventActionReason, type2NetEventGenericService, type2NetEventServiceInformation, type3NetEventsLogTableLastValidRow, type3NetEventLogIndex, type3NetEventProtocol, type3NetEventSrcIpAddress, type3NetEventMappedSrcIpAddress, type3NetEventDstIpAddress, type3NetEventMappedDstIpAddress, type3NetEventSrcIpPort, type3NetEventMappedSrcIpPort, type3NetEventDstIpPort, Grall [Page 62] Internet-Draft Firewall MIB 24 November 1997 type3NetEventMappedDstIpPort, type3NetEventGenericService, type3NetEventServiceInformation, type3NetEventAuthdEntity, type3NetEventRuleID, type3NetEventActionReason, healthEventsLogTableLastValidRow, healthEventLogIndex, healthEventResourceType, healthEventResourceDetails, healthEventProblemDetail, managementEventsLogTableLastValidRow, managementEventLogIndex, managementEventSubjectName, managementEventSubjectAction, managementEventActionDetail, managementEventObjectManaged } STATUS current DESCRIPTION "A collection of objects allowing the description of event details occurring on a firewall." ::= { fwGroups 2 } fwqueryGroup OBJECT-GROUP OBJECTS { fwProductName, fwVersionMajor, fwVersionMinor, fwOSName, fwOSVersion, fwModuleType, fwModuleInformation, fwModuleVersion, fwModulePatchLevel, fwModuleLicenseKey, fwModuleSerialNumber, fwModuleCfgID, fwModuleCfgDate, fwModuleCfgState, resourceType, resourceInformation, resourceStatus, packetStatServiceType, packetStatServiceDetail, packetsAccepted, packetsDropped, packetsEncrypted, packetsInvalid, packetsIgnore, packetsRejected, packetsForwarded, fwStatServiceType, fwStatServiceInformation, fwStatType, fwStatValue, fwStatDescription, fwStatStartTime, fwStatElapsedTime } STATUS current DESCRIPTION "A collection of objects allowing the collection of information about the firewall." ::= { fwGroups 3 } END Contributing authors: Grall [Page 63] Internet-Draft Firewall MIB 24 November 1997 Lee Brown Holly Ding Dorit Dor Dale Lancaster Ken Laube Herbert Lin Ian McDonnell Thomas Oeser Ashok Nadkarni Poornima Rao Ephraim Vider Michael Wittig 6. References [1] Cerf, V., "IAB Recommendations for the Development of Internet Net- work Management Standards", RFC 1052, NRI, April 1988. [2] Cerf, V., "Report of the Second Ad Hoc Network Management Review Group", RFC 1109, NRI, August 1989. [3] Rose M., and K. McCloghrie, "Structure and Identification of Manage- ment Information for TCP/IP-based internets", STD 16, RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990. [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996. [5] McCloghrie K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets", STD 17, RFC 1213, Performance Systems International, March 1991. [6] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [7] SNMPv2 working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Net- work Management Protocol (SNMPv2)", RFC 1905, January 1996. [8] McCloghrie, K., and F. Kastenholz, "Evolution of the Interfaces Grall [Page 64] Internet-Draft Firewall MIB 24 November 1997 Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software, Janu- ary 1994. [9] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), Interna- tional Organization for Standardization. International Standard 8824, (December, 1987). [10] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization. Interna- tional Standard 8825, (December, 1987). [11] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. [12] Rose, M., Editor, "A Convention for Defining Traps for use with the SNMP", RFC 1215, Performance Systems International, March 1991. [13] F. Yergeau, "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996. 7. Security Considerations Security issues are not discussed in this memo. 8. Author's Address Cindy Grall Trusted Information Systems 3415 S. Sepulvida Blvd., suite 700 Los Angeles, CA 90034 Phone: (310) 737-1744 EMail: grall@tis.com Appendix A: Sample Configurations and Scripts This appendix will contain configuration and script samples for using this MIB with some popular SNMP management products. Security Considerations ........................................... 65 Grall [Page 65] Internet-Draft Firewall MIB 24 November 1997 Author's Address .................................................. 65 Appendix A: Sample Configurations and Scripts ..................... 65 Grall [Page 66] --=====================_879823291==_ Content-Type: text/plain; charset="us-ascii" Herbert Lin Manager, Software Development Mail Stop: 20/6D GTE Internetworking, Powered by BBN 150 CambridgePark Drive Cambridge, MA 02138 E-mail: hlin@bbnplanet.com Tel: 617-873-5920 Fax: 617-873-6846 --=====================_879823291==_-- From daemon Tue Nov 18 03:25:38 1997 Delivery-Date: Tue, 18 Nov 1997 03:29:43 -0500 Return-Path: daemon Received: (from daemon@localhost) by ietf.org (8.8.7/8.8.7a) id DAA02716 for ietf-outbound.10@ietf.org; Tue, 18 Nov 1997 03:24:49 -0500 (EST) Received: from aun.uninett.no (aun.uninett.no [129.241.1.99]) by ietf.org (8.8.7/8.8.7a) with ESMTP id DAA02701; Tue, 18 Nov 1997 03:24:43 -0500 (EST) Received: from dale.uninett.no by aun.uninett.no with SMTP (PP); Tue, 18 Nov 1997 09:23:50 +0100 Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.12) with ESMTP id JAA18937; Tue, 18 Nov 1997 09:24:12 +0100 X-Mailer: exmh version 1.6.9 8/22/96 From: Harald.T.Alvestrand@UNINETT.NO To: Herbert Lin cc: fred@cisco.com, Keith Moore , jcurran@bbn.com, ietf@ietf.org, solo@bbn.com, ietf-web@ietf.org, cclingen@tis.com, grall@tis.com, marvind@tis.com, ishikawa@tis.com, mwittig@mail.cybg.com, lbrown@mail.cybg.com, anadkarni@raptor.com, rmoorman@raptor.com, dlancaster@raptor.com, Thomas.Oeser@mch.sni.de, nir@checkpoint.com, dorit@checkpoint.com, poornima@us.checkpoint.com, tari@us.checkpoint.com, udi@checkpoint.com, hding@bbnplanet.com, sseltser@bbnplanet.com, jbrooks@bbn.com, Jack Danahy , laube@bbnplanet.com, dchouinard@ideal.jf.intel.com, eff@checkpoint.com, jjones@tis.com Subject: Re: Request for IETF Work Group Meeting In-reply-to: Your message of "Mon, 17 Nov 1997 17:21:31 EST." <3.0.3.32.19971117172131.00726694@pobox3.bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Nov 1997 03:24:12 -0500 Message-ID: <18935.879841452@dale.uninett.no> Sender: hta@dale.uninett.no My immediate reactions are three: - There is no time to get a WG approved before Washington, so this will have to be treated as a BOF request - This work item belongs in the Operations & Management area, firewalls being rather a tool to stop applications from working than an application in itself. - Given that I do not see a need for the charter review, I'm not going to take the time to get the MS-Word document out of the message; a charter submission is best done in ASCII. Regards, Harald T. Alvestrand From daemon Tue Nov 18 10:47:31 1997 Delivery-Date: Tue, 18 Nov 1997 10:51:17 -0500 Return-Path: daemon Received: (from daemon@localhost) by ietf.org (8.8.7/8.8.7a) id KAA08292 for ietf-outbound.10@ietf.org; Tue, 18 Nov 1997 10:47:16 -0500 (EST) Received: from bbnplanet.com (mail.bbnplanet.com [198.114.157.21]) by ietf.org (8.8.7/8.8.7a) with SMTP id KAA08277; Tue, 18 Nov 1997 10:47:12 -0500 (EST) Received: from hlin.bbnplanet.com by mail.bbnplanet.com id aa13406; 18 Nov 97 10:44 EST Message-Id: <3.0.3.32.19971118103545.030ee560@pobox3.bbn.com> X-Sender: hlin@pobox3.bbn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 18 Nov 1997 10:35:45 -0500 To: Harald.T.Alvestrand@UNINETT.NO, John Curran , "Michael O'Dell" , Steve Coya , fred@cisco.com, Keith Moore From: Herbert Lin Subject: Re: Request for IETF Work Group Meeting Cc: fred@cisco.com, Keith Moore , jcurran@bbn.com, ietf@ietf.org, ietf-web@ietf.org, cclingen@tis.com, grall@tis.com, marvind@tis.com, ishikawa@tis.com, mwittig@mail.cybg.com, lbrown@mail.cybg.com, anadkarni@raptor.com, rmoorman@raptor.com, dlancaster@raptor.com, Thomas.Oeser@mch.sni.de, nir@checkpoint.com, dorit@checkpoint.com, poornima@us.checkpoint.com, tari@us.checkpoint.com, udi@checkpoint.com, hding@bbnplanet.com, sseltser@bbnplanet.com, jbrooks@bbn.com, Jack Danahy , laube@bbnplanet.com, dchouinard@ideal.jf.intel.com, eff@checkpoint.com, jjones@tis.com In-Reply-To: <18935.879841452@dale.uninett.no> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_879885345==_" --=====================_879885345==_ Content-Type: text/plain; charset="us-ascii" All- Please reconsider our request for IETF Work Group Meeting with the reasons below. Herbert At 03:24 AM 11/18/97 -0500, Harald.T.Alvestrand@uninett.no wrote: >My immediate reactions are three: > >- There is no time to get a WG approved before Washington, so this > will have to be treated as a BOF request > Cindy Grall (TIS) and I tried our best to formulate/revise the RFC and the Charter document revisions. Our request went out on the Date: Mon, 17 Nov 1997 17:21:31. I think we meet the deadline requirements posted by IETF listed below: Deadline dates for the 40th IETF Meeting - Washington, DC November 17 - Working Group scheduling closes at 1800 November 21 - Internet Draft submission cutoff date at 1700 November 28 - Registration Payment cutoff date at 1700 December 4 - Registration cutoff date at 1700 December 4 - Working Group agendas due date by 1700 >- This work item belongs in the Operations & Management area, firewalls > being rather a tool to stop applications from working than an application > in itself. > I discussed where this work item belongs in the 39th IETF Munich Meeting with Steve Coya and John Curran. They both suggested that Firewall MIB can belong to the Application Area. That's why I send it over for your approval yesterday. However, after review the BOF and WG sessions planned in the IETF Operations & Management Area, I can agree with your suggestion too. John Curran and Michael O'Dell , do you agree? Can you approve our request and agree to help us? >- Given that I do not see a need for the charter review, I'm not going > to take the time to get the MS-Word document out of the message; a > charter submission is best done in ASCII. > Sorry about the MS Word format document. The ASCII text formatted Firewall MIB Work Group Charter statment is attached with is e-mail. Furthermore, I do not want to repeat the RFC document for everyone in this list. I can sent it separately, if John and Michael O'Dell need it. PS. A minor correction in my original e-mail: Intel is not a firewall vendor. Thanks to David Chouinard's correction. I included it by a careless mistake; but with the intention to honor all the participants in this Firewall MIB creation effort. >Regards, > > Harald T. Alvestrand > > > > -------------------- Original request sent Nov. 17 attached below: >Date: Mon, 17 Nov 1997 17:21:31 -0500 >To: fred@cisco.com, Harald Alvestrand , Keith Moore , jcurran@bbn.com, ietf@ietf.org, solo@bbn.com, ietf-web@ietf.org >From: Herbert Lin >Subject: Request for IETF Work Group Meeting >Cc: IETF Firewall MIB Mailing List >X-Attachments: C:\Herbert\SitePartol\4.0\SNMP agent and MIB\Firewall MIB Charter.doc; C:\Herbert\SitePartol\4.0\SNMP agent and MIB\draft-ietf-fireall-mib-19.txt; > >Fred, Harald, Keith, John, and Dave, > >I am writing this request on the behalf of industry leading firewall vendors (Check Point, TIS, CyberGuard, Raptor, Intel, SNI)and managed security service provides (GTE/BBN) for your approval of a new IETF Working Group and its meeting in the 40th IETF Meeting in Washington DC. We had met together in the 39th IETF meeting in Munich and started our BOF session. Since then, we also have met 5 times on the teleconference or face-to-face in our private meetings. The attached documents are the results of our meetings: > >1. the Firewall MIB Working Group chater document >2. the Firewall MIB RFC: draft-ietf-fireall-mib-19.txt > >Please approve our application and help us set up an official place under the Application Areas in the IETF. Thank you for your help. > >Best Regards, >Herbert Lin --=====================_879885345==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="Firewall MIB Charter.txt" Firewall MIB (fwmib) Last Modified: 17-Nov-97 Chair(s): Herbert Lin Operations & Management Area Director(s): John Curran Michael O'Dell (Note: The actual IETF area which this work group will be part of is TBD) Mailing Lists: General Discussion: send e-mail to hlin@bbn.com to get/add-on the mailing list To Subscribe: send e-mail to hlin@bbn.com to get/add-on the mailing list Archive: TBS Description of Working Group: The Firewall MIB Working Group is chartered to define a set of managed objects for the monitoring of firewalls in an IP only network. Specifically, these managed objects will focus on providing information about the security (including traps to report about unusual events), health (including status information such as up, down, or degraded) and performance (including resource utilization) of firewalls. The current scope of this working group is to provide information for the purpose of monitoring firewall activity from an enterprise management console. The purpose of this MIB is not to replicate all firewall audit information e.g. suspicious activity monitoring entities would probably require audit information which would not be provided as part of this MIB. Items expected to be addressed: * Monitor a variety of information that is visible to a firewall (this includes identifying information to be monitored and addressing the correlation between such information) * Categorizing information * Unique style of reporting this information * Identification of information to be monitored * Creation of MIB objects that can be used on a variety of firewalls to obtain the information identified * Identification of traps which carry some of the objects * Discussion of possible implementation issues for support of the objects defined (i.e., in order to determine whether it is feasible to include the object in the MIB). The working group will only concern itself with the specification of MIB objects in the management areas defined above. It will not undertake to define details of implementation such as programming API's for the access to this information. The activities of the working group include the following steps. 1. Identify the basic components of Firewall MIB 2. Provide detailed descriptions of the basic components 3. Identify the mechanics of how basic components can be combined to produce new components (complex components). 4. Identify complex components 5. Define relationships between components 6. Define a detailed firewall MIB 7. Review of overall Firewall MIB architecture 8. Submit to IETF standards track (including RFC documents and reference implementations) 9. Address schedule for Firewall MIB review and changes. 10. Discussion/presentation of reference implementation issues Goals and Milestones: Aug 97 Initial meeting, BOF Munich IETF. Aug 97 Setup Firewall MIB charter Sept 97 Create initial Internet-Draft Oct 97 Review revised draft Nov 97 Post initial Internet-Draft of the Firewall MIB Nov 97 Reference Implementation of SNMP Agents based on the initial Internet-Draft of the Firewall MIB Dec 97 Meet at Washington DC IETF. Dec 97 Conduct Interoperatability Testing and review Internet-Draft in the 40th IETF Meeting Jan 98 Post revised Internet-Draft. Feb 98 Issue final Internet-Draft. Feb 98 Submit Internet-Draft to IESG for consideration as a Proposed Standard. Internet-Drafts: Firewall MIB (121,478 bytes) : See attached No Request For Comments IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org. Return to working group directory. Return to IETF home page. --=====================_879885345==_ Content-Type: text/plain; charset="us-ascii" Herbert Lin Manager, Software Development Mail Stop: 20/6D GTE Internetworking, Powered by BBN 150 CambridgePark Drive Cambridge, MA 02138 E-mail: hlin@bbnplanet.com Tel: 617-873-5920 Fax: 617-873-6846 --=====================_879885345==_-- From adm Tue Dec 16 16:45:11 1997 Delivery-Date: Tue, 16 Dec 1997 16:49:50 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id QAA08242 for ietf-outbound.10@ietf.org; Tue, 16 Dec 1997 16:45:01 -0500 (EST) Received: from bbnplanet.com (mail.bbnplanet.com [198.114.157.21]) by ns.ietf.org (8.8.7/8.8.7a) with SMTP id QAA08202; Tue, 16 Dec 1997 16:43:19 -0500 (EST) Received: from hlin.bbnplanet.com by mail.bbnplanet.com id aa06896; 16 Dec 97 16:41 EST Message-Id: <3.0.3.32.19971216163029.0313396c@pobox3.bbn.com> X-Sender: hlin@pobox3.bbn.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 16 Dec 1997 16:30:29 -0500 To: cclingen@tis.com, grall@tis.com, marvind@tis.com, ishikawa@tis.com, mwittig@mail.cybg.com, lbrown@mail.cybg.com, anadkarni@raptor.com, rmoorman@raptor.com, dlancaster@raptor.com, Thomas.Oeser@mch.sni.de, nir@checkpoint.com, dorit@checkpoint.com, poornima@us.checkpoint.com, tari@us.checkpoint.com, udi@checkpoint.com, hlin@bbnplanet.com, hding@bbnplanet.com, sseltser@bbnplanet.com, jbrooks@bbn.com, Jack Danahy , laube@bbnplanet.com, dchouinard@ideal.jf.intel.com, eff@checkpoint.com, jjones@tis.com, coram@tis.com, dtrevett@cisco.com, fred@cisco.com, Steve Coya , John Curran , Jeffrey Schiller , mcr@sandelman.ottawa.on.ca, mkrisch@bbn.com, rossetti@cisco.com, nyuan@bbn.com, cliff_wang@vnet.ibm.com, balenson@tis.com, ajaber@certicom.com, jokrent@cisco.com, sned@cisco.com From: Herbert Lin Subject: Status of Firewall MIB in the 40th IETF Meeting in DC Cc: fred@cisco.com, ietf@ns.ietf.org, jsharrow@bbnplanet.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" All, This is to report to you the status of Firewall MIB standardization effort in the 40th IETF meeting in DC. We had several new companies approached me in this DC IETF meeting and discuss their interests on this effort. They had asked me to include their names in this mailing list (and I did as you can see). I have also met with Jeffrey Schiller, Area Director of Security, IETF and officially requests to standardize Firewall MIB. I showed him that we would like to be a working group in the LA IETF Meeting on March. He promised me to review our Charter Statements and the contributed document Firewall MIB (v.1.9). Many people had asked me about our Charter statements and the Firewall MIB. Both documents can be found in the web site we had just set up with the following URL: http://cso.bbnplanet.com/ietf/ The ASCII format of the firewall MIB can also be found in the IETF official Web Site with the following URL: ftp://ietf.org/internet-drafts/draft-grall-firewall-mib-00.txt I am in the process of create an mailing list for anyone in the IETF community to subscribe to the discussion group mailing list automatically. This will be announced in the above GTE web site as well as notification through e-mail. Meanwhile, please submit your subscriptions to me or Cindy and use the above mailing list for our discussion. Currently, TIS and GTE have (partially) completed their reference implementation and started their interoperatability testing. I am also aware of that Check Point might also has started their reference implementation. If you have done some reference implementation as an SNMP agent on the Firewall side, and would like to conduct the interoperatability testing with the management (monitoring) systems, please drop me an e-mail. Thanks for your support. Best Regards, Herbert Lin Manager, Software Development Mail Stop: 20/6D GTE Internetworking, Powered by BBN 150 CambridgePark Drive Cambridge, MA 02138 E-mail: hlin@bbnplanet.com Tel: 617-873-5920 Fax: 617-873-6846 From cclark Wed May 27 09:11:27 1998 Delivery-Date: Wed, 27 May 1998 09:20:06 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id JAA00541 for ietf-outbound.10@ietf.org; Wed, 27 May 1998 09:10:02 -0400 (EDT) Received: from relay.hq.tis.com (relay.hq.tis.com [192.94.214.100]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA00149 for ; Wed, 27 May 1998 08:54:28 -0400 (EDT) Received: by relay.hq.tis.com; id IAA15643; Wed, 27 May 1998 08:50:48 -0400 (EDT) Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (4.0a) id xma015610; Wed, 27 May 98 08:49:55 -0400 Received: from balenson.hq.tis.com (balenson.hq.tis.com [10.33.80.11]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id IAA11159; Wed, 27 May 1998 08:44:44 -0400 (EDT) Message-Id: <199805271244.IAA11159@clipper.hq.tis.com> X-Sender: balenson@pop.hq.tis.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 27 May 1998 08:52:07 -0400 To: ids@uow.edu.au, firewalls@greatcircle.com, cat-ietf@mit.edu, ietf@ietf.org, ipsec@tis.com, dns-security@tis.com, www-security@ns2.rutgers.edu, www-buyinfo@allegra.att.com, ietf-otp@bellcore.com, pem-dev@tis.com, virus-l@lehigh.edu, ietf-pkix@tandem.com, spki@c2.net, ietf-tls@consensus.com, ietf-open-pgp@IMC.ORG, ietf-smime@IMC.ORG, aft@socks.nec.com, ietf-radius@livingston.com, ietf-ssh@clinet.fi, OGsecurity@OPENGROUP.ORG, cryptography@c2.net, risks@csl.sri.com From: "David M. Balenson" Subject: CFP: 1999 Network & Distributed System Security Symposium (NDSS '99) Cc: balenson@tis.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_896287927==_" --=====================_896287927==_ Content-Type: text/plain; charset="us-ascii" --=====================_896287927==_ Content-Type: text/plain; charset="us-ascii" C A L L F O R P A P E R S The Internet Society 1999 Network and Distributed System Security Symposium (NDSS'99) Where: Catamaran Resort, San Diego, California When: February 3-5, 1999 GOAL: The symposium will foster information exchange among hardware and software developers of network and distributed system security services. The intended audience includes those who are interested in the practical aspects of network and distributed system security, focusing on actual system design and implementation, rather than theory. A major goal of the symposium is to encourage and enable the Internet community to apply, deploy, and advance the state of available security technology. The proceedings of the symposium will be published by the Internet Society. Topics for the symposium include, but are not limited to, the following: * Security in malleable systems: mobile code, mobile agents, active networks, dynamic policy updates, etc. * Special problems: e.g. interplay between security goals and other goals such as efficiency, usability, reliability, interoperability, resource sharing, and cost. * Integrating security services with system and application security facilities and with application protocols, including message handling, file transport, remote file access, directories, time synchronization, data base management, routing, voice and video multicast, network management, boot services, and mobile computing. * Fundamental services: authentication, integrity, confidentiality, authorization, non-repudiation, and availability. * Supporting mechanisms and APIs: key management and certification infrastructures, audit, and intrusion detection. * Telecommunications security, especially for emerging technologies -- very large systems, e.g., the Internet, high-speed systems, e.g., the gigabit testbeds, wireless systems, personal communication systems, and large-scale, heterogeneous distributed systems. * Controls: firewalls, packet filters, application gateways * Object security and security objects * Network information resources and tools such as World Wide Web (WWW), Gopher, archie, and WAIS. * Electronic commerce: payment services, fee-for-access, EDI, notary services; endorsement, licensing, bonding, and other forms of assurance; rights management and other forms of intellectual property protection * Implementation and management of network security policy * Security for voice over IP * Security for routing GENERAL CHAIR: Stephen Welke, Trusted Computer Solutions PROGRAM CHAIRS: Stephen Kent, BBN Technologies Gene Tsudik, USC/Information Sciences Institute TUTORIAL CHAIR: Doug Maughan, National Security Agency PROGRAM COMMITTEE: David Balenson, TIS Labs at Network Associates Steve Bellovin, AT&T Labs -- Research Matt Bishop, University of California at Davis Bob Blakley, IBM Doug Engert, Argonne National Laboratories Warwick Ford, VeriSign Li Gong, Sun Microsystems Rich Graveman, Bellcore Ari Juels, RSA Laboratories Tom Longstaff, CERT Doug Maughan, National Security Agency Dan Nessett, 3Com Corporation Michael Roe, Cambridge University Jeffrey Schiller, MIT Wolfgang Schneider, GMD Darmstadt Christoph Schuba, Purdue University Win Treese, Open Market Jonathan Trostle, Cisco LOCAL ARRANGEMENTS CHAIR: Thomas Hutton, San Diego Supercomputer Center PUBLICATIONS CHAIR: John Kochmar, SEI PUBLICITY CHAIR: David Balenson, TIS Labs at Network Associates LOGISTICS CHAIR: Carla Rosenfeld, Internet Society REGISTRATIONS CHAIR Beth Strait, Internet Society SUBMISSIONS: The committee invites technical papers and panel proposals, for topics of technical and general interest. Technical papers should be 10-20 pages in length. Panel proposals should be two pages and should describe the topic, identify the panel chair, explain the format of the panel, and list three to four potential panelists. Technical papers will appear in the proceedings. A description of each panel will appear in the proceedings, and may at the discretion of the panel chair, include written position statements from each panelist. Each submission must contain a separate title page with the type of submission (paper or panel), the title or topic, the names of the author(s), organizational affiliation(s), telephone and FAX numbers, postal addresses, Internet electronic mail addresses, and must list a single point of contact if more than one author. The names of authors, affiliations, and other identifying information should appear only on the separate title page. Submissions must be received by 31 July 1998, and must be made via electronic mail in either PostScript or ASCII format. If the committee is unable to print a PostScript submission, it will be returned and hardcopy requested. Therefore, PostScript submissions must arrive well before 31 July. All submissions and program related correspondence (only) should be directed to the program chair: Stephen Kent c/o BBN Technologies 70 Fawcett Street Cambridge, Mass. 02138 Email:sndss99-submissions@bbn.com Phone: +1 (617) 873-1996 FAX: +1 (617) 873-4086 Dates, final call for papers, advance program, and registration information will be available at the URL: http://www.isoc.org/ndss99. Each submission will be acknowledged by e-mail. If acknowledgment is not received within seven days, please contact the program chair as indicated above. Authors and panelists will be notified of acceptance by 18 September 1998. Instructions for preparing camera-ready copy for the proceedings will be sent at that time. The camera-ready copy must be received by 16 October 1998. --=====================_896287927==_ Content-Type: text/plain; charset="us-ascii" ---------------------------------------------------------------------------- David M. Balenson, Publicity Chair, NDSS '99 TIS Labs at Network Associates, Inc. 3060 Washington Road, Glenwood, MD 21738 USA balenson@tis.com; 301-854-5358; fax 301-854-5363 --=====================_896287927==_-- From cclark Wed May 27 15:02:56 1998 Delivery-Date: Wed, 27 May 1998 15:12:37 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id PAA08044 for ietf-outbound.10@ietf.org; Wed, 27 May 1998 15:00:02 -0400 (EDT) Received: from mole.slip.net (mole.slip.net [207.171.193.16]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA08010 for ; Wed, 27 May 1998 14:58:57 -0400 (EDT) Received: from eb-pm2-19-83.dialup.slip.net ([207.171.198.83] helo=207.171.198.83) by mole.slip.net with smtp (Exim 1.90 #1) id 0yelOM-0007FF-00; Wed, 27 May 1998 11:57:38 -0700 Message-ID: <356C63A5.61CC@ccnet.com> Date: Wed, 27 May 1998 12:04:05 -0700 From: Kurt Stammberger X-Mailer: Mozilla 3.01 (Macintosh; I; PPC) MIME-Version: 1.0 To: ids@uow.edu.au, firewalls@greatcircle.com, cat-ietf@mit.edu, ietf@ietf.org, ipsec@tis.com, dns-security@tis.com, www-security@ns2.rutgers.edu, www-buyinfo@allegra.att.com, ietf-otp@bellcore.com, pem-dev@tis.com, virus-l@lehigh.edu, ietf-pkix@tandem.com, spki@c2.net, ietf-tls@consensus.com, ietf-open-pgp@IMC.ORG, ietf-smime@IMC.ORG, aft@socks.nec.com, ietf-radius@livingston.com, ietf-ssh@clinet.fi, OGsecurity@OPENGROUP.ORG, cryptography@c2.net, risks@csl.sri.com Subject: RSA'99 Deadline Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dave's NDSS note reminded me to remind y'all: D E A D L I N E ! D E A D L I N E ! The Deadline for talk proposals for RSA'99 is SIX DAYS AWAY (June 1st). For more information, or to propose a talk or submit a paper for presentation, visit www.rsa.com/conf99 Questions? E-mailez-moi. Kurt Stammberger Conference Director RSADSI From cclark Wed May 27 15:41:34 1998 Delivery-Date: Wed, 27 May 1998 15:51:01 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id PAA08642 for ietf-outbound.10@ietf.org; Wed, 27 May 1998 15:40:03 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.8.5/8.8.7a) with SMTP id PAA08513 for ; Wed, 27 May 1998 15:30:00 -0400 (EDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA17338; Wed, 27 May 1998 12:25:41 -0700 Received: from basilisk.Eng.Sun.COM (basilisk.Eng.Sun.COM [129.144.49.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA01991; Wed, 27 May 1998 12:25:35 -0700 Received: from alquds by basilisk.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id MAA21067; Wed, 27 May 1998 12:25:31 -0700 Message-Id: <199805271925.MAA21067@basilisk.Eng.Sun.COM> Date: Wed, 27 May 1998 12:25:35 -0700 (PDT) From: Yahya Al-Salqan Reply-To: Yahya Al-Salqan Subject: Call for participation (FYI) To: firewalls@greatcircle.com, cat-ietf@mit.edu, ietf@ietf.org, ipsec@tis.com, dns-security@tis.com, www-security@ns2.rutgers.edu, www-buyinfo@allegra.att.com, ietf-otp@bellcore.com, pem-dev@tis.com, virus-l@lehigh.edu, ietf-pkix@tandem.com, spki@c2.net, ietf-tls@consensus.com, ietf-open-pgp@IMC.ORG, ietf-smime@IMC.ORG, aft@socks.nec.com, ietf-radius@livingston.com, ietf-ssh@clinet.fi, OGsecurity@OPENGROUP.ORG, cryptography@c2.net, risks@csl.sri.com Cc: ssl-talk@netscape.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: SCk4v9pjCPXd6BFIFnKHgg== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Today is the deadline for the early registration ... take advantage of it. My appology if you receive this e-mail more than once! ================================================= Call for Participation: IEEE WET ICE '98 Third International Workshop on Enterprise Security Stanford University, Palo Alto, USA June 17-19 1998 ================================================= On behalf of the Workshop Program and Organizing Committees, I would like to invite you to participate in The 3rd IEEE International Enterprise Security Workshop will be held June 17-19, Stanford University, Palo Alto, California. The Workshop includes paper presentations, panel discussions, keynote speeches and invited talks covering all aspects of enterprise security. Topics to be covered include: Public key infrastructure, intrusion detection, Web security, application security (e.g. digital library and healthcare), and access control. Highlights of the program: o Keynote speech by Dr. Li Gong, Java Security Architect, Sun Microsystems; o Industrial security expertise from: Microsoft NT security group, Sun Microsystems, Entrust, Certicom, Verisign, SSH Communication security and many others. It is an unprecedented opportunity to put all these companies in one room. Don't miss it. o Participation of IETF security group leaders; o Participation of NSA (National Security Agency); o Two panel discussions: - "State-of-the-art Enterprise Security: Practice and Future" - "Intrusion Detection: Present and Future" o Workshop held in conjunction with other WETICE workshops: "Web-based infrastructure for collaborative Enterprises," "Collaboration in Presence of Mobility," o Two social events. The Workshop Preliminary program can be found at: http://www.ida.liu.se/labs/iislab/SECWK/agenda.html The Registration form can be found at: http://www.cerc.wvu.edu/WETICE/WETICE98/registration.html (Please mark the Enterprise Security on the registration form) The Workshop main page can be found at: http://www.ida.liu.se/labs/iislab/SECWK/ I look forward to meeting you at the Workshop. Sincerely, Yahya Al-Salqan, Ph.D. Workshop General Chair Sun Microsystems ------------- End Forwarded Message ------------- ------------- End Forwarded Message ------------- From ipp-owner@pwg.org Tue Jun 2 11:22:21 1998 Delivery-Date: Tue, 02 Jun 1998 11:22:21 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA25709 for ; Tue, 2 Jun 1998 11:22:16 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA08361 for ; Tue, 2 Jun 1998 11:24:37 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA06296 for ; Tue, 2 Jun 1998 11:22:09 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Jun 1998 11:17:17 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA05699 for ipp-outgoing; Tue, 2 Jun 1998 11:13:33 -0400 (EDT) Message-ID: From: "Vinod Valloppillil (Exchange)" To: "'Rob Polansky'" , "David W. Morris" Cc: http-wg , ipp@pwg.org Subject: IPP> RE: Implications of introducing new scheme and port for existing HTTP servers Date: Tue, 2 Jun 1998 08:15:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2225.0) Content-Type: text/plain Sender: owner-ipp@pwg.org Rob's argument is broadly correct -- as a long term firewall design issue, method inspection (and occasionally payload inspection) will become the rule. However, as a small carrot to today's protocol designers, the vast majority of the installed base of firewalls do no method / payload inspection on HTTP data being passed through. Purely from the perspective of 'reach' there's no impediment to IPP using it's own method in the short run. > -----Original Message----- > From: Rob Polansky [SMTP:polansky@raptor.com] > Sent: Tuesday, June 02, 1998 6:06 AM > To: David W. Morris > Cc: http-wg; ipp@pwg.org > Subject: RE: Implications of introducing new scheme and port for > existing HTTP servers > > I know of at least one :-) firewall that not only rejects unknown methods > but also examines the HTTP request method as part of its "algorithm". From > a > protocol and security perspective, it appears to be the right thing to do. > If you don't understand the method, how can you properly proxy it? Take > the > CONNECT method as an example. > > In summary, any proxy that is more than a simple packet passer (supports > CONNECT, protocol conversion, proxy authentication, etc.) runs the risk of > failing to pass IPP if it uses a new scheme and/or a new method. Not that > that's a bad thing... :-) > > -Rob Polansky > > > -----Original Message----- > > From: David W. Morris [mailto:dwm@xpasc.com] > > Sent: Monday, June 01, 1998 10:34 PM > > To: Carl-Uno Manros > > Cc: http-wg@cuckoo.hpl.hp.com; ipp@pwg.org; http-wg@hplb.hpl.hp.com > > Subject: Re: Implications of introducing new scheme and port for > > existing HTTP servers > > > > (I'm also not wild about new HTTP methods as I know of existing proxies > > which will reject unknown methods. Don't know of any which will accept > > unknown methods. I'm also unaware of any firewall software which > examines > > the HTTP request method as part of its algorithm but then I'm not a > > firewall expert.) > > From ipp-owner@pwg.org Tue Jun 2 11:41:49 1998 Delivery-Date: Tue, 02 Jun 1998 11:41:53 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA25987 for ; Tue, 2 Jun 1998 11:41:49 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA08464 for ; Tue, 2 Jun 1998 11:44:03 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA06984 for ; Tue, 2 Jun 1998 11:41:39 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Jun 1998 11:37:16 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA06412 for ipp-outgoing; Tue, 2 Jun 1998 11:34:02 -0400 (EDT) Message-Id: <199806021525.IAA09754@slafw.enet.sharplabs.com> X-Sender: rturner@admsrvnt02.enet.sharplabs.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 02 Jun 1998 08:33:48 -0700 To: "Vinod Valloppillil (Exchange)" , "'Rob Polansky'" , "David W. Morris" From: Randy Turner Subject: Re: IPP> RE: Implications of introducing new scheme and port for existing HTTP servers Cc: http-wg , ipp@pwg.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipp@pwg.org The past few comments about firewalls do not (IMHO) appear to pose a problem for IPP deployment. If the majority of the installed base of firewall products do not do HTTP method inspection then thats ok. everything would work. When the "next-generation" products that can perform this type of inspection, then during installation of this new infrastructure, the administrator will then enable IPP (or WEBDAV) or whatever at that time. Ultimately, I believe firewall admins will explicitly enable internet printing or faxing or whatever, and I don't think a firewall issue should impose undue design constraints on what we (the WG) want to do. Firewall admins already do this explicitly enabling/disabling of application protocols (POP, FTP, IMAP, etc.) and I think we're just another application. I don't think these protocol designers were too bogged down in firewall issues during the development process. At least with the Checkpoint Firewall-1 product, it takes about 45 seconds to bring up the console and enable or disable a particular application protocol. Just my (possibly more than) $0.02 Randy At 08:15 AM 6/2/98 -0700, Vinod Valloppillil (Exchange) wrote: >Rob's argument is broadly correct -- as a long term firewall design issue, >method inspection (and occasionally payload inspection) will become the >rule. > >However, as a small carrot to today's protocol designers, the vast majority >of the installed base of firewalls do no method / payload inspection on HTTP >data being passed through. Purely from the perspective of 'reach' there's >no impediment to IPP using it's own method in the short run. > >> -----Original Message----- >> From: Rob Polansky [SMTP:polansky@raptor.com] >> Sent: Tuesday, June 02, 1998 6:06 AM >> To: David W. Morris >> Cc: http-wg; ipp@pwg.org >> Subject: RE: Implications of introducing new scheme and port for >> existing HTTP servers >> >> I know of at least one :-) firewall that not only rejects unknown methods >> but also examines the HTTP request method as part of its "algorithm". From >> a >> protocol and security perspective, it appears to be the right thing to do. >> If you don't understand the method, how can you properly proxy it? Take >> the >> CONNECT method as an example. >> >> In summary, any proxy that is more than a simple packet passer (supports >> CONNECT, protocol conversion, proxy authentication, etc.) runs the risk of >> failing to pass IPP if it uses a new scheme and/or a new method. Not that >> that's a bad thing... :-) >> >> -Rob Polansky >> >> > -----Original Message----- >> > From: David W. Morris [mailto:dwm@xpasc.com] >> > Sent: Monday, June 01, 1998 10:34 PM >> > To: Carl-Uno Manros >> > Cc: http-wg@cuckoo.hpl.hp.com; ipp@pwg.org; http-wg@hplb.hpl.hp.com >> > Subject: Re: Implications of introducing new scheme and port for >> > existing HTTP servers >> > >> > (I'm also not wild about new HTTP methods as I know of existing proxies >> > which will reject unknown methods. Don't know of any which will accept >> > unknown methods. I'm also unaware of any firewall software which >> examines >> > the HTTP request method as part of its algorithm but then I'm not a >> > firewall expert.) >> > > From ipp-owner@pwg.org Tue Jun 2 20:47:17 1998 Delivery-Date: Tue, 02 Jun 1998 20:47:18 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA01679 for ; Tue, 2 Jun 1998 20:47:17 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA11266 for ; Tue, 2 Jun 1998 20:49:36 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id UAA16042 for ; Tue, 2 Jun 1998 20:47:10 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 2 Jun 1998 20:42:24 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA15465 for ipp-outgoing; Tue, 2 Jun 1998 20:37:34 -0400 (EDT) Message-ID: From: Paul Moore To: "'Randy Turner'" , "Vinod Valloppillil (Exchange)" , "'Rob Polansky'" , "David W. Morris" Cc: http-wg , ipp@pwg.org Subject: RE: IPP> RE: Implications of introducing new scheme and port for existing HTTP servers Date: Tue, 2 Jun 1998 17:37:19 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org The issue is proxies - enablers - not firewalls - disablers. If you replace my proxy by a passthrough cable I cannot do anything, if you replace my firewall by a cable you can do anything. > -----Original Message----- > From: Randy Turner [SMTP:rturner@sharplabs.com] > Sent: Tuesday, June 02, 1998 8:34 AM > To: Vinod Valloppillil (Exchange); 'Rob Polansky'; David W. Morris > Cc: http-wg; ipp@pwg.org > Subject: Re: IPP> RE: Implications of introducing new scheme and port > for existing HTTP servers > > > The past few comments about firewalls do not (IMHO) appear to pose a > problem for IPP deployment. If the majority of the installed base of > firewall products do not do HTTP method inspection then thats ok. > everything would work. When the "next-generation" products that can > perform > this type of inspection, then during installation of this new > infrastructure, the administrator will then enable IPP (or WEBDAV) or > whatever at that time. > > Ultimately, I believe firewall admins will explicitly enable internet > printing or faxing or whatever, and I don't think a firewall issue should > impose undue design constraints on what we (the WG) want to do. > Firewall admins already do this explicitly enabling/disabling of > application protocols (POP, FTP, IMAP, etc.) and I think we're just > another > application. I don't think these protocol designers were too bogged down > in > firewall issues during the development process. At least with the > Checkpoint Firewall-1 product, it takes about 45 seconds to bring up the > console and enable or disable a particular application protocol. > > Just my (possibly more than) $0.02 > > Randy > > > > At 08:15 AM 6/2/98 -0700, Vinod Valloppillil (Exchange) wrote: > >Rob's argument is broadly correct -- as a long term firewall design > issue, > >method inspection (and occasionally payload inspection) will become the > >rule. > > > >However, as a small carrot to today's protocol designers, the vast > majority > >of the installed base of firewalls do no method / payload inspection on > HTTP > >data being passed through. Purely from the perspective of 'reach' > there's > >no impediment to IPP using it's own method in the short run. > > > >> -----Original Message----- > >> From: Rob Polansky [SMTP:polansky@raptor.com] > >> Sent: Tuesday, June 02, 1998 6:06 AM > >> To: David W. Morris > >> Cc: http-wg; ipp@pwg.org > >> Subject: RE: Implications of introducing new scheme and port for > >> existing HTTP servers > >> > >> I know of at least one :-) firewall that not only rejects unknown > methods > >> but also examines the HTTP request method as part of its "algorithm". > From > >> a > >> protocol and security perspective, it appears to be the right thing to > do. > >> If you don't understand the method, how can you properly proxy it? Take > >> the > >> CONNECT method as an example. > >> > >> In summary, any proxy that is more than a simple packet passer > (supports > >> CONNECT, protocol conversion, proxy authentication, etc.) runs the risk > of > >> failing to pass IPP if it uses a new scheme and/or a new method. Not > that > >> that's a bad thing... :-) > >> > >> -Rob Polansky > >> > >> > -----Original Message----- > >> > From: David W. Morris [mailto:dwm@xpasc.com] > >> > Sent: Monday, June 01, 1998 10:34 PM > >> > To: Carl-Uno Manros > >> > Cc: http-wg@cuckoo.hpl.hp.com; ipp@pwg.org; http-wg@hplb.hpl.hp.com > >> > Subject: Re: Implications of introducing new scheme and port for > >> > existing HTTP servers > >> > > >> > (I'm also not wild about new HTTP methods as I know of existing > proxies > >> > which will reject unknown methods. Don't know of any which will > accept > >> > unknown methods. I'm also unaware of any firewall software which > >> examines > >> > the HTTP request method as part of its algorithm but then I'm not a > >> > firewall expert.) > >> > > > From ipp-owner@pwg.org Wed Jun 3 12:22:25 1998 Delivery-Date: Wed, 03 Jun 1998 12:22:29 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA20989 for ; Wed, 3 Jun 1998 12:22:24 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA14151 for ; Wed, 3 Jun 1998 12:24:45 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA21356 for ; Wed, 3 Jun 1998 12:22:20 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 12:18:02 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA20186 for ipp-outgoing; Wed, 3 Jun 1998 12:12:13 -0400 (EDT) Message-ID: From: Paul Moore To: "'Rob Polansky'" Cc: http-wg , ipp@pwg.org Subject: RE: IPP> RE: Implications of introducing new scheme and port for existing HTTP servers Date: Wed, 3 Jun 1998 09:12:02 -0700 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: owner-ipp@pwg.org I just want to be clear on what I am trying to say:- Firewalls are a completely legitimate and valuable tool in the Internet and I think that issues associtaed with IPP and its penetration or otherwise through them are extremely important. Having said that I think that the proxy issue is the more important one because:- a) This is how most businesses users access the Internet b) They invert the firewall model (a firewall blocks, a proxy enables) If we use a mechanism not carried by the current proxy installed base then the majority of business users will not be able to use IPP to talk to 'printers' on the Internet. This would be a big change. I do not place a value judement on this - I merely point out the enormity of the change that would occur. I should point out that at one of the first IPP meeting attended by MS we pointed out that using HTTP primarily as a means of 'stealthing' through firewalls was totally bogus and this continues to be our position. The PWG came to an uneasy agreement that the 'firewall issue' was no longer open for debate since the group divided in two on it and would not be reconciled. > -----Original Message----- > From: Rob Polansky [SMTP:polansky@raptor.com] > Sent: Wednesday, June 03, 1998 5:55 AM > To: Paul Moore > Cc: http-wg; ipp@pwg.org > Subject: RE: IPP> RE: Implications of introducing new scheme and port > for existing HTTP servers > > This kind of flamebait is not really helpful to our discussion. Firewalls > serve legitimate technical and business needs as our friends from > Microsoft > know, and those firewalls with application proxies look at protocols from > a > different point of view than your typical caching proxies. The beauty of > it > is that protocol compliant implementations from either the firewall or the > cache point of view will interoperate. The difference is when they > encounter > something unexpected. Firewalls by definition must "fail closed" so as not > to make their protected resources vulnerable to attacks; most other > software > makes a best effort to pass data. I don't see anything wrong with that > difference. > > Once again, if IPP uses existing methods and schemes, it should be > passable > through all proxies without trouble. Add a new method and/or scheme i.e. > CHANGE THE STANDARD, and you should expect that existing implemenations > will > not understand it and some (not many) may not pass it. > > -Rob Polansky > > > -----Original Message----- > > From: Paul Moore [mailto:paulmo@microsoft.com] > > Sent: Tuesday, June 02, 1998 8:37 PM > > To: 'Randy Turner'; Vinod Valloppillil (Exchange); 'Rob Polansky'; David > > W. Morris > > Cc: http-wg; ipp@pwg.org > > Subject: RE: IPP> RE: Implications of introducing new scheme and port > > for existing HTTP servers > > > > > > The issue is proxies - enablers - not firewalls - disablers. If > > you replace > > my proxy by a passthrough cable I cannot do anything, if you replace my > > firewall by a cable you can do anything. > > > > > -----Original Message----- > > > From: Randy Turner [SMTP:rturner@sharplabs.com] > > > Sent: Tuesday, June 02, 1998 8:34 AM > > > To: Vinod Valloppillil (Exchange); 'Rob Polansky'; David W. > Morris > > > Cc: http-wg; ipp@pwg.org > > > Subject: Re: IPP> RE: Implications of introducing new scheme and port > > > for existing HTTP servers > > > > > > > > > The past few comments about firewalls do not (IMHO) appear to pose a > > > problem for IPP deployment. If the majority of the installed base of > > > firewall products do not do HTTP method inspection then thats ok. > > > everything would work. When the "next-generation" products that can > > > perform > > > this type of inspection, then during installation of this new > > > infrastructure, the administrator will then enable IPP (or WEBDAV) or > > > whatever at that time. > > > > > > Ultimately, I believe firewall admins will explicitly enable internet > > > printing or faxing or whatever, and I don't think a firewall > > issue should > > > impose undue design constraints on what we (the WG) want to do. > > > Firewall admins already do this explicitly enabling/disabling of > > > application protocols (POP, FTP, IMAP, etc.) and I think we're just > > > another > > > application. I don't think these protocol designers were too bogged > down > > > in > > > firewall issues during the development process. At least with the > > > Checkpoint Firewall-1 product, it takes about 45 seconds to bring up > the > > > console and enable or disable a particular application protocol. > > > > > > Just my (possibly more than) $0.02 > > > > > > Randy > > > > > > > > > > > > At 08:15 AM 6/2/98 -0700, Vinod Valloppillil (Exchange) wrote: > > > >Rob's argument is broadly correct -- as a long term firewall design > > > issue, > > > >method inspection (and occasionally payload inspection) will become > the > > > >rule. > > > > > > > >However, as a small carrot to today's protocol designers, the vast > > > majority > > > >of the installed base of firewalls do no method / payload inspection > on > > > HTTP > > > >data being passed through. Purely from the perspective of 'reach' > > > there's > > > >no impediment to IPP using it's own method in the short run. > > > > > > > >> -----Original Message----- > > > >> From: Rob Polansky [SMTP:polansky@raptor.com] > > > >> Sent: Tuesday, June 02, 1998 6:06 AM > > > >> To: David W. Morris > > > >> Cc: http-wg; ipp@pwg.org > > > >> Subject: RE: Implications of introducing new scheme and port > for > > > >> existing HTTP servers > > > >> > > > >> I know of at least one :-) firewall that not only rejects unknown > > > methods > > > >> but also examines the HTTP request method as part of its > "algorithm". > > > From > > > >> a > > > >> protocol and security perspective, it appears to be the > > right thing to > > > do. > > > >> If you don't understand the method, how can you properly > > proxy it? Take > > > >> the > > > >> CONNECT method as an example. > > > >> > > > >> In summary, any proxy that is more than a simple packet passer > > > (supports > > > >> CONNECT, protocol conversion, proxy authentication, etc.) > > runs the risk > > > of > > > >> failing to pass IPP if it uses a new scheme and/or a new method. > Not > > > that > > > >> that's a bad thing... :-) > > > >> > > > >> -Rob Polansky > > > >> > > > >> > -----Original Message----- > > > >> > From: David W. Morris [mailto:dwm@xpasc.com] > > > >> > Sent: Monday, June 01, 1998 10:34 PM > > > >> > To: Carl-Uno Manros > > > >> > Cc: http-wg@cuckoo.hpl.hp.com; ipp@pwg.org; > http-wg@hplb.hpl.hp.com > > > >> > Subject: Re: Implications of introducing new scheme and port for > > > >> > existing HTTP servers > > > >> > > > > >> > (I'm also not wild about new HTTP methods as I know of existing > > > proxies > > > >> > which will reject unknown methods. Don't know of any which will > > > accept > > > >> > unknown methods. I'm also unaware of any firewall software which > > > >> examines > > > >> > the HTTP request method as part of its algorithm but then I'm not > a > > > >> > firewall expert.) > > > >> > > > > > > > From ipp-owner@pwg.org Wed Jun 3 14:11:54 1998 Delivery-Date: Wed, 03 Jun 1998 14:11:55 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA24210 for ; Wed, 3 Jun 1998 14:11:54 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA14815 for ; Wed, 3 Jun 1998 14:14:15 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA26511 for ; Wed, 3 Jun 1998 14:11:52 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 14:07:36 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA25980 for ipp-outgoing; Wed, 3 Jun 1998 14:03:10 -0400 (EDT) Message-ID: <3FF8121C9B6DD111812100805F31FC0D0297140C@red-msg-59.dns.microsoft.com> From: Yaron Goland To: "'Rob Polansky'" , Paul Moore Cc: http-wg , ipp@pwg.org Subject: RE: IPP> RE: Implications of introducing new scheme and port for existing HTTP servers Date: Wed, 3 Jun 1998 11:02:58 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipp@pwg.org When you say "change the standard" are you referring to RFC 2068 or the IPP standard? Thanks, Yaron > -----Original Message----- > From: Rob Polansky [mailto:polansky@raptor.com] > Sent: Wednesday, June 03, 1998 5:55 AM > To: Paul Moore > Cc: http-wg; ipp@pwg.org > Subject: RE: IPP> RE: Implications of introducing new scheme and port > for existing HTTP servers > > > This kind of flamebait is not really helpful to our > discussion. Firewalls > serve legitimate technical and business needs as our friends > from Microsoft > know, and those firewalls with application proxies look at > protocols from a > different point of view than your typical caching proxies. > The beauty of it > is that protocol compliant implementations from either the > firewall or the > cache point of view will interoperate. The difference is when > they encounter > something unexpected. Firewalls by definition must "fail > closed" so as not > to make their protected resources vulnerable to attacks; most > other software > makes a best effort to pass data. I don't see anything wrong with that > difference. > > Once again, if IPP uses existing methods and schemes, it > should be passable > through all proxies without trouble. Add a new method and/or > scheme i.e. > CHANGE THE STANDARD, and you should expect that existing > implemenations will > not understand it and some (not many) may not pass it. > > -Rob Polansky > > > -----Original Message----- > > From: Paul Moore [mailto:paulmo@microsoft.com] > > Sent: Tuesday, June 02, 1998 8:37 PM > > To: 'Randy Turner'; Vinod Valloppillil (Exchange); 'Rob > Polansky'; David > > W. Morris > > Cc: http-wg; ipp@pwg.org > > Subject: RE: IPP> RE: Implications of introducing new > scheme and port > > for existing HTTP servers > > > > > > The issue is proxies - enablers - not firewalls - disablers. If > > you replace > > my proxy by a passthrough cable I cannot do anything, if > you replace my > > firewall by a cable you can do anything. > > > > > -----Original Message----- > > > From: Randy Turner [SMTP:rturner@sharplabs.com] > > > Sent: Tuesday, June 02, 1998 8:34 AM > > > To: Vinod Valloppillil (Exchange); 'Rob Polansky'; > David W. Morris > > > Cc: http-wg; ipp@pwg.org > > > Subject: Re: IPP> RE: Implications of introducing new > scheme and port > > > for existing HTTP servers > > > > > > > > > The past few comments about firewalls do not (IMHO) > appear to pose a > > > problem for IPP deployment. If the majority of the > installed base of > > > firewall products do not do HTTP method inspection then thats ok. > > > everything would work. When the "next-generation" > products that can > > > perform > > > this type of inspection, then during installation of this new > > > infrastructure, the administrator will then enable IPP > (or WEBDAV) or > > > whatever at that time. > > > > > > Ultimately, I believe firewall admins will explicitly > enable internet > > > printing or faxing or whatever, and I don't think a firewall > > issue should > > > impose undue design constraints on what we (the WG) want to do. > > > Firewall admins already do this explicitly enabling/disabling of > > > application protocols (POP, FTP, IMAP, etc.) and I think > we're just > > > another > > > application. I don't think these protocol designers were > too bogged down > > > in > > > firewall issues during the development process. At least with the > > > Checkpoint Firewall-1 product, it takes about 45 seconds > to bring up the > > > console and enable or disable a particular application protocol. > > > > > > Just my (possibly more than) $0.02 > > > > > > Randy > > > > > > > > > > > > At 08:15 AM 6/2/98 -0700, Vinod Valloppillil (Exchange) wrote: > > > >Rob's argument is broadly correct -- as a long term > firewall design > > > issue, > > > >method inspection (and occasionally payload inspection) > will become the > > > >rule. > > > > > > > >However, as a small carrot to today's protocol > designers, the vast > > > majority > > > >of the installed base of firewalls do no method / > payload inspection on > > > HTTP > > > >data being passed through. Purely from the perspective > of 'reach' > > > there's > > > >no impediment to IPP using it's own method in the short run. > > > > > > > >> -----Original Message----- > > > >> From: Rob Polansky [SMTP:polansky@raptor.com] > > > >> Sent: Tuesday, June 02, 1998 6:06 AM > > > >> To: David W. Morris > > > >> Cc: http-wg; ipp@pwg.org > > > >> Subject: RE: Implications of introducing new > scheme and port for > > > >> existing HTTP servers > > > >> > > > >> I know of at least one :-) firewall that not only > rejects unknown > > > methods > > > >> but also examines the HTTP request method as part of > its "algorithm". > > > From > > > >> a > > > >> protocol and security perspective, it appears to be the > > right thing to > > > do. > > > >> If you don't understand the method, how can you properly > > proxy it? Take > > > >> the > > > >> CONNECT method as an example. > > > >> > > > >> In summary, any proxy that is more than a simple packet passer > > > (supports > > > >> CONNECT, protocol conversion, proxy authentication, etc.) > > runs the risk > > > of > > > >> failing to pass IPP if it uses a new scheme and/or a > new method. Not > > > that > > > >> that's a bad thing... :-) > > > >> > > > >> -Rob Polansky > > > >> > > > >> > -----Original Message----- > > > >> > From: David W. Morris [mailto:dwm@xpasc.com] > > > >> > Sent: Monday, June 01, 1998 10:34 PM > > > >> > To: Carl-Uno Manros > > > >> > Cc: http-wg@cuckoo.hpl.hp.com; ipp@pwg.org; > http-wg@hplb.hpl.hp.com > > > >> > Subject: Re: Implications of introducing new scheme > and port for > > > >> > existing HTTP servers > > > >> > > > > >> > (I'm also not wild about new HTTP methods as I know > of existing > > > proxies > > > >> > which will reject unknown methods. Don't know of any > which will > > > accept > > > >> > unknown methods. I'm also unaware of any firewall > software which > > > >> examines > > > >> > the HTTP request method as part of its algorithm but > then I'm not a > > > >> > firewall expert.) > > > >> > > > > > > > > From ipp-owner@pwg.org Wed Jun 3 15:02:26 1998 Delivery-Date: Wed, 03 Jun 1998 15:02:27 -0400 Return-Path: ipp-owner@pwg.org Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA25311 for ; Wed, 3 Jun 1998 15:02:26 -0400 (EDT) Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA15093 for ; Wed, 3 Jun 1998 15:04:43 -0400 (EDT) Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA00345 for ; Wed, 3 Jun 1998 15:02:19 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 3 Jun 1998 14:57:43 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA29624 for ipp-outgoing; Wed, 3 Jun 1998 14:56:29 -0400 (EDT) Message-ID: <3FF8121C9B6DD111812100805F31FC0D02971412@red-msg-59.dns.microsoft.com> From: Yaron Goland To: "'Rob Polansky'" , Paul Moore Cc: "'http-wg'" , "'ipp@pwg.org'" , "Vinod Valloppillil (Exchange)" Subject: RE: IPP> RE: Implications of introducing new scheme and port for existing HTTP servers Date: Wed, 3 Jun 1998 11:56:10 -0700 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: owner-ipp@pwg.org Rob clarified in personal e-mail that he meant the latest rev of the HTTP draft. One of the innovations of HTTP in respect to many other protocols is that you do not need to modify the HTTP standard in order to add new methods for use with HTTP. Rather HTTP defines exactly how one is to act if one receives an unknown method. Thus one can safely add new methods and know that at the worst one will simply receive a method unknown error from servers/firewalls and be tunneled by proxies. Firewall designers understood this simple design goal and thus allowed administrators to specify which methods they did and did not want to allow through their firewall. Thus the issue is not forcing administrators to rev their firewalls to be compliant with some new standard but rather having administrators brought into the loop in order to approve the use of a new method through their firewall. Once they approve they need only change settings on their firewall to permit the new method. It is this very process that firewalls were introduced to enforce. Administrators realized they could not possibly control what every server in their network did. Rather than chasing after every user in order to ensure they were not running "unapproved" or "insecure" software they configured their network such that anyone wishing to do anything external to the network had to run through their firewall. Thus were IPP to use a new method there would be absolutely no need to alter the HTTP standard and IPP would be acting in a manner consistent with the express desires of the administrative community. Yaron > -----Original Message----- > From: Yaron Goland > Sent: Wednesday, June 03, 1998 11:03 AM > To: 'Rob Polansky'; Paul Moore > Cc: http-wg; ipp@pwg.org > Subject: RE: IPP> RE: Implications of introducing new scheme and port > for existing HTTP servers > > > When you say "change the standard" are you referring to RFC > 2068 or the IPP standard? > > Thanks, > Yaron > > > -----Original Message----- > > From: Rob Polansky [mailto:polansky@raptor.com] > > Sent: Wednesday, June 03, 1998 5:55 AM > > To: Paul Moore > > Cc: http-wg; ipp@pwg.org > > Subject: RE: IPP> RE: Implications of introducing new > scheme and port > > for existing HTTP servers > > > > > > This kind of flamebait is not really helpful to our > > discussion. Firewalls > > serve legitimate technical and business needs as our friends > > from Microsoft > > know, and those firewalls with application proxies look at > > protocols from a > > different point of view than your typical caching proxies. > > The beauty of it > > is that protocol compliant implementations from either the > > firewall or the > > cache point of view will interoperate. The difference is when > > they encounter > > something unexpected. Firewalls by definition must "fail > > closed" so as not > > to make their protected resources vulnerable to attacks; most > > other software > > makes a best effort to pass data. I don't see anything > wrong with that > > difference. > > > > Once again, if IPP uses existing methods and schemes, it > > should be passable > > through all proxies without trouble. Add a new method and/or > > scheme i.e. > > CHANGE THE STANDARD, and you should expect that existing > > implemenations will > > not understand it and some (not many) may not pass it. > > > > -Rob Polansky > > > > > -----Original Message----- > > > From: Paul Moore [mailto:paulmo@microsoft.com] > > > Sent: Tuesday, June 02, 1998 8:37 PM > > > To: 'Randy Turner'; Vinod Valloppillil (Exchange); 'Rob > > Polansky'; David > > > W. Morris > > > Cc: http-wg; ipp@pwg.org > > > Subject: RE: IPP> RE: Implications of introducing new > > scheme and port > > > for existing HTTP servers > > > > > > > > > The issue is proxies - enablers - not firewalls - disablers. If > > > you replace > > > my proxy by a passthrough cable I cannot do anything, if > > you replace my > > > firewall by a cable you can do anything. > > > > > > > -----Original Message----- > > > > From: Randy Turner [SMTP:rturner@sharplabs.com] > > > > Sent: Tuesday, June 02, 1998 8:34 AM > > > > To: Vinod Valloppillil (Exchange); 'Rob Polansky'; > > David W. Morris > > > > Cc: http-wg; ipp@pwg.org > > > > Subject: Re: IPP> RE: Implications of introducing new > > scheme and port > > > > for existing HTTP servers > > > > > > > > > > > > The past few comments about firewalls do not (IMHO) > > appear to pose a > > > > problem for IPP deployment. If the majority of the > > installed base of > > > > firewall products do not do HTTP method inspection then > thats ok. > > > > everything would work. When the "next-generation" > > products that can > > > > perform > > > > this type of inspection, then during installation of this new > > > > infrastructure, the administrator will then enable IPP > > (or WEBDAV) or > > > > whatever at that time. > > > > > > > > Ultimately, I believe firewall admins will explicitly > > enable internet > > > > printing or faxing or whatever, and I don't think a firewall > > > issue should > > > > impose undue design constraints on what we (the WG) want to do. > > > > Firewall admins already do this explicitly enabling/disabling of > > > > application protocols (POP, FTP, IMAP, etc.) and I think > > we're just > > > > another > > > > application. I don't think these protocol designers were > > too bogged down > > > > in > > > > firewall issues during the development process. At > least with the > > > > Checkpoint Firewall-1 product, it takes about 45 seconds > > to bring up the > > > > console and enable or disable a particular application protocol. > > > > > > > > Just my (possibly more than) $0.02 > > > > > > > > Randy > > > > > > > > > > > > > > > > At 08:15 AM 6/2/98 -0700, Vinod Valloppillil (Exchange) wrote: > > > > >Rob's argument is broadly correct -- as a long term > > firewall design > > > > issue, > > > > >method inspection (and occasionally payload inspection) > > will become the > > > > >rule. > > > > > > > > > >However, as a small carrot to today's protocol > > designers, the vast > > > > majority > > > > >of the installed base of firewalls do no method / > > payload inspection on > > > > HTTP > > > > >data being passed through. Purely from the perspective > > of 'reach' > > > > there's > > > > >no impediment to IPP using it's own method in the short run. > > > > > > > > > >> -----Original Message----- > > > > >> From: Rob Polansky [SMTP:polansky@raptor.com] > > > > >> Sent: Tuesday, June 02, 1998 6:06 AM > > > > >> To: David W. Morris > > > > >> Cc: http-wg; ipp@pwg.org > > > > >> Subject: RE: Implications of introducing new > > scheme and port for > > > > >> existing HTTP servers > > > > >> > > > > >> I know of at least one :-) firewall that not only > > rejects unknown > > > > methods > > > > >> but also examines the HTTP request method as part of > > its "algorithm". > > > > From > > > > >> a > > > > >> protocol and security perspective, it appears to be the > > > right thing to > > > > do. > > > > >> If you don't understand the method, how can you properly > > > proxy it? Take > > > > >> the > > > > >> CONNECT method as an example. > > > > >> > > > > >> In summary, any proxy that is more than a simple > packet passer > > > > (supports > > > > >> CONNECT, protocol conversion, proxy authentication, etc.) > > > runs the risk > > > > of > > > > >> failing to pass IPP if it uses a new scheme and/or a > > new method. Not > > > > that > > > > >> that's a bad thing... :-) > > > > >> > > > > >> -Rob Polansky > > > > >> > > > > >> > -----Original Message----- > > > > >> > From: David W. Morris [mailto:dwm@xpasc.com] > > > > >> > Sent: Monday, June 01, 1998 10:34 PM > > > > >> > To: Carl-Uno Manros > > > > >> > Cc: http-wg@cuckoo.hpl.hp.com; ipp@pwg.org; > > http-wg@hplb.hpl.hp.com > > > > >> > Subject: Re: Implications of introducing new scheme > > and port for > > > > >> > existing HTTP servers > > > > >> > > > > > >> > (I'm also not wild about new HTTP methods as I know > > of existing > > > > proxies > > > > >> > which will reject unknown methods. Don't know of any > > which will > > > > accept > > > > >> > unknown methods. I'm also unaware of any firewall > > software which > > > > >> examines > > > > >> > the HTTP request method as part of its algorithm but > > then I'm not a > > > > >> > firewall expert.) > > > > >> > > > > > > > > > > > > From root@uscore.underscore.com Thu Jun 25 00:15:30 1998 Delivery-Date: Thu, 25 Jun 1998 00:20:30 -0400 Return-Path: root@uscore.underscore.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA02790 for ; Thu, 25 Jun 1998 00:06:29 -0400 (EDT) Received: from uscore.underscore.com (uscore.underscore.com [199.125.69.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA18407 for ; Thu, 25 Jun 1998 00:08:41 -0400 (EDT) Received: (from root@localhost) by uscore.underscore.com (8.8.4/8.7.2) id TAA08640; Wed, 24 Jun 1998 19:54:45 -0400 (EDT) Date: Wed, 24 Jun 1998 19:54:45 -0400 (EDT) From: Super-User Message-Id: <199806242354.TAA08640@uscore.underscore.com> To: AL_PIEPHO@HP-Greeley-om2.om.hp.com, Aillil_Halsema@es.xerox.com, Angelo.Caruso@usa.xerox.com, BERENGUER_TORELLO@non-hp-iberia-om2.om.hp.com, Brent.Thomas@eng.efi.com, CARLOS_F_BECERRA@HP-Guadalajara-om1.om.hp.com, Chris_Mason@csme.canon.co.uk, Chung-Mei_Sung@xn.xerox.com, DAVID_KUNTZ@HP-Roseville-om2.om.hp.com, DEK1%mimi@magic.itg.ti.com, DENISE_ZIMMERMAN@HP-Boise-om8.om.hp.com, DTAYLOR@novell.com, Diana.Klashman@East.Sun.COM, Don_Purpura@cissc.canon.com, ERIC_CLEMENT@HP-Roseville-om2.om.hp.com, Edward_R_Rhoads@ccm.intel.com, Eugene.Chen@eng.efi.com, Foteos.Macrides@gte.net, Gregg_Bonikowski@wb.xerox.com, Harish.Manepalli@eng.efi.com, JPODOJIL@genicom.com, JRackowitz@engpo.msmailgw.intermec.com, Jason.Chen@eng.efi.com, Joel.Bennett@usa.xerox.com, KEN_OAKESON@HP-Boise-om8.om.hp.com, KL@PNPTECH.dk, KRIS_SCHOFF@HP-Boise-om8.om.hp.com, Kevin_Brayton@wb.xerox.com, Kevin_Bross@ccm.intel.com, Kiyoshi_Katano@cbj.canon.co.jp, ListSaver-of-pmp@vault.findmail.com, Louis_Ormond@cissc.canon.com, Miyasaka.Takashi@exc.epson.co.jp, OWEN@MPA15AB.MV.UNISYS.COM, OYAMADA@jp.ibm.com, Onishi.Joji@exc.epson.co.jp, Ozay_Oktay@cissc.canon.com, PETER_E_MELLQUIST@hp-roseville-om3.om.hp.com, Phil_Verghese@hp.com, RUSSELL_JOHNSTON@HP-Boise-om2.om.hp.com, Randy_Grohs@hp.com, Regis.Brochu@pwc.ca, Rich.Gray@Digital-Controls.Com, Roberto.SANNINO@st.com, Rod.Belshee@tek.COM, Rohlfingdg@agedwards.com, Ronald.Macera@usa.xerox.com, SHARPEG@CLIFFY.POLAROID.COM, SISAACSON@novell.com, STUART@KEI-CA.CCMAIL.CompuServe.COM, Scott_Barnes@es.xerox.com, Shinichi.Nakamura@fujixerox.co.jp, Shuyuan.Chen@crt.xerox.com, Stephen_Wilczek@es.xerox.com, Susumu_Takase@cbj.canon.co.jp, THERESA_RHOADES@HP-Boise-om8.om.hp.com, TLasko@genicom.com, TMCLTD@aol.com, TSUIC@CLIFFY.POLAROID.COM, TTRONSON@novell.com, Thomas_C_Jones@ccm.intel.com, Toshiyuki-AOKI@KDD.co.jp, Troncoso@corp.adaptec.com, Vivian_Cancio@xn.xerox.com, YUKI@KEI-CA.CCMAIL.CompuServe.COM, adamsc@pogo.WV.TEK.COM, adar@vnet.ibm.com, akasaka@tpp.epson.co.jp, akrsaito@ga3.mmlab.toshiba.co.jp, alan_berkema@hp.com, albrahme@byas.com, amiller@kodak.com, anders.olsson@axis.se, ando.makoto@fujixerox.co.jp, andrea@vividimage.com, andrew_barker@es.xerox.com, andyd@pogo.WV.TEK.COM, aoki@mita.co.jp, aoki@rdmg.mgcs.mei.co.jp, armon@wrc.xerox.com, arpalists+computing.ietf-ipp@andrew.cmu.edu, asada@sd.nara.sharp.co.jp, asain@jp.ibm.com, atsnaka@cbs.canon.co.jp, atsushi.yuki@kyocera.com, austin@sdsp.mc.xerox.com, awatanabe@Technoscope.co.jp, b_nixon@emulex.com, babakj@microsoft.com, barry@abcdprint.com, bathatcher@earthlink.net, berche@ocegr.fr, bgalten@rbi.com, bhasting@rbi.com, bill@xcd.com, bis@rose.hp.com, bixhorna@reston.btna.com, bkd@auratek.com, bob@sismicro.com, bob_mross@hp.com, bol@Axp1.IenD.wau.nl, bpathak@popmail1.vcd.hp.com, bpenteco@boi.hp.com, brian@quiotix.com, brian_griebe@hp.com, brianb@vcd.hp.com, briangl@pogo.WV.TEK.COM, broccolo@page.kodak.com, bruewer@uni-hohenheim.de, bsetterb@adobe.com, bstevens@zk3.dec.com, bva@allegrosoft.com, byuan@PRC.Sun.COM, caradec@piano.grenoble.hp.com, carl@manros.com, carney@vnet.ibm.com, carterk@us.ibm.com, catherine.mazier@ocegr.fr, cato@df.lth.se, ccb@pubweb.net, ccvlok@ust.hk, cgordon@digprod.com, chad@lexmark.com, chansler@adobe.com, charles@emerald.oucs.ox.ac.uk, chirag.bakshi@eng.efi.com, chodongi@samsung.co.kr, chrisw@iwl.com, cmanros@cp10.es.xerox.com, colinws@bristol.st.com, cpip@sesun87.cse.canon.co.jp, craigl@usa.net, cullen@sdsp.mc.xerox.com, d_willie@emulex.com, dalmer@bridge.net, danbold@apple.com, daved@gop.sps.mot.com, david_kellerman@nls.com, davidlroach@unn.unisys.com, db_murray@vnet.ibm.com, dbrean@stellar.East.Sun.COM, dcarney@us.ibm.com, dcrocker@brandenburg.com, debecker@lexmark.com, denise@rd.qms.com, devonw@microsoft.com, dgaucas@wrc.xerox.com, digirol@lexmark.com, dker@matrox.com, dker@total.net, dmitchell@ti.com, don@lexmark.com, douchida@vcd.hp.com, dtenbroe@csc.com, dumroese@3a.com, dwing@Cisco.COM, echen@cp10.es.xerox.com, ekelleher@spyglass.com, elenat@bpo.hp.com, emking@lexmark.com, endoh@cse.canon.co.jp, ericr@vcd.hp.com, ewa@apple.com, fhanzel@cp10.es.xerox.com, fhernandez@peerless.com, frank@pharos.co.nz, frankm@extendsys.com, fredrik.hugosson@axis.se, fujisawa@the.canon.co.jp, fujita@yamato.ibm.co.jp, fujitani@isp.rp.ricoh.co.jp, fukunaga@cbs.canon.co.jp, fullman@cp10.es.xerox.com, fumiona@venus.dtinet.or.jp, funazaki@den.fujifilm.co.jp, fw@hplb.hpl.hp.com, fweerdenburg@tulip.com, fzhao@ix.netcom.com, ganta@mutoh.co.jp, gary_padlipsky@cp10.es.xerox.com, gcurtis@ms.com, geoff@paypc.com, ggarbutt@earthlink.net, gleeson@zk3.dec.com, goldey@lexmark.com, gonda@tkb.ysknet.co.jp, grasool@ford.com, greg@erc.epson.com, gregs@sdd.hp.com, gsonger@tsoft.com, gwm@austin.ibm.com, gz@harlequin.com, hak@ocegr.fr, harald.ripa@axis.com, harald.t.alvestrand@uninett.no, harryl@us.ibm.com, hart@zk3.dec.com, hastings@cp10.es.xerox.com, hathaway@pubweb.com, havera@hpb18423.boi.hp.com, havera@hpb27925.boi.hp.com, hclark@lexmark.com, heilbron@nm.informatik.uni-muenchen.de, henrik.holst@i-data.com, herman@ti.com, hi-kohara@KDD.co.jp, hirao@ipdc.sanyo.co.jp, hirata@vip.iwa.fujixerox.co.jp, hiroshi.ishikawa@fujixerox.co.jp, hitoshis@microsoft.com, hparra@novell.com, hsato@cse.canon.co.jp, hshenava@fmi.fujitsu.com, hsidorsky@auco.com, ht@i-data.com, hyperm@hotair.hobl.lucent.com, ietf-archive@ns.cnri.reston.va.us, ietf-ipp@redist.uit.no, iitsuka@avrl.mei.co.jp, ikeda@micom.mec.mei.co.jp, imai@prg.nara.sharp.co.jp, imcdonal@eso.mc.xerox.com, ipp@dazel.com, ipp@xionics.com, isoda@cse.canon.co.jp, isr@ix.netcom.com, iwamoto@comg.ksp.fujixerox.co.jp, jack@netg.ksp.fujixerox.co.jp, james.smith@gte.com, jds@underscore.com, jeremy_powell@sbcss.k12.ca.us, jessica.murphey@mbv.tu-chemnitz.de, jfuller@microsoft.com, jfung@cp10.es.xerox.com, jgw@hprnd.rose.hp.com, jh@harlequin.com, jhollins@eng.adaptec.com, jhy@gsu.edu, jidomir@vcd.hp.com, jim.lo@Eng.Sun.COM, jjv@page.kodak.com, jkm@underscore.com, jldavis@adobe.com, jlinton@lexmark.com, jlo@oce.nl, jmp@dazel.com, joel@mw-inc.com, johan@holhouse.nl, jon_lewis@hp.com, joshco@microsoft.com, jshockey@jrl.com, jtu@oce.nl, jwenn@cp10.es.xerox.com, k_makoto@bsd.canon.co.jp, kadiyala@ti.com, kage@yh.msy.co.jp, kakihara@jp.ibm.com, kakinum@yamato.ibm.co.jp, kamimura@ffc.co.jp, kawasima@rsk-kitami.grp.ricoh.co.jp, kazuaki@sd.nara.sharp.co.jp, kcarter@vnet.ibm.com, keisuket@microsoft.com, keita@nikongw.nikon.co.jp, kenditt@us.ibm.com, kevin.osborn@East.Sun.COM, kevin@sun470.rd.qms.com, kevin_keaney@hp.com, kinji.kanie@brother.co.jp, kita@mol.minolta.co.jp, kjarvis@parc.xerox.com, kjo@ess.mc.xerox.com, komer@trinc.com, kono@hd.epson.co.jp, kpalmer@duplousa.com, krister.svard@skandia.se, kugler@us.ibm.com, kurokawa@prt.sony.co.jp, kusumi@lsi.nsc.co.jp, kyou@cp.cs.fujitsu.co.jp, laurentp@bpo.hp.com, laurie@sdd.hp.com, lawrence@agranat.com, lee_farrell@cissc.canon.com, leisner@sdsp.mc.xerox.com, leong@cp10.es.xerox.com, listsaver-of-fin@findmail.com, listsaver-of-ipp@vault.findmail.com, listsaver-of-jmp@findmail.com, listsaver-of-p1394@findmail.com, listsaver-of-sense@findmail.com, listsaver-of-upd@findmail.com, lpyoung@lexmark.com, lstein@fapo.com, lwang@sdsp.mc.xerox.com, mabry@rd.qms.com, maehara@naltec.co.jp, maezawa@iog.atsugi.fujixerox.co.jp, mamezaki@ffm.fujifilm.co.jp, manchala@cp10.es.xerox.com, marcodg@vcd.hp.com, marina_kalika@es.xerox.com, mario.scurati@st.com, masa-koi@on.rim.or.jp, masegi@cse.canon.co.jp, masinter@parc.xerox.com, matsuki@cse.canon.co.jp, mattj@blip.org, mayer@wrc.xerox.com, mdesai@auco.com, mfenelon@microsoft.com, mhn@cdl.ucop.edu, mhodges@hpb11302.boi.hp.com, mholser@adobe.com, michael@qms.com, michiakn@microsoft.com, middendo@us.ibm.com, mike@fireflyinc.com, mike@lexmark.com, mikee@extendsys.com, mikek@iwl.com, miller@filenet.com, mkumar@trinc.com, mlchen@pdd.att.com, mochi@cns.canon.co.jp, monte_g_johnson@ccm.intel.com, moody@lexmark.com, moore+ipp@cs.utk.edu, moore+printmib@cs.utk.edu, mori@yps.kyocera.co.jp, morita@ic.rdc.ricoh.co.jp, motoyama@str.ricoh.com, mps@mspratt.hpl.hp.com, mwhit@vcd.hp.com, myoung@boi.hp.com, nadler@chopper.us.dg.com, nagahashi.toshinori@exc.epson.co.jp, nagahasi@hdccgw.hd.epson.co.jp, nagy@kodak.com, nankou@avrl.mei.co.jp, nao@cbs.canon.co.jp, naviac@rd.qms.com, ned+ipp@innosoft.com, nemo@dibe.unige.it, nesbitt@cp10.es.xerox.com, nishi@cefiro.iod.ricoh.co.jp, nishi@iod.ricoh.co.jp, nishiwaki@avrl.mei.co.jp, nisikawa@mita.co.jp, nisimura@ipdc.sanyo.co.jp, niteeyes@3Sheep.COM, niwa@iod.ricoh.co.jp, noel@rim.crl.fujixerox.co.jp, noriko.kure@toshiba.co.jp, nschade@xionics.com, nwebb@auco.com, o-tomita@cp.cs.fujitsu.co.jp, ogawa@mos.fvd.fujitsu.co.jp, ogawa@yps.kyocera.co.jp, ogino@fine.ad.jp, ohirata@cbm.canon.com, ohm+ml-ipp@rcac.tdi.co.jp, ohuchi@ess.atsugi.fujixerox.co.jp, oka@pure.cpdc.canon.co.jp, okamoto@cp10.es.xerox.com, okigami@dsap.nara.sharp.co.jp, ootsu@kk1g.kme.mei.co.jp, osaki@lpd.sj.nec.com, otallman@in-system.com, papowell@astart.com, papowell@sdsu.edu, patrick_mckinley@om.cv.hp.com, paul_lei@es.xerox.com, paulmo@microsoft.com, peter.zehler@usa.xerox.com, peter@digideas.com.au, peterm@shinesoft.com, pgloger@cp10.es.xerox.com, phil@netbrand.com, pmp@dazel.com, polansky@raptor.com, pond2@apple.com, pshukla@novell.com, psutton@GGX.COM, pthambid@okidata.com, pwg-ipp@prd.fc.nec.co.jp, pwg-jmp@prd.fc.nec.co.jp, pwg-p1394@prd.fc.nec.co.jp, pwg-pmp@prd.fc.nec.co.jp, pwg-sense@prd.fc.nec.co.jp, pwg-upd@prd.fc.nec.co.jp, qqrob@oce.nl, r18786@email.sps.mot.com, ramnath@rrsycore.co.in, ravi@india.ti.com, ravikm@us.ibm.com, raylutz@cognisys.com, rbergma@dpc.com, rblancha@rbi.com, rchawla@adn.alcatel.com, rdebry@us.ibm.com, rdhondy@qosnet.com, rick@cp10.es.xerox.com, rjm2@cornell.edu, rmccomiskie@xionics.com, robert.bruell@i-data.com, robert.herriot@Eng.Sun.COM, robert_laman@es.xerox.com, robertt@vcd.hp.com, rommel@polgas.topmax.com.ph, ronnie@best.com, rorzol@okidata.com, rpotter@xsoft.xerox.com, rrussell@lexmark.com, rschneid@erc.epson.com, rsherer@peerless.com, rturner@sharplabs.com, s-seshadri1@ti.com, saito@optsys.cl.nec.co.jp, sakamoto@yps.kyocera.co.jp, sal.gurnani@ucop.edu, salm@roch875.mc.xerox.com, samitsu@hj.hro.epson.co.jp, sandram@boi.hp.com, sasaki@cse.canon.co.jp, sasaki@jci.co.jp, sasamori.takahide@fujixerox.co.jp, sathyan@trinc.com, satoshi.ishihara@rdmg.mgcs.mei.co.jp, sbeckst@dpc.com, sbonar@hpb16977.boi.hp.com, sbutler@boi.hp.com, sbutterfield@peerless.com, scott_isaacson@novell.com, scottr@cts.com, sdumas@francenet.fr, sense@dazel.com, sergi@bpo.hp.com, sgray@cp10.es.xerox.com, shimazu@iij.ad.jp, shimura@pure.cpdc.canon.co.jp, shin.ohtake@fujixerox.co.jp, shines@sdd.hp.com, shivaun@al712.rose.hp.com, shuichiro@kaneko.com, shuji@ccs.mt.nec.co.jp, shuyuan@wrc.xerox.com, sjohnson@cp10.es.xerox.com, slw1@cornell.edu, smaruo@hrl.hitachi.co.jp, smg1@vnet.ibm.com, solina_phan@es.xerox.com, srao@trinc.com, stang@adobe.com, stanmcc@cp10.es.xerox.com, starkey@lexmark.com, stephen_holmstead@hp.com, stevet@research.canon.com.au, suehiro@ed.fujitsu.co.jp, sumino@sddc.sps.mot.com, swire@kodak.com, szilles@adobe.com, takami.takeuchi@brother.co.jp, takata@jps.net, takeda@vrl.mei.co.jp, takeshi@netg.ksp.fujixerox.co.jp, taniyan@hd.epson.co.jp, tarl@East.Sun.COM, tatsuya.matsumoto@fujixerox.co.jp, tetsu@spdd.ricoh.co.jp, tgoto@ipdc.sanyo.co.jp, thayashi@mita.co.jp, thrasher@lexmark.com, timb@cv.hp.com, tkj@wipsys.soft.net, tmori@jp.ibm.com, todd_fischer@hp.com, trieu.nguyen@intel.com, tsuna@rd1.ebina.fujixerox.co.jp, ttruong@cp10.es.xerox.com, tuda@cp10.es.xerox.com, tvu@cp10.es.xerox.com, uchino@tpp.epson.co.jp, ueda@iml.mkhar.sharp.co.jp, ueda@pure.cpdc.canon.co.jp, uenaka@vrl.mei.co.jp, vandang@hprnd.rose.hp.com, verhelst@xs4all.nl, victor@kodak.com, vijay.kumar@tek.COM, wakai@slab.tnr.sharp.co.jp, walker@dazel.com, webbj@lexmark.com, wei@tecont1.teco-info.com.tw, william_mccuskey@es.xerox.com, wolff@crc.ricoh.com, ws@seh.de, wwagner@digprod.com, xriley@cp10.es.xerox.com, yamasy@yamato.ibm.co.jp, yaron@writeme.com, yasuaki@webjapan.com, yasushin@microsoft.com, ybanker@GGX.COM, yo-oonaka@KDD.co.jp, yokada@flab.fujitsu.co.jp, yokko@cse.canon.co.jp, yoram@minolta-mil.com, yoshim@erc.epson.com, yue_chen@wb.xerox.com, yuka@fuji.mol.minolta.co.jp, zandee@apple.com, zhi-hong@zeno.com Subject: PWG> The PWG Internet server remains DOWN "Some days you eat bear, and some days the bear eats you..." The PWG Internet server (providing web, mail and ftp services) has seriously died. We are actively working on the problem, but find we're going to have to replace the existing Sun server. As a result, PWG net services will not be available until some time tomorrow, Thursday, June 25. When service has been reestablished, we will send an email message to all persons registered on the pwg-announce mailing list. (Recall that the pwg-announce mailing list is a special, automatic list representing the unique union of all subscribers to any PWG mailing list.) If by chance the problem results in the system being down beyond close of business on Thursday (EDT), then we will also send a message so as to keep everyone informed. We apologize for this inconvenience. The PWG web staff at Underscore From owner-diff-serv@BayNetworks.COM Fri Jun 26 16:56:45 1998 Delivery-Date: Fri, 26 Jun 1998 16:56:45 -0400 Return-Path: owner-diff-serv@BayNetworks.COM Received: from smtp-gw.BayNetworks.COM (ns2.BayNetworks.COM [134.177.3.16]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA02896 for ; Fri, 26 Jun 1998 16:56:44 -0400 (EDT) Received: from mailhost.BayNetworks.COM ([132.245.135.84]) by smtp-gw.BayNetworks.COM (8.8.8/8.8.8) with ESMTP id NAA25708; Fri, 26 Jun 1998 13:53:45 -0700 (PDT) Received: from majordomo.BayNetworks.COM ([192.32.253.10]) by mailhost.BayNetworks.COM (8.8.8/8.8.8) with ESMTP id QAA28282; Fri, 26 Jun 1998 16:53:34 -0400 (EDT) Received: (from major@localhost) by majordomo.BayNetworks.COM (8.8.6/BNET-SVR4) id QAA18963; Fri, 26 Jun 1998 16:57:55 -0400 (EDT) for diff-serv-outgoing X-Authentication-Warning: majordomo.BayNetworks.COM: major set sender to owner-diff-serv@majordomo using -f Received: from mailhost.BayNetworks.COM (h016d.s86b1.BayNetworks.COM [134.177.1.109] (may be forged)) by majordomo.BayNetworks.COM (8.8.6/BNET-SVR4) with ESMTP id QAA18959; Fri, 26 Jun 1998 16:57:49 -0400 (EDT) for Received: from majordomo.BayNetworks.COM ([192.32.253.10]) by mailhost.BayNetworks.COM (8.8.8/8.8.8) with ESMTP id NAA04895 for ; Fri, 26 Jun 1998 13:49:25 -0700 (PDT) Received: from smtp-gw.BayNetworks.COM (ns3.BayNetworks.COM [192.32.253.3]) by majordomo.BayNetworks.COM (8.8.6/BNET-SVR4) with ESMTP id QAA18955; Fri, 26 Jun 1998 16:57:16 -0400 (EDT) for Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by smtp-gw.BayNetworks.COM (8.8.8/8.8.8) with ESMTP id QAA12057 for ; Fri, 26 Jun 1998 16:49:21 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id QAA40940; Fri, 26 Jun 1998 16:47:55 -0400 (EDT) Received: from ellesson.raleigh.ibm.com (socks11.raleigh.ibm.com [9.37.3.58]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id QAA48734; Fri, 26 Jun 1998 16:47:58 -0400 Message-Id: X-Sender: ellesson@rtp-pop3.raleigh.ibm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 26 Jun 1998 16:47:33 -0400 To: Scott Bradner , Vern Paxson From: Ed Ellesson Subject: Request for Policy BOF Cc: agenda@ietf.org, policy@raleigh.ibm.com, rap@iphighway.com, rsvp@ISI.EDU, diff-serv@BayNetworks.COM, ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-diff-serv@BayNetworks.COM Precedence: bulk [Note: Please excuse multiple notes if you are on more than one of these lists. See bottom of this note for a mailing list specifically for discussion of policy frameworks.] Scott and Vern, Please consider this to be a formal request for a BOF at the August IETF on the topic of "Policy Framework". (This request was compiled from the results of an informal policy meeting in Cambridge, June 12, 1998, which took place immediately following the diffserv interim meeting, held there June 11-12. In fairness to those participants, I am copying the diffserv mailing list, and I therefore felt it to be only fair to copy other working group mailing lists who may have an interest....please see policy mailing list at end of this note for discussion on this BOF request.) Number of Attendees (to informal pre-BOF policy meeting): 41 (Signup list available on request) At this stage, the agenda is preliminary, and not all presenters have confirmed. I have also left room for other presenters. Should the BOF be approved, and others want time on the agenda, please contact me at: ellesson@raleigh.ibm.com BOF Description ---------------- Objectives of BOF: 1. To consider the creation of a new IETF working group called "Policy Framework". The proposed scope for this working group includes a common, interoperable, and scalable framework and namespace for administering QOS and VPN security policy in a single network domain which uses some or all of the following protocols: LDAP, SNMP, COPS, RADIUS, RSVP, Intserv, Diffserv, ISSLL, DSSLL, IPSEC 2. To develop a charter for this new working group 3. To discuss the proposed architectural framework and functional description of the architectural elements, for policy administration and distribution, documented in draft-ellesson-sla-schema-02.txt (see diffserv archive) 4. To discuss the functional requirements of a schema or schemas which could act as a central repository for policy rules for administering QOS and security policy in a single network domain. (QOS includes rsvp, intserv, diffserv, issll and dssll. Security includes vpn and ipsec.) (The reason that both QOS and VPN security are considered here, is that it may be more efficient to include them both in the same schema, from an implementation and management perspective.) 5. To discuss whether a specific schema should be a deliverable of the working group. Preliminary BOF Agenda (2 1/2 hours) ------------------------------------- -Review of BOF agenda and objectives: (Ed Ellesson) - 10 minutes -Proposed Architectural Framework (Ed Ellesson) - 15 minutes -Proposed positioning of this framework and namespace relative to other IETF and non-IETF work: * LDAP, DEN and DMTF: (TBD: John Strassner?) - 15 minutes * RSVP, Intserv, and RAP: (Raj Yavatkar) - 15 minutes * Diffserv: (TBD: Jean Christophe Martin or Raju Rajan?) - 15 minutes * VPN/IPSEC: (TBD: Charlie Kunzinger?) - 15 minutes * DHCP/RADIUS/Routing Policy (TBD: Rajiv Chaudhuri?) - 15 minutes * other proposals - 20 minutes -Proposed Charter Discussion (Ed Ellesson) - 30 minutes * Scope/track * Framework definition * Schema * Workgroup documents and Timeframe *************** Please direct discussion related to this proposed BOF to the following mailing list: policy@raleigh.ibm.com To subscribe: send a note to policy-request@raleigh.ibm.com, with subscribe on the first line of the note. Archives at: http://www.raleigh.ibm.com/m aillists/policy] ****************** Regards, Regards, Ed Ellesson Sr. Engineer, TCP/IP Technology Management IBM Networking Software Products Research Triangle Park, NC ellesson@raleigh.ibm.com 919-254-4115 From owner-qosr@ca.newbridge.com Wed Jul 15 18:38:03 1998 Delivery-Date: Wed, 15 Jul 1998 18:38:08 -0400 Return-Path: owner-qosr@ca.newbridge.com Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA27398 for ; Wed, 15 Jul 1998 18:38:03 -0400 (EDT) Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id SAA25626; Wed, 15 Jul 1998 18:30:20 -0400 (EDT) Received: from kanata-gw1.newbridge.com(192.75.23.72), claiming to be "kanata-gw1.ca.newbridge.com" via SMTP by ns.newbridge.com, id smtpdAAAa25432; Wed Jul 15 18:29:59 1998 Received: from kanmaster.ca.newbridge.com by kanata-gw1.ca.newbridge.com via smtpd (for ns.newbridge.com [192.75.23.67]) with SMTP; 15 Jul 1998 22:29:56 UT Received: from distmaster.newbridge.com (distmaster.ca.newbridge.com [138.120.118.27]) by ca.newbridge.com. (8.8.8/8.8.6) with SMTP id SAA05393; Wed, 15 Jul 1998 18:29:55 -0400 (EDT) Received: by distmaster.newbridge.com (SMI-8.6/SMI-SVR4) id SAA21963; Wed, 15 Jul 1998 18:14:02 -0400 From: gratta@holta.ho.lucent.com To: ion@sunroof.eng.sun.com, mpls@external.cisco.com, diff-serv@BayNetworks.COM, int-serv@isi.edu, qosr@newbridge.com, rsvp@isi.edu, rap@iphighway.com Cc: rcoltun@fore.com, nip-kita@ma.kcom.ne.jp, ARSHEY.ODEDRA@ITU.CH Message-Id: <199807152116.RAA24401@holta.ho.lucent.com> Comments: Authenticated sender is Original-To: ion@sunroof.eng.sun.com, mpls@external.cisco.com, diff-serv@BayNetworks.COM, int-serv@isi.edu, qosr@newbridge.com, rsvp@isi.edu, rap@iphighway.com Date: Wed, 15 Jul 1998 17:26:40 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: ITU-T SG 11 discussions concerning Internet interoperation with Original-CC: rcoltun@fore.com, nip-kita@ma.kcom.ne.jp, ARSHEY.ODEDRA@ITU.CH X-mailer: Pegasus Mail for Windows (v2.52) Sender: owner-qosr@ca.newbridge.com Precedence: bulk X-Info: [Un]Subscribe to qosr-request@newbridge.com ITU-Telecommunication Standardization Sector Study Group 11 Questions: ALL (SoI) SUBJECT: Status of SoI discussions concerning Internet interoperation with DSS2 and B-ISUP signalling APPROVAL: ITU-T SG 11 in Geneva, 22 May 1998 1. Introduction The May 1998 meeting of ITU-T SG 11 benefited from the participation of the following ISOC representatives: - Dr. Hui-Lan Lu, ISOC representative appointed by the PSTN/Internet Internetworking Working Group to Working Party 4/11 (Intelligent Networks)(Questions 5/11 and 22/11); - Mr. Joel M. Halpern, ISOC representative at ITU-T Study Group 11 Meeting, Geneva, 4-15 May 1998; and - Mr. Matt Holdrege, IETF Transport Directorate Liaison to ITU-T SG 11. Their contributions to the progress of our work during our May 1998 meeting were significant both in technical substance and in assisting the participants of ITU-T SG 11 to understand the ongoing work at ISOC/IETF, thus initiating a constructive dialogue between the two organizations. 2. Future interactions ITU-T SG 11 has appointed Dr. Kenichi KITAMI, Chairman of Working Party 1/11, to serve as overall point of contact with the ISOC/IETF. His e-mail address is: kitami@magnet.netlab.ntt.co.jp. As the need arises for extensive interaction in particular work areas, it is our intention to appoint appropriate individuals as contact persons in those areas, so that distributed communications may accelerate information exchange. So far the following points of contact have been identified: Subject: DSS2 and B-ISUP support of services over the Internet IETF Working Groups: ION, MPLS, DIFF-SERV, INT-SERV, RSVP, RAP Contact: Dr. Kenichi KITAMI, kitami@magnet.netlab.ntt.co.jp Subject: Intelligent Network interoperation with services over the Internet IETF Working Groups: PINT Contact: Professor Zhengkun Mi, mizk@njupt.edu.cn 3. Major Achievements of the ITU-T SG11 May 1998 meeting 3.1 Major objectives of ITU-T SG 11 concerning Signalling Support of Services Over the Internet The participants agreed that there are 5 objectives for efforts within Study Group 11 for standardization of Signalling Support of Services Over the Internet (SoI): a) Efficiently identifying and routing traffic destined for Internet Service Providers (ISPs) to minimize negative impact upon the Public Switched Telephone Network (PSTN), which has been engineered for relatively short holding time calls; b) Defining signalling support for new, value added services which may enable public network operators, as well as ISPs, to capitalize on the growing demand for Internet based and Intelligent Network (IN) based capabilities; c) Serving the need of ISPs, Internet Access Providers, and "Internet users" to flexibly manage dynamic bandwidth and quality of service demands from a public network; d) Defining mobile wireless access to services over the Internet, e.g., virtual private networks, provided by either ISPs or public network operators; and e) Signalling support for Service Interworking of both dialup Internet access data applications and Voice over IP applications with traditional telecommunication services, including support of signalling applications and user parts over IP based networks. 3.2 DSS2 and B-ISUP support of services over the Internet Related to objective c) mentioned above, ITU-T SG 11 received a written indication from the co- chairman of the MPLS WG that support for the end to end transport of MPLS VCID had been discussed in the MPLS WG and were considering the use of a structured UUI information element. A number of contributions addressing this subject were also received. The result of the discussions within ITU-T SG 11 are: 1) Agreement to associate an ATM Virtual Connection with an Internet Session, or an MPLS VCID, at the occasion of the connection setup, via the Generic Identifier Transport information element; 2) The creation of two baseline documents, one for DSS2 (UNI signalling)and the other for B- ISUP (NNI signalling); and 3) Agreement in principle to initiate approval of the draft Recommendation in the next ITU-T SG 11 meeting in March 1999 (implying final approval in February 2000). Individuals interested in viewing the details of the DSS2 baseline document should send a request to gratta@lucent.com. A Word format document (of TD GEN/11-67R1) will be forwarded to such individuals. Greg Ratta, Vice Chairman, ITU-T WP 1/11 Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com From owner-diff-serv@BayNetworks.COM Wed Jul 15 18:42:41 1998 Delivery-Date: Wed, 15 Jul 1998 18:42:42 -0400 Return-Path: owner-diff-serv@BayNetworks.COM Received: from smtp-gw.BayNetworks.COM (ns4.BayNetworks.COM [192.32.253.7]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA27492 for ; Wed, 15 Jul 1998 18:42:41 -0400 (EDT) Received: from mailhost.BayNetworks.COM ([132.245.135.115]) by smtp-gw.BayNetworks.COM (8.8.8/8.8.8) with ESMTP id SAA28157; Wed, 15 Jul 1998 18:35:52 -0400 (EDT) Received: from majordomo.BayNetworks.COM ([192.32.253.10]) by mailhost.BayNetworks.COM (8.8.8/8.8.8) with ESMTP id SAA27680; Wed, 15 Jul 1998 18:33:51 -0400 (EDT) Received: (from major@localhost) by majordomo.BayNetworks.COM (8.8.6/BNET-SVR4) id SAA03931; Wed, 15 Jul 1998 18:23:11 -0400 (EDT) for diff-serv-outgoing X-Authentication-Warning: majordomo.BayNetworks.COM: major set sender to owner-diff-serv@majordomo using -f Received: from mailhost.BayNetworks.COM (h016d.s86b1.BayNetworks.COM [134.177.1.109] (may be forged)) by majordomo.BayNetworks.COM (8.8.6/BNET-SVR4) with ESMTP id SAA03927; Wed, 15 Jul 1998 18:22:29 -0400 (EDT) for Received: from majordomo.BayNetworks.COM ([192.32.253.10]) by mailhost.BayNetworks.COM (8.8.8/8.8.8) with ESMTP id PAA21443 for ; Wed, 15 Jul 1998 15:13:31 -0700 (PDT) Received: from smtp-gw.BayNetworks.COM (ns4.BayNetworks.COM [192.32.253.7]) by majordomo.BayNetworks.COM (8.8.6/BNET-SVR4) with ESMTP id SAA03923; Wed, 15 Jul 1998 18:21:56 -0400 (EDT) for Received: from ihgw2.lucent.com (ihgw2.lucent.com [207.19.48.2]) by smtp-gw.BayNetworks.COM (8.8.8/8.8.8) with SMTP id SAA27562 for ; Wed, 15 Jul 1998 18:13:32 -0400 (EDT) From: gratta@holta.ho.lucent.com To: ion@sunroof.eng.sun.com, mpls@external.cisco.com, diff-serv@BayNetworks.COM, int-serv@ISI.EDU, qosr@newbridge.com, rsvp@ISI.EDU, rap@iphighway.com Cc: rcoltun@fore.com, nip-kita@ma.kcom.ne.jp, ARSHEY.ODEDRA@ITU.CH Received: from holta.ho.lucent.com by ihig2.firewall.lucent.com (SMI-8.6/EMS-L sol2) id RAA26181; Wed, 15 Jul 1998 17:02:12 -0500 Received: from nj7460grattal.holta by holta.ho.lucent.com (SMI-8.6/EMS-1.4.1 sol2) id RAA24401; Wed, 15 Jul 1998 17:16:24 -0400 Message-Id: <199807152116.RAA24401@holta.ho.lucent.com> Comments: Authenticated sender is Original-To: ion@sunroof.eng.sun.com, mpls@external.cisco.com, diff-serv@BayNetworks.COM, int-serv@isi.edu, qosr@newbridge.com, rsvp@isi.edu, rap@iphighway.com Date: Wed, 15 Jul 1998 17:26:40 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: ITU-T SG 11 discussions concerning Internet interoperation with Original-CC: rcoltun@fore.com, nip-kita@ma.kcom.ne.jp, ARSHEY.ODEDRA@ITU.CH X-mailer: Pegasus Mail for Windows (v2.52) Sender: owner-diff-serv@BayNetworks.COM Precedence: bulk ITU-Telecommunication Standardization Sector Study Group 11 Questions: ALL (SoI) SUBJECT: Status of SoI discussions concerning Internet interoperation with DSS2 and B-ISUP signalling APPROVAL: ITU-T SG 11 in Geneva, 22 May 1998 1. Introduction The May 1998 meeting of ITU-T SG 11 benefited from the participation of the following ISOC representatives: - Dr. Hui-Lan Lu, ISOC representative appointed by the PSTN/Internet Internetworking Working Group to Working Party 4/11 (Intelligent Networks)(Questions 5/11 and 22/11); - Mr. Joel M. Halpern, ISOC representative at ITU-T Study Group 11 Meeting, Geneva, 4-15 May 1998; and - Mr. Matt Holdrege, IETF Transport Directorate Liaison to ITU-T SG 11. Their contributions to the progress of our work during our May 1998 meeting were significant both in technical substance and in assisting the participants of ITU-T SG 11 to understand the ongoing work at ISOC/IETF, thus initiating a constructive dialogue between the two organizations. 2. Future interactions ITU-T SG 11 has appointed Dr. Kenichi KITAMI, Chairman of Working Party 1/11, to serve as overall point of contact with the ISOC/IETF. His e-mail address is: kitami@magnet.netlab.ntt.co.jp. As the need arises for extensive interaction in particular work areas, it is our intention to appoint appropriate individuals as contact persons in those areas, so that distributed communications may accelerate information exchange. So far the following points of contact have been identified: Subject: DSS2 and B-ISUP support of services over the Internet IETF Working Groups: ION, MPLS, DIFF-SERV, INT-SERV, RSVP, RAP Contact: Dr. Kenichi KITAMI, kitami@magnet.netlab.ntt.co.jp Subject: Intelligent Network interoperation with services over the Internet IETF Working Groups: PINT Contact: Professor Zhengkun Mi, mizk@njupt.edu.cn 3. Major Achievements of the ITU-T SG11 May 1998 meeting 3.1 Major objectives of ITU-T SG 11 concerning Signalling Support of Services Over the Internet The participants agreed that there are 5 objectives for efforts within Study Group 11 for standardization of Signalling Support of Services Over the Internet (SoI): a) Efficiently identifying and routing traffic destined for Internet Service Providers (ISPs) to minimize negative impact upon the Public Switched Telephone Network (PSTN), which has been engineered for relatively short holding time calls; b) Defining signalling support for new, value added services which may enable public network operators, as well as ISPs, to capitalize on the growing demand for Internet based and Intelligent Network (IN) based capabilities; c) Serving the need of ISPs, Internet Access Providers, and "Internet users" to flexibly manage dynamic bandwidth and quality of service demands from a public network; d) Defining mobile wireless access to services over the Internet, e.g., virtual private networks, provided by either ISPs or public network operators; and e) Signalling support for Service Interworking of both dialup Internet access data applications and Voice over IP applications with traditional telecommunication services, including support of signalling applications and user parts over IP based networks. 3.2 DSS2 and B-ISUP support of services over the Internet Related to objective c) mentioned above, ITU-T SG 11 received a written indication from the co- chairman of the MPLS WG that support for the end to end transport of MPLS VCID had been discussed in the MPLS WG and were considering the use of a structured UUI information element. A number of contributions addressing this subject were also received. The result of the discussions within ITU-T SG 11 are: 1) Agreement to associate an ATM Virtual Connection with an Internet Session, or an MPLS VCID, at the occasion of the connection setup, via the Generic Identifier Transport information element; 2) The creation of two baseline documents, one for DSS2 (UNI signalling)and the other for B- ISUP (NNI signalling); and 3) Agreement in principle to initiate approval of the draft Recommendation in the next ITU-T SG 11 meeting in March 1999 (implying final approval in February 2000). Individuals interested in viewing the details of the DSS2 baseline document should send a request to gratta@lucent.com. A Word format document (of TD GEN/11-67R1) will be forwarded to such individuals. Greg Ratta, Vice Chairman, ITU-T WP 1/11 Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com From owner-ion@sunroof.Eng.Sun.COM Wed Jul 15 18:43:44 1998 Delivery-Date: Wed, 15 Jul 1998 18:43:45 -0400 Return-Path: owner-ion@sunroof.Eng.Sun.COM Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.8.5/8.8.7a) with SMTP id SAA27509 for ; Wed, 15 Jul 1998 18:43:43 -0400 (EDT) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA01529; Wed, 15 Jul 1998 15:31:52 -0700 Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with ESMTP id PAA08293; Wed, 15 Jul 1998 15:31:50 -0700 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA06258 for ion-dist; Wed, 15 Jul 1998 15:23:52 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id PAA06251 for ; Wed, 15 Jul 1998 15:23:43 -0700 (PDT) From: gratta@holta.ho.lucent.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA10862 for ; Wed, 15 Jul 1998 15:23:38 -0700 Received: from ihgw2.lucent.com (ihgw2.lucent.com [207.19.48.2]) by earth.sun.com (8.8.8/8.8.8) with SMTP id PAA08376 for ; Wed, 15 Jul 1998 15:23:31 -0700 (PDT) To: ion@sunroof.Eng.Sun.COM, mpls@external.cisco.com, diff-serv@BayNetworks.COM, int-serv@isi.edu, qosr@newbridge.com, rsvp@isi.edu, rap@iphighway.com Cc: rcoltun@fore.com, nip-kita@ma.kcom.ne.jp, ARSHEY.ODEDRA@ITU.CH Received: from holta.ho.lucent.com by ihig2.firewall.lucent.com (SMI-8.6/EMS-L sol2) id RAA26181; Wed, 15 Jul 1998 17:02:12 -0500 Received: from nj7460grattal.holta by holta.ho.lucent.com (SMI-8.6/EMS-1.4.1 sol2) id RAA24401; Wed, 15 Jul 1998 17:16:24 -0400 Message-Id: <199807152116.RAA24401@holta.ho.lucent.com> Comments: Authenticated sender is Original-To: ion@sunroof.eng.sun.com, mpls@external.cisco.com, diff-serv@BayNetworks.COM, int-serv@isi.edu, qosr@newbridge.com, rsvp@isi.edu, rap@iphighway.com Date: Wed, 15 Jul 1998 17:26:40 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: (ION) ITU-T SG 11 discussions concerning Internet interoperation with Original-CC: rcoltun@fore.com, nip-kita@ma.kcom.ne.jp, ARSHEY.ODEDRA@ITU.CH X-mailer: Pegasus Mail for Windows (v2.52) Sender: owner-ion@sunroof.Eng.Sun.COM Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to ion@sunroof.eng.sun.com X-Info: Hypermail archive at http://netlab.ucs.indiana.edu/hypermail/ion/ ITU-Telecommunication Standardization Sector Study Group 11 Questions: ALL (SoI) SUBJECT: Status of SoI discussions concerning Internet interoperation with DSS2 and B-ISUP signalling APPROVAL: ITU-T SG 11 in Geneva, 22 May 1998 1. Introduction The May 1998 meeting of ITU-T SG 11 benefited from the participation of the following ISOC representatives: - Dr. Hui-Lan Lu, ISOC representative appointed by the PSTN/Internet Internetworking Working Group to Working Party 4/11 (Intelligent Networks)(Questions 5/11 and 22/11); - Mr. Joel M. Halpern, ISOC representative at ITU-T Study Group 11 Meeting, Geneva, 4-15 May 1998; and - Mr. Matt Holdrege, IETF Transport Directorate Liaison to ITU-T SG 11. Their contributions to the progress of our work during our May 1998 meeting were significant both in technical substance and in assisting the participants of ITU-T SG 11 to understand the ongoing work at ISOC/IETF, thus initiating a constructive dialogue between the two organizations. 2. Future interactions ITU-T SG 11 has appointed Dr. Kenichi KITAMI, Chairman of Working Party 1/11, to serve as overall point of contact with the ISOC/IETF. His e-mail address is: kitami@magnet.netlab.ntt.co.jp. As the need arises for extensive interaction in particular work areas, it is our intention to appoint appropriate individuals as contact persons in those areas, so that distributed communications may accelerate information exchange. So far the following points of contact have been identified: Subject: DSS2 and B-ISUP support of services over the Internet IETF Working Groups: ION, MPLS, DIFF-SERV, INT-SERV, RSVP, RAP Contact: Dr. Kenichi KITAMI, kitami@magnet.netlab.ntt.co.jp Subject: Intelligent Network interoperation with services over the Internet IETF Working Groups: PINT Contact: Professor Zhengkun Mi, mizk@njupt.edu.cn 3. Major Achievements of the ITU-T SG11 May 1998 meeting 3.1 Major objectives of ITU-T SG 11 concerning Signalling Support of Services Over the Internet The participants agreed that there are 5 objectives for efforts within Study Group 11 for standardization of Signalling Support of Services Over the Internet (SoI): a) Efficiently identifying and routing traffic destined for Internet Service Providers (ISPs) to minimize negative impact upon the Public Switched Telephone Network (PSTN), which has been engineered for relatively short holding time calls; b) Defining signalling support for new, value added services which may enable public network operators, as well as ISPs, to capitalize on the growing demand for Internet based and Intelligent Network (IN) based capabilities; c) Serving the need of ISPs, Internet Access Providers, and "Internet users" to flexibly manage dynamic bandwidth and quality of service demands from a public network; d) Defining mobile wireless access to services over the Internet, e.g., virtual private networks, provided by either ISPs or public network operators; and e) Signalling support for Service Interworking of both dialup Internet access data applications and Voice over IP applications with traditional telecommunication services, including support of signalling applications and user parts over IP based networks. 3.2 DSS2 and B-ISUP support of services over the Internet Related to objective c) mentioned above, ITU-T SG 11 received a written indication from the co- chairman of the MPLS WG that support for the end to end transport of MPLS VCID had been discussed in the MPLS WG and were considering the use of a structured UUI information element. A number of contributions addressing this subject were also received. The result of the discussions within ITU-T SG 11 are: 1) Agreement to associate an ATM Virtual Connection with an Internet Session, or an MPLS VCID, at the occasion of the connection setup, via the Generic Identifier Transport information element; 2) The creation of two baseline documents, one for DSS2 (UNI signalling)and the other for B- ISUP (NNI signalling); and 3) Agreement in principle to initiate approval of the draft Recommendation in the next ITU-T SG 11 meeting in March 1999 (implying final approval in February 2000). Individuals interested in viewing the details of the DSS2 baseline document should send a request to gratta@lucent.com. A Word format document (of TD GEN/11-67R1) will be forwarded to such individuals. Greg Ratta, Vice Chairman, ITU-T WP 1/11 Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe ion' in the body of the message.