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.
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.