MicroISPs: Providing Convenient and Low-Cost High-Bandwidth Internet Access
José Brustoloni and Juan Garay
Information Sciences Research Center
Bell Laboratories, Lucent Technologies
600 Mountain Avenue, Murray Hill, NJ 07974, USA
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.
Keywords: Mobile access, access devices, electronic commerce, security and privacy.
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.
Figure 1: Dial-up PSTN lines are still the most common ISP access links. They provide low bandwidth and usually require one access link and ISP account per computer. When the user is mobile, dial-up PSTN lines may be unavailable, inconvenient, or expensive to use.
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.
Figure 2: A MicroISP amortizes among many users the cost of a high-bandwidth access link (e.g., DSL). MicroISPs require little investment and space and therefore may be deployed widely and in convenient locations. MicroISPs support mobile users by allowing short-term contracts.
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  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 ).
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 , SET , IBM Micro Payments , or Millicent ). 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)  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.
Organization of paper
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:
- Use of standard hardware and protocols. MicroISP access will typically be based on a shared medium, and it is tempting to design special network cards, protocols, tokens, or smartcards to guarantee secure access and payment in such networks. For example, cable access networks are also based on a shared medium and use special, certified cable modems and a special protocol (BPI+ ) to secure communications between cable modems and cable head-ends. (An offline process binds a certified cable modem with a user account, to which Internet usage is billed.) However, special hardware makes installation costly, and special protocols may not be as well scrutinized and secure as standard ones. For example, the protocol initially used in cable systems did not authenticate the cable head-end, leaving an important security hole. In contrast, MicroISPs interoperate with standard LAN cards that many users already own (e.g., Ethernet or WaveLAN), and use IETF's standard IPSec protocols . IPSec is supported by most current operating systems, including Windows 2000, NT 5, and Linux.
- Use of existing online payment method implementations. There are many proposals for online payment methods (e.g., eCash , SET , CyberCash , IBM Micro Payments , or Millicent ). Some proposals are proprietary and no proposal has achieved wide use. Embedding specific online payment methods into MicroISP implementations would therefore involve considerable licensing and maintenance difficulties. These difficulties are avoided by MicroISP's secure binding of payments received by independently designed and implemented processes.
- Support for offline payment. Depending solely on online payment could adversely delay MicroISP deployment, given that adoption of online payment methods has been slow. Additionally, offline payment would be quite natural in many scenarios, e.g. when a user checks in at an airport, hotel, or conference, or comes into a lounge or café.
Consequently, the MicroISP protocol actually combines several underlying protocols and processes, some of which may be offline.
The MicroISP protocol defines the following phases:
- Networking configuration. Before a user's computer can communicate with the MicroISP, some of its networking parameters need to be configured, e.g. the IP addresses of the user's computer and of the default router. MicroISP uses the standard Dynamic Host Configuration Protocol (DHCP)  to achieve this configuration.
- Secure tunnel establishment. MicroISP uses IPSec's AH protocol in tunnel mode to authenticate user packets. The tunnel guarantees that all packets received by the MicroISP from a certain IP address correspond to the same user. The identity of that user is immaterial to the MicroISP, provided that the user pays for the MicroISP services. Therefore, the user may present a self-signed certificate. On the other hand, before paying, users may want to verify that they are communicating with a bona fide MicroISP. Therefore, MicroISPs must present a certificate signed by a recognized MicroISP certifying authority. Users are also given the option of privacy on the MicroISP's LAN. When this option is selected, the tunnel encrypts packets between the user's computer and the MicroISP's router, using IPSec's Encapsulating Security Payload (ESP)  protocol.
- Control channel establishment. The MicroISP needs a secure control channel to send to the user the MicroISP's price list before payment and a receipt after payment. The user also uses this channel to control his or her Internet usage. If the tunnel established in the previous phase uses ESP, the control channel is simply a TCP connection; otherwise, the control channel uses the TLS protocol .
- Contract establishment and binding. In this phase, (1) the MicroISP presents to the user a list of options for service (e.g., usage metrics: elapsed or usage time, or number of bytes or packets transmitted) and payment (e.g., eCash, SET, IBM Micro Payments, or Millicent) and the respective prices, (2) the user selects the desired options, (3) the user makes a deposit payment, and (4) the MicroISP gives a receipt to the user. This phase is skipped entirely if the user's computer already has the receipt of an outstanding contract and the user, e.g., is reconnecting to the MicroISP again after turning his or her computer off. Steps 1 to 3 are skipped if the user presents a valid password, received from the MicroISP in offline processing of those steps (e.g., payment by cash, credit card, or billing to a hotel room account). Step 3 may be performed over channels other than the one established in the previous phase (e.g., in the case of independent online payment method implementation). However, any online payment will necessarily use the tunnel established in phase 2, and therefore can be securely bound to it.
- Usage metering. Until a user's Internet usage reaches the amount selected in the previous phase, the user can send or receive packets to the Internet using the MicroISP's facilities. To monitor and control his or her usage, the user may exchange messages with the MicroISP, using the control channel established in phase 3. These messages may, for example, suspend, resume, or terminate service.
- Settlement. When service to a user terminates, the net amount paid by the user should be equal to his or her actual usage. If the deposit of phase 4 is greater than the net amount, the user may be due a refund. This settlement is performed in this final phase.
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  in MicroISPs.
IPSec defines two protocols for secure data communication, AH  and ESP . 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.
Figure 3: IPSec packet format depends on protocol (AH or ESP) and mode (transport or tunnel). The portion of the packet that is authenticated or encrypted is different for AH or ESP. The encapsulated packet is shown in bold.
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 , 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 . The MicroISP protocol uses IKE authenticated with signatures. The initiator is always the user. Using this method, MicroISP and user perform a Diffie-Hellman  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  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 . 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 , these certificates would contain a policies extension with explicit-text user notice. This notice should be displayed to the user  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 . 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  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  and SEMPER .)
The contract is established in four steps:
- MicroISP offer. The MicroISP presents to the user a contract form containing a serial number, the current date and time, available service options, including acceptable usage metrics (e.g., elapsed or usage time, or number of bytes or packets transmitted) and the respective prices, and acceptable payment methods (e.g., in offline cases: cash, credit card, or billing to an account, such as a hotel room account; or in online cases: eCash , SET , IBM Micro Payments , or Millicent ). A contract is always subject to an expiration time. Prices may depend, e.g., on whether the user has selected phase 2's privacy option, on the amount of usage, on the payment method selected, and on the current or anticipated MicroISP load.
- User request. The user completes the form indicating the desired usage metrics, soft and hard usage limits, and payment method. In offline cases, if the payment method is not cash, the user physically signs the form.
- User deposit. The user employs the selected payment method to deposit with the MicroISP an amount equal to the selected hard usage limit. If the payment method is credit card or SET, this deposit is implemented by an authorization transaction. In certain online cases (which do not include SET or eCash), the MicroISP may need to allow the user to communicate directly with external servers before paying. In IBM Micro Payments , for example, the user may need to contact his or her issuer to obtain the user's daily certificate, which is necessary for making payments. As another example, in Millicent , the user may need to contact his or her broker to convert broker scrips into MicroISP scrips (scrips are Millicent's merchant-issued payment instruments). To enable the latter payment methods, modifications in IPSec's SPDs may be necessary (e.g., permitting user communication with certain supported issuers or brokers for a limited time).
- MicroISP receipt. The MicroISP gives to the user a copy of the contract and password (offline cases) or a receipt (online cases). The user commits the receipt to stable storage. The receipt is a data structure that includes the contract's serial number, date and time, expiration, selected usage metrics and limits, and payment parameters. The MicroISP authenticates the receipt with a Message Authentication Code (MAC). MAC computation uses a secret key with, e.g., the DES-MAC , keyed-MD5 , or HMAC  algorithms.
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.
Figure 4: Contract states and transitions. The initial states are the top ones.
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.
Figure 5: IP address states and transitions. The initial state is unallocated.
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 , and Millicent  cases, a refund is returned to the user. In the cases of offline billing to an account and of IBM Micro Payments , 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)  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) . 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 .
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  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  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) . 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 .
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 ) 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 .
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 ), 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 ), 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.
- M. Bellare, R. Canetti, and H. Krawczyk, ``Keyed Hash Functions and Message Authentication,'' in Advances in Cryptology-Crypto '96, N. Koblitz, ed., Lecture Notes in Computer Science No. 1109, Springer-Verlag, 1996, pp. 1-15.
- J. Brustoloni and J. Garay. ``Application-Independent End-to-End Security in Shared-Link Access Networks,'' in Proc. IFIP Networking'2000, Lecture Notes in Computer Science, Springer-Verlag, May 2000.
- CyberCash. Home page at http://www.CyberCash.com/.
- Data-Over-Cable Service Interface Specifications, ``Baseline Privacy Plus Interface Specification,'' SP-BPI+-101-990316, CableLabs, 1999. Available at http://www.cablemodem.com.
- T. Dierks and C. Allen. ``The TLS Protocol Version 1.0,'' IETF, RFC 2246, Jan. 1999.
- W. Diffie and M.E. Hellman. ``New directions in cryptography,'' in Transactions on Information Theory, IEEE, IT-22: 644-654, 1976.
- N. Doraswamy and D. Harkins. ``IPSec: The New Security Standard for the Internet, Intranets and Virtual Private Networks,'' Prentice-Hall, 1st. ed., July 1999.
- R. Droms. ``Dynamic Host Configuration Protocol,'' IETF, RFC 2131, Mar. 1997.
- eCash Technologies, Inc. Home page at http://www.ecashtechnologies.com/.
- FreeS/WAN. Homepage at http://www.xs4all.nl/~ freeswan/.
- A. Freier, P. Karlton and P. Kocher. ``The SSL Protocol Version 3.0,'' Netscape, Mar. 1996. Available at http://home.netscape.com/eng/ssl3/ssl-toc.html.
- S. Glassman, M. Manasse, M. Abadi, P. Gauthier and P. Sobalvarro. ``The Millicent Protocol for Inexpensive Electronic Commerce,'' in Proc. 4th Intl. World Wide Web Conference, W3C, Boston, MA, Dec. 1995. Available at http://www.w3.org/conferences/WWW4/.
- R. Glenn and S. Kent. ``The NULL Encryption Algorithm and Its Use With IPsec.'' IETF, RFC 2410, Nov. 1998.
- J. Hardin. ``Linux VPN Masquerade.'' Homepage at http://www.wolfenet.com/~ jhardin/ip_masq_vpn.html.
- D. Harkins and D. Carrel. ``The Internet Key Exchange (IKE),'' IETF, RFC 2409, Nov. 1998.
- A. Herzberg and H. Yochai. ``MiniPay: Charging per Click on the Web,'' in Proc. 6th Intl. World Wide Web Conference, W3C, Santa Clara, CA, 1997. Available at http://www.scope.gmd.de/info/www6/. Now called IBM Micro Payments. Home page at http://www.hrl.il.ibm.com/mpay/.
- R. Housley, W. Ford, W. Polk and D. Solo. ``Internet X.509 Public Key Infrastructure Certificate and CRL Profile,'' IETF, RFC 2459, Jan. 1999.
- S. Kent and R. Atkinson. ``IP Authentication Header,'' IETF, RFC 2402, Nov. 1998.
- S. Kent and R. Atkinson. ``Security Architecture for the Internet Protocol,'' IETF, RFC 2401, Nov. 1998.
- S. Kent and R. Atkinson. ``IP Encapsulating Security Payload (ESP),'' IETF, RFC 2406, Nov. 1998.
- C. Madson and N. Doraswamy. ``The ESP DES-CBC Cipher Algorithm with Explicit IV,'' IETF, RFC 2405, Nov. 1998.
- C. Madson and R. Glenn. ``The Use of HMAC-MD5-96 within ESP and AH,'' IETF, RFC 2403, Nov. 1998.
- C. Madson and R. Glenn. ``The Use of HMAC-SHA-1-96 within ESP and AH,'' IETF, RFC 2404, Nov. 1998.
- D. Maughan, M. Schertler, M. Schneider and J. Turner. ``Internet Security Association and Key Management Protocol (ISAKMP),'' IETF, RFC 2408, Nov. 1998.
- Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot and E. Lear. ``Address Allocation for Private Internets,'' IETF, RFC 1918, Feb. 1996.
- R. Rivest, A. Shamir and L. Adleman. ``A Method for Obtaining Digital Signatures and Public-Key Cryptosystems,'' in Communications of the ACM, ACM, Vol. 21(2), Feb. 1978.
- B. Schneier. ``Applied Cryptography,'' 2nd. ed., John Wiley & Sons, New York, NY, 1996.
- Secure Electronic Marketplace for Europe (SEMPER). Homepage at http://www.semper.org/.
- SET. Homepage at http://www.setco.org/.
- P. Srisuresh and M. Holdrege. ``IP Network Address Translator (NAT) Technology and Considerations,'' IETF, RFC 2663, Aug. 1999.
- G. Tsudik, ``Message Authentication with One-Way Hash Functions,'' Proc. INFOCOM '92, IEEE, 1992, pp. 2055-2059.
- W3C Joint Electronic Payments Initiative (JEPI). Homepage at http://www13.w3.org/ECommerce/Overview-JEPI.html.
- Recommendation X.509 (1197 E). ``Information Technology - Open Systems Interconnection - The Directory: Authentication Framework,'' ITU-T.
José C. Brustolonireceived 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. Garayreceived 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.