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]