Authenticators and Authenticatees

The calling machine on a PPP link is considered the authenticatee because it must prove its identity to the remote peer. The peer is considered the authenticator. The authenticator looks up the caller's identity in the appropriate PPP files for the security protocol and authenticates or does not authenticate the caller.

You typically configure PPP authentication for a dial-up link. When the call begins, the dial-out machine is the authenticatee. The dial-in server is the authenticator. The server has a database in the form of a secrets file, which lists all users who are granted permission to set up a PPP link to the server. Think of these users as trusted callers.

Some dial-out machines require remote peers to provide authentication information when responding to the dial-out machine's call. Then their roles are reversed: the remote peer becomes the authenticatee and the dial-out machine the authenticator.

Note - PPP 4.0 does not prevent authentication by leased-line peers, but it is not often used. The nature of leased-line contracts usually means that both participants on the ends of the line are known to each other and often are trusted. However, because PPP authentication is not that difficult to administer, you should seriously consider implementing authentication for leased lines.

PPP Authentication Protocols

The PPP authentication protocols are Password Authentication Protocol (PAP) and Challenge-Handshake Authentication Protocol (CHAP). Each protocol uses a secrets database that contains identification information, or security credentials, for each caller that is permitted to link to the local machine. For a detailed explanation of PAP, see "Password Authentication Protocol (PAP)". For a CHAP explanation, see "Challenge-Handshake Authentication Protocol (CHAP)".

Why Use PPP Authentication?

Providing authentication on a PPP link is optional. Moreover, though authentication does verify that a peer is to be trusted, it does not provide confidentiality of data. For confidentiality, use encryption software, such as IPsec, PGP, SSL, and the Solaris secure shell.

Note - Solaris PPP 4.0 does not implement the PPP Encryption Control Protocol (ECP) that is described in RFC 1968.

Consider implementing PPP authentication in the following situations:

Your company accepts incoming calls from users over the public, switched telephone network.
Your corporate security policy requires remote users to provide authentication credentials when accessing your network through a corporate firewall or when engaging in secure transactions.
You want to authenticate callers against a standard UNIX password database (/etc/passwd, NIS, NIS+, LDAP, or PAM). Use PAP authentication for this scenario.
Your company's dial-in servers also provide the network's Internet connection. Use PAP authentication for this scenario.
The serial line is less secure than the password database on the machine or networks at either end of the link. Use CHAP authentication for this scenario.

Support for DSL Users Through PPPoE

Many network providers and individuals who are working at home use Digital Subscriber Line (DSL) technology to provide fast network access. To support DSL users, Solaris PPP 4.0 includes the PPP over Ethernet (PPPoE) feature. PPPoE technology enables multiple hosts to run PPP sessions over one Ethernet link to one or more destinations.

If one of the following factors apply to your situation, you should use PPPoE:

You support DSL users, possibly including yourself. Your DSL service provider might require users to configure a PPPoE tunnel to receive services over the DSL line.
Your site is an ISP that intends to offer PPPoE to customers.

This section introduces terms that are associated with PPPoE and an overview of a basic PPPoE topology.

PPPoE Overview

PPPoE is a proprietary protocol from RedBack Networks. PPPoE is a discovery protocol, rather than another version of standard PPP. In a PPPoE scenario, a machine that initiates PPP communications first must locate, or discover, a peer that runs PPPoE. The PPPoE protocol uses Ethernet broadcast packets to locate the peer.

After the discovery process, PPPoE sets up an Ethernet-based tunnel from the initiating host, or PPPoE client, to the peer, the PPPoE access server.Tunneling is the practice of running one protocol on top of another protocol that normally occupies a higher or the same position on the TCP/IP protocol stack. Using PPPoE, Solaris PPP 4.0 tunnels PPP over Ethernet IEEE 802.2, both of which are data link protocols. The resulting PPP connection behaves like a dedicated link between the PPPoE client and the access server. For detailed information about PPPoE, see "Creating PPPoE Tunnels for DSL Support".

Parts of a PPPoE Configuration

Three participants are involved in a PPPoE configuration: a consumer, a telephone company, and a service provider, as the following figure shows.

Figure 29-4 Participants in a PPPoE Tunnel

PPPoE Consumers

As system administrator, you might assist consumers with their PPPoE configurations. One common type of PPPoE consumer is an individual who needs to run PPPoE over a DSL line. Another PPPoE consumer is a company that purchases a DSL line through which employees can run PPPoE tunnels, as illustrated in the previous figure.

The main reason for a corporate consumer to use PPPoE is to offer PPP communications through a high-speed DSL device to a number of hosts. Often a single PPPoE client has an individual DSL modem. Or, a group of clients that are connected to a hub might share a DSL modem that is also connected to the hub by an Ethernet line.

Note - DSL devices are technically bridges, not modems. However, because common practice is to refer to these devices as modems, this guide uses the term "DSL modem."

When PPPoE runs, it runs PPP over a tunnel on the Ethernet line that is connected to the DSL modem. That line is connected to a splitter, which, in turn connects to a telephone line.

PPPoE at a Telephone Company

The telephone company is the middle layer of the PPPoE scenario. The telephone company splits the signal that is received over the phone line by using a device that is called a Digital Subscriber Line Access Multiplexer (DSLAM). The DSLAM breaks out the signals onto separate wires, analog wires for telephone service, and digital wires for PPPoE. From the DSLAM, the digital wires extend the tunnel over an ATM data network to the ISP.

PPPoE at a Service Provider

The ISP receives the PPPoE transmission from the ATM data network over a bridge. At the ISP, an access server that runs PPPoE functions as the peer for the PPP link. The access server is very similar in function to the dial-in server that was introduced in Figure 29-2, but the access server does not use modems. The access server converts the individual PPPoE sessions into regular IP traffic, for example Internet access.

If you are a system administrator for an ISP, you might be responsible for configuring and maintaining an access server.

Security on a PPPoE Tunnel

The PPPoE tunnel is inherently insecure. You can use PAP or CHAP to provide user authentication for the PPP link that is running over the tunnel.


	Authenticators and Authenticatees The calling machine on a PPP link is considered the authenticatee because it must prove its identity to the remote peer. The peer is considered the authenticator. The authenticator looks up the caller's identity in the appropriate PPP files for the security protocol and authenticates or does not authenticate the caller. You typically configure PPP authentication for a dial-up link. When the call begins, the dial-out machine is the authenticatee. The dial-in server is the authenticator. The server has a database in the form of a secrets file, which lists all users who are granted permission to set up a PPP link to the server. Think of these users as trusted callers. Some dial-out machines require remote peers to provide authentication information when responding to the dial-out machine's call. Then their roles are reversed: the remote peer becomes the authenticatee and the dial-out machine the authenticator. Note - PPP 4.0 does not prevent authentication by leased-line peers, but it is not often used. The nature of leased-line contracts usually means that both participants on the ends of the line are known to each other and often are trusted. However, because PPP authentication is not that difficult to administer, you should seriously consider implementing authentication for leased lines. PPP Authentication Protocols The PPP authentication protocols are Password Authentication Protocol (PAP) and Challenge-Handshake Authentication Protocol (CHAP). Each protocol uses a secrets database that contains identification information, or security credentials, for each caller that is permitted to link to the local machine. For a detailed explanation of PAP, see "Password Authentication Protocol (PAP)". For a CHAP explanation, see "Challenge-Handshake Authentication Protocol (CHAP)". Why Use PPP Authentication? Providing authentication on a PPP link is optional. Moreover, though authentication does verify that a peer is to be trusted, it does not provide confidentiality of data. For confidentiality, use encryption software, such as IPsec, PGP, SSL, and the Solaris secure shell. Note - Solaris PPP 4.0 does not implement the PPP Encryption Control Protocol (ECP) that is described in RFC 1968. Consider implementing PPP authentication in the following situations: Your company accepts incoming calls from users over the public, switched telephone network. Your corporate security policy requires remote users to provide authentication credentials when accessing your network through a corporate firewall or when engaging in secure transactions. You want to authenticate callers against a standard UNIX password database (`/etc/passwd`, NIS, NIS+, LDAP, or PAM). Use PAP authentication for this scenario. Your company's dial-in servers also provide the network's Internet connection. Use PAP authentication for this scenario. The serial line is less secure than the password database on the machine or networks at either end of the link. Use CHAP authentication for this scenario. Support for DSL Users Through PPPoE Many network providers and individuals who are working at home use Digital Subscriber Line (DSL) technology to provide fast network access. To support DSL users, Solaris PPP 4.0 includes the PPP over Ethernet (PPPoE) feature. PPPoE technology enables multiple hosts to run PPP sessions over one Ethernet link to one or more destinations. If one of the following factors apply to your situation, you should use PPPoE: You support DSL users, possibly including yourself. Your DSL service provider might require users to configure a PPPoE tunnel to receive services over the DSL line. Your site is an ISP that intends to offer PPPoE to customers. This section introduces terms that are associated with PPPoE and an overview of a basic PPPoE topology. PPPoE Overview PPPoE is a proprietary protocol from RedBack Networks. PPPoE is a discovery protocol, rather than another version of standard PPP. In a PPPoE scenario, a machine that initiates PPP communications first must locate, or discover, a peer that runs PPPoE. The PPPoE protocol uses Ethernet broadcast packets to locate the peer. After the discovery process, PPPoE sets up an Ethernet-based tunnel from the initiating host, or PPPoE client, to the peer, the PPPoE access server.Tunneling is the practice of running one protocol on top of another protocol that normally occupies a higher or the same position on the TCP/IP protocol stack. Using PPPoE, Solaris PPP 4.0 tunnels PPP over Ethernet IEEE 802.2, both of which are data link protocols. The resulting PPP connection behaves like a dedicated link between the PPPoE client and the access server. For detailed information about PPPoE, see "Creating PPPoE Tunnels for DSL Support". Parts of a PPPoE Configuration Three participants are involved in a PPPoE configuration: a consumer, a telephone company, and a service provider, as the following figure shows. Figure 29-4 Participants in a PPPoE Tunnel PPPoE Consumers As system administrator, you might assist consumers with their PPPoE configurations. One common type of PPPoE consumer is an individual who needs to run PPPoE over a DSL line. Another PPPoE consumer is a company that purchases a DSL line through which employees can run PPPoE tunnels, as illustrated in the previous figure. The main reason for a corporate consumer to use PPPoE is to offer PPP communications through a high-speed DSL device to a number of hosts. Often a single PPPoE client has an individual DSL modem. Or, a group of clients that are connected to a hub might share a DSL modem that is also connected to the hub by an Ethernet line. Note - DSL devices are technically bridges, not modems. However, because common practice is to refer to these devices as modems, this guide uses the term "DSL modem." When PPPoE runs, it runs PPP over a tunnel on the Ethernet line that is connected to the DSL modem. That line is connected to a splitter, which, in turn connects to a telephone line. PPPoE at a Telephone Company The telephone company is the middle layer of the PPPoE scenario. The telephone company splits the signal that is received over the phone line by using a device that is called a Digital Subscriber Line Access Multiplexer (DSLAM). The DSLAM breaks out the signals onto separate wires, analog wires for telephone service, and digital wires for PPPoE. From the DSLAM, the digital wires extend the tunnel over an ATM data network to the ISP. PPPoE at a Service Provider The ISP receives the PPPoE transmission from the ATM data network over a bridge. At the ISP, an access server that runs PPPoE functions as the peer for the PPP link. The access server is very similar in function to the dial-in server that was introduced in Figure 29-2, but the access server does not use modems. The access server converts the individual PPPoE sessions into regular IP traffic, for example Internet access. If you are a system administrator for an ISP, you might be responsible for configuring and maintaining an access server. Security on a PPPoE Tunnel The PPPoE tunnel is inherently insecure. You can use PAP or CHAP to provide user authentication for the PPP link that is running over the tunnel.