Network Working Group R. Penno Internet-Draft A. Albuquerque Expires: October, 2001 Nortel Networks April, 2001 ISP Selection in Open Access Networks draft-penno-isp-selection-00.txt 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract The most common challenge of Open Access networks is the choice of the most appropriate ISP Selection method. This document intends to explain the current ISP Seletion models, its pros and cons, and make people better understand the existing scenarios. Specification of Requirements The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [1]. Penno, et al. [Page 1] Internet-Draft ISP Selection March,2001 Table of Contents 1. Definitions. . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction. . . . . . . . . . . . . . . . . . . . . . . .3 3. High Speed Access Deployment Models. . . . . . . . . . . . 3 4. DHCP login. . . . . . . . . . . . . . . . . . . . . . . . .4 5. PPPoE login. . . . . . . . . . . . . . . . . . . . . . . . 5 6. PPPoA login. . . . . . . . . . . . . . . . . . . . . . . . 7 7. Layer 2 or 3 Network Technology and Web Page Login. . . . .8 8. L2TP. . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. IPSec. . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . .11 11. Security Considerations. . . . . . . . . . . . . . . . . .12 12. Acknowledgments. . . . . . . . . . . . . . . . . . . . . .12 Author's Addresses. . . . . . . . . . . . . . . . . . . . 13 Full Copyright Statement. . . . . . . . . . . . . . . . . 13 Penno, et al. [Page 2] Internet-Draft ISP Selection March,2001 1. Definitions User: A unique person that has access to the Internet or some other IP network. One or more person can be treated as a single subscriber. Subscriber: A logical unit to which services are be applied. It can be (but not limited to) a ATM VC, a IP address or a PPP session. A subscriber can composed of one of more users. 2. Introduction One of the most common problems encountered is, herein referred to by the author as, ISP selection. Essentially, the problem to be solved is to simplify the ISP selection by the user. However some premises have to be respected so as not to restrict the scope of the discussion provided, these are: o Several users subscribed to different ISPs may share the same PC connected to a access network (usually in a residential environment). o Several PCs belonging to different users can share the same device (for instance, cable or xDsl modem) that provides connectivity to the infrastructure provider (for instance, in a condominium). o One user can have accounts with different ISPs. o The IP address used by the subscriber at a given moment may be supplied by the ISP or the access provider. 3. High Speed Access Deployment Models The following discussion applies for deployment models for Open Access. This is the scenario where a subscriber subscribes to a high speed Internet service but can select the ISP of their choice as opposed to using the ISP associated with the access provider. There are 3 common access models used in enable Open Access networks, these are: o DHCP login o PPPoE login o PPPoA login o Web Page login There are two extra models suitable for telecommuter's access to their VPNs: o L2TP login o IPSec login Penno, et al. [Page 3] Internet-Draft ISP Selection March,2001 4. DHCP login In this model there is no layer 2 end-to-end session established between the user's personal computer and the IPServices router as in the PPPoX model. So, the access network between the user's personal computer and the DHCP server or IPServices Router maybe be bridged or routed. A premise here is that when the subscriber changes from ISP-A to ISP-B, the IP address of the personal computer must change, and either come from ISP-B or from a pool of the access provider's IP block specially reserved for ISP-B subscribers. We can see then that a drawback of this model is that users that share the same PC must subscribe to the same ISP, because the ISP<->Subscriber association is made through to the PC's MAC address or the Relay Agent Information, and not through a specific user authentication mechanism. The concept above can be further undesrtood by saying that in access provider's point of view the subscriber is the PC and not a specific user using it. There is a possibility that users sharing the same PC be able to subscribe to different ISPs, but this calls for DHCP Server dynamic provisioning. The following are the steps for ISP selection: o User-A powers on the PC which gets a IP address through DHCP. This IP address is associated to ISP-A. o When it's time for User-B to access the Internet through the same PC, the IP address of the PC must be changed since User-B is subscribed to ISP-B. o User-B then accesses a web form where he can change the Subscriber<->ISP association. User-B then submits this form to the web server, which through the use of scripts or other mechanism, reprovisions the DHCP server with a new (MAC address or Relay Agent)<->IP address address mapping. When the PC sends another DHCP request due to IP address leased time expiration, a reboot, some manual intervention, it will receive an IP address assciated to ISP-B. 4.1 DHCP Reconfigure Extension There is work being done within the IETF to allow dynamic reconfiguration of a single host triggered by the DHCP server (eg. a new IP address). This is achieved by introducing a unicast DHCP FORCERENEW message which forces the client to the RENEW state. Penno, et al. [Page 4] Internet-Draft ISP Selection March,2001 This would allow a much more cleaner ISP Selection without requiring the user to peform some manual intervention on his PC or a reboot. 4.1.1 Force renew procedures The DHCP server sends a force renew message to the client. The client will change its state to the RENEW state. The client will then try to renew its lease according to normal DHCP procedures. If the server wants to assign a new IP address to the client, it will reply to the DHCP REQUEST with a DHCP NAK. The client will then go back to the init state and broadcast a DHCP DISCOVER message. The server can now assign a new IP address to the client by replying with a DHCP OFFER. If the force renew message is lost, the DHCP server will not receive a DHCP REQUEST from the client and it should retransmit the DHCP FORCERENEW message using an exponential backoff algorithm. Depending on the bandwidth of the network between server and client, the server should choose a delay. This delay grows exponentially as retransmissions fail. The amount of retransmissions should be limited. 4.1.2 Rationale This approach has a number of advantages. It does not require new states to be added to the DHCP client implementation. This minimizes the amount of code to be changed. It also allows lease RENEWAL to be driven by the server, which can be used to optimize network usage or DHCP server load. For the open access model, the greatest advantege is the ability to change the IP address of the client without a reboot or any type of intervention by the user. For example, the user can go to a web page and click on a button to change the ISP (and consequently the IP address) that he is subscribed at that moment. 5. PPPoE login In this model the access network must pass the packets transparently between the DSL modem and the edge device, since a layer 2 end-to-end session must be established between the user's personal computer and the edge device. Layer 2 PPPoE [RFC2516] access via xDSL networks is quite similar to dial-up access, where in the dial-up model, the Remote Access Server (RAS) plays the part of physical access concentrator that the DSL Access Multiplexer (DSLAM) plays in xDSL Networks. In either case an end-to-end PPP session is established, followed by authentication, user validation and IP address allocation for the duration of the call. The fundamental difference is that instead of using a traditional POTS dial-up mechanism, the user executes a PPPoE client on his machine, fills in the user and passwords fields and opens a session with his provider much faster. Penno, et al. [Page 5] Internet-Draft ISP Selection March,2001 The PPPoE protocol is relatively new, but its basic function is to encapsulate PPP packets into Ethernet frames that will be de- encapsulated by the tunnel termination device. The PPPoE protocol has two stages; session and discovering. PPP session packets are encapsulated in the Ethernet frame with the Ethertype equal to 0x 88 64. The Ethertype (0x 88 63) is used during the discovering stage, where the user's PPPoE client tries to identify the device that will terminate the PPPoE session. To obtain further and more in depth information on the PPPoE protocol refer to recommendation [RFC2516]. One of the disadvantages of this model is the need to install software on the user's PC. However software distribution can be done via a provisioning page and the user can perform the installation, since existing PPPoE clients on the market are easy to install and operate. Notwithstanding, this model offers important advantages when compared to others. o Subscriber IP address can be easily assigned by the ISP. o The user has some control over some of the connection variables. o It is possible to use standards already established for PPP protocols. o User differentiation for those sharing a PC is easy and immediate. The ISP selection steps for this model are the following: The user executes the PPPoE client, enters username and password, presses the connect button, and is now ready to navigate the internet. In the step above, the value added provider knows, by the realm or domain used in the username (eg. user1@isp1.com) or the PPPoE 0x0101 Service-Name TAG_TYPE, to which ISP the user belongs to, in which Radius server it should perform the authentication and which service package should be used with that particular user. For example, if the user's name is reinaldo@silver.isp2.com.br, the provider knows that it must use one of the ISP2 Radius servers to perform the authentication and the user's has the silver service package. Since each user has a different username and password, ISP Selection even for users that share the same PC is straightforward There is still a possibility that the session characteristics will be transferred, during the authentication step, by the Radius to the value added provider, instead of remaining stored in it. In this case the user may connect Simply as reinaldo@isp2.com.br, since there will be attributed-value pairs (AV-pair) that describes the behavior (service package) that the user has purchased. Penno, et al. [Page 6] Internet-Draft ISP Selection March,2001 Altough the process of disconnecting and reconnecting to change ISPs is quick and uncomplicated, some services providers prefer that this process occur without any user intervention on the PPPoE client running on the PC in order to provide a better experience and easier access to on-demand services. To accomplish this automatic service switch, the ISP Selection web page could signal the IP Services router, which would use a PPPoE Active Service Change (PADC) [PPPoE-Ext] packet to change the ISP or Service of the user seamlessly. 6. PPPoA Login In this model the access network must pass the packets transparently between the DSL modem and the edge device, since a layer 2 end-to-end session must be established between the user and the edge device. Layer 2 PPPoA access [RFC2364] via xDSL networks is similar to the PPPoE model mentioned above. The main difference is that PPPoA does not use the Ethernet as transport, ATM is used instead of Ethernet. From a xDSL standpoint, where ATM is used by definition, it means less overhead. The PPPoA session, in the PPPoA model, is established from the PPPoA modem to the Edge Device. If the user's personal computer has a internal modem, there is no difference between this model and the PPPoE modem in terms of ISP Selection. The user will use a client to perform the connection and will supply a username and password to do that. On the other hand, if the user has an external PPPoA modem, the ISP Selection isn't so straightforward. The username and password is usually stored into the modem's flash memory. The user has to connect to the modem to perform the change of username and realms in order to connect to another ISP. Some vendors implements a mini web server in the modem in order to facilitate this interaction. Some others makes it available through command line interface (telnet session). There is some which implements a dummy modem driver which can interact with the modem, the user creates an dial-up connection just like the old days and can perform the ISP selection in the same way as the PPPoE model. Penno, et al. [Page 7] Internet-Draft ISP Selection March,2001 7. Layer 2 or 3 Network Technology and Web Page Login This method is one of the most controversial, because its advantages and disadvantages are so polarized. To understand this better we shall divide the user login into two stages, the first is performed by the DHCP, where the user's PC obtains an IP address associated to the user's MAC address, and second, where the user name and password are entered in a web form and is authenticated against a Radius server or some external database. It must be highlighted that the IP address supplied to the user in the first stage must belong to the same ISP's address block that will supply the service parameters, via the Radius server, during the second stage. However both stages must be synchronized, that is, the user that received the IP address block from a particular ISP, must not, at the second stage, be authenticated and consequently receive service parameters from another ISP. If a user has more than one ISP or a PC is shared by users which use different ISPs, in order to guarantee that both stages be synchronized, it is necessary that the DHCP be provisioned whenever there is an ISP switch to be used in the second stage. Also, knowing that no session is established between the user and the provider, some problems should be discussed: The user name and password are sent in clear text through the network, unless a secure web server is used. The user must explicitly inform the provider, via a web form or Similar, when it no longer is using his network IP address. Otherwise, the user's profile will remain stored at the provider until it is removed because of inactivity. If many users use the same web page to validate their data, it must be ensured that the Radius client used for requesting is scalable. On the other hand, the network can optionally, transmit or not the packets transparently between the user and the provider, and there is no need to install a client on the user's PC, since the login is performed via a web page. In addition to this, the absence of client software on the user PC means there is no need for installation kits and associated software support. The ISP selection steps for this model are the following: o The user powers on the PC and an IP address request is sent to the DHCP. Penno, et al. [Page 8] Internet-Draft ISP Selection March,2001 o Since the user's network card MAC address is not associated to any ISP, the DHCP will attribute a temporary private address [RFC1918] so the user can do the auto-provisioning. o The user then accesses a web form where he can select the ISP service package (QoS, VPN, etc) of his choice. o The user then submits this form to the system where this data is used to provision, via scripts or other method, a Radius server and the value added provider. o At the next login (after rebooting) or when the PC sends another DHCP request when the original (reserved) IP address expires, the user will receive an IP address from the ISP block, selected previously. o The user then accesses or is directed to the provisioning page, to enter the user name and password to be authenticated in a Radius server. In this case the Radius server supplies the provider with the user's data and services to be provided to the user. If the PC is shared by several subscribers, everytime a new subscriber wants to use the PC he has to go to the ISP Selection web page and enter his own username and password. Optionally the DHCP is reprovisioned and consequently the client PC has to change his IP address 7.1 Network Address Translation (NAT) There are some variations of the previous model, based on the use of NAT [RFC1631]. In essence, during the first stage the user receives a reserved address [RFC1918] or from the designated access provider block, and after authentication in the second stage, the provider (or an external device) performs the NAT between the address provided by the Radius server and the initial server. At first glance, these variations may have a certain appeal, but when appropriately analyzed, it is clear that these must be used very carefully due to the problems arising from the use of NAT. Amongst these problems we can highlight the following: Inverse consultations to DNS servers do not function correctly, which causes several security related problems and serial reuse of addresses. Users cannot use IPsec client on their PCs, since by definition address translation, is seen as a man-in the-middle-attack by the IPsec protocol. This means that, for example, employees which use these clients to connect to their companies and establish a virtual private network, will not be able to accomplish this via the CATV carrier's network. Penno, et al. [Page 9] Internet-Draft ISP Selection March,2001 H.323 [H.323] (Internetphone, Netmeeting, etc) based applications will not work adequately. H.323 is a complex protocol, which uses dynamic ports and includes several UDP flows. The addresses and ports negotiated between the participants in a multimedia session, are transmitted within the highest level data flow (payload) connection. For example, the H.245 connection address and port are negotiated within the data flow of protocol Q.931. This makes NAT particularly difficult, since it requires address modification within the data flow. Even worse, it is possible in the Q.931 protocol, for example, to request that an H.245 connection be encrypted, which makes the use of NAT unviable. The issues raised for the H.323 protocol are also trrue for the Session Initiation Protocol (SIP). The use of NAT requires an intense processing power, even with the help of an optimized checksum algorithm adjustment, since each data packet is subject to a search in the translation and modification table. In addition to the above mentioned problems, there also exist others related to QoS, routing tables trading, Secure DNS [RFC2535] as well as other popular applications, such as ICQ [ICQ]. Therefore NAT must only be considered very carefully. 8. L2TP Login In this model, there is a layer 2 session established between the L2TP Access Concentrator (LAC) and the L2TP Network Server (LNS). There is a PPP session carried within a layer 3 infrastructure, between the LAC and the LNS. In this case, a software running in the user's personal computer may act as a LAC and the IP Services Router can be the LNS. When a user wants to change from an ISP-A to an ISP-B, he only needs to close the L2TP session and reconnect to the LNS. This is quite similar to the PPP model, the user disconnects, closing the tunnel, and provide a different username and password, possibly changing the realms to perform the ISP selection (eg. user@isp-a.com would connect the user to the ISP-A and user@isp-b.com would connect the user to the ISP-B). This model permits users sharing the same PC to connect to different ISPs by reestablishing the L2TP tunnel, and providing different usernames and realms. This approach has the advantage to maintain the session concept when the only access network available is a layer 3 access network. The natural way of recognizing subscribers in layer 3 networks is through the source IP address. Penno, et al. [Page 10] Internet-Draft ISP Selection March,2001 Since the IP protocol is not session oriented, there are some inherent dificulties in determining the begining and the end of a session. The main disadvantage of L2TP, one may argue, is the overhead of carrying a layer 2 protocol over layer 3. It should be taken in consideration when choosing the network access method to the ISPs. Just like with PPPoE the ISP Selection could be accomplished through a web page that downloads a executable to the subscribers PC that terminated the current L2TP connection and initiates a new one with a new username and password to a different ISP. The PPTP model works just the same as the L2TP model just described. 9. IPSec The IPSec protocol does not have inherent methods of authentication based on username and password, but there is some proposed extensions, which set new authentication methods to be used in Phase 1 of the Internet Key Exchange (IKE), that allows the use of an username and password in order to establish the initial Security Association (SA) of the IPSec tunnel. One of the most known extensions is called "A Hybrid Authentication Mode for IKE" [1] and currently has the status of "work in progress" (draft). The dynamic of the IPSec has the concept of a session. The maintenance of Security Associations (SAs) requires continuous exchanges between the IPSec Hosts or Gateways (i.e. between the IPSec Client Software, running in the user's PC, and the IPSec Edge Device, the IPServices router), and the communication failure between devices denies any possibility of renewing SAs, dropping the tunnel. The username and password schema allows to perform ISP Selection based on realms or domains. The IPSec Client is very similar to the standard dial-up clients, the user can actually disconnect a session and establish another session, connecting to another ISP, if he wants to. The main objective of the IPSec authentication extension is to provide the option of having a secure tunnel through IP Networks to Telecommuters. The confidentiality requirement demands strong overhead and intense processing capabilities. The IPSec protocol is suitable for telecommuters, not for bulk use. 10. References [H.323] ITU-T Recommendation H.323 (02/98) - Packet-based multimedia communications systems Penno, et al. [Page 11] Internet-Draft ISP Selection March,2001 [ICQ] http://www.mirabilis.com [RFC1631] Egevang, K. and P. Francis, "The IP Network Address Translator (NAT)", RFC 1631, May 1994. [RFC2131] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC2661] A. Valencia, W. M. Townsley, W. Palter, et. al. "Layer Two Tunneling Protocol", RFC2661, August 1999. [DHCP-RECONF] P. De Schrijver, et al. "Dynamic host configuration: DHCP reconfigure extension ", draft-ietf-dhc-pv4-reconfigure-02.txt, November 2000, Work in progress. [NTS] http://www.nts.com [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994 [RFC2364] G. Gross et al, "PPP over AAL5", RFC 2364, July 1998 [RFC2516] Mamakos, et. al., "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999 [Litvin] M. Litvin, R. Shamir, T. Zegman, "A Hybrid Authentication Mode for IKE", draft-ietf-ipsec-isakmp-hybrid-auth-05.txt, work in progress. [PPPoE-Ext] R.Penno, "PPPoE Extensions For Seamless Service Selection", draft-penno-pppoe-ext-service-01.txt, work in progress. 11. Security Considerations All security to be considered in this document regards the access security, defined in other RFCs, and with the way the users handles their usernames and passwords. The Web Login method lies in the browser security too, improper cache handling, cookies and so forth could be used by malicious hackers in order to gain unauthorized access to the network. 12. Acknowledgments To be provided. Penno, et al. [Page 12] Internet-Draft ISP Selection March,2001 Author's Addresses Reinaldo Penno Nortel Networks, Inc. 2305 Mission College Boulevard Building SC9 Santa Clara, CA 95134 Email: rpenno@nortelnetworks.com Andre Gustavo de Albuquerque Nortel Networks, Inc. Av. Lauro Muller, 116 Torre do Rio Sul - Room 605 Rio de Janeiro, Brazil 22290-160 EMail: gustavoa@nortelnetworks.com Full Copyright Statement Copyright (C) The Internet Society (2000). 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.