Security considerations for using point-to-point protocol

Point-to-point protocol (PPP) is available as part of TCP/IP.

PPP is an industry standard for point-to-point connections that provides additional function over what is available with SLIP. With PPP, your iSeries™ server can have high-speed connections directly to an Internet Service Provider or to other systems in an intranet or extranet. Remote LANs can realistically make dial-in connections to your iSeries server.

Remember that PPP, like SLIP, provides a network connection to your iSeries server. A PPP connection essentially brings the requester to your system’s door. The requester still needs a user ID and password to enter your system and connect to a TCP/IP server like TELNET or FTP. Following are security considerations with this new connection capability:

Note: You configure PPP by using iSeries Navigator on an IBM^® iSeries Access for Windows^® workstation.

PPP provides the ability to have dedicated connections (where the same user always has the same IP address). With a dedicated address, you have the potential for IP spoofing (an imposter system that pretends to be a trusted system with a known IP address). However, the enhanced authentication capabilities that PPP provides help protect against IP spoofing.
With PPP, as with SLIP, you create connection profiles that have a user name and an associated password. However, unlike SLIP, the user does not need to have a valid user profile and password. The user name and password are not associated with a user profile. Instead, validation lists are used for PPP authentication. Additionally, PPP does not require a connection script. The authentication (exchange of user name and password) is part of the PPP architecture and happens at a lower level than with SLIP.
With PPP, you have the option to use CHAP (challenge handshake authentication protocol). You will no longer need to worry about an eavesdropper sniffing passwords because CHAP encrypts user names and passwords.
Your PPP connection uses CHAP only if both sides have CHAP support. During the exchange signals to set up communications between two modems, the two systems negotiate. For example, if SYSTEMA supports CHAP and SYSTEMB does not, SYSTEMA can either deny the session or agree to use an unencrypted user name and password. Agreeing to use an unencrypted user name and password is referred to as negotiating down.

The decision to negotiate down is a configuration option. On your intranet, for example, where you know that all your systems have CHAP capability, you should configure your connection profile so that it will not negotiate down. On a public connection where your system is dialing out, you might be willing to negotiate down. The connection profile for PPP provides the ability to specify valid IP addresses. You can, for example, indicate that you expect a specific address or range of addresses for a specific user.

This capability, together with the ability for encrypted passwords, provides further protection against spoofing. As additional protection against spoofing or piggy-backing on an active session, you can configure PPP to rechallenge at designated intervals. For example, while a PPP session is active, your iSeries server might challenge the other system for a user and password. It does this every 15 minutes to ensure that `it is the same connection profile.

The end-user will not be aware of this rechallenge activity. The systems exchange names and passwords below the level that the end-user sees. With PPP, it is realistic to expect that remote LANs might establish a dial-in connection to your iSeries server and to your extended network. In this environment, having IP forwarding turned on is probably a requirement. IP forwarding has the potential to allow an intruder to roam through your network. However, PPP has stronger protections (such as encryption of passwords and IP address validation). This makes it less likely that an intruder can establish a network connection in the first place.