GET <URL1> GET <URL2>

Transcription

1 Anetd: Active NETworks Daemon (v1.0) Livio Ricciulli August 10, Introduction Anetd is an experimental daemon specically designed to support the deployment, operation and control of active networks [3]. Anetd implements some new network management and engineering ideas derived from the ANCORS research project [2]. The anetd design philosophy is to be fully backward compatible with current networking software, and at the same time to introduce new innovative functionality in managing, designing and controlling active networks. Anetd can run in either user mode or supervisory mode and has minimal installation requirements. Today, anetd can be be used to manage legacy networking software and more experimental software derived from active networking research. Anetd performs two major functions: It allows the deployment, conguration and control of networking software (including current active networking execution environment (EE) prototypes) into the network. It demultiplexes active network packets (encapsulated using ANEP [1]) to multiple EEs located on the same network node and sharing the same input port. Anetd requires little or no change to either legacy networking software or current active networking prototypes and greatly improves the ability to manage large active networks. We describe the two main features of Anted and show how these can be elegantly integrated in a single design. 1.1 Deployment Capability Today's global networks are extremely loosely coupled; they are composed of distinct administrative domains that share little or no \electronic knowledge" among them. In today's model, each domain replicates all software resources by copying large amounts of electronic data from software producers. As a software producer improves its products or augments them with new features, a task force of administrators manually changes the local electronic knowledge to keep the administrative domain in synch with the changes. From a system point of view, today's global networks can be seen as a 2-level caching hierarchy in which consistency is automatically maintained at the local level (between the user's machine and the local le server) but requires human intervention at the global level (manually installing new software as it becomes available). 1

2 Load_process <URL1> anetd Fork GET <URL1> Load_thread <URL2> New Process New thread GET <URL2> HTTP Server Figure 1: ANCORS daemons can spawn a new process or a thread within a process Anetd allows dierent administrative domains to share the same software base specied as URLs, and allows the deployment and control of distributed network services through a centralized source of electronic knowledge. The network services to be deployed are specied as URLs; anetd, after downloading a service with an HTTP GET command, strips the HTML header from the received code and installs the service. As shown in Figure 1, the download command can either (1) trigger the anetd to duplicate itself by using a fork system call to run the downloaded network service, or (2) simply add a thread to an existing process. Our current system management prototype supports the deployment of native binary compatible code or Java applications. The deployment and conguration mechanism is fully backward compatible. Legacy services can be congured by downloading conguration les and specifying required command-line arguments so that existing software can be easily deployed without modication. In addition to legacy services, anetd can be used to deploy and control ANCORS engineering services. For these applications, the daemon oers a set of built-in primitives, which are services that, in addition to standard native system functionality (I/O, memory management, networking), provide (1) multithreading (nonpreemptive), (2) LAN multicast emulation, and (3) global time synchronization. These primitives can provide support for distributed simulation network engineering applications, as well as some forms of sophisticated network monitoring. 1.2 ANEP Demultiplexing Active networking is motivated by the notion that the improvement and evolution of current networking software is greatly hindered by slow and expensive standardization processes. Active networking tries to facilitate changes to the networking software by developing an architecture that, by design, allows safe and ecient dynamic reconguration of the network. It has been proposed [3] that this idea can be implemented in two orthogonal ways. The discrete approach allows network administrators or engineers to issue explicit commands that load, modify or remove networking software. With this approach a network is active in the sense that it can be dynamically changed administratively. The integrated approach is being followed today by most active networking research and allows a much ner-grain dynamism. The network is modied by the data packets 2

3 that travel through it. When packets travel through the network, they automatically cause required software and resources to be loaded on demand. Anetd is a prototype that supports the merging of these two approaches. Anetd listens on a unique UDP port (e.g., the active networks port 3322) and accepts commands to implement the discrete approach (i.e., download, congure and manage networking software). In addition to processing commands directed to itself, anetd looks at the packets it receives and, if a packet is destined to one of the services it downloaded, it forwards that packet to the appropriate service. This kind of functionality is very useful in cases where several network services need to share a limited set of port numbers (as in the current architecture of an active node) and it is not possible or desirable to modify the lower level-protocols. 1.3 Deployable Networking Applications Anetd has been designed to require minimal modications to traditional networking applications to deploy them according to the discrete approach outlined in section 1.2. The only general requirement is that the applications must be fairly encapsulated and do not have many dependencies (e.g. do not require a large number of specic shared libraries that are not commonly available). Anetd supports the deployment of resources needed by the applications to facilitate the porting of existing software, but anetd is not intended to be used to deploy a large number of libraries or large portions of installation directories. In these cases, it is advisable to use standard manual installation methodologies or (as in the case of Java) bundle the required resources with anetd in advance. Anetd demultiplexing uses the standard input of the deployed service for forwarding packets to it. In other words, as explained below, an application wanting to receive trac demultiplexed by anetd coming from an ANEP port must read its input stream from standard input. This is accomplished as follows: once a new application with an ANEP type assigned to it is deployed, anetd adds the type ID to a demultiplexing table. The demultiplexing table maps an ANEP type ID to a le descriptor; the le descriptor, in turn, maps to the standard input of the application. Application output streams do not require any support from anetd and can allow the system to assign output ports automatically. 1 2 Implementation and Usage Anetd is implemented in \C" and, because it uses a standard Unix API, it should be easily portable to any Unix platform. For the moment, Anetd is available for Solaris on Sparc, Linux on x86 and FreeBsd on x Anetd listens on a user-assigned UDP port and accepts ANEP encapsulated packets. If the type ID in the ANEP packet header is of the type assigned to ANCORS by ANANA, the ANEP payload is parsed and anetd control commands are executed. A client application is also provided that formats control commands using ANEP and allows the sending of user-dened anetd commands to the daemon. 1 As far as we understand, this demultiplexing scheme is analogous to the mechanism that is used in inetd. 2 We strongly believe that with reasonable eort it could also be ported to Window-based platforms 3

4 2.1 Anetd Invocation Anetd is started on a network node as a user application. Anetd in its current implementation does not need any runtime privileges and can be started as ad.< ostype > [-p < ANEP port >] [-u < localportpoolstart >] [-s] < ostype > is one of solaris, linux or bsd44. These tags refer to the three platforms that anetd currently supports. { solaris=sunos 5.5.x running on Sparc { linux=linux running on Intel x86 { bsd44=freebsd running on Intel x86 < ANEP port > is the port on which anetd listens and is also demultiplexed (default. 3322). < localportpoolstart > is the starting port number for dynamically allocating local ports (default 8000). -s authorizes anetd to send a small heart-beat UDP packet every 30 seconds to our main anetd server (please enable it). For example, to start anetd on a Linux system using ANEP port 3324 and allocating local ports starting at port 7500, one would enter ad.linux -p u 7500 In case multiple Anetd servers need to be installed on the same host and using the dierent Unix user accounts to implement local access control policies (see Section 2.1.1) all these Anetd need to be started using the same ANEP port Access Control Network security is a very important issue that should be addressed during all stages of design and implementation of any networking system. Anetd version 1.0 now aords substantial security by employing 512 bit public key cryptography. As in the previous experimental version Anetd oers two ways of providing access control: (1) it executes deployment and control commands only originating from a set of known IP addresses (specied in a le called hosts.allow), and (2) it accepts code only originating from a set of known http servers (specied in a le called webs.allow). Clents' Access Control List Accepting control commands only from a set of clients allows administrative authority to be set, thus limiting misuse of the daemon. The main improvement in Anetd v1.0 is that the control commands are now digitally signed through RSA 512-bit public key cryptography. In addition, to improve security and exibility, each client can now be assigned a particular local Unix account. The access control le hosts.allow has the following format: < ClientIP > [< publickey >] [< localuseraccount >] 4

5 < ClientIP > is the IP address of the client that is authorized to issue control commands to Anetd. < publickey > is the client's 512-bit public key in printable ASCII (RFC 1113). If the public key is not present, any request coming from the hosts < ClientIP > will be executed without requiring a digital signature. If this led is present, any incoming request from the hosts < ClientIP > will be veried using the key. A give < ClientIP > address can be listed multiple times with dierent public key entries. In this case, all entries are tried until one of the entries matching the source address successfully veries the command or no more appropriate entries are found. In case a command cannot be veried, anetd returns the error CLIENT NOT AUTHORIZED. < localuseraccount > is the user name of the local user account that a client must use. In case this eld is not present, any request coming from the host < ClientIP > that is successfully veried will execute in the user account where the main Anetd daemon is executing. If this led is present, the main Anetd daemon will attempt to forward the incoming request to a daemon executing under user account localuseraccount. If no daemon executing under localuseraccount is found the command will be executed as if the eld was not present. Code Base Access Control List Limiting the origin of deployable services is somewhat analogous to providing an implicit form of certication of the code. Anetd uses the le web.allow to list the IP addresses of the code servers from which anetd is authorized to receive code. Setting up multiple local user accounts The hosts.allow access control le allows to map clients to local user accounts. This allows a node administrator (1) to customize access control rights for each client reusing Unix access control mechanisms and (2) provide protection to the services deployed by the clients from interfering from one another. The setup of local user accounts is as easy as creating the accounts as one would normally do in Unix and invoke an Anetd daemon to execute in each of the created accounts. The rst Anetd daemon that is invoked on a host will serve as the main Anetd daemon that will receive all ANEP packets and forward them to the appropriate user accounts (if necessary). All other Anetd daemons subsequently started that share the same ANEP port will automatically congure themselves as secondary daemons 2.2 Forwarding Unless a request is executed on the main daemon, requests need to be forwarded to secondary daemons thus increasing response time. To improve performance, the daemon responding to a client's request includes in the acknowledge the port number on which it is listening. This allows a client to learn the port number after the rst request and subsequently use that port to directly communicate with the right daemon without the additional forwarding delay. This port-mapping feature can be used in those cases in which performance is critical but can be ignored for normal operation. 5

6 2.3 Multiple Virtual Networks All Anetd daemons running under dierent user accounts started by specifying the same ANEP port logically behave as a single Anetd daemon, they all respond to requests coming on a unique port and may be indistinguishable from the client. Multiple logical Anetd daemons can be running simultaneously on the same host, perhaps implementing multiple virtual active networks. The only restrictions are that (1) multiple logical daemons, obviously, cannot share the same ANEP port, (2) if multiple logical daemons are controlled by the same client, care must be taken in avoiding overwriting conguration les and output redirection les (see Section 2.4 for more details) and (3) multiple logical daemons must share the same access control settings if their respective main daemons run under the same user account. 2.4 Control Commands Anetd control commands allow a client to deploy, congure and manage network application software. The LOAD command instructs anetd to download a number of les specied with URLs and start a network service. The load command has the format: LOAD [T=< anepid >] [J=< jurl > j X =< url > j A =< url >] [F=< url >...] [E=< var : val >...] [D=< dir >] [O=< file >] [R=< file >] T=< anepid > is the ANEP ID of the service being deployed. If this argument is not present, the deployed service will be assigned type 0 and no packets will be demultiplexed to it by anetd. J=< jurl > species a Java application. < jurl > is of the form where { servername.edu:port species the server where the data is located following the normal URL conventions. { classpath is a path pointing to the base classpath of the Java application. { class is the class to invoke. Both classpath and class can be a series of directories separated by \/". For example, J= species the URL of the ANTS application ants.congurationmanager located on SRI's http code server in the directory java/ants-1.2/. X=< url > means that < url > species a native binary executable. A=< url > means that < url > species an ANCORS thread (see [2]). F=< url > means that < url > species a data le that should be simply transferred and written on the local installation directory. 6

7 S=< string > tells anetd to invoke the deployed service with < string > as a command line argument. < string > cannot contain any white spaces. E=< variable >:< value > tells anetd to set the environment variable < variable > to the value < value >. D=< dir > tells anetd to use the directory < dir > as the root directory for the service installation. Anetd by default uses the directory /homedirectory/< clientip >/ for installing all downloaded code; by specifying the D=< dir > option, anetd installs all downloaded code in /homedirectory/< clientip >/< dir >. O=< f ile > redirects the standard output of the network service to the le < f ile > (to be created in the installation directory). R=< f ile > redirects the standard error of the network service to the le < f ile > (to be created in the installation directory). C=< description > species a description < description > for the deployed services. This description is then returned to the client when QUERY commands are invoked. The description string cannot contain white spaces. Because the X and A types specify native executables, anetd automatically appends the extensions solaris, linux, and bsd44 to the URLs, depending on what platform anetd is running on. For example, suppose that anetd is running on a Linux machine; the URL would actually fetch the le The QUERY command returns, to the client originating the command, a list of network services that were forked by anetd. The QUERY command format is simply QUERY. The list of forked services has the format: < index > < clientip > < description > < index > is an index generated by anetd (0,1,2 etc.). < clientip > is the IP address of the client that installed the service. < description > is a textual description of the service. The KILL command allows a client to terminate a network service by sending a SIGINT signal. The KILL command has the format: KILL < index > < index > is the index of the thread to be terminated by anetd (0,1,2 etc.). The < index > value should be retrieved by using the QUERY command. Anetd will automatically garbage-collect all resources allocated to the terminated service and will only allow the client that originally deployed the service to perform the operation. 7

8 The GET command allows a client to retrieve a le through anetd. The GET command has the format: GET [D=< dir >] < file > D=< dir > tells anetd to look in the directory < dir >. Anetd by default uses the directory /homedirectory/< clientip >/ to look for the le < f ile >; by specifying the D=< dir > option, anetd will look in /homedirectory/< clientip >/< dir >. < f ile > species the name of the le to retrieve. Anetd only allows the client that originally created the le < f ile > to retrieve it. The content of the le is returned to the client in the acknowledge message. The PUT command has the format: PUT [D=< dir >] < file > < content::: > allows a client to upload a le through anetd. The PUT command D=< dir > tells anetd to look in the directory < dir >. Anetd by default uses the directory < f ile > species the name of le to be created. < content::: > is the data to be stored. Anetd allows clients to upload les. For example the command PUT cong... will create a le \cong" in the installation directory of the client and write the data that follows into it. From the client side this is specied by invoking sc PUT < port > < host > cong < f ilename > where < host > is the name of the machine on which anted is running, < port > is the port on which anetd is listening, cong is the remote le name and < f ilename > is the local lename. The CONF Command applies to ANCORS threads and is similar to a remote procedure call. The CONF command has the format: CONF < symbol > [args...] < symbol > species the name of the function to invoke. The symbol < symbol > is resolved by anetd to a local memory address, and the function is invoked. args are a sequence of command line arguments to be passed to the function < symbol >. 8

9 2.5 Client Application SC Anetd's client application (sc) assists in issuing control commands formatted using ANEP and creating digital signatures for authentication. sc looks for the le homedirectory=:anetd=secretkey and if it nds valid 512-bit key, it creates a digital signature of the user command. The signature includes a timestamp to avoid replay attacks and is sent together with the command to the specied Anetd daemon for verication. The sc command line usage is sc < port > < hostname > args... [< filename1 > < filename2 >] < port > is the port on which a logical anetd is listening (by default anetd listens on port 3322) < hostname > is the name of the network node where anetd is running. args are any of the control commands specied in Section 2.4. < f ilename1 > is the name of a remote le to be created using the PUT command. < f ilename2 > is the name of the local le name whose content should be sent using the PUT command. Sc returns the port number of the Anetd daemon that acknowledged the request. This is useful in bypassing the forwarding of Anetd commands (if any) to improve response time. 2.6 Example We include an example for demonstrating how sc can be used to deploy ANTS [4] active nodes and monitor their standard output. Three dierent ANTS active nodes can be deployed on host1, host2, and host3 by using the following commands: sc PUT 3322 host1 data.config data.config sc PUT 3322 host1 data.routes data.routes sc 3322 host1 LOAD J= F= F= S=data.config S= T=18 O=output C=ANTS_active_node1 sc PUT 3322 host2 data.config data.config sc PUT 3322 host2 data.routes data.routes sc 3322 host1 LOAD J= F= F= S=data.config S= T=18 O=output C=ANTS_active_node2 sc PUT 3322 host3 data.config data.config sc PUT 3322 host3 data.routes data.routes sc 3322 host1 LOAD J= F= F= S=data.config S= T=18 O=output C=ANTS_active_node3 9

10 Notice that the ANTS application specied by J=< jurl > requires two conguration les specied by F=< url > arguments, and the command-line arguments S=data.cong S= The T=18 argument is needed to instruct anetd to later forward ANEP packets of type ID 18 to this application. After installing the active nodes it is possible to also deploy simple monitoring agents that simply read the standard output contents in output by issuing the following commands: sc 3322 host1 LOAD J= S=host1output S=output S=5000 E=DISPLAY:clientip:0.0 sc 3322 host2 LOAD J= S=host2output S=output S=5000 E=DISPLAY:clientip:0.0 sc 3322 host3 LOAD J= S=host3output S=output S=5000 E=DISPLAY:clientip:0.0 A simple Java application GetStat1 is downloaded to the hosts host1, host2 and host3, and it is instructed to display to the client at IP address clientip the content of the le output every 5000 milliseconds in a window entitled host1output, host2output or host3output, respectively. 3 Conclusion Anetd is available for download at For the time being, we do not provide the source code because we are sorting out some license-agreement details. Anetd is currently available for Linux and FreeBsd on x86 and Sunos 5.2 on Sparc. Because we feel awkward in not providing source code, we will be very responsive in porting anetd to any other Unix system as needed (forward requests to ancors@csl.sri.com). Anetd is an alpha release and therefore may have bugs. (report any bugs or inconsistencies to ancors@csl.sri.com). Please notify us of any interesting uses of anetd in managing networked systems. References [1] Scott Alexander, Carl A. Gunter, Angelos D. Keromytis, Gary Minden, and David Wetherall. ANEP: Active network encapsulation protocol. switchware/anep/docs/anep.txt,

11 [2] Livio Ricciulli, Phillip Porras, and Nachum Shacham. ANCORS: Adaptable network control and reporting system. SRI International Technical Report SRI-CSL-98-01, [3] D. J. Wetherall, J. V. Guttag, and D. L. Tennenhouse. Ants: A toolkit for building and dynamically deploying network protocols. Submitted to IEEES OPENARCH'98, [4] D. J. Wetherall, J. V. Guttag, and D. L. Tennenhouse. ANTS: A toolkit for building and dynamically deploying network protocols. Submitted to IEEE OPENARCH'98,