Network Working Group S. Brim Internet-Draft A. Simu Expires: January 30, 2002 Cisco Systems, Inc. August 2001 Midcom Agents and Topology draft-brim-midcom-inandout-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 30, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract A midcom agent does not know whether to ask for a ruleset to be installed in a middlebox or not. Even when it does ask, in some situations the middlebox does not know how to apply the ruleset. This document tries to solve these problems without adding an overwhelming amount of complexity to every agent and middlebox. Brim & Simu Expires January 30, 2002 [Page 1] Internet-Draft Midcom Agents and Topology August 2001 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . 4 4. The Simplest Scenario . . . . . . . . . . . . . . . . . . . 4 5. Overlapping Address Spaces . . . . . . . . . . . . . . . . . 5 5.1 Should a Request Be Sent? . . . . . . . . . . . . . . . . . 5 5.2 Inside or Outside? . . . . . . . . . . . . . . . . . . . . . 7 5.3 Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Agent on the Outside . . . . . . . . . . . . . . . . . . . . 8 7. More on Rulesets . . . . . . . . . . . . . . . . . . . . . . 8 8. Concatenated Addressing Realms . . . . . . . . . . . . . . . 9 9. Multiple Overlapping Address Spaces . . . . . . . . . . . . 10 10. Middleboxes and Discovery . . . . . . . . . . . . . . . . . 10 10.1 Anycast . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.2 Probing the Target Address . . . . . . . . . . . . . . . . . 11 10.3 Server Location Protocol . . . . . . . . . . . . . . . . . . 11 11. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 12 12. Security Considerations . . . . . . . . . . . . . . . . . . 13 References . . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 Full Copyright Statement . . . . . . . . . . . . . . . . . . 15 Brim & Simu Expires January 30, 2002 [Page 2] Internet-Draft Midcom Agents and Topology August 2001 1. Introduction The IETF Midcom Working Group is defining a protocol (or extensions to one) by which an agent with application intelligence can request middleboxes to install specific sets of rules for packet matching and treatment [1][2]. The middleboxes of particular interest are NATs and firewalls. The goal is to make it possible to separate application intelligence from the actual handling of packets. The Midcom Working Group has encountered a problem in doing this separation -- any topology knowledge the middlebox might have, and any information regarding the security of the networks attached to its interfaces, is not directly available to the agent. The agent apparently needs this information to make decisions about when to make requests of middleboxes. This information could be made available but a brute force approach would make both functions more complex than they are now. What is the minimum amount of information that needs to be given to an agent? What approach minimizes overall system complexity? 2. Terminology All terminology is as in the Midcom Framework [1] with the following additions: Addressing Realm: A contiguous part of the Internet in which all used IP addresses are unique. Inside: In the same addressing realm as the entity being discussed. Outside: In a different addressing realm from the entity being discussed. Ruleset: A set of rules for middlebox packet processing which are installed and removed as a unit. In particular a ruleset includes at least one "filtering" or "matching" rule (e.g. any packet destined for 192.168.100.1 port 42) and at least one "action" rule (e.g. "let it through", "let it through with source address translation to 10.0.0.25", or "discard it"). Target Address: A source or destination IP address or address range in a rule. Informant Address: The address of the packet originator from which a target address was learned by the midcom agent. The mechanism by which the target address is conveyed from the informant to the agent is not relevant. The mechanism could be, for example, static configuration, a DNS reply or an application protocol Brim & Simu Expires January 30, 2002 [Page 3] Internet-Draft Midcom Agents and Topology August 2001 control packet. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. 3. The Problem In a network with a current NAT or firewall middlebox, the middlebox sits between an "inside" area and one or more "outside" areas. The middlebox applies rules to packets passing between the inside and outside areas (including the possibility of dropping them). The middlebox is configured to know whether a particular interface is connected to an inside or outside area. The middlebox also knows the egress interface for any packet it is supposed to forward -- if it didn't, the network administrator would have a problem and would arrange for it to have that information, either through configuration or through having the middlebox participate in routing in some way. However, the midcom agent may be physically separate from the middlebox. There are two problems with using the midcom framework as it is currently conceived. First a midcom agent will ask a middlebox to install rules for packets which the agent doesn't know for sure will ever pass through the middlebox in the first place. Second, it doesn't know how to tell the middlebox which interfaces on the outside of the middlebox should carry those packets. Proposed solutions range from hand-configuration to drastically reducing the Midcom Working Group's goals. 4. The Simplest Scenario Consider a very simple scenario to start. Suppose a single agent is controlling a single middlebox connecting two addressing realms, and the two address spaces do not overlap. The agent's client, an end system, wishes to initiate communication. If the packets are going to pass through the middlebox, a ruleset needs to be installed in the middlebox allowing them to do so. With current NATs and firewall middleboxes, application intelligence would be yet another function co-resident with the middlebox's NAT and/or firewall ones. Having all these functions, the middlebox would know what to do with any packet it received on any interface, and would not have to install any rules before the packets arrived. With Midcom, and separation of application intelligence from the middlebox functions, decision has to be made whether to install a ruleset for a particular packet before the packet arrives at the middlebox. What if the two endpoints are both on the same side of the middlebox? Brim & Simu Expires January 30, 2002 [Page 4] Internet-Draft Midcom Agents and Topology August 2001 In this particular case, since the address spaces do not overlap, no great harm is done by installing a ruleset, even if the communication it allegedly supports never passes through it. The only harm would be useless state information in the middlebox -- a large number of useless rulesets might block the installation of other, actually useful, rulesets. In this simple case, with moderate use, it is probably all right to use the mechanisms of the midcom protocol as currently conceived of in the Midcom Framework [1] -- no new capabilities are required. Heavy use does lead to the risk of exhausting middlebox resources uselessly, and a new approach is required. 5. Overlapping Address Spaces Consider a scenario like the one above except let the inside and outside realms have overlapping addresses. In order for communication to happen across the middlebox, both the inside and the outside endpoints need to be given non-overlapping addresses by the middlebox -- a classic chicken-and-egg problem. This is a "Twice NAT" scenario [4]. One mechanism for dealing with this, if necessary, is for an agent (or an endpoint) to request a globally unique address from its local middlebox, so that when others try to find that endpoint they will receive a useful address in response. Another mechanism is for a middlebox or an agent to monitor responses to DNS or other higher-layer requests, so that when an address for an endpoint or agent is being looked for, rulesets for address translation for the address being acquired can be installed in its local middlebox. If a NAT middlebox is monitoring DNS itself, it can just install its own ruleset. If a Midcom agent is doing the monitoring, then after it receives the response containing the target address it needs to send a request to the middlebox to have a ruleset installed for it. It uses the midcom protocol to do so. However, unlike the simple case in Section 4, there are problems here. The inside and outside address spaces overlap. The target address, for which a ruleset is being requested, might be valid in either realm. The middlebox has no way of knowing which addressing realm the agent is referring to. Also, unlike the previous case, in this case an unnecessary ruleset will be a security problem. We need to be sure that packets can only pass through the middlebox when appropriate. 5.1 Should a Request Be Sent? Several possible solutions for the problem of avoiding unnecessary rulesets have been proposed in the Midcom Working Group, including: Brim & Simu Expires January 30, 2002 [Page 5] Internet-Draft Midcom Agents and Topology August 2001 o The agent could listen in on the domain's routing protocol and only make a request of the middlebox when traffic would actually pass through the middlebox. Because of this the middlebox would assume that any address which was valid both inside and outside would refer to an outside address. First, this would add much more complexity to an agent than was intended by the Midcom concept. An agent should be able to be a small bit of software, perhaps resident in the same device as the middlebox function, or perhaps distributed with an application. Second, the knowledge that could be gained this way would be limited. The requirement in the general case is to learn whether a particular destination address is inside or outside from the point of view of a middlebox. A distance vector routing protocol would not carry this information at all, only the next hop to reach that address from the agent (which could be far from the middlebox). Even with a link state protocol, area boundaries abstract routing information. o The agent could query the middlebox for topology information available at the middlebox. This would require the middlebox to be able to dump a list of all network-layer prefixes on one side of it -- preferably the "inside". The agent would then avoid asking for rulesets for any destination covered by one of those prefixes. One problem with this approach is that routing might change with a network reconfiguration, but we could extend the protocol so that the middlebox could instruct the agent to refresh any topology information it might have. However, this approach would not reduce the complexity of the system at all -- it requires enough complexity at both ends of the midcom protocol that midcom as a whole would probably never be accepted by users. Finally, it adds a security issue because it requires the middlebox to prefer outside addresses to inside ones at all times. o The agent could use application-layer intelligence to determine if an endpoint is inside or outside. For example, a SIP proxy could parse the identifier of the callee to determine if it is within its trust boundaries, or keep track of which peers were "inside" and "outside" the trust boundary itself. This is a treacherous layer violation and is not robust. It may require constant monitoring to be sure that network layer configuration is matched in agent configuration. It may require a globally unique namespace for all administrative domains, something we don't have or need to have in the Internet today. We don't know how this layer violation will constrain our flexibility in the future. The application trust boundary need not correspond to the middlebox. Application entities can move around and register at IP addresses on different sides of the middlebox at unknown times. Finally, there is the required preference of outside addresses over inside Brim & Simu Expires January 30, 2002 [Page 6] Internet-Draft Midcom Agents and Topology August 2001 ones. In reality the agent only needs to know topology information with reference to the middlebox for one particular ruleset, for one particular time. The simplest approach is to have the agent not care whether its targets are inside or outside, and to always ask for a ruleset but allow for the middlebox to reply with two different kinds of "success" messages: first that the communication can go ahead because the ruleset is acceptable, and second that the communication can go ahead because from the point of view of the middlebox such a ruleset is unnecessary. This is a base for proceeding, but in itself it is not enough. 5.2 Inside or Outside? Just because the agent does not have to care if an address (or address range) is inside or outside, the middlebox still needs to know. The agent does not need to make that decision, but does hold information the middlebox needs to do so. It acquired this information when it acquired the target address. It must pass that information to the middlebox. The agent acquired its target addresses somehow. A target address may be statically configured in the agent, or the agent may acquire it through some other protocol (including DNS). In all cases, when it sends a target address to the middlebox as part of a rule, the way to make sure the middlebox has the proper context for interpreting that address is for the agent to include, with both source and destination target addresses, the "informant" address -- the address of the entity from which it acquired that target address. The "informant" address is locally unique in the address space shared by the agent and middlebox, and thus provides an absolutely sure way for the middlebox to know whether to interpret the target address in "inside" or "outside" context. If the target address was learned from an informant in another addressing realm on the other side of the middlebox, the informant's remote address will have been translated into a locally unique address. If the target address was learned from a target or an informant in the same addressing realm, the informant address could be the same as the target address, or perhaps be that of its local DNS server, or agent. If the target address is statically configured, the agent could list itself as the informant (note this would make it impossible for an "outside" address to be statically configured, although a statically configured locally unique translation of one could be). As a default rule of last resort, to Brim & Simu Expires January 30, 2002 [Page 7] Internet-Draft Midcom Agents and Topology August 2001 close off security problems, the middlebox can give precedence to inside addresses. Thus, in most cases the informant address is all the middlebox needs to determine the addressing realm in which the target address is to be interpreted. 5.3 Wildcards Sometimes an agent will want to install a matching rule for a source or destination range of addresses, for example in order to allow calls to come in to a server. Often any caller is acceptable and "inside" and "outside" do not matter. However, there will certainly be cases where an agent wants a server to be able to accept calls from a range of addresses only as long as they are "inside". We want to allow this restriction, and even default to it, but not require it. To handle this case, we add one more attribute to each of the addresses specified in matching rules: an "outside okay" flag, which says that an outside address is allowable, and that if an address is valid both inside and outside the middlebox, the outside should be chosen. 6. Agent on the Outside Consider the case where the agent is in a public realm (for example an ISP) and the two endpoints are in the same private realm. The same principles hold and no new mechanisms are necessary. The agent will have acquired the target addresses from an informant. The target addresses may only be meaningful in the informants' addressing realms, but the address for the informant will be unique and meaningful in the addressing realm shared by the agent and the middlebox. When the agent sends a ruleset request to the middlebox, specifying the target addresses and informant addresses, the informant addresses will allow the middlebox to determine that both the addresses are "outside", and it will respond that no ruleset installation is necessary. 7. More on Rulesets Because an agent usually does not know if a target address is inside or outside when it first passes it to the middlebox, rules cannot generally be phrased in terms of inside and outside addresses -- only whether an outside address is acceptable. Because directionality is important (for example, ports may differ), rules must be phrased in terms of source and destination. There was a proposal in the Midcom Working Group that the midcom protocol should include actual interfaces as attributes for addresses Brim & Simu Expires January 30, 2002 [Page 8] Internet-Draft Midcom Agents and Topology August 2001 in matching rules. Besides the fact that it is extremely complex for the agent to able to keep track of the middlebox's interfaces and what they are connected to, let alone specify them in a way that is mutually understandable, it is not necessary. If the agent includes the addresses of its informants and an "outside okay" flag, it tells the middlebox all it needs to know how to reach the target addresses and to determine if installing a ruleset is necessary. 8. Concatenated Addressing Realms There are several scenarios in which more than two addressing realms are involved. Suppose an agent is in one addressing realm and the two endpoints are reachable through two different middleboxes connected to that realm. The agent needs to install a ruleset in each middlebox. In this case the mechanism described above works well. Informant addresses, as received at the agent, are always unique and meaningful in the addressing realm of the agent. The agent sends the target addresses and informant addresses to each middlebox. At each middlebox one informant address will be "outside", and the associated target address will be interpreted as such, while the other will appear to be on the inside (the same side as the agent). The ruleset will be installed. The "informant address" technique will not work if the target addresses provided by informants are not meaningful to the relevant middleboxes -- for example, if an endpoint is more than one addressing realm away from the midcom agent and the informant provides an address which is only meaningful in the endpoint's local addressing realm. In order for an agent to establish connectivity between two endpoints, both of them need to be represented by IP addresses which are unique within the space in which they will be used. Fortunately it looks like the implementations and strategies proposed so far do follow this rule. A DNS server representing endpoints in a NATted addressing realm will respond with global addresses, and an agent can acquire a global (or at least non-local) address for its client in advance with the help of the middlebox and the midcom protocol as described here. Similarly, the "informant address" technique will not work if the agent is trying to control a middlebox through an intervening NAT. The agent and middlebox must share an addressing realm in order for the midcom protocol to be able to carry addresses as data meaningfully. Situations where it would be appropriate to run the midcom protocol through a NAT might not exist at all. Those networks would be less secure and more difficult to manage. If such situations did exist, an explicit fix would be to require what agents Brim & Simu Expires January 30, 2002 [Page 9] Internet-Draft Midcom Agents and Topology August 2001 seem to be inclined to do anyway, which is to acquire a global address for any client before it begins communicating. In the worst case, if nothing else is possible, a subsidiary controller can be installed in the address realm on the other side of the NAT. Given that these situations are unlikely, and that there are workarounds for both of them, elaborating the midcom protocol to provide general support for unlikely and probably undesirable situations is not worth the complexity it would require. 9. Multiple Overlapping Address Spaces There is a situation which is theoretically possible, but which current NATs don't handle. It may become possible in the future. Assume there is only one middlebox NAT function, but let it interface between more than two overlapping address spaces. This could be made possible using the "informant address" and "outside okay" mechanisms. 10. Middleboxes and Discovery The problem of finding the right middlebox to make requests of overlaps somewhat with how those requests are made, so we discuss the discovery problem briefly. Middlebox discovery is important in order to find a middlebox at all, to find a middlebox which is appropriate for the ruleset the agent wants to install, and to find a middlebox which can handle the expected load. Draft-lear-middlebox-discovery-requirements-00.txt [5] lists some requirements. One of those requirements was that no endpoint or agent should be required to participate in routing, which the scheme proposed here satisfies. 10.1 Anycast It might be possible to use anycast and avoid having any explicit discovery mechanism at all -- the agent would simply launch queries at an anycast address appropriate for middleboxes of a particular type. However, anycast literally finds any target. The only way to discriminate between middleboxes using anycast would be to use different addresses. It's very likely that we will want to be able to discriminate between middleboxes much more flexibly than just by IP address. For example some middleboxes might be connected to some outside realms while others were connected to others. Also, anycast is intended for one-time or at least short duration interactions, since if routing changes the destination found by an Brim & Simu Expires January 30, 2002 [Page 10] Internet-Draft Midcom Agents and Topology August 2001 anycast packet may change. This would be a problem for any association which has synchronized state. The midcom protocol already has a long-lasting association -- authentication/authorization and capability negotiation are done for the middlebox to start with, and it is expected that authentication/authorization for each request after that will depend on that initial exchange. 10.2 Probing the Target Address Tunnel Endpoint Discovery (TED) [6] is for finding IKE intermediaries. Its approach could possibly be reused. TED sends a special probe packet toward the target address, which is actually intended for any appropriate intermediary. If an authorized intermediary notices the packet it intercepts it and responds. A similar probe could be used to discover middleboxes. If there were multiple disjoint connections between the agent's domain and the outside world, this would ensure that the agent established an association with the appropriate middlebox for that particular needed ruleset. The problem with using special probes like this is the very basic issue that the agent should not have to know if a target address is inside or outside the middlebox. If the agent launches a probe toward an address which is on the same side of the middlebox, it will get no response. What has it learned then? TED is a different case, in that discovery of a tunnel endpoint is required for the service to be provided at all. 10.3 Server Location Protocol If middlebox discovery used SLP, a request for a middlebox "service" could be given detailed attributes, including the entire ruleset needed. A domain could create its own policies for deciding which middlebox a particular agent should use for a particular ruleset, and change them arbitrarily. In particular this arbitrariness would allow complex topologies, middleboxes with differing capabilities -- in series as well as in parallel -- and spontaneous changes in administrative relationships. Different outside domains could be reached via different middleboxes at different times of the day and so on. SLP uses multicast, which some may think is a problem. However in simple situations discovery is not necessary, as demonstrated above for simple scenarios, and in complex situations unicast SLP can be used. Brim & Simu Expires January 30, 2002 [Page 11] Internet-Draft Midcom Agents and Topology August 2001 Thus, SLP might be useful for middlebox discovery. The mechanisms proposed in this document do not have any architectural conflict with using SLP. The mechanisms proposed in this document do lead the agent to ask an SLS about every ruleset request. There are a number of possible means to cut back on SLP activity and to reduce the potential scaling problem. For example, the ability to ask SLP about ranges, the ability of the SLP responses to include ranges and TTLs, and the possibility of information being "pushed". If SLP is actually selected as a base for middlebox discovery, and the rate of SLP activity is seen as a problem, we could explore ways to make this approach scale. 11. Summary The problem is that an agent does not know whether to ask for a ruleset to be installed or not. To solve this problem without adding an overwhelming amount of complexity to every agent and middlebox: o The agent queries the middlebox about every possible ruleset. The agent does not have to know if packets for a particular association would pass through a middlebox or not. o In a query the agent says what the two endpoint addresses are that it will need to be able to establish an association between (wildcards are allowed). Each specific address or address range has associated with it an "outside okay" attribute and the address of the "informant" from which the agent learned that address. An informant address could be the address of the agent itself, for example in the case of static configuration, the address of some other helper, or the address of one of the endpoints. o The middlebox has a new type of reply to such queries, which is that the query has succeeded through no rules being necessary (since that association will not pass through the middlebox). This scheme adds no extra management burden, either locally or globally, nor does it add any of the concomitant security risk that extra configuration brings in a dynamic network environment. It does not threaten Internet scalability or robustness. It does not create new layer violations. It adds three simple pieces of information to the coalescing midcom protocol. Middlebox discovery is still a poorly explored area, but this scheme appears to work with middlebox discovery mechanisms at least as well Brim & Simu Expires January 30, 2002 [Page 12] Internet-Draft Midcom Agents and Topology August 2001 as any other proposal. There are restrictions on the applicability of this approach, but the cost of creating a protocol to cover the unusual scenarios which this approach does not is not worth paying. There are several loose ends to be explored, but none that call the basic protocol mechanisms into question. 12. Security Considerations The topology knowledge which a middlebox uses to make decisions about whether to install a ruleset or not is no more secure than the source of that knowledge, which is either configuration or routing protocols. The transfer of specific knowledge between the middlebox and the midcom agent is only as secure as the midcom protocol. There are requirements for mutual authentication of middlebox and agent. However, the protocol has not yet been specified or implemented and cannot be analyzed for security problems. The middlebox may be misled into opening up trust boundaries if "inside" versus "outside" is not explicitly indicated, or if an agent gets confused over the origin from which it learned a particular address. References [1] Srisuresh, P., Kuthan, J., Rosenberg, J. and A. Rayhan, "Middlebox Communication Architecture and framework", Internet Draft draft-ietf-midcom-framework-03.txt, July 2001. [2] Swale, R., Mart, P. and P. Sijben, "Middlebox Control (MIDCOM) Protocol Architecture and Requirements", Internet Draft draft- ietf-midcom-requirements-02.txt, July 2001. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Srisuresh, P. and M. Holdredge, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [5] Lear, E., "Requirements for Discovering Middleboxes", Internet Draft draft-lear-middlebox-discovery-requirements-00.txt, April 2001. [6] "Tunnel Endpoint Discovery Enhancement", February 2001, Brim & Simu Expires January 30, 2002 [Page 13] Internet-Draft Midcom Agents and Topology August 2001 . Authors' Addresses Scott Brim Cisco Systems, Inc. 146 Honness Lane Ithaca, NY 14850 USA EMail: sbrim@cisco.com Adina Simu Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: asimu@cisco.com Brim & Simu Expires January 30, 2002 [Page 14] Internet-Draft Midcom Agents and Topology August 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Brim & Simu Expires January 30, 2002 [Page 15]