We present MicroISP, a novel architecture for Internet Service Providers suitable for installation in airports, hotels, conference centers, cafés, and office or apartment buildings. Users access a MicroISP via a low-cost, high-bandwidth LAN, e.g. Ethernet or WaveLAN. A router connects the MicroISP's LAN to a shared high-bandwidth access link (e.g., DSL or cable) to a conventional ISP. For this service, a MicroISP charges its clients. The architecture supports a variety of payment methods, both offline (e.g., cash, credit card, or billing to a hotel room account) and online (e.g., eCash, SET, IBM Micro Payments, or Millicent). MicroISPs use IPSec's IKE protocol for securely exchanging authentication keys with paying users. Paying users use IPSec's AH protocol in tunnel mode to authenticate each packet they send. Therefore, MicroISPs can easily detect and drop packets of nonpaying users. A MicroISP must present to users a certificate signed by a recognized authority, but a user may simply present a self-signed certificate, as long as the user pays for service. Regardless of how online payment is implemented, it runs on the user's authenticated tunnel, and therefore can be securely bound to it. The MicroISP protocol allows users to monitor and control usage and supports recovery in case of a MicroISP or user computer crash.
Users typically connect to the Internet via Internet Service Providers (ISPs). In the conventional ISP architecture, illustrated in Figure 1, each user pays for the installation and maintenance of an access link connecting the user's computer(s) to an ISP's POP (Point of Presence). Alternatives for access links include dial-up PSTN (Public Switched Telephone Network) or ISDN (Integrated Services Digital Network) telephone lines, dedicated telephone lines (e.g., T1), DSL (Digital Subscriber Line), and cable. A contract between user and ISP lasts typically at least a month and often much longer than that.
The conventional ISP architecture has two shortcomings. First, access link costs are significant, i.e., correspond to a considerable fraction of the user's total Internet connection cost. Second, mobility support is poor, especially for higher access bandwidths. On the one hand, dedicated telephone lines, DSL, and cable can provide high bandwidths, but are available only where the user installs them (e.g, office or home). On the other hand, dial-up lines allow access wherever there is a phone, but phones may be unavailable, inconvenient, or expensive to use and, in any case, provide low bandwidth. For example, the number and location of pay-phones in airports, conference centers, and cafés is often adequate for short conversations but inappropriate for laptop hookups and Web browsing. Wireless phones are convenient in such situations, but are expensive to use for more than a few minutes. Additionally, long-distance calls may be necessary to dial-up the nearest POP of the user's ISP.
This paper introduces a novel architecture, MicroISP, that overcomes the above-mentioned shortcomings of conventional ISPs. A MicroISP reduces access costs by amortizing among many users the cost of a high-bandwidth access link to a conventional ISP. Users access a MicroISP via a low-cost, high-bandwidth Local Area Network (LAN), e.g., Ethernet or WaveLAN, as shown in Figure 2. The bandwidth dynamically allocated to each user is likely to be similar to that which many users enjoy at work, and much better than that afforded at home by a dial-up PSTN line. A router connects the MicroISP's LAN to the shared high-bandwidth access link, which may be, e.g., DSL or cable. For this service, the MicroISP charges its clients. The architecture supports a variety of offline and online payment methods. MicroISPs support the needs of transient (mobile) users because, unlike conventional ISP contracts, MicroISP contracts can be short-term (e.g., may last only 15 minutes). The low investment necessary to set up a MicroISP and the potential profitability encourage widespread deployment.
A challenge in this type of architecture is how to prevent a nonpaying user from gaining free service or charging his or her Internet usage to a paying user. For example, if the MicroISP's LAN uses a shared medium, e.g. Ethernet or WaveLAN, a nonpaying user n might be able to communicate with another host h by (1) snooping in the LAN to find the IP address of an active (paying) user p, (2) sending packets to h by spoofing them, i.e., making the source address equal to p, and (3) receiving packets from h by snooping in the LAN to find packets with source equal to h and destination equal to p. The MicroISP architecture uses IPSec's standard Authentication Header (AH) in tunnel mode [18] to solve this problem. MicroISPs and paying users securely exchange authentication keys using IPSec's IKE (Internet Key Exchange) protocol [15,24]. Paying users then use AH with such keys to authenticate each packet they send. No application (e.g., browser) modifications are necessary because IPSec is configured and operates at the network layer [19,7]. Because AH authentication includes the packet's source address, and nonpaying users do not have authentication keys, the MicroISP can easily detect and drop spoofed packets, shutting off nonpaying users.
The MicroISP architecture uses IKE with certificate-based authentication. A MicroISP must present to users a certificate signed by a recognized MicroISP Certifying Authority (CA). Users, on the other hand, need not incur the cost or trouble of obtaining certificates from a recognized CA. A user may present to MicroISPs a self-signed certificate and may thus remain anonymous if the payment method also preserves anonymity (e.g., cash or eCash [9]).
A potential source of complexity and implementation difficulty is the need to accommodate within the architecture the many different usage metrics and payment methods that may be desirable in a given MicroISP. Usage metrics may be, e.g., elapsed or usage time, or number of bytes or packets transmitted. Payment methods may be offline (e.g., cash or credit card) or online (e.g., eCash [9], SET [29], IBM Micro Payments [16], or Millicent [12]). The MicroISP architecture defines a carefully designed protocol that supports these and other options. In particular, the MicroISP protocol does not require modifications in online payment method implementations, because the protocol automatically and securely binds online payment (however implemented) with the above-mentioned AH tunnel.
Another potential pitfall is how to recover from computer crashes. In many scenarios, crashes are actually expected. For example, a guest at a hotel or conference center may turn her laptop on and off several times until her contract with the local MicroISP expires. The MicroISP protocol allows graceful recovery by issuing the user a receipt after the user pays. The MicroISP authenticates the receipt using a secret key. If the usage metric is simply elapsed time (flat fee until an expiration time), the receipt contains all the information necessary for recovery and, except for online payments, the MicroISP need not commit user state to stable storage. Recovery of crashes between the time the user sends online payment to the MicroISP and the time the user commits the respective receipt to stable storage is handled according to the respective payment method.
As mentioned above, MicroISPs use the services of conventional ISPs. MicroISPs may be able to reduce substantially the cost of such services by implementing NAPT (Network Address Port Translation) [30] in the router between the MicroISP LAN and the shared high-bandwidth access link. In this case, all MicroISP users use the same global IP address and appear to the conventional ISP as a single host.
Cybercafés are a competing alternative to ISPs. Typically, cybercafés lease to users desktop computers connected to the Internet. Like MicroISPs, cybercafés allow short-term service contracts. Cybercafés require much greater investment than do MicroISPs because cybercafés own the computers used and need space for them, whereas MicroISPs simply provide Internet access to user-owned laptop or desktop computers and therefore need negligible space. Consequently, MicroISPs may be deployed more widely and in more convenient locations. An additional advantage of MicroISPs is that users may find their own computers more familiar and secure to use than are those provided by a cybercafé. A hybrid service model, MicroISP café, is also possible, and would accommodate the latter users as well as users who do not have their computers with them.
Unlike conventional ISPs, cybercafés and MicroISPs do not themselves provide to users local content and email or Web page hosting services. However, this is becoming hardly a disadvantage, because users can easily find on the Web portals or servers that provide such services for free (e.g., www.yahoo.com, hotmail.com, and www.geocities.com). Web-based services have the advantage of being accessible wherever the user may be.
The rest of this paper is organized as follows. Section 2 gives an overview of the MicroISP protocol and its phases. Sections 3 to 8 describe each of the phases in greater detail: networking configuration, secure tunnel establishment, control channel establishment, contract establishment and binding, usage metering, and settlement. Section 9 discusses implications of using NAPT, and Section 10 discusses some other variations in the MicroISP design. Finally, Section 11 reports the performance of a prototype implementation, and Section 12 concludes.
As shown in Figure 2, the main components of the MicroISP architecture are a high-bandwidth LAN, a router, a server, a shared high-bandwidth access link, and a protocol for communication between user computers and the MicroISP server and router. Although server and router can in general be implemented separately, in this paper we assume that the server is implemented within or as an adjunct to the router, and the term ``MicroISP'' is used to refer to that combination when communicating with users.
This section gives an overview of the MicroISP protocol. Its design was influenced by the following constraints:
Consequently, the MicroISP protocol actually combines several underlying protocols and processes, some of which may be offline.
The MicroISP protocol defines the following phases:
The following sections describe each phase in greater detail.
This section describes in greater detail phase 1 of the MicroISP protocol.
In this phase, MicroISPs use DHCP for configuring the networking parameters of dynamically connected user computers. When user computers boot or restart, they broadcast in the LAN DHCP packets requesting configuration. A MicroISP server replies with the necessary parameters, including network mask and broadcast address, IP addresses of the user's computer and of the default router, and possibly the IP addresses of a DNS (Domain Name System) server, NTP (Network Time Protocol) server, and line printer server. MicroISPs use DHCP's dynamic IP address allocation, so that IP addresses assigned to a user's computer remain valid only during a specified lease time. User computers must periodically renew their leases to preserve their IP addresses. Expired IP addresses may be reused. In MicroISPs, the list of unallocated addresses is maintained in FIFO order.
DHCP makes MicroISPs easy to use: A user may, for example, link her laptop to the Ethernet or WaveLAN in an airport lounge or conference room, reboot the computer, and automatically be configured to access the Internet. DHCP is supported by most current operating systems, including Windows 2000, NT, and Linux.
This section describes phase 2 of the MicroISP protocol and the use of IPSec [19] in MicroISPs.
IPSec defines two protocols for secure data communication, AH [18] and ESP [20]. These protocols are implemented at the network layer and therefore do not require modifications in user applications. AH can provide authentication of packet origin, proof of integrity of packet data, and protection against packet replay. ESP can provide, in addition to AH's services, encryption of packet data and limited traffic flow confidentiality. However, unlike AH's authentication, ESP's does not include the packet's source and destination IP addresses. Therefore, to guarantee that an IP address is always used by the same user while the address is allocated or bound to a contract, MicroISPs use the AH protocol to authenticate all packets sent from that address. If the user so selects, MicroISPs also use ESP encryption for all packets sent to or received from the user's address. This option preserves privacy on the MicroISP's LAN.
AH and ESP can be used in either transport or tunnel mode, as illustrated in Figure 3. Transport mode provides end-to-end security between the packet's source and destination. In contrast, tunnel mode encapsulates packets and thus provides security between the nodes where the packet is encapsulated and decapsulated. MicroISPs use tunnel mode between user computers and MicroISP routers. A user may establish other IPSec tunnels within the user's MicroISP tunnel. A user may do this, e.g., when using the MicroISP and Internet to communicate securely with an IPSec gateway into the Intranet of the user's employer.
Another IPSec protocol, IKE [15], establishes security associations that define the algorithms and cryptographic keys used by AH and ESP. Security associations have a specified lifetime, after which they are terminated and need to be replaced [19]. The MicroISP protocol uses IKE authenticated with signatures. The initiator is always the user. Using this method, MicroISP and user perform a Diffie-Hellman [6] key exchange for securely establishing a shared secret, from which AH and ESP keys are derived. Each party then authenticates the other by verifying the other's signature [26] on a message containing the other's certificate. A party's certificate contains that party's public key, which is necessary for verifying that party's signatures. A party's certificate also contains that party's identity and is itself usually signed by a certifying authority (CA) whose public key is widely known, so that any party can verify the certificate. Certificate formats are defined, e.g., in the X.509 standard [33]. Authentication is necessary to prevent ``person-in-the-middle'' attacks, where an intruder would pretend to be the user when communicating with the MicroISP and to be the MicroISP when communicating with the user. Therefore, MicroISPs must present certificates signed by a recognized MicroISP CA, which maintains registration procedures appropriate for such certification. In a PKIX-based implementation [17], these certificates would contain a policies extension with explicit-text user notice. This notice should be displayed to the user [17] and informs the location and type of LANs supported by the MicroISP. On the other hand, the MicroISP does not really need to authenticate the user's identity in this phase; the MicroISP's only requirement is that the user pay in phase 4 of the protocol, and that no other user be able to use that payment to gain service. Therefore, the MicroISP can be configured to accept self-signed user certificates in IKE exchanges. Using such certificates, users can remain anonymous.
IPSec security policies are defined in a Security Policy Database (SPD) per network interface [19]. Each SPD entry specifies a selector and a rule. Selectors may match, e.g., packets that have a certain protocol and source and destination IP addresses and port numbers (ranges and wild cards are allowed for these values). Actions may be to drop the packet, bypass IPSec, or apply specified IPSec protocols to the packet. The SPD of the LAN interface of MicroISP routers is configured, in the incoming case, to bypass IPSec in the cases of DHCP and IKE packets destined to the MicroISP, to perform AH and optionally ESP processing to packets whose source address is bound (phase 4) to an active contract or whose destination is the MicroISP, and to drop remaining packets. In the outgoing case, the SPD is configured to bypass IPSec in the cases of DHCP and IKE packets whose source is the MicroISP, to either bypass IPSec or apply ESP processing to packets whose source is the MicroISP or whose destination address is bound to an active contract, and to drop remaining packets. While a user's computer is accessing a MicroISP, the SPD of the computer's LAN interface is similarly configured, with the incoming and outgoing cases reversed.
This section briefly covers phase 3 of the MicroISP protocol.
Because of its uses in the MicroISP protocol, the control channel should guarantee message authenticity and privacy in both directions. Privacy is needed, e.g., to prevent the eavesdropping of receipts and their later use by nonpaying users. If the user selected the privacy option in phase 2, all communication over the user's tunnel is already secured in both directions by ESP. Therefore, the user establishes the control channel by simply opening a TCP connection to a well-known port in the MicroISP. Otherwise, the tunnel established in phase 2 does not provide all the required security (i.e., only authenticates user packets to the MicroISP). Therefore, the user employs the TLS [5] protocol for establishing a secure control channel over the user's tunnel. The principals of the TLS channel are guaranteed to be the same as those of the AH tunnel: The MicroISP is authenticated using its certificate, while the user is authenticated by AH.
This section describes how a contract between MicroISP and user is established in offline and online cases and how the IP address assigned to the user in phase 1 and secured in phase 2 is bound to the user's contract in phase 4 of the MicroISP protocol. (Note: Frameworks for online price negotiation and payment selection have been discussed in the e-commerce literature and there are proposals for their standardization, e.g. JEPI [32] and SEMPER [28].)
The contract is established in four steps:
Phase 4 of the MicroISP protocol is executed as follows. If the user's stable storage contains the receipt of an outstanding contract, the user sends the receipt over the control channel to the MicroISP, which verifies that the contract is still outstanding, is not bound to an IP address, and is not being settled. The MicroISP then binds the contract with the user's IP address, concluding this phase. Otherwise, if the user sends over the control channel the password of an unbound outstanding offline contract, the MicroISP binds the contract with the user's IP address and returns the corresponding receipt. The user then commits the receipt to stable storage, concluding this phase. Otherwise, the user sends over the control channel a request for online contract establishment, triggering the four steps described above. The contract is bound to the user's IP address in step 4.
This section describes phase 5 of the MicroISP protocol, usage metering. Metering depends on contract and IP address states. Therefore, this section discusses the possible states and the events that trigger state transitions (e.g., user commands).
Metering is greatly simplified when the usage metric is elapsed time. In such cases, the MicroISP does not need to commit contract state and usage to stable storage in order to be able to recover from MicroISP crashes: The receipts themselves contain all the necessary information. If the MicroISP's shared link to a conventional ISP is charged on a similar basis, this is probably the best alternative. However, if the MicroISP is charged according to number of bytes or packets transmitted, it may need to do the same with respect to its clients.
In general, users monitor and control contract state by sending commands to the MicroISP. Available commands include report usage, start/resume, suspend, or terminate a contract, and extend a contract's soft limit up to its hard limit. The MicroISP replies to these commands include the accumulated usage and the soft and hard limits. The MicroISP may also send asynchronous warning messages when a contract's accumulated usage reaches its soft or hard limit or expires, or when a user on a different IP address presents the contract's receipt on phase 4 of the MicroISP protocol. All these messages contain the contract's serial number and are sent over the control channel.
A contract is outstanding between its establishment and settlement, and becomes extinguished when it expires, has accumulated usage that reaches its hard limit, or after settlement, as shown in Figure 4. An outstanding contract can be unbound, bound, or in settlement. An outstanding contract is initially unbound. An unbound contract becomes bound to an IP address when a receipt for that contract is sent to or from that IP address in phase 4 of the MicroISP protocol. A bound contract becomes unbound when the user's computer lets the respective DHCP lease or IPSec security association expire (e.g., because of a crash). An unbound or bound contract becomes in settlement when the user issues a terminate command.
A bound contract can be suspended, active, or delinquent. A bound contract is initially suspended. A suspended contract becomes active when the user issues a start/resume command. An active contract becomes suspended when the user issues a suspend command, and becomes delinquent when the usage reaches the soft limit. A delinquent contract becomes active when the user issues a valid extend command.
An IP address can be unallocated, allocated, or bound to a contract, as shown in Figure 5. IP addresses are initially unallocated. An unallocated IP address becomes allocated when DHCP allocates it to a user's computer. An allocated IP address becomes unallocated again if the user's computer allows the respective DHCP lease or IPSec security association to expire. An allocated IP address becomes bound to a contract when the converse is true. A bound IP address b becomes unallocated when the respective contract becomes unbound or extinguished or (1) a user on a different IP address d presents the contract's receipt on phase 4 of the MicroISP protocol; and (2) the MicroISP repeatedly warns b but b does not respond, which suggests that the user's computer crashed and is now recovering on a different address.
The MicroISP meters a contract's usage time only while the contract is active. The MicroISP router forwards to or from the Internet and meters the number of bytes or packets only of packets that use an IP address bound to an active contract. The MicroISP also allows packets whose source or destination is the MicroISP.
This section describes phase 6 of the MicroISP protocol. This is the final phase.
If the user lets the contract expire or uses the contract fully to its hard limit, the MicroISP retains the whole deposit. If the payment method is credit card or SET, the MicroISP automatically performs a settlement transaction for that value. On the other hand, if the usage is below the hard limit, an adjustment or refund is necessary, and will be processed according to the payment method. In offline cases other than cash, the user physically signs a new form. In the credit card and SET cases, a settlement transaction for the value of the actual usage is performed. In the cash, eCash [9], and Millicent [12] cases, a refund is returned to the user. In the cases of offline billing to an account and of IBM Micro Payments [16], the MicroISP simply adjusts its billing records.
MicroISPs have to allocate one IP address per contract that is bound or in settlement. In order to get more than one IP address from a conventional ISP, the MicroISP will typically need to pay extra. A cost-saving alternative is to have the MicroISP router implement NAPT (Network Address Port Translation) [30] so that all MicroISP users share a single global IP address. However, NAPT may not support certain protocols, as discussed in this section.
If a MicroISP implements NAPT, the IP addresses that it allocates to user computers are private (unregistered and possibly not globally unique) [25]. NAPT translates respectively the source or destination IP addresses and port numbers (between private and global) in packets sent to or received from the Internet. NAPT builds a translation table such that all local hosts share the same global IP address, and destinations of packets received from the Internet can be determined by the global port numbers.
NAPT is not transparent to application-layer protocols that include host addresses or port numbers within their payloads (e.g., FTP). For each such protocol, NAPT requires a corresponding Application Level Gateway (ALG) that knows how to modify the application-level payloads. ALG support has been increasing, but NAPT may still not interoperate with certain protocols [30].
NAPT is also not transparent with respect to most of IPSec's protocols and modes. (However, note that NAPT does not affect the AH tunnel used in the MicroISP protocol, which terminates at the router.) NAPT address translations invalidate AH's authentication, whose scope includes the source and destination addresses. NAPT address translations can also invalidate TCP or UDP checksums of ESP packets in transport mode, which are calculated including the packet's source and destination addresses. An ALG for these cases is not possible because it would need to know the cryptographic keys used, which would violate end-to-end security. NAPT can, however, interoperate with ESP in tunnel mode, where the entire packet is encapsulated and NAPT's translations do not affect the encapsulated checksum. VPN Masquerade [14] is a NAPT implementation that provides such support. VPN Masquerade uses a number of heuristics for demultiplexing incoming traffic. These heuristics are subject to race conditions and may, in some cases, fail, causing packet misdelivery. However, packet misdelivery does not break security any more than eavesdropping in the LAN would.
We recently proposed [2] a DHCP extension that allows hosts to lease from NAPT, e.g., global IP addresses and port numbers. Using that extension, IPSec implementations can always interoperate correctly with NAPT. Another alternative currently being considered is to replace NAPT by RSIP (Realm-Specific IP) [30]. We believe that either solution will go a long way toward eliminating NAPT's current interoperation difficulties. Therefore, the cost-reducing option of using a single global IP address in MicroISPs may soon become even more attractive.
Many details is the MicroISP design can be altered without essentially impacting in the overall functionality. This section discusses some of the possible modifications.
An obvious variation is to use another protocol for authentication and/or encryption in the secure tunnel. The new protocol must be able to encapsulate and decapsulate packets. For example, instead of AH, a MicroISP might employ ESP's authentication option to authenticate packets sent by paying users. In either case, ESP's encryption is optional, and tunnel mode is used. Unlike AH, ESP's authentication does not cover the packet's source and destination IP addresses. However, ESP's authentication does cover the entire encapsulated packet. Therefore, ESP's authentication is sufficient for spoofing prevention [13].
Another variation would be to set up the control channel before the secure tunnel. The control channel might allow, for example, the transmission of cryptographic keys to be used in the tunnel. In this case, IKE authentication could, e.g., use a pre-shared key, instead of digital signatures.
Other variations include using a solution other than the DHCP protocol for configuring networking parameters of user computers; using a solution other than the IKE protocol for establishing the secure tunnel's cryptographic algorithms and keys; using a firewall, instead of IPSec's SPDs, for dropping packets of nonpaying users; or using a protocol other than TLS (e.g., TLS's predecessor, SSL [11]) for the secure control channel.
An important practical question is how powerful a computer would be necessary for implementing a MicroISP router/server. To answer this question, we built a PC-based MicroISP router/server prototype and report its performance in this section.
Our prototype is based on a low-cost PC with a 400 MHz Pentium II CPU and 64 MB of main memory. The prototype uses the freely available Linux 2.2.12 operating system and the FreeS/WAN 1.1 IPSec implementation [10].
To circumvent limitations of our prototype environment, we used several of the design alternatives discussed in the previous section. First, we used SSL instead of TLS because we had an SSL implementation easily available. Second, the prototype uses SSL to establish the control channel before the secure tunnel, because FreeS/WAN 1.1 does not fully implement IKE. The control channel securely transmits randomly generated keys for FreeS/WAN authentication using pre-shared keys.
We connected a client and a server Linux PCs to the MicroISP prototype using separate 10 Mbps Ethernets, and measured the TCP throughput between the client and server. For control, we also measured the TCP throughput between client and server when connected on the same 10 Mbps Ethernet (without the MicroISP): 6.4 Mbps. When client and server were connected through the prototype implementing only routing and NAPT (no MicroISP functionality), the TCP throughput dropped slightly to 6.2 Mbps, and the CPU utilization on the prototype was 4%. With MicroISP functionality and packet authentication between client and MicroISP (using AH with MD5 [22]), the TCP throughput between client and server was 5.8 Mbps and the CPU utilization on the prototype was 26%. (Note: For ease of implementation, in the latter experiment AH was used in both directions; results would probably improve significantly if AH were used only from client to MicroISP, as described in Section 4.) Finally, with MicroISP functionality and both authentication and encryption between client and MicroISP (using ESP with MD5 and triple DES [21]), the TCP throughput between client and server was 5.3 Mbps, and the CPU utilization on the prototype was 70%.
We also measured the time necessary for a client to connect to the MicroISP prototype (steps 1 to 4 of the MicroISP protocol), as well as the load imposed on the prototype's CPU by such connections (with no other network or CPU activity). We simultaneously started connections from two 100 MHz Pentium clients and one 700 MHz dual-processor Pentium III client. Connection took 0.5 s for the fast client and 1.9 and 2.1 s for the slow clients. The prototype CPU was 31% utilized during these connections.
These measurements suggest that even a modest PC can handle the loads that may be expected on a MicroISP router/server. Access links such as T1, DSL and cable provide bandwidths from 0.6 to 7 Mbps downstream and from 0.6 to 1.5 Mbps upstream (cable can theoretically support up to 27 Mbps downstream, but cable modems usually limit a client's bandwidth to 1 Mbps). Such bandwidths are one to two orders of magnitude greater than those enabled by PSTN (57 Kbps downstream and 33 Kbps upstream), but still represent only a moderate load for today's processors.
The measurements also justify charging a premium price for privacy on the MicroISP's LAN: ESP's authentication (MD5) and encryption (triple DES) imposed a much higher load on the MicroISP prototype than did AH's authentication (MD5) alone.
We described MicroISP, a novel architecture that allows Internet access services to be securely provided and charged over standard shared-medium LANs, e.g. Ethernet or WaveLAN. Such LANs can be easily installed in convenient locations, e.g. airports, hotels, conference centers, lounges, and cafés. Standard protocols automatically configure user computers so that they can access the Internet. A router connects the MicroISP LAN to a shared high-bandwidth access link (e.g., DSL or cable) to a conventional ISP. Because a MicroISP amortizes the cost of the access link among many users, it can also reduce the cost of Internet access in offices and apartment buildings. The bandwidth dynamically allocated to each user is likely to be similar to that enjoyed by many users at work, and much better than that provided by a dial-up PSTN line. The architecture supports a variety of payment methods, both offline (e.g., cash, credit card, or billing to a hotel room account) and online (e.g., eCash, SET, IBM Micro Payments, or Millicent). MicroISPs use IPSec's IKE protocol for securely exchanging authentication keys with paying users. Paying users use IPSec's AH protocol in tunnel mode to authenticate each packet they send. Therefore, MicroISPs can easily detect and drop packets of nonpaying users. A MicroISP must present to users a certificate signed by a recognized MicroISP certifying authority. However, MicroISPs can accept users who do not have a certificate by a recognized authority or who choose to remain anonymous, as long as those users provide valid payment. The MicroISP protocol can use independent online payment method implementations because, regardless of how online payment is implemented, it runs on the user's authenticated tunnel, and therefore can be securely bound to it. The MicroISP protocol allows users to monitor and control usage and supports recovery in case of a MicroISP or user computer crash.
José C. Brustoloni
received his Ph.D. in Computer Science from Carnegie Mellon University in 1997 and has been with Bell Labs since then, where he works in the Network Systems Research Department. His main research interests are in access networks, quality of service and billing, programmable networks, protocol performance, and embedded systems.
Juan A. Garay
received his Ph.D. in Computer Science from Penn State University in 1989. Before joining the Secure Systems Research Department at Bell Labs, he was with IBM's T.J. Watson Research Center in Yorktown Heights, NY. His areas of interest include the design and analysis of cryptographic protocols, distributed computing, and fault tolerance.