[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
INTERNET-DRAFT               Kohei Ohta [kohei@nemoto.ecei.tohoku.ac.jp]
draft-kohei-rmon-svcloc-00.txt                        Tohoku University.
                             Tomohiro Ika [ika@nemoto.ecei.tohoku.ac.jp]
                                                       Tohoku University
                                      Glenn Mansfield [glenn@wide.ad.jp]
                                                    Cyber Solutions Inc.
                                                           November 1997


               Network Service Discovery using RMON-MIB.


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. Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress."

   To learn the current status of any Internet-Draft, please check the
   1id-abstracts.txt listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or
   munnari.oz.au.
Abstract
   The Remote network monitoring MIB may be conveniently utilised to
   discover network services. This memo briefly outlines the technique
   of carrying out the discovery.

Table of Contents

   1.  Introduction .................................................. 2
   2.  The Network Service Discovery Algorithm ....................... 2
   3.  The Details  .................................................. 3
   4.  Examples of Discovered services ............................... 4
   5.  Pros and Cons ................................................. 5
   6.  Acknowledgements .............................................. 5
   7.  References .................................................... 5
   Security Considerations ........................................... 5
   Authors' Addresses ................................................ 6






Expires: May 16, 1998                                           [Page 1]


Internet Draft                                          November 16 1997


1. Introduction


   Remote network monitoring devices are probes that are deployed to
   look at all packets in a connected network segment(s). These are
   generally dedicated devices with dedicated resources to carry out
   traffic capture, filter and analysis at a Managers bidding.  The
   Remote Network Monitoring Management Information Base, RMON-MIB
   [RFC1757] , provides an interface to a remote networking device which
   is called an RMON-agent. The more recent Remote Network Monitoring
   Management Information Base version 2, RMON2-MIB [RFC2021] has even
   more efficient and sophisticated facilities. Both can be conveniently
   used to to discover various network services. In this memo we show a
   simple mechanism to discover network services by using the RMON-MIB
   which is more widely deployed.


2. The Network Service Discovery Algorithm


   An RMON-agent can be configured to filter the probed network traffic
   by protocol and send a notification to a manager in case a packet
   passes the filter. A  protocol directory containing the essential
   details required to identify a network service in a packet is
   required.  It will essentially tell the position and value of the
   corresponding assigned portnumber [RFC1700]. The RMON2-MIB has a
   built-in protocol directory.

   The RMON agent will be probing the traffic and watching for packets
   which correspond to any of the network services listed in the
   protocol directory, by applying the corresponding "service filters".
   If a packet passes the filter, it is "captured" and a "network
   service discovered" notification is sent to the Network Manager which
   is performing in the role of a network service discoverer.

   When the network manager receives a "network service discovered"
   notification it fetches the captured packet(s) from the RMON-agent.
   determines the corresponding server address from the packet (IP-
   Source). And updates the network service directory appropriately.  To
   reduce load on the system, the network manager may also apply a
   suppress filter to suppress similar packets (describing the same
   service on the same server) from being captured.

   Fig. 1 shows the algorithm schematically.







Expires: May 16, 1998                                           [Page 2]


Internet Draft                                          November 16 1997


                            RMON Agent
              +--------------------------------------+
   network    | service filter --- channel --- event |     discovery
   traffic -->|                     |                | -->   client
              | (supress filter)----+                |        |
              +-------^------------------------------+        |
                      |                                       |
                      +---------------------<-----------------+

        Fig. 1. Network Service Discovery using an RMON Agent





3. Details.



3.1 Filter Definitions for discovering network services.

   The definition of filters to be used in the RMON probe essentially
   comprises three Managed Objects - filterPktData, filterPktDataMask,
   and filterPktDataNotMask. Each of these are bit patterns and are
   briefly explained below. For detailed descriptions refer to RFC1757.

      o filterPktData is the data that is to be matched with the input
        packet.
      o filterPktDataMask is the mask that is applied to the match
        process.
      o filterPktDataNotMask is the inversion mask that is applied to
        the match process.

   For example the following filter is applied to discover an HTTP
   service related packet.

           IP                      TCP                      HTTP
   ---------------------------------------------------------------
   filterPktData =
             8 0 0 0 0 0 0 0 0 0 0   6 0 0 0 0 0 0 0 0 0 0   0  80
   filterPktDataMask =
           255 0 0 0 0 0 0 0 0 0 0 255 0 0 0 0 0 0 0 0 0 0 255 255
   filterPktDataNotMask =
           255 0 0 0 0 0 0 0 0 0 0 255 0 0 0 0 0 0 0 0 0 0 255 255

   Note, for divide and conquer, above filter is configured as SUPRESS
   filter by filterPktDataNotMask object.




Expires: May 16, 1998                                           [Page 3]


Internet Draft                                          November 16 1997


   These filters are needed for each service and associated to channels.


3.2 Scope of Discovery

   It is straightforward to restrict the discovery to a specific network
   or networks. A target network is specified by a network number and
   mask. For each target network a filter is configured and associated
   to the channel.

   Example: Say we want to restrict the discovery to the following
   networks defined by a network number and mask,

           130.34.199.0/26

   The corresponding filter configuration is as follows:

            IP                           IP source addr
   -----------------------------------------------------------------
   filterPktData =
             8 0 0 0 0 0 0 0 0 0 0 0 0 0 130  34 199   0 0 0 0 0 0 0
   filterPktDataMask =
           255 0 0 0 0 0 0 0 0 0 0 0 0 0 255 255 255 192 0 0 0 0 0 0
   filterPktDataNotMask =
           255 0 0 0 0 0 0 0 0 0 0 0 0 0 255 255 255 192 0 0 0 0 0 0

   These filters are also configured as SUPRESS filter as same as above
   service filter.


4. Examples of Discovered services

   The following is an example of the network services directory which
   is dicovered by employing the filters shown in examples of 3.1 And
   3.2.
















Expires: May 16, 1998                                           [Page 4]


Internet Draft                                          November 16 1997


   +--------------------+----------------+-----------------+
   |                    |  service name  |  server address |
   +--------------------+----------------+-----------------+
   |                    |    www-http    |   130.34.199.4  |
   |                    |    www-http    |   130.34.199.35 |
   |   target network   |    www-http    |   130.34.199.8  |
   |  130.34.199.0/26   |    ftp         |   130.34.199.8  |
   |                    |    domain      |   130.34.199.2  |
   |                    |    domain      |   130.34.199.2  |
   |                    |    pop3        |   130.34.199.2  |
   |                    |    ntp         |   130.34.199.2  |
   :                    :       :        :         :       :
   +--------------------+----------------+-----------------+


   The discovery time-stamp is also available.


5. Pros and Cons.

   The technique proposed is useful as it is automatic and passive. It
   does not count on any other service and is thus more robust. If there
   is a service and if it is being used via the segment on which the
   RMON agent is attached, it will be detected.

   On the other hand the technic is passive. If the service is not used
   it will not be detected. And, the technic can be used only in places
   where an RMON probe can be attached.



6.  Acknowledgements.

   This draft is the product of discussions and deliberations carried
   out in the NetMan working group of Tohoku University.

7.  References

      [1] CCITT Blue Book, "Data Communication Networks: Directory",
          Recommendations X.500-X.521, December 1988.


Security Considerations

       In deploying the proposed mechanism, care will need to be taken
   to ensure the authenticity of the sources of information viz. the
   DNS servers and the WHOIS servers.
       It needs to be noted that information from these sources do not



Expires: May 16, 1998                                           [Page 5]


Internet Draft                                          November 16 1997


   in generally carry any guarantee about the integrity or consistency
   of the contents.
       Clients availing of the directory services will need ensure the
   authenticity of the corresponding servers.


Authors' Addresses

      Kohei Ohta
      GSIS, Tohoku University
      Aoba-ku, Sendai
      Japan

      Phone: +81-22-217-7140
      EMail: kohei@nemoto.ecei.tohoku.ac.jp

      Tomohiro Ika
      GSIS, Tohoku University,
      Aoba-ku, Sendai 989-32
      Japan

      Phone: +81-22-217-7140
      EMail: ika@nemoto.ecei.tohoku.ac.jp

      Glenn Mansfield
      Cyber Solutions Inc.
      6-6-3 Minami Yoshinari
      Aoba-ku, Sendai 989-32
      Japan

      Phone: +81-22-303-4012
      EMail: glenn@wide.ad.jp



















Expires: May 16, 1998                                           [Page 6]