Point to Point Protocol (PPP)
Introduction
PPP is based on the High-Level Data link Control (HDLC) protocol and provides a standard
for sending data over DTE and DCE interfaces such as V.35, T1, E1, HSSI, EIA-232-D, EIA-449.
It replaces Serial Line Internet Protocol (SLIP) which uses a variation of TCP/IP
and is not as complicated.
PPP allows multiple protocols per line, error detection, header compression, compression
and multilinks. PPP has two components:
- Link Control Protocol (LCP): LCP
(RFC 1570 describes LCP extensions)
opens, configures and terminates the link.
Additionally, Link Quality Monitoring (LQM) can be configured along with Password Authentication
Protocol (PAP) or Challenge Handshake Authentication Protocol (CHAP).
- Network Control Protocol (NCP): NCP opens, configures and terminates network
layer protocol communication e.g. IP, IPX, AppleTalk and DECnet.
Both LCP and NCP operate at Layer 2.
There is an extension to PPP to cater for multiple links and this is called Multilink
PPP (MPPP) and uses Multilink Protocol (MLP) to link the LCP and NCP layers.
RFC 1661 describes PPP in general.
Frame Format
The PPP frame format is detailed below:
There are five phases for a PPP link:
- Dead:
- Establish: Initialises LCP and when Configure ACK is received we move to...
- Authenticate: Optional use of PAP or CHAP.
- Network: Supported Network Layer protocols are brought up and data transfer starts.
- Terminate:
Piggyback routing can be used, where routing information is cached and only sent when the link is up.
In the LCP packet (contained within the Information field of the PPP packet), the Code field
will identify the packet as a Configure Request (1), Configure Ack (2), Configure Nak (3) meaning
unacceptable and Configure Reject (4).
There is an NCP code for each protocol, and these are identified in the protocol field of the
NCP packet as shown below:
| Code |
Protocol |
| 8021 |
IP |
| 8029 |
AT |
| 8025 |
XNS, Vines |
| 8027 |
DECnet |
| 8031 |
Bridge |
| 8023 |
OSI |
RFC 1662 describes the HDLC-like framing
and RFC 1549 describes PPP in HDLC framing.
Authentication
Password Authentication Protocol (PAP)
At the LCP phase, when a PPP connection is requested by the client and PAP is being used, the access server tells the client to use PAP.
The client then sends a username and a password, both of which are in clear text within the PPP packet. The server then decides whether
to accept or reject the connection. This is One-way PAP between a client and a server. If two routers are talking to each other
then Two-way PAP is used where each router sends its username and password, and each router authenticates each other.
Challenge Handshake Protocol (CHAP)
CHAP is more commonly used rather than PAP, since it encrypts the password as well as the data.
Each end of the link share the same CHAP secret and each end is given its own
local name.
- A caller A dials in to an access server B.
- The Access server sends across the link an initial Type 1 authentication packet
called a Challenge. This Challenge packet contains a randomly generated number, an ID sequence number
to identify the challenge and the authentication name of the challenger.
- The caller takes the authentication name and looks up the CHAP secret associated with that name.
- The caller feeds the CHAP secret, the ID sequence number and the randomly generated number into the Message
Digest 5 (MD5) hashing algorithm.
- The resultant hashed value is sent back to the Challenger (the Access server) in a CHAP Response packet (Type 2)
which contains the hash, the authentication name of the caller and the ID (Sequence Number) copied from the Challenge packet.
- On receipt of the Type 2 Response packet, the Challenger uses the ID to find the original Challenge packet.
- The caller username (A) is used to look up the CHAP secret from a local database, a RADIUS or a TACACS+ server.
- The ID, the original Challenge random value and the CHAP secret are fed into the MD5 hash generator.
- The resultant hashed value is then compared with the value sent in the Response packet.
- If they are the same, then CHAP authentication has been successful and Type 3 packets are sent to the caller
containing the ID. This means that the authenticated link is 'legal'.
- On CHAP authentication failure, a Type 4 packet is sent to the caller containing the original ID,
this indicates that the authentication is incorrect.
Hashing is different from encryption as it is not reversible, like a grinder!
In Nortel Networks routers Code C223 indicates a CHAP operation.
RFC 1994 describes CHAP in detail whereas
RFC 1334 describes Authentication Protocols.
PPP Callback
Callback is useful for minimising costs and security. The processes that occur are as follows:
- Initiation of call by client. The client requests callback as one of the options
during the LCP negotiation phase (The Callback Option Message Field defined in
RFC 1570).
- Callback request is acknowledgement by server and it checks its configuration to
see if it is allowed.
- User authentication occurs and the client username is used in the dialer map
to identify the dial string to be used in the return call.
- If authentication is successful but there is no callback option
then the call continues and the client pays for the call, otherwise
the call is disconnected by server.
- Client called by the server using the dial string.
- Authentication occurs again.
- The connection continues.
Ideally, for maximum security the call back should occur on a different modem
at the server end from the line used by the incoming call. When using
ISDN callback uses the D-channel which incurs no charge at all, whereas callback
using modems will always incur a small charge whilst the authentication process occurs.
Link Quality Monitoring (LQM)
This may only be implemented on standard synchronous links. Link quality is based on
the percentage of successfully transmitted or received frames within a reported period. These
Link Quality Reports (LQR) have counters which determine inbound and outbound link quality.
Echo Requests are also periodically sent, if, after a certain number of echo requests, there
have been no echo replies, then the NCPs are terminated.
RFC 1333 describes Link Quality Monitoring.
Compression
Software compression can come in the form of utilities such as Wellfleet Compression Protocol (WCP) (as used in
Nortel Networks routers) and
is best used on slow links (128Kb/s or less). The Lempel-Ziv (LZS) ( RFC 1974) algorithm provides
fast data compression and decompression. This is used by STAC compression and you will find it used on PPP, ISDN and Frame Relay.
In addition, PKZIP uses the deflate algorithm so you obtain no benefit from sending ZIP files down an already compressed link, in fact
there will a slight increase in packet size. The algorithm works by by first searching for redundant data strings, then replacing these with
tokens. A dictionary of these tokens is built up at each end of the link.
Although all layer 3 data (IPCP and IPXCP) is subject to compression, Layer 2 LCP and NCP traffic is exempt. WCP
compression can only occur between two Nortel routers as the WCP puts a protocol value in the
protocol field that is proprietory to Nortel Networks.
A history buffer works at both ends to match strings of data being sent and received, so if
a match in the transmission end buffer is found, then the offset and length of the data is
sent instead of the actual data itself. The receiving end appropriately places the matched
data into the incoming message and so this minimises data transmission.
Nortel have two compression modes available:
- Continuous Packet Compression: The history buffer spans multiple packets, which
means more memory is used up, but produces greater compression ratio.
- Packet-by-Packet Compression: The history buffer is reset with each packet, which
means less memory is used but the compression ratio is not as great.
Cisco, on the other hand use their own two forms of compression:
- Stacker - which examines the data and only sends each data type once and sends
information indicating to the other end where each type occurs within the data stream.
The other end reassembles the data into the various data types from the data stream. Stacker tends to be
more CPU intensive and less memory intensive.
- Predictor - examines the data to see if it is already compressed and sends it. It does
not waste time compressing data that is already compressed. Predictor tends to be more memory intensive
and less CPU intensive.
Compressing data that is already compressed adds a little overhead to the frames so in fact the data exapnds
slightly purely due to the header. In addition, applying compression unnecessarily adds CPU processing which
is not required.
Multilink PPP Interleaving
LCP has a number of options, one of which is multilink with interleaving.
For multilink PPP to work, PPP packets can be fragmented and marked with sequence numbers so that
large packets can be split across a number of PPP links. This is built in to the PPP specifications
in RFC 1717 and happens to be useful for
real time data traffic such as voice even if you are using PPP as the transport across just
one link.
A large data frame is split up into smaller fragments, each one having a small header with its own
sequence number. Small Real time data packets are not fragmented and remain as 'naked' PPP.
The receptor of these fragmented packets needs to utilise a queue that can hold the fragments
long enough to be able to re-order them and reform the large data frame. A separate queue is set
aside for the sensitive real time data packets. This queue can be dealt with more quickly than
the others.
Multilink PPP (MPPP or MP)
MPPP provides load balancing over a number of interfaces of varying sorts, synchronous, asychronous
and ISDN.
Multilink PPP uses Bandwidth Allocation Protocol (BAP & BACP)
( RFC 2125) to dynamically
change the number of bearer channels (of various sorts if you want)
being used for a connection depending on the current demand requirement. These separate
channels are treated as one logical channel, or bundle, and upper layer PDUs are
segmented and reassembled.
The PPP frame has an 4 byte sequencing header for PPP multilink which is used when datagrams
are split and sequenced to travel across the multiple links. During LCP negotiation
a peer that is wanting to multilink, sends a Maximum Received Reconstructed Unit (MRRU)
during LCP negotiation, that defines the size of the pipe or bundle. The username is used to determine which bundle to add
a particular link to.
Multichassis Multilink PPP is an extension of Multilink PPP where the various
bearer channels can come from a number of separate devices rather than just one.
RFC 1717 describes PPP Multilink Protocol
and has more recently been superceded by RFC 1990
The following RFCs provide more detail on PPP:
- RFC 1332 describes IP over PPP (IPCP).
- RFC 1877 describes IPCP Extensions for DNS and NetBIOS.
- RFC 1378 describes AppleTalk ATCP.
- RFC 1552 describes IPXCP.
- RFC 1220 describes Bridging on PPP.
- RFC 1638 describes Bridging Control Protocol (BCP).
- RFC 1762 describes DECnet IV (DNCP).
- RFC 1763 describes Banyan Vines (BNCP).
- RFC 1764 describes XNS (XNSCP).
- RFC 1492 describes Access Control Protocol or TACACS.
|
