IEPM

PingER phone meeting between HEPNRC & SLAC 6/21/00

Rough notes by Les Cottrell
Attendees: Les Cottrell, Warren Matthews - SLAC; Bill Lidinsky, George Beranek - HEPNRC.
Comments in bold face italics are action items. SLAC Home Page


Agenda

Caltech

Caltech has some security concerns and thus don't want to make the data available via the web. Warren is collecting the data using a Perl script running at Caltech to an ftp incoming directory at SLAC automatically each night, Warren then extracts it automatically. FNAL will look at automatically getting the data out of their incoming directory, then Caltech can send it to both places.

Missing Data

Data from two sites RAL and ESnet are missing. ESnet is a special case requiring a password. George will look at why the two sites appear to be having problems.

Releasing new timeping.pl

HEPNRC has successfully installed and configured the new timeping, and it is working with the new Beacons (May00) list. Warren confirms that the data is now being collected correctly.

New beacon Sites

The new Beacon list is at http://www-iepm.slac.stanford.edu/pinger/beacons-jun00.txt.

# --------------- New Beacons Updates May 2000 -------------------                         
# The last set of Beacons was finalized about 6 months ago. 
# Now (June 2000) the Beacons need to reflect that we have over doubled the 
# number of countries monitored (72) 
# and increased the # of monitoring sites and need to augment the Beacon sites.
# There have also been some corrections needed for the existing Beacon sites 
# As of the release of this Beacon list we have 30 monitoring sites, 
# 75 monitored countries, over 2200 pairs and 74 Beacons.
# The list below shows the changes made for the June 2000 Beacon list compared
# to the August-September 1999 Beacon list.

With the release of the new timeping.pl we need to also release the new beacons list. One can run the olkd timeping with the new beacons list, or the new timeping with the old Beacons list.

Naming of Remote Hosts

George points out that it would be much easier in having continuous data if there was a standard alias for remote hosts (e.g. ping.domain). Then if the hardware is replaced the name would continue. On the other hand if a host does change so may performance, so it may be useful to know. Warren has a site vs. host option in pingtable.pl that provides a way to aggregate data from multiple hosts at a site that also takes care of host name changes at a site. The host requirements recommendations (see   http://www.slac.stanford.edu/comp/net/wan-req.html) does recommend that an alias be used, and the alias be "ping". There are about 13 such hosts. We agreed it would be nice to have this, but eforts so far in effecting this has been minimally effective, so it was agreed to keep the recommendation and if we have a remote site contact list then make the recommendation to the contacts.

Notifying remote sites of ping activities

SLAC security folks have asked that we (SLAC) notify contacts at all remote sites monitored by PingER of our activities. There are about 256 hosts monitored from SLAC. About 90 of these sites have contacts. Some of the hosts belong to an organization, for example 20 are surveyor or ippm or advanced, 5 are amp, 4 are nlanr, 4 are Intel, 12 are XIWT. So maybe we only need a single contact for those. So we may need to get contacts for about 150 sites. When we have the contacts then we can notify them.

This still leaves several questions:

What do we want from each site (host):

Rate Limiting

Les has been working with a student and Warren to try and identify and see the effect of rate limiting. It appears that using existing ping data to get a signature does not work well. We appear to need to make synack comparisons occasionally (e.g. monthly) at least for Beacon site: in order to reduce the rsik of being mis-identified as a port scan these tests should be done against port 80 (www) Port 25 (smtp) for mail servers Port 53 (domain) for name servers Port 21 (ftp control) for FTP servers. We may nned alternates for sites where the above are not chosen hosts for PingER. Requires adding a port and method directive if see port then use synack on it need a way to not do pings, e.g. method=-ping

Action Items

Bill will contact the security folks at FNAL about the need to notify sites of ping activity to get a reading from them on this. George will look at the missing data from RAL & ESnet and try and fix.  Les will announce the new Beacon list. Les will look at how to notify sites of PingER activity. George will look at getting the Caltech data. Warren will announce the new timeping.pl to the pinger-admin@slac.stanford.edu mailing list.

Back to Top


Revised: June 21, 2000
Comments to iepm-l@slac.stanford.edu