Les Cottrell, SLAC, last update April 22, 1997
| Networking | Distributed Computing |
There were about 12 attendees. The main topics were spamming (unsolicited email), macro viruses, security (e.g. PGP) directions. The chair was Mark Rosenberg of LBNL.
The most offensive problem is offensive email spamming, such as child portnography. Legislation may help in addressing this. It was recognized that there is little we can do about this. There may be pressures on ISPs to ensure return addresses are not bogus. The IETF was said to be working on recommendations to identify unsolicited Email (e.g. by a "Bulk Mailing" header of some kind). One person mentioned that Portland phone books have an option for an identifier against the name of people who do not wish to receive unsolicited (e.g. telemarketing) phone calls. If this is violated the first time the telemarketer gets a warning, and after that the aggrieved party can sue.
Four of the 12 attendees said their sites pass spam complaints to the postmaster. The others seem to rely on users to simply ignore/delete spam mail or use Email user agent filters. PNL said their culture is to simply tell users to delete spams. Bill Wing of ORNL felt it is not worth the overhead of extraordinary efforts to subdue the amount of spamming. Ames have discussed blocking sites and expect to have to do it soon but have not implemented it yet. SLAC blocks about 60 sites. It was agreed that ESnet sites would share their lists of blocked sites by sending them to Mark Rosenberg. A lot of the spammers harvesting of email addresses seems to come from email lists. Nobody is currently talking about restricting majordomo list in response to spamming. It was also pointed out that the ESnet X.500 database would be another good source of email addresses. Unfortunately majordomo does not appear to have much granularity on what people can scan its lists, or where it accepts postings from.
LBNL (Mark Rosenberg reported) has put in a virus scanner (Interscan Virus Wall from Trend Micro, licensing depends on number of users for LBNL was about $7K for 3000 users) in a mail gateway (running on a Solaris Sparc 5 box) that scans all mail enclosures. Last week it found 31 viruses (7 different instances such as Concept, Wazoo) in tens of thousands of email messages scanned, some going in to LBLNL, the majority going out (matches external to internal email ratios). They do not restrict to which hosts email can be sent (SLAC does restrict at the router firewall), so only email addressed via the gateway (i.e. mail addressed as user@lbl.gov) are scanned. They also have a Scan Mail virus checker for ccMail. They have nothing for QuickMail. Most of the viruses are aimed at Macs, since the anti-virus software for the Macs is not as advanced. They had to increase the RAM to 112MB, and the disk space on the gateway. There appears to be no impact on delaying delivery of Email. They surveyed virus scanners about a year ago, it had to run on Solaris, and they looked at a couple of others. The gateways will only scan one protocol (e.g. only MIME, or only uuencodes, or binhex, LBNL only support MIME).
Entrust was mentioned, but nobody seemed to have experience. LLNL was supposed to be looking at an Entrust enabled Eudora. AT&T has said that Secret Agent will work with Entrust. Secret Agent has the hooks to get into Email user agents, but was said not to work with the modern clients (e.g. Windows 95 clients). INEL is looking at PGP, Cisco is said to be looking at SMIME. Scanning for viruses will be harder when they are encrypted.
NGI is the major focus. The new DOE secretary is Federico Pena from the department of transportation. See http://www.er.doe/production/octr/octr.html for more information on the MICS office. Two thrusts: national colaboratories and weapons simulation. ESnet budget is $14M expect to be flat, DOE2000 is $9M this year, NGI $35M starting in FY98. NERSC finished move Oct 22 '96, Strategic plan completed, progress report will finish early CY 97, NGI Concept paper finish May 97 (send comments now), NGI workshop May 97 is by invitation only (also see www.ngi.gov), ESnet video support re-evaluation due mid CY 97, (should it continue, can it be done by private industry), NGI implementation plan due June 97, ESnet program plan (requirements plan) due mid CY 97, NGI budget received late CY 97, ESnet program plan for NGI mid CY 97 (Congress is hesitating, need a better selling job especially on the details), ESnet program review mid CY 98 (last one 3 years ago).
Why is DOE involved in NGI: long established & successful role in network research (multicast implementers & congestion control) & early incorporation of advanced tech, into production (e.g. ATM, kerberos ...); DOE uses Internet in a major way to do research. The current Internet is a victim of its own success, has gone from a tool for scientists & engineers to overloaded public utility. DOE has programs at 278 colleges & universities.
Timeline: 100+ site hi-perf test beds w' OC3 connections over OC12 1998-9; Federal-Academic-Industry partneships 99-00; 10+ at OC48 in 1999; consortiums conduct network applications using hi-speed 99-00.
DOE will put $25M in 100x program, & $6M in 1000x program, plus $4m in applications. Other agencies are DARPA, NSF, NASA, DOE, (NIH). The total is $100M over 3 years (there are hopes it will get extended to 5 years), $60M is new money. DOE has many roles in NGI, about 10 were mentioned, one was network monitoring.
14.3 Gpkts accepted, 1.31% DECnet (an actual decrease as oppsed to relative decrease), 4.53 TB in Mar 97, about 10% growth in last year also packet size growing (277 -> 317 bytes). Starting Nov 95 traffic seems to have flattened out but this appears to be an artifact of changing over the measurement software in the last year, also a lot of the international traffic moved off ESnet to public carriers.
New sites: Allied-Signal (Albuquerque) T1 in progress via Sandia-NM; INEL T1 via LLNL awaits routing plan; Rutgers T1 via PPPL online Apr-97; Savannah River T1 via ORNL online Mar-97; Chicago NAP T3 via Chicago hub scheduled (4-6 weeks away); SDSC T3 via GA expect Apr-97 with improved peering to vBNS & SDSC will also improve connectivity to CalREN; UCnet via LBNL DMZ peering established thru LBNL-ESnet connection on-line Feb-97; Network Virginia (consolidation of some higher education and some State establishments in Virginia) T3 via DC hub awaiting activation of Sprint-DC hub; Princeton U. T1 via PPPL extend use of existing facilities.
Bandwidth changes: FIX-W, Sprint NAP: PVCS upgraded to 10Mbps; PNNL T3/ATM access scheduled Apr-97; MIT T3/ATM access planned scheduled Mar-97 locally delayed; FNAL OC3 via Chicago hub scheduled; ORNL upgrade to OC3 scheduled Apr-97 (ORNL paying incremental costs); LANL, Sandia/NM upgrade to OC3 shared port for 2Q97, DP paying incremental costs; JLAB being moved to DC hub at T3. SSC was disconnected Dec-96 end of an era. Interesting aside, in many cases T3 costs are similar to OC3 costs.
Domestic Issues: native ATM access to FNAL installed 1Q97; site changes at ANL via Chicago hub, FNAL via Chicago hub, UWisc connected indirectly via NAPnet FNAL (will replace the IP tunneling) - this could be a model for other universities (UWisc<-IP/ATM->NAPnet<-IP/ATM->FNAL<-IP->ESnet, there is an ATM PVC carrying IP between NAPnet & ESnet).
Sharing a Sprint ATM port among multiple sites, is cost effective since the cost of the port is the most expensive component, upgrades can be staged i.e. upgrade port for aggregate traffic, then upgrade sites as appropriate, can more easily reconfigure to meet changing site requirements. The hubbing is done at carrier (Sprint) facilities which reduces local-loop costs and provides conditioned facilities (e.g. back up power).
Plans for hubbing include: Oakland POP; San Diego (SDSC, GA, ITER-US all at T3); Chicago POP (ANL OC3, FNAL OC3, CHI NAP T3); Albuquerque (LANL T3, Sandia/NM OC3); DC POP (JLab at T3); NY POP (BNL, MIT, PPPL all at T3). Each hub connects into the Sprint ATM cloud at either OC3 or T3.
DC Hubbing plans include bringing in MAE-E (T3 will avoid FIX-E congestion), DOE (3*T1), Network Virginia OC3, JLab (at T1 & T3), DFN, CERN (N*E1), vBNS (OC3-12). The ESnet router with DOE, MAE-W, Network Virginia and the Sprint cloud (T3) is at Sprint POP at Conn Ave the rest is at the MCI POP at Perryman. Perryman and Conn. Ave., will upgrade connection from T1 (via JLab today) to T3 (in May-97). INFN and DANTE may also come into the DC hub (unclear whether Conn Ave or Perryman).
ER in FY97 funded 250 universities for over $400M; ESCC believes that university access to/from ESnet needs improvment. An ESSC sub-committee to assess & prioritize, chaired by Walter Toki, recommended ~ 15 sites "most deserving" in two groups "bad" and "poor". UCnet should help 2 of the sites (UCSD, UCI), further improvements expected with CalREN2 peering. UWisc improved with peering through FNAL/NAPnet. DC hub/Network Virginia will help UMd & Johns Hopkins U. Other university sites need consideration wrt NGI, Internet II.
ESnet peers with about 50 networks at FIX/MAE-W.
Utilization for DFN-PPPL used to be 75% over 50% of the month Oct-95. There were many complaints. Recently DFN installed 2 transatlantic (TA) T3s that terminate in the MCI POP (Perryman just outside Washington) rather than the Sprint NAP in New Jersey. It was operational in mid-Jan-97 (IP only). ESnet managed to get a T3 connection between the Sprint POP in Conn. Ave to Perryman. The PPPL-DFN T1 was turned off at the end of Feb-97. DFN is peering directly with Internet/MCI. INFN and DANTE (should help ESnet connections to TEN-34) are planning to arrive later.
INFN link looks good (5% loading 50% of time) due to unloading of traffic onto other (non ESnet links). They have plans to use DFN TRansAtlantic NxT3 access.
The Japanese JAERI link (128kbps) is getting more heavy use, probably about 20% use. The 512kbps KEK traffic is also going up with utilization at about 25% capacity. The NIFS 64kbps link has also grown to about 30%. All three links are on the edge of needing upgrading. Have selected a competitive proposal for two frame relay connections from ATT/KDD with NIFS 128K CIR, 256K port shared T1 access, and JAERI 768K CIR, 1Mb port shared T1 access. There are some default routing issues. KEK link will be a dedicated T1 to LBNL with ITJ as the Japanese vendors, ESnet will compete the US half circuit.
CERN currently has 1 T1/E1 terminated in MCI POP (West Orange) which peers with ESnet through Internet/MCI. MCI congestion has impacted ESnet access on occasion. CERN plan to upgrade 2-3 E2s (4-6Mbps) locating a router at Perryman which will peer with MCI & ESnet (connection via ATM between Perryman and Conn Ave). ESnet will provide collocation space at Perryman.
Canada plans to provide T1 between CA*net & ESnet scheduled for end Apr-97 at PPPL on interim (until DC hub fully ready) and move to DC later. The Chicago NAP may provide a better inter-connection (CA*net II is connected to the Chicago NAP at OC3).
NSF is promoting a STAR-TAP (Science Technology And Research Technology Access Point) overlayed at the Chicago NAP. Canarie (Canada) is already connected, APAN (Asia Pacific Advanced Networking) is interested as is Singapore, DFN not enthused (already connected to East coast).
ESnet looking at test bed network facilities which can crash & burn and may require bleeding edge performance, i.e. cannot run over the production network. They have looked at using ATM services for benign activities. One possibility might be the Sprint "guard bandwidth" which we would lose as soon as Sprint needs it. It would be for early use of leading edge performance (OC12) but the local loop is typically a problem.
ESSC concerns:
Prioritization guidelines (from Jan ESSC meeting):
Distributed computing support provides support for selected tools which have an impact on research facilities needs a support service to optimize use.
The network research/testbed will use the production network where compatible, but will provide a dedicated testbed where needed using incremental resources.
This is an ad hoc group of labs, users & providers meeting to coordinate & improve international networking. There have been meetings in Jul-95 (Napa), Feb-96 (Dulles), Jun-96 (Elba), Sep-97 (Santa Fe), plus video meetings.
Document & evaluate the status of networking used by the whole ICFA community, and analyse its likely evolution until the turn-on of LHC. This work should especially take into account:
The chair is David Williams of CERN. It has working groups on: monitoring, remote regions, present status, requirements analysis, and the proposal. Time scale is, at the end of 1998, to come up with a proposal on what to do and why. The next meeting is with the ESSC/ESnet International at Santa fe, Sept-97.
Since the last ESCC meeting several papers have been submitted for publication (see http://www.slac.stanford.edu/xorg/nmtf/nmtf.html for more information), progress has been made on visualizing the long term trends in the data, the monitoring software architecture for deployment has been defined, and the software has been successfully ported to a collection site (the University of Maryland). There has also been considerable interest expressed in the work and the results and presentations have been made to the FNC, CCIRN, ICFA and the ESSC. In the latter two cases the NMTF focus group is working to provide information to help in understanding problems with Internet performance and as a basis for deciding how to address.
The meeting on Monday was attended by about 20 people from 15 sites. The agenda can be found at http://www.slac.stanford.edu/xorg/nmtf/agenda-apr97. At the meeting details were presented on the deployment of software and the analysis, generation of reports, and how the reports may be used in the real world to select ISPs, provide Quality of Service (QOS) contract information, for trouble shooting and problem reporting. It is hoped to start deploying the software in the near future. Several sites including KEK (JP), RAL (UK), CERN (CH), DESY (DE), Hungary, INFN (IT), and MSU (SU) have agreed to act as collectors. Serveral other avenues to improve the software are also being explored and are in progress.
At the Monday meeting, Bill Wing of ORNL presented a proposal to build a tool to allow end-to-end monitoring of an ATM WAN. The idea is to build a box (e.g. a Linux based PC) which can inject timestamped cells into an ATM stream to another time synchronized (using GPS) host to allow one way trip times to be measured.
There are 7 people who cover network engineering, network monitoring and network services.
Used to have 63 peerings at 16 locations, now 110 peerings at 16 locations. They now carry 45K routes on the backbone, with 186 prefixes which ESnet is primary for.
ESnet access to UColo used to go from ESnet to MCI to Westnet to UC (goes thru West Orange POP). Now goes ESnet -> vBNS -> NCAR -> CU (which avoids MCI swamp at West Orange).
They have also improved peering to U Cal Network,
Running IPv6 on Cisco testing IPv6 RIP will be testing multiprotocol BGP. ESnet is part of the 6Bone test network which beside the US includes Italy, Japan.
Running new BESTview commercial product from BGS (Jon Saperia ex DEC MSU fame), replace 40k loc developed in house, it is still in beta. They are also using pathchar from van Jacobson. Used to characterize the route between an internet source & destination, determines bandwidth, delay, average queue & loss rate between any 2 hops. They have used the tool to discover a bottleneck in an ATM path. Internally they use the Cabletron Spectrum product. It is fairly stable, constantly find small bugs, work with Cabletron to fix. They have 2 Spectraservers in production, one in development. Cabletron is making an NT client (Spectrograph).
Includes lower level services such as MBONE and DNS. They have 2 name servers one at LBNL, one at PPPL, both are alpha based. Plan to add a nameserver at LANL. On the MBONE they announce about 270 subnets. There are now versions of MBONE tools (sdr, vic, vat, rat) that run under Windows NT. A working Windows NT only sdr (session director, the main user interface to allow one to bring up the video (vic) and audio (vat/rat) tools) lookalike (a rewrite of the sdr 2.2 function by Arlie Davis <arlie@thepoint.net) is available at http://archive.thepoint.net/Win32SD). Tommy Thomas of ORNL gave me a working demo running on a 133MHz Pentium laptop with Windows NT of the MBONE tools with a Connectix color camera (it also works with a greyscale Connectix). Mark Hanley has an sdr (version 2.2a21) for Windows 95 which Gary Olario at PPPL has made work, but Tommy Thomas or ORNL is having problems with (no announcements appear). It is available at http://www-mice.cs.ucl.ac.uk/mice/mice_home.html. There is no Whiteboard available yet for Intel Windows (95 or NT). Vic 2.8 for WNT is available from http://www.cs.ucl.ac.uk/staff/I.Kouvelas/vic/. The Connectix driver is available from www.connectix.com/connect/upda/quic.html.
This is a frame relay net connects nodes at 128kbps and in some cases up to T1. It is hard to set up since one needs routers etc. They have special security requirements. ESnet does provide security in pilot mode. We (ESnet) may need to educate them. It is unclear exactly what their needs are or whether ssh or pgp could help. It sometimes appears that their requirements change in response to protecting their network. According to Bob Aiken the problem is that sites need to resist connecting the Business net to ESnet by educating their directors about the stupidity of having 2 networks.
ESnet X.400 to be retired! Replacing mail hubs with more up to date Sun Enterprise servers running Sun Solaris with dual cpus, RAID disk array and configured as primary/secondary
Using public domain MTA: exim unmodified, list management smart list. Subscriptions are open or closed plus catches subscription requests. Unsubscriptions may be open or closed plus automatic bounce detection/clean-up. This is important for the IETF lists with 1200 members internationally they host. Postings may be open closed or restricted (specified list of posters). Digests posted at regular intervals. Management of the lists is via the Web, add/delet list members, view logs, view statistics, create customized introduction, help subscribe & unsubscribe. Also have priority queueing an 8bit SMTP processing. They cross post with netnews.
All servers are being upgraded and are transitioning to Solaris, will use Sun SparcStorage Arrays (RAID). They have autopatching for security buges etc from Sun, it is quite successful. They are using ssh & kerberized-rlogin diisabled all telent & FTP & TCP wrappers. They are installing "secure" terminal servers (Sun boxes with multiple ports and ssh stuff using a product discovered by PNL).
PGP Key Server has 43168 keys on public key ring, response was very slow so relocated to Sun Solaris & software upgraded, bugs found/fixed looking into new key server code.
ESnet community Cafe (www.es.net/cafe). It is a jump station for ESCC members, with site contact information and site ESnet property information, site upgrade plans/information (upgrade, open trouble tickets, milestones, equipment required). Also has late breaking news with news of interest to the ESnet community, a Cafe spotlight featuring sites, projects, resaerch efforts taking place over ESnet, conference info giving contact, information & site info for ESnet hosted conferences.
Will be adding streaming video to ESnet Web servers to serve ESnet's videos plus ESnet research/collaboratory videos, plus record/play back VCS conferences (there are some bandwidth/security issues), plus record/playback Mbone conferences and ESCC meetings (including delayed broadcast & individual presentations). The intent is to develop a "video library" with greatly varying retention. Emerging enabling technologies include "Closed Caption" technologies for indexing and searching, MPEG support coming to Java soon (class libraries, applets & plug-ins), also Oracle blobs. Looking at products for the Web MultiMedia server which will provide the above. The preferred server is Sun's MediaCenter server, for editing SGI's Octane workstation looks nice. Issues include responsible use of the bandwidth, minimal impact on the NOC/NIC, will have to look at caching servers around the sites. He gave a demo of streaming video of an ESnet presentation at http://192.74.215.252/ESNET.mpg, which was a local server in the same room, at 1.5Mbps compression using a product from Interview. It worked, there was a small amount of voice stuttering, and the video looked like 10 frames per second.
There are 3 major initiatives that will affect ESnet: the NSF "Connections" program, the Internet2, and NGI. My Mac crashed during this session (may Canvas rot in hell) so unfortunately I lost my notes on this. I will try and get information from Jim Leighton and add stuff here later.
Nov 95 HSSG (High Speed Standard Group) formed. Last feature added Mar-97, Products appearing 1997. On track for Mar-98 standard.
Collision diameter with a shared bus CSMA/CD feature is a problem. Gbit Enet would have ~20m collision diameter if just scaled. Extend minimum transmit-hold time (slot-time) with non-data symbols to hold onto wire for 512 bytes (4096 bit times, convenient number with margin for error - probably closer to 300m), then can see collisions up to ~200m (on fiber can extend to 400m). But loss of bandwidth. So then propose packet bursting to transmit up to 3000 bytes & as many a 24 packets in one transmission time. No changes to repeater designs, minimal change to MAC Pascal (state machine) design. Capture effect reduced by pushing out to higher loads. Makes HDX (half duplex Ethernet) a desirable option. Extends maximum network throughput from 550Mbps to 680Mbps. Still expect few people to use HDX Gbit Ethernet, expect more to use full duplex switching.
HP research indicates that "shaped" launch may yield longer distances up to several km. Connector to be specified in standard is duplex SC for SMF & MMF, both SWL (Short Wavelength Lasers) & LWL, at the equipment level. Modern miniature low cost fiber connectors will likely prevail in marketplace, these will be RJ-45 size, e.g. 3M Galaxy. Use your own choice of connectors in your backbone fiber plant. The new connectors are mainly for bulkheads and wall plugs and not for the backbone.
LWL laser safety issue - there will be a PCS procedure for this. There are also cheap, small fiber optic transceivers proposed.
Short Wave Length (750-850nm for multimode) was 200m is now to 300m, the LWL (1300nm for single mode) was 2km is now 3km.
Cisco is integrating the Gbps stuff into Cat 5000 and 75xx routers. Other, smaller, vendors are more aggressive and will have products before Cisco.
The 6bone is much larger, ESnet continues with stronger support for IPv6. The IETF IPng put out extensive effort to evaluate the O'Dell 8+8 (now called GSE) proposal. May have the first Big 6 ISP (MCI, Sprint, UUnet, PSI ...) player. ESnet heavily involved and is viewed as strong leaders in IPv6 process. Matt Crawford is a pricipal player in IETF IPv6 standards work, 6bone activity has become the IETF IPv6 activity with Bob Fink leading. Becca Nitzan is a major routing player. Networl/Interop Las Vegas will have IPv6 ready shownet drops on a sizable percent of the overall shownet. The 6bone now goes into 22 countries, 125 sites, 8 router implementations done or under way plus 20 workstations implementations done or underway (see www-6bone.lbl.gov/6bone/ (soon will be 6bone.net) for more information).
The DARPA CAIRN project is proposing to act as a native IPv6 core backbone for the 6bone (good native multicast opportunities here as well). The 6bone will soon switch to a real RIPE-191 style routing registry courtesy of ISI. They will soon restructure addressing to use IETF aggregation addressing standard.
Cisco IPv6 field test is well underway and ahead of schedule. RIPng was made available in Nov-96 ahead of schedule. The IS-IS & EIGRP extensions for IPv6 status is unknown (Dave Katz left to join a BFR company). BGP4+ for IPv6 is released for field test. Cisco strongly claims taht when IPv6 specs are solid, & if customers want it, it will move into the production IOS product line.
Current impediment is getting commercial ISPs to play. They are skeptical about IPv6. UUnet (Mike O'Dell) seems ready to join the 6bone as a core router backbone site. Now need some very new & different application that need IPv6 to move aheaed in deployment - a good candidate might be the international traffic monitoring industry that has approached the IETF IPng activity (think of traffic lights being networked, each with their own IP address).
Site renumbering now viewed as a key issue, and major efforts will be extended to standardize mechanisms and procedures. Concern is if a site changes provider, the site has to renumber which is a MAJOR effort. The idea is to specify how a site's network management might inform routers of new routing prefixes that will become active at a certain time. Overlap exists for weeks not minutes. When overlap expires active connection using the old prefix will die (this is the hardest problem to solve). This relies on IPv6 autoconfiguration so that within a site renumbering is not hard to deal with. It will have to be well documented.
There is a new addressing plan being proposed called "Aggregation-based" Unicast addressing structure. They introduced a 13 bit "Top Level Aggregator" (i.e. major ISPs or Exchanges). Below this the TLA allocates 32 bits for the Next Level Aggregators (NLA), below this is a 16 bit Site Partition (subnet), followed by a 64bit Node ID in EUI-64 format which can include the lower portion (24 bits) of the Ethernet Mac address.
For more information see: www.epm.ornl.gov/enote/
Involves three Labs (LBNL, ORNL, PNL), Goal to develop a common, flexible extensible electronic notebook architecture complete with prototype implementations available to DOE collaboratories & general community.
He showed the demo running on a Windows machine. It requires a Java capable browser, plus a Web server that can run Perl 5 scripts. If the notebook is to be portable and run without a network connection then both the browser & server must run on the same machine (e.g. a laptop). If a network connection can be assumed to be always available, then the server can run elsewhere. They are working on a Macintosh version (I think he must have been refrring to the server and the Perl 5 scripts).
Buttons allow add, edit, delete, annotate, & notarize, plus navigate via first, prev, next last, contents, & search. Easy to add documents (e.g. Web pages, plain text, gifs, tables, audio bite, graph, video - grabs current image) from elsewhere. Can have private or public notebooks. There is also a Java based sketchpad editor. The demo was quite impressive.
WG has not met yet, there is no membership defined, there is no charter yet. Want a group which is like ESCC was originally (back in 1989). The old ESCC charter was:
ESCC changed about the time of ATM backbone when it decided the emphasis should move to the higher layers. However, there are problems with the lower layers, in particular university connectivity. So the ENWG focus is to refocus on basic network infrastructure and is limited to the transport layer and below. Key issue is connectivity across ESnet backbone, to collaborating institutions (domestic & foreign) ... Participate in and extend various activities (ESnet, ESSC, NMTF, HEPNRC, ICFA NTF etc.) to:
Propose ENWG activities in the NGI. rovide a technical forum & intersite coordination, with ESnet, for NGI activities, including:
Propose providing a technical forum for interchange of information among site on new net technologies, including non-backbone technical issues such as:
These activities provide a reasonable initial set, a balance of "Classic Internet" & NGI issues with a few low maintenance items thrown in. Any added activities need high benefit/cost. Much work will be assigned to task forces:, including:
Next steps: achieve consensus, come up with plan, set up administration infrastructure.
Need to be discussing more technical networking issues. For example remote access servers, DHCP, xDSL trials, WNT networking, site switches network plans, ATM/WAN management for the end user ... Some of the discussions could be done in email lists but it also needs face to face meetings. Could do much of the discussions in a"Monday" all-day meeting (instead of just the current half day) in addition to the existing working group meetings (EMTF, NMTF). The idea would be to have realtime discussions, possibly moderated, on issues pre-discussed in email lists, but with either no or limited formal presentation. Will need to leverage off each others' experiences. The ENWG chair (Mark Kaletka) will be discussing with Jim Leighton how to make the ENWG work well with ESnet.
See www.mcs.anl.gov/DOE2000/ for DOE2000's home page.
DOE2000 will change the way DOE does collaborative experiments and computatio. There are 3 components: a toolkit for advanced computational testing and simulation (ACTS) - includes DP weapons stewardship simulation; collaboratory technology research & development; collaboratory pilot programs. ACTS FY97 funding directed at making existing tools interoperable & usable by ER & DP.
Collaboratory R&D focuses on development of new capabilities & enhancing tools, plan for support as tools mature, close interaction with pilot projects & other users. R&D projects include shared Virtual Reality, software infrastructure, collaboration management, security infrastructure, electronic note books, floor control (takes care of problem of someone in a video conference wanting to get attention - analogy of putting up one's hand, Van Jacobsen is working on this), and quality of service (CVQ?).
There was a call for proposals by Dave Nelson (OCTR) to other DOE programs, to define collaborations, looking for high impact ... There were 17 proopsals submitted, all with matching funds. The technical review identified 5 highly qualified proposals, the final selection based on DOE mission criteria brought it down to two projects which were funded. The 2 funded were: diesel combustion (reduce pollution and increase efficiency for next generation of engines); and a materials microcharacterization collaboratory (e.g. catalytic converters for diesel engines), some efforts are going on with others with limited funds.
Tools must be supported, so DOE2000 will establish a support site to test, document & distribute software developed in R&D projects as well as in the community, this support will be closely integrated with ESnet & NERSC support.
See www.mcs.anl.gov/DOE2000/ for DOE2000's home page.
Looking at 3 time frames: immediate utility; 6 month plan; 3 year project to "revolutionary" functionality.
Electronic notebook (LBNL, ORNL, PNNL) shared www based access to data, query/search, secure, interactive ... Six month plan is to have: working/extensible notebooks with text, image capture, spreadsheet, sketch, UI improvements, signing; a publishes API for adding editors/viewers to allow 3rd party tools; join the CENS consortium - an industry group working to promote commercial notebook development.
DOE2000 Collaboration management (ANL, PNNL) provides basic tools for realtime collbaoration, will provide an AI for adding new tools, session management, plus dynamic choice of floor control policy (open, lecture, manual ...). It will have shared browsers, file transfer, chat box, televiewer ...). They are looking at the bae platfor including NCSA Habanero, NPAC tango, Sun Collaboration API, EMSL Core. Then will add port shared browser, televiewer, A/V to new environment, and to provide/promote an API.
DOE2000 collaboration interoperability framework (ANL, LBNL, PNNL, SNL) will promote interoperability of other R&D projects, identify common needs (multicast (reliable, unreliable), person database, security interface, common metadata (notebook, security, PRE objects)), and evaluate/promote integration technologies (Java, CORBA). In the last 6 months they (the collaboration interoperability framework group) have defined the API and developed version 1.0. They have gained CORBA knowledge (Sandia PRE framework, Mitre DISCUS, examples of R&D projects); and (I think) have a Person LDAP server.
The purpose of the group is to:
This would be focused for ESnet (the big MBONE list is rather intimidating to post to) and could evolve into the ESnet help desk.
The WWW pages will include:
Examples of tools: DCE, CORBA, Java, Habernos, Tcl/TK, LabView, Kerberos, Public Key, MBONE videoconferencing (Deb has a Web site for this and she has excellent contacts with Van Jacobsen a major devleoper of these tools), Moo/MUD, IRC, SSH, CuSeeMe, CoolTalk. Need volunteers to provide web sites for these tools.
In the short term (it may move to the DOE2000 page space) see: http://www-itg.lbl.gov/AWG.html
Separate from (but complementary to) the existing NOC, trouble-ticket system, ESnet infrastructure services, networking services or physical networking services. It will facilitate communication, supports a variety of services, ESnet TTs treated as a peer to all other TTs, distributes problem resolution responsibility. It is meant for distributed collaborators who are using collaboratory applications on a collaboratory infrastructure.
The proposed approach treats all (at multiple sites) existing TTS (Trouble Ticket Systems), help desks & points of contact are as peers (these are collectively referred to as POCs); end users are treated as customers of POCs; all POCs are centrally registered; all POCs know of all other POCs; users only know of their local POCs. There will be a registry with multiple views (e.g. by site, by service) for POCs. The registry will be protected (e.g. to reduce head hunting activities). It will provide service name, service description, site name, services supported, the POC (primary, secondary and tertiary) for each service supported with name, email address, phone,URLs, preferred contact method, other information. Note that the POC registry can/would point to help desk/TT information at other sites where relevant (based on services supported by site). For example, ESnet does not support CuSeeMe so if a call comes in with a problem with CuSeeMe the help desk would
Building the registry will require volunteers, pilots and will build on events/demand. Having built the registry (phase 1) the knowledge data base (phase 2) will need to be built. The knowledge database will include problem descriptions, problems solutions and will need to be visible to all. The registry will be Web-based. ESnet will provide/support registry tools. The full POC data is protected (so authentication/authorization is required). The local POC data is "open" (defined by domain name, IP address, or or site-defined). It will use COTS (Common Off The Shelf Software) in particular Oracle (with registry reminder), Remedy ARS tools, Apriori from Platinum technologies for the Knowledge Base. Inter-POC communication will use PictureTalk with Shared White Boards. Also they will use Desktop Video Conferencing.
The pros are: leverage knowledge/experience of the entire ESnet community; significantly reduces effort to solve te same or similar problem; builds a database; provides opportunites to gain knowledge, provides sense of community.
Cons are: no mandatory requirement to participate; not all support personnel at every site may volunteer; identified suport personnel may become overloaded;
Outstanding isues include: user education; how to track a problem when not reported to ESnet; site does not provide a TTS/HelpDesk; trouble ticket hand off.
As a pilot they are setting up an Mbone service under the HelpDesk, they need volunteers. The distributed HelpDesk doesn't exist yet so should an ESCC task foce be formed. Alan is looking for feedback. He will post his proposal to the mailer.
The field work requires to understand the user activity in context, what are the user need and requirements. This is done by getting immersed in the user's perspective, interacting with the development team and understanding the technology background. The results are descriptive/qualitative not quantitative.
She has done a sociological study of remote experiment operation. There are 4 sites in the fusion field. She has done interviews & visits to all sites and created an initial user work activity report. She has met with collaboratory leaders with interviews and visits at all sites and a collaboratory technology use report. Next she is submitting a conference paper to get visibility.
She has visited 4 sites, 15 scientists & technicians (4 at other geographic sites), she has notes, audio recordings, photographs, artifacts, The interviews etc. have been transcribed. the input needs to be "listened" to one needs to immerse oneself into it.
The equipment is unique, state of the art, hard to understand, difficult to use, require lots of expertise, expensive, hard to duplicate. It requires complex planning and coordination. The experiments are very dynamic, you are continuoulsy changing the experiment. It takes multiple minds to figure out what is going on, need to be in sync., working in parallel. The analysis and results are shared.
Most of the above requirements tend to be different from what the commercial collaboratory market has been aimed at (e.g. commerce aims at small groups, fairly static experiments).
The implications are that the following are critical for the design: training, respect for local expertise, rapid acces to plans and data, real-time personal interaction. Even though obvious, some of these things are not being addressed.
The challenges are that: resources are already in high demand, even now few have access to everything they need, solutions are social as well as technological, opening up a collaboration implies exposing work in progress, being remote is never the same as being there (it is different, may be better in some cases).
The opportunities are: familiarity will increase understanding, technology & practice can co-evolve, remote collaborations already exist, small steps have value (pre and post data, sharing, intra-facility interactions, use of existing tetchnologies).
"The vision for a collaboratory environment sets the goal of permitting scientific collaborations from geographically distant sites to take place."
Next phase questions: what are the technologies, how are they being used, what do the scientists now have to say, what do we see in the activity? Will revisit the 4 sites and create a collaboratory use report, and make a conference paper submission.
In summary, experiments are complex (the equipment, the process, the people), collaboration is happening (multiple specialities, ongoing distributed interactions, shared research), collaboratories can make a difference (data access, communication support, shared realtime interactions on experiments).
See http://www-itg.lbl.gov/SecurityArch
Authentication problem will be solved (e.g. Kerberos).
The stakeholder decides how and whether a set of resources will be available. They expect a few stake holder, a few thousands of resources and hundreds of thousands of users. All of this is geographically dispersed so location of users must not make a difference. It must not require excessive human intervention per authorization, and as the number of resources and users grow the untrustworthiness must not grow (within reasonable bounds). The other goal is to provide flexible authorization since there can be different risks for different resources, and different expressiveness (some may be very simple transactions, others, e.g. credit authorization maybe quite complex).
The model is that trust relationships are assumed. This architecture is being implemented and is aimed, initially, at the Globus project. One particular item still needing implementation is the access control "policy engine". Other things needing implementation include the Identity Certificate Issuance, the attribute issuance and the resource use-condtiotn issuance.
State of authentication standard can be found at: http://www.es.net/hidden/dsmwg.html and http://www.es.net/hypertext/authtf/documents.html
Demand for cross cell authentication is growing, awareness is growing at higher levels, identifying concerns concerns of DP labs. Contemplating roll out strategies: 1997 H1 self assessment & audits, 1997 H2 ER Labs and DP labs as separate camps doing cross-cell authentication, 1999 all labs.
Need to define a frequency of audits and appoint a management function for the audits and a mechanism for distributing audit results. Then there is the question of liability which is involved meeting with ANL attorney, discussions with DOE attorney, also see Michael Baum's book NTIS PB94-191202.
Some (ESnet?) KDC central management will probably be needed to track ESnet sites that have exchanged keys, does info distribution for probes, compromises etc., provide information on notifying remote sites of user terminations at other sites.
http:///www.es.net/hidden/dsmwg has a comparison matrix of user responsibility statements for 4 Labs (Ames, ANL, Jefferson ...). May need to draft a uniform statement.
What are the criteria for the qualification for the sta managing the KDCs, what tarining do they need.
See http://csrc.rcsl.nist.gov/pki/welcome.html and httP://www.ietf.org/html.charters/pkix-charter.html for information from NIST and the IETF.
"Free Certificate" Results: ESnet is currently evaluating Entrust and had 10 certificates it could give out for free. A majority of requests were for Web/SSL support (but Entrust does not yet support this). Some wanted to kick the tires to see how a certificate works, others don't know what certificates are about, but figure they'd better learn ASAP.
Web/SSL does not have concept of a PKI yet. Will need to tie together Web/SSL, Entrust, policy engines etc.
Need to id "service" that ESnet should provide to facilitate research efforts, but must keep ESnet "liabilities" within existing parameters. An ESnet CA policy cannot be created until the service is clearly defined & understood. Alan has had Email discussions with Whitney, Long, Johnston.
A summary of the email discussions is that a PCA is not the best approach (liabilities too great, dilutes the trust relationship), ESnet will provide CA services, sites will provide CA services. Each site will probably have a single CA since the cost of establishing a trusted CA and associated policies/procedures is high. Geographically dispersed sites may have multiple, hierarchical CAs. Some concerns raised include personnel possessing certificates using them for unintended purposes (does this increase the CA's liability, or what does a "trusted" certificate imply); CAs may disclaim all uses except as specifically noted in order to limit CA's liability. This requires coordination and well understood/documented policies. With all that should/how can ESnet provide a service?
DFS has considerable promise as secure WAN file tsystem, transparent to use, cost & difficulty of setting up DCE is presently a liiting factor for small groups or sites. A local DFS server with remote DCE services night be a solution for small DOE groups or sites. This (in Tommy's experience) works well with a high quality network like ESnet.
I talked to Brian Herhusky of Transarc <herhusky@transarc.com>. They have a Mac AFS client. It runs over Appletalk and thus requires AppleTalk to be routed on the site. The Mac has a very thin client which is simple to configure (need to give it the IP address of the PCI server, see below). Stanford has a site license that includes SLAC. Stanford is integrating it into the PC Leland environment. It requires a PCI server that will run on AIX or Solaris plus some other Unixes not supported by SLAC, but does not run under NT. The PC Enterprise server appears to act as a gateway providing access to the AFS filespace on one side, and AppleShare (i.e the chooser paradigm on the client) on the other.
See http://ciac.llnl.gov/ciac/SecurityTools.html for the tools. Marlin is a tool that add a GUI & management capabilities for several popular security tools such as SPI-Net, Tiger, COPS, Crack and Tripwire. The Hoaxes page is getting 80K hits/month. They also have pointers to a lot of public tools. Interesting existing in-house tools include: Network Intrusion Detector (world's greatest packet sniffer), Security Profile Analyzer, Text Analysis Project.
NID is a realtime packet capture & analysis tool with playback, ramp up, pattern match by service and a User Guide. Runs on Solaris, Linux, HPUX, BSD UNIX, supports Ethernet and FDDI. The availability (executable only) is now from LLNL (http://ciac.llnl.gov/cstc/nid/nid.html). Need DES key to decrypt it.
SPI is a configuration/vulnerability checker, with desktop or network versions, runs on Solaris, Linux and desktop for NT (1.5 FTEs working on WNT security and SPI NT). Executable shipping. Access via: http://ciac.llnl.gov/cstc/spi/spinet.html and http://ciac.llnl.gov/cstc/spi/spiwnt/spiwnt.html
AIS alarms is an intrusion detection & response system that is not available yet. It is a rules-based centrl assessment with distributed sensors and an extensible architecture.
Text Analysis Project is a document text analyzer, declassifier aid featuring a data-driven text database. Ir runs on Win 3,1 and Win95 is in beta. Contact John Rannellettis (510)424-6975. Availability is by arrangement. Could be extended to look for inappropriate of the network
This is a tri-Lab project team (LANL, LLNL, Sandia), a 3 year, 3 phase project sponsored by OSS DOE. Phase 0 demo feasibility with basic functions, phase 1 rigorous design, production quality system for UNIX, phase 2 extend to additional OS's. $7M project. It is based on near real-time event recognition, not audit trails. It is easily configurable with an open architecture. It is low impact, sensors only ramp up when threats are detected, reducing the impact in unthreatened mode. It has rules based assessment where threat evaluation and response are data-driven and can be tailored by the admin. The system can run unattended and will take evasive action automatically. It is far more than just detection. Right now it runs behind the firewall. Sensors are distributed on possible victim CPUs, they detect suspicious events and make simple reports to Central assessment. They will provide specifications for sensors, so others can supply sensors. Assessment receives reports from sensors, evaluates based on rules established by user, where the rules also specify the response. Central assessment allows for sensor data function (e.g. gathering together muliple sensor reports and correlating). The response agents can be any arbitrary software program. Can beep, page, email. Reponse agent can ask for more data or turn the sensor on/off or reconfigure the sensor. Response agents can even reconfigure routers.
They have found it is very effective to provide "honeypot" accounts for unclassified sensitive systems with fairly easy to crack user/password pairs. The pairs have to accessible, not too obvious that the cracker will identify the trap, and not lead to threatening intrusions. They trap such logons and can log if a single attempt, or block traffic (e.g. by reconfiguring the firewall router) from the source if trap multiple logons.
This is a future product. They are at phase 1 (phase 0 completed), they expect to have production by Xmas 1997.
Next ESCC meeting is 28-30 Sept and 1-3 Oct 1997.