Serial connections represent a form of legacy technology that has commonly been used for the support of Wide Area Network (WAN) transmissions. The transmission of data as electrical signals over a serial link again requires a form of signaling to control the sending and receiving of frames as found with Ethernet. Serial connections define two forms of signaling that may be used for synchronization of transmissions, known as Asynchronous and Synchronous communication. Asynchronous signaling works on the principle of sending additional bits referred to as start and stop bits with each byte or frame to allow the receiving node to be aware of the incoming frame, and thus periodically reset the timing between frames to ensure that the rates between transmission and reception are maintained. The start bit is always represented as a 0 bit value while the stop bit represents a 1 bit value. One of the main concerns with this signaling method is the additional overhead as a result for each frame delivered, with the start and stop bits representing a large percentage of the frame overall. This method however is commonly associated with technologies such as Asynchronous Transfer Mode (ATM), a form of cell switching technology that generates fixed sized frames (cells) of 53 bytes as a means of supporting lower jitter through minimizing queue processing times, making it ideal for real time communication such as voice, but has begun to make way for newer technologies such as MPLS switching and due to the loss of its advantage over the frame processing speeds that are now possible with routers and switches.
Synchronous serial connections rely on a clocking mechanism between the peering devices in which one side (DCE) provides the clocking to synchronize communication. This clocking is maintained through the carrying of clocking information between the sender and receiver as part of the data signal.
The High-level Data Link Control (HDLC) is a bit-oriented data link protocol that is capable of supporting both synchronous and asynchronous data transmissions. A complete HDLC frame consists of the Flag fields that are used to mark the start and end of a HDLC frame, often as 01111110, or 01111111 when a frame is to be suddenly aborted and discarded. An address field supports multipoint situations where one or multiple secondary terminals communicate with a primary terminal in a multipoint (multidrop) topology known as unbalanced connections, as opposed to the more commonly applied balanced (point to point) connections. The control field defines the frame type as either information, supervisory or unnumbered, and frame check sequence (FCS) field for ensuring the integrity of the frame.
Of the control field frame types, only the information frame type is supported by Huawei ARG3 series routers and is used to carry data. The information frame type carries send N(S) and receive N(R) sequence numbers, as well as Poll and Final bits (P/F) for communicating status between primary and secondary stations. Supervisory frame types in HDLC are used for error and flow control and unnumbered frame types are used to manage link establishment for example between primary and secondary stations.
Establishment of HDLC as the link layer protocol over serial connections requires simply that the link protocol be assigned using the link-protocol hdlc command under the interface view for the serial interface that is set to use the protocol. The configuration of the link protocol must be performed on both peering interfaces that are connected to the point-to-point network before communication can be achieved.
When an interface has no IP address, it cannot generate routes or forward packets. The IP address unnumbered mechanism allows an interface without an IP address to borrow an IP address from another interface. The IP address unnumbered mechanism effectively enables the conservation of IP addresses, and does not require that an interface occupy an exclusive IP address all of the time. It is recommended that the interface that is assigned as the interface from which the unnumbered IP address is borrowed be a loopback interface since this type of interface is more likely to be always active and as such supply an available address.
When using an unnumbered address, a static route or dynamic routing protocol should be configured so that the interface borrowing the IP address can generate a route between the devices. If a dynamic routing protocol is used, the length of the learned route mask must be longer than that of the lender's IP address mask, because ARG3 series routers use the longest match rule when searching for routes. If a static route is used and the IP address of the lender uses a 32-bit mask, the length of the static route mask must be shorter than 32 bits. If a static route is used and the IP address of the lender uses a mask less than 32 bits, the length of the static route mask must be longer than that of the lender's IP address mask.
Through the display ip interface brief command, a summary of the address assignment is output. In the event of assigning an unnumbered address, the address value will display as being present on multiple interfaces, showing that the IP address has been successfully borrowed from the logical loopback interface for use on the physical serial interface.
The Point-to-Point Protocol (PPP) is a data link layer protocol that encapsulates and transmits network layer packets over point-to-point (P2P) links. PPP supports point-to-point data transmission over full-duplex synchronous and asynchronous links.
PPP is built upon the Serial Line Internet Protocol (SLIP). PPP supports both synchronous and asynchronous links, whereas other data link layer protocols such as Frame Relay (FR) support only synchronous links. PPP is an extensible protocol, facilitating the extension of not only IP but also other protocols and is capable of supporting the negotiation of link layer attributes. PPP supports multiple Network Control Protocols (NCP) such as the IP Control Protocol (IPCP) and Internetwork Packet Exchange Control Protocol (IPXCP) to negotiate the different network layer attributes. PPP provides the Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP) for network security authentication. PPP has no retransmission mechanism, reducing the network cost and speeding up packet transmission.
PPP encapsulation provides for multiplexing of different network-layer protocols simultaneously over the same link however in today’s networks, the capability of PPP requires generally an IP only solution. The versatility of PPP to accommodate a variety of environments is well supported through Link Control Protocol (LCP). In order to establish communications over a point-to-point link, each end of the PPP link must first send LCP packets to configure and test the data link. More specifically LCP is used to negotiate and establish agreement for encapsulation format options, manage the MRU of packets, detect a looped-back link through magic numbers and determine errors in terms of parameter misconfigurations, as well as terminate an established link. Peer authentication on the link, and determination of when a link is functioning properly and when it is failing represent other optional facilities that are provided by LCP.
After the link has been established and optional facilities have been negotiated as required by the LCP component of PPP, NCP packets must then be sent to choose and configure one or more network-layer protocols. Typical IP based Network Control Protocols enable features such as address configuration (IPCP), and (van Jacobson) compressed TCP/IP.
This initiation and termination of a PPP link begins and ends with the dead phase. When two communicating devices detect that the physical link between them is activated (for example, carrier signals are detected on the physical link), PPP will transition from the Dead phase into the Establish phase. In the Establish phase, the two devices perform an LCP negotiation to negotiate the working mode as either single-link (SP) or multi-link (MP), the Maximum Receive Unit (MRU), authentication mode etc.
If the authentication mode is defined, the optional Authenticate phase will be initiated. PPP provides two password authentication modes: PAP authentication and CHAP authentication. Two CHAP authentication modes are available:unidirectional CHAP authentication and bidirectional CHAP authentication. In unidirectional CHAP authentication, the device on one end functions as the authenticating device, and the device on the other end functions as the authenticated device. In bidirectional CHAP authentication, each device functions as both the authenticating device and authenticated device. In practice however, only unidirectional CHAP authentication is used. Following successful authentication, the Network phase initiates, through which NCP negotiation is performed to select and configure a network protocol and to negotiate networklayer.
Parameters. Each NCP may be in an Opened or Closed state at any time. After an NCP enters the Opened state, network-layer data can be transmitted over the PPP link.
PPP can terminate a link at any time. A link can be terminated manually by an administrator, or be terminated due to the loss of carrier, an authentication failure, or other causes.
PPP generally adopts a HDLC like frame architecture for the transmission over serial connections. Flag fields are adopted to denote the start and the end of a PPP frame which is identifiable from the binary sequence 01111110 (0x7E). The address field, although present, is not applied to PPP as is the case with HDLC and therefore must always contain a 11111111 (0xFF) value, which represents an ‘AllStations’ address. The control field is also fixed with a value of 00000011 (0x03) representing the unnumbered information command.
The frame check sequence (FCS) is generally a 16 bit value used to maintain the integrity of the PPP frame. PPP additionally defines a 8 or 16 bit protocol field that identifies the datagram encapsulated in the Information field of the packet. Typical examples may include 0xc021 for Link Control Protocol, 0xc023 for Password Authentication Protocol, and 0xc223 for the Challenge Handshake Authentication Protocol. The Information field contains the datagram for the protocol specified in the Protocol field.
The maximum length for the Information field, (not including the Protocol field), is defined by the Maximum Receive Unit (MRU), which defaults to 1500 bytes. Where the value 0xc021 is implemented, communicating devices negotiate by exchanging LCP packets to establish a PPP link.
The LCP packet format carries a code type field that references various packet types during PPP negotiation, for which common examples include ConfigureRequest (0x01), Configure-Ack (0x02), Terminate-Request (0x05) etc. The Data field carries various supporting type/length/value (TLV) options for negotation, including MRU, authentication protocols etc.
As part of the LCP negotiation, a number of packet types are defined that enable parameters to be agreed upon before a PPP data link is established. It is necessary that the two communicating devices negotiate the link layer attributes such as the MRU and authentication mode. In order to achieve this, various packet types are communicated.
The Configure-Request packet type allows initiation of LCP negotiation between peering devices and must be transmitted at such times. Any Configure-Request packet type sent must be responded to, and may be done so through one of a number of response packet types. Where every configuration option received in a Configure-Request is recognizable and all values are acceptable, a Configure-Ack packet type will be transmitted.
Where all received configuration options in the Configure-Request packet type are recognized, but some values are not accepted, a Configure-Nak packet type will be transmitted, and contain only the unaccepted configuration options originally received in the Configure-Request packet type. A Configure-Reject is used when certain configuration options received in a Configure-Request are not recognizable, and thus are not accepted for negotiation.
Some of the common configuration options that are negotiated and carried as part of the LCP packet include the MRU, Authentication protocol supported by the sending peer as well as the magic number.
The magic number provides a method to detect looped-back links and other anomalies at the data link layer. In the case where a Configure-Request is received containing a Magic-Number as a configuration option, the received MagicNumber is used to compare multiple received Configure-Request messages sent to the peer by comparison of the Magic-Number. If the two Magic-Numbers of the received Configure-Request messages are different, then the link is understood to be a non-looped-back link for which a Request-Ack can be given in response. If the two Magic-Numbers are equal however, then a possibility exists that the link is looped-back and that further checking must be performed for this Configure-Request, and is done so by sending a Configure-Nak to effectively request a different Magic-Number value.
The sequence of events leading to the establishment of PPP between two peers is initiated by the sending of a Configure-Request packet to the peering device. Upon receiving this packet, the receiver must assess the configuration options to determine the packet format to respond with. In the event that all configuration options received are acceptable and recognized, the receiver will reply with a Configure-Ack packet.
Following the initial transmission of the Configure-Request as part of PPP negotiation, it is also possible that a Configure-Nak be returned, in particular where all configuration options are recognized, but some values are not accepted. On reception of the Configure-Nak packet a new Configure-Request is generated and sent, however the configuration options may generally be modified to the specifications in the received Configure-Nak packet.
Multiple instances of a configuration option may be specified by the ConfigureNak packet for which the peer is expected to select a single value to include in the next Configure-Request packet.
For PPP LCP negotiation in which one or multiple configuration options received in a Configure-Request are unrecognized or considered not acceptable for negotiation, a Configure-Reject packet is transmitted. Reception of a valid Configure-Reject indicates that when a new Configure-Request be sent, and any configuration options that are carried together with the Configure-Reject packet must be removed from the configuration options to be sent as part of the following Configure-Request packet.
Establishment of PPP requires that the link layer protocol on the serial interface be specified. For ARG3 series of routers, PPP is enabled by default on the serial interface. In the event where the interface is currently not supporting PPP, the linkprotocol ppp command is used to enable PPP at the data link layer. Confirmation of the change of encapsulation protocol will be prompted, for which approval should be given as demonstrated in the configuration example.
The Password Authentication Protocol (PAP) is a two-way handshake authentication protocol that transmits passwords in plain text. PAP authentication is performed during initial link establishment. After the Link Establishment phase is complete, the user name and password are repeatedly sent by the peer to the authenticator until authentication is acknowledged or the connection is terminated. PAP authentication effectively simulates login operations in which plain text passwords are used to establish access to a remote host. The authenticated device sends the local user name and password to the authenticator. The authenticator checks the user name and password of the authenticated device against a local user table and sends an appropriate response to the authenticated device to confirm or reject authentication.
The Challenge Handshake Authentication Protocol (CHAP), is used to periodically verify the identity of the peer using a three-way handshake. This is done upon initial link establishment, and can be repeated periodically. The distinguishing principle of CHAP lies in the protection given through avoiding transmission of any password over the link, instead relying on a challenge and response process that can only be successful if both authenticator and authenticated devices are supporting a value referred to as a secret. An algorithm such as MD5 is commonly used to hash any challenge and response, to ensure the integrity of the value and the resulting hash value, and is compared to a result generated by the authenticator. If both the response and value that is created by the authenticator match, the authenticated peer is approved.
The IP Control Protocol (IPCP) is responsible for configuring, enabling, and disabling the IP protocol modules on both ends of the point-to-point link. IPCP uses the same packet exchange mechanism as the Link Control Protocol (LCP). IPCP packets may not be exchanged until PPP has reached the Network phase. IPCP packets received before this phase is reached are expected to be silently discarded. The address negotiation configuration option provides a way to negotiate the IP address to be used on the local end of the link, for which a statically defined method allows the sender of the Configure-Request to state which IP-address is desired. Upon configuration of the IP address a ConfigureRequest message is sent containing the IP address requested to be used, followed by a Configure-Ack from the peering device to affirm that the IP address is accepted.
A local device operating as a client and needing to be assigned an IP address in the range of the remote device (server) must make a request for a valid address by applying the ip address-ppp negotiate command on the physical interface with which the client peers with the server. Through this method, a client can retrieve a valid address. This is applicable in scenarios such a where a client accesses the Internet through an Internet Server Provider (ISP) network, and through which it can obtain an IP address from the ISP. An address is proposed to the client upon receiving a configure request for which no IP address has been defined. The PPP server (RTB) will respond with a Configure-Nak which contains suggested IP address parameters for RTA. A follow up Configure-Request message with a change to the IP addressing enables the (NCP) IPCP to successfully establish network layer protocols.
The establishment of PAP authentication requires that one peer operate as the authenticator in order to authenticate an authenticated peer. The PPP PAP authenticator is expected to define the authentication mode, a local user name and password, and the service type. If a domain is defined to which the local user belongs (as defined by AAA), the authentication domain is also expected to be specified under the PAP authentication mode.
An authenticated peer requires that an authentication user name, and authentication password be specified in relation to the username and password set by the authenticator. The ppp pap local-user <username> password { cipher | simple } <password> command is configured on the authenticated device to achieve this.
Through debugging commands which provide a real-time output of events in relation to specific protocols, the authentication request process can be viewed. As displayed in the example, a PAP authentication request is performed to which authentication establishment is deemed successful.
In CHAP authentication, the authenticated device sends only the user name to the authenticating device. CHAP is understood to feature higher security since passwords are not transmitted over the link, instead relying on hashed values to provide challenges to the authenticated device based on the configured password value on both peering devices. In its simplest form, CHAP may be implemented based on local user assignments as with PAP, or may involve more stringent forms of authentication and accounting achieved through AAA and authentication/accounting servers.
As demonstrated, the configuration of CHAP based on locally defined users requires limited configuration of local user parameters and the enablement of PPP CHAP authentication mode on the authenticator device. Where domains exist, the authenticator may also be required to define the domain being used if different from the default domain.
Debugging of the CHAP authentication processes displays the stages involved with CHAP authentication, originating from listening on the interface for any challenges being received following the LCP negotiation. In the event that a challenge is sent, the authenticated device must provide a response for which a hash value is generated, involving the set authentication parameters on the authenticated peer (password), that the authenticator will promptly validate and provide a success or failure response to.
A Configure-Ack packet is required in order to allow the link layer to be successfully established when using PPP as the link layer encapsulation mode.
The Internet Protocol Control Protocol (IPCP) is used to negotiate the IP protocol modules as part of the NCP negotiation process. This occurs during the Network phase of PPP establishment.