Ethereal Exercise 2 (Part A): Link Control Protocol

Course: Semester: ELE437 Ethereal Exercise 2 (Part A): Link Control Protocol Introduction In this exercise some details at the data link layer will be examined. In particular, the Link Control Protocol (LCP) used with the Point-to-Point Protocol (PPP) will be examined. By looking at a capture of the establishment of a dial-up Internet connection, it s possible to see what LCP packets are used to establish a link, authenticate the client, and set up the connection to use IP packets at the network layer. At the end, you ll also see what is done to terminate the connection. PPP and LCP are presented on pages 238-242 of the Tanenbaum textbook. The connection establishment, use, and termination process is shown in Figure 3-28 on page 241 of the textbook. Several of the LCP packet types used in this paper are described on pages 241-242. Background Information When establishing a dial-up connection, a physical link must first be established. This is the time period that you ll typically hear the modem making a variety of irritating sounds. First, the communication speed must be agreed upon. The modem will initially attempt to connect to the remote device at its maximum speed. If no response to this request is received, or it is received but is corrupt, then the modem will fall back on the next highest speed setting. This fallback process repeats until a speed is agreed on or there are no speeds left to try. If there are no speeds left, the connection attempt is abandoned. If a speed is agreed on, compression and error correction schemes are agreed upon for use at the physical layer. After this, the exchange of LCP packets begins. While LCP packets are actually handled at the link layer, the capture file used in this exercise shows Ethernet II as the link layer protocol, and then the LCP packets at the next layer up. This is due to Microsoft s Network Monitor, which is where Ethereal is getting the captured network activity from. The most significant result of this in terms of packet analysis is that you cannot see the actual PPP packets or framing. This means that the information on the PPP frame format from the textbook will not be used in this exercise. 1

Figure 1: SEND Address in the Ethernet II Header If you look in Figure 1 above, you ll notice that the Ethernet II data has been selected in one of the LCP packets. If you look at the raw data pane (bottom) then you ll also notice that the word SEND appears twice at the beginning of the packet. This is where the source and destination MAC addresses would normally be. However, since it was already pointed out that these aren t really Ethernet packets, that would suggest that the addresses aren t real either. While they aren t MAC addresses, when the characters for the address spell out SEND it means that the selected packet was sent by the client. Similarly, when the characters RECV appear, it means that the selected packet was received from the server. You will need to keep this in mind when you look at the capture file yourself. Section 1: LCP Packet Format Before the dial-up connection can be used to connect to the Internet, packets must be sent between the client and the dial-up server to set up a link. Let s take a look at the general LCP packet format, shown in Table 1 below. Table 1: LCP Packet Format Byte Offset 0 1 2 4 Field Size (Bytes) 1 1 2 Length - 4 Field LCP Packet Code Packet ID Length Payload / Data The first field, LCP Packet Code, is used to specify what type of LCP packet this is. This code will determine how the packet recipient will interpret its contents. A list of all valid LCP Packet Codes is listed in Table 2 below. 2

Table 2: LCP Packet Types LCP Packet Code Packet Type 1 Configure-Request 2 Configure-Ack 3 Configure-Nak 4 Configure-Reject 5 Terminate-Request 6 Terminate-Ack 7 Code-Reject 8 Protocol-Reject 9 Echo-Request 10 Echo-Reply 11 Discard-Request 12 Identification 13 Time-Remaining Several of these packet types will be used during this exercise. The second field, Packet ID, is used to distinguish the current packet from other LCP packets with the same Packet Code. The packet ID values will not be important in this exercise. The third field, Length, specifies the number of bytes in the current LCP packet. This length includes the 4 header bytes (consisting of the first three fields) plus the number of payload (data) bytes in the packet. Now that you have a basic understanding of the packet format, let s look at a specific example. Section 2: Configuration Request Packets Initially, the format of the LCP packets is fixed to ensure that the client and server can communicate. However, this packet format may have unused or oversized fields that would be noticeable overhead over a dial-up connection. We all know that dial-up is slow, so anything that might make it even slower should definitely be avoided. To reduce overhead and ensure that the client and server can communicate with one another, both the client and server send Configuration Request packets to one another. The format of Configuration Request packets is given in Table 3 on the next page. 3

Table 3: Configuration Request Format Byte Offset 0 1 2 4 Field Size (Bytes) 1 1 2 Length - 4 Field 0x01 Packet ID Length Configuration Options In this case, the LCP Packet Code in the first field is 1 (or 0x01 in hexadecimal), which corresponds to the Configure-Request packet type. The Packet ID can be ignored and the Length field is defined the same way as described in Section 1. For the last field, look at the Configuration Option format in Table 4 below. Table 4: Configuration Option Format Byte Offset 0 1 2 Field Size (Bytes) 1 1 Length - 2 Field Name Option ID Length Option Data Any number of Configuration Options can be in the Configuration Request packet. For each Configuration Option, the Option ID specifies a particular option that the sender wishes to agree upon with the packet s recipient. A list of valid Option IDs is in Table 5 below. Table 5: Configuration Option IDs Option ID number Decimal Hexadecimal Option Name 1 0x01 Maximum-Receive-Unit (MRU) 2 0x02 Async-Control-Character-Map 3 0x03 Authentication-Protocol 4 0x04 Quality-Protocol 5 0x05 Magic-Number 6 0x06 RESERVED 7 0x07 Protocol-Field-Compression 8 0x08 Address-and-Control-Field-Compression 9 0x09 FCS-Alternatives 10 0x0A Self-Describing-Pad 11 0x0B Numbered-Mode 12 0x0C Multi-Link-Procedure 13 0x0D Callback 14 0x0E Connect-Time 15 0x0F Compound-Frames 16 0x10 Nominal-Data-Encapsulation 17 0x11 Multilink-MRRU 18 0x12 Multilink-Short-Sequence-Number-Header-Format 19 0x13 Multilink-Endpoint-Discriminator 4

Option ID numbers 1 (MRU) and 3 (Authentication-Protocol) will be the most important for this exercise, although a few others including 2, 7, 8, 13, and 17 are also used. For additional information on each of the different Configuration Options, read the RFC 1548 selections provided on pages 9-13 of this handout. Section 3: Configuration Reject and Configuration Ack Packets When the configuration request contains one or more configuration options that are unrecognizable to the receiving party, it must send a Configure-Reject (LCP type 4) packet to the sender. The format of the Configure-Reject packet is the same as the Configure-Request, but instead of including desired configuration options the rejected configuration options are included. When a Configure-Reject packet is received, it can be examined to find out which configuration options were rejected. A new Configure- Request can then be transmitted with alternative configuration options that the receiver might accept. This Request-Reject procedure is repeated until a Configure-Ack packet is received. A Configuration Acknowledgement packet (Configure-Ack, LCP type 2) indicates that the client and server have agreed on how to communicate with one another. The format of the Configure-Ack packet is the same as the Configure-Request packet with the exception of the LCP type code (2 for Configure-Ack, 1 for Configure-Request). The configuration options accepted from the last Configure-Request are simply copied into the Options field in the Configure-Ack packet. Note that the options might not be copied into the Ack packet in the same order as they were originally received. Section 4: Preview of Exercise 2, Part B Once the connection configuration has been completed, as done in Sections 2 and 3, it is often necessary for the server to authenticate the client. In part B of this exercise, authentication is necessary for the client to inform the server that they have a valid user name and password. Once this information has been verified, the connection can be used with network layer protocols including IP. When done using the connection, it needs to be terminated. As a preview of Part B of this exercise, you may want to take a look at http://www.ietf.org/rfc/rfc1994.txt, the RFC on CHAP. You will not be asked any questions about the security mechanisms used by CHAP, but you will be asked about the protocol s basic operation. If you re interested in the security aspect, an example of a similar protocol is provided in section 8.7.1 of the textbook, on pages 786-790. You may also visit the ELE437 course web site for links to other information. Searching for information on IPCP and CCP online should also be helpful. 5

Questions 1) Which configuration options, if any, were rejected by the a. Client b. Server (Dial-up router) 2) Which configuration options, if any, replaced the options rejected by the a. Client b. Server (Dial-up Router) 3) In packet #3, a. What does the value 04 at byte offset 000E in the raw pane represent? b. At what byte offset in the raw pane is the LCP packet length located? c. How many bytes are used to represent the LCP packet length? d. Why isn t the length value 17 since there are only 17 bytes used in the Options field? 4) For authentication of the client, a. What protocol does the server request that the client to use? b. What is the PPP protocol ID number assigned to this protocol? (Hint: Look at both the capture file and the PPP Packet Encapsulation information on pages 7 and 8) c. What algorithm is used? Grading - 14 points - The questions have the following point values: 1) 4 points (2 for each) 2) 2 points (1 for each) 3) 5 points (1 for a-c, 2 for d) 4) 3 points (1 for each) 6

PPP Packet Encapsulation and Protocol ID Numbers Selection from RFC 1548 (http://www.networksorcery.com/enp/rfc/rfc1548.txt) 2. PPP Encapsulation The PPP encapsulation is used to disambiguate multiprotocol datagrams. This encapsulation requires framing to indicate the beginning and end of the encapsulation. Methods of providing framing are specified in companion documents. A summary of the PPP encapsulation is shown below. The fields are transmitted from left to right. Protocol Field +----------+-------------+---------+ Protocol Information Padding 16 bits * * +----------+-------------+---------+ The Protocol field is two octets and its value identifies the datagram encapsulated in the Information field of the packet. The field is transmitted and received most significant octet first. The structure of this field is consistent with the ISO 3309 extension mechanism for address fields. All Protocols MUST be odd; the least significant bit of the least significant octet MUST equal "1". Also, all Protocols MUST be assigned such that the least significant bit of the most significant octet equals "0". Frames received which don't comply with these rules MUST be treated as having an unrecognized Protocol. Protocol field values in the "0***" to "3***" range identify the network-layer protocol of specific packets, and values in the "8***" to "b***" range identify packets belonging to the associated Network Control Protocols (NCPs), if any. Protocol field values in the "4***" to "7***" range are used for protocols with low volume traffic which have no associated NCP. Protocol field values in the "c***" to "f***" range identify packets as link-layer Control Protocols (such as LCP). Up-to-date values of the Protocol field are specified in the most recent "Assigned Numbers" RFC [2]. Current values are assigned as follows: Value (in hex) Protocol Name 0001 Padding Protocol 0003 to 001f reserved (transparency inefficient) 0021 Internet Protocol 0023 OSI Network Layer 0025 Xerox NS IDP 0027 DECnet Phase IV 0029 Appletalk 002b Novell IPX 7

002d 002f Van Jacobson Compressed TCP/IP Van Jacobson Uncompressed TCP/IP 0031 Bridging PDU 0033 Stream Protocol (ST-II) 0035 Banyan Vines 0037 unused 0039 AppleTalk EDDP 003b AppleTalk SmartBuffered 003d Multi-Link 005d reserved (compression inefficient) 00cf reserved (PPP NLPID) 00fd 1st choice compression 00ff reserved (compression inefficient) 0201 802.1d Hello Packets 0203 IBM Source Routing BPDU 0231 Luxcom 0233 Sigma Network Systems 8021 Internet Protocol Control Protocol 8023 OSI Network Layer Control Protocol 8025 Xerox NS IDP Control Protocol 8027 DECnet Phase IV Control Protocol 8029 Appletalk Control Protocol 802b Novell IPX Control Protocol 802d Reserved 802f Reserved 8031 Bridging NCP 8033 Stream Protocol Control Protocol 8035 Banyan Vines Control Protocol 8037 unused 8039 Reserved 803b Reserved 803d Multi-Link Control Protocol 80fd Compression Control Protocol 80ff Reserved c021 c023 c025 c223 Link Control Protocol Password Authentication Protocol Link Quality Report Challenge Handshake Authentication Protocol Developers of new protocols MUST obtain a number from the Internet Assigned Numbers Authority (IANA), at IANA@isi.edu. Information Field The Information field is zero or more octets. The Information field contains the datagram for the protocol specified in the Protocol field. The maximum length for the Information field, including Padding, is termed the Maximum Receive Unit (MRU), which defaults to 1500 octets. By negotiation, consenting PPP implementations may use other values for the MRU. Padding 8

On transmission, the Information field MAY be padded with an arbitrary number of octets up to the MRU. It is the responsibility of each protocol to distinguish padding octets from real information. Configuration Option Formats Selections from RFC 1548 (http://www.networksorcery.com/enp/rfc/rfc1548.txt) 6.1 Maximum-Receive-Unit Description This Configuration Option may be sent to inform the peer that the implementation can receive larger packets, or to request that the peer send smaller packets. The default value is 1500 octets. If smaller packets are requested, an implementation MUST still be able to receive the full 1500 octet information field in case link synchronization is lost. Implementation Note: This option is used to indicate an implementation capability. The peer is not required to maximize the use of the capacity. For example, when a MRU is indicated which is 2048 octets, the peer is not required to send any packet with 2048 octets. The peer need not Configure-Nak to indicate that it will only send smaller packets, since the implementation will always require support for at least 1500 octets. A summary of the Maximum-Receive-Unit Configuration Option format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Length Maximum-Receive-Unit +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1 Length: 4 Maximum-Receive-Unit The Maximum-Receive-Unit field is two octets, and specifies the maximum number of octets in the Information and Padding fields. It does not include the framing, Protocol field, FCS, nor any transparency bits or bytes. 6.2 Async-Control-Character-Map Description 9

This Configuration Option provides a method to negotiate the use of control character transparency on asynchronous links. For asynchronous links, the default value is 0xffffffff, which causes all octets less than 0x20 to be mapped into an appropriate two octet sequence. For most other links, the default value is 0, since there is no need for mapping. However, it is rarely necessary to map all control characters, and often it is unnecessary to map any control characters. The Configuration Option is used to inform the peer which control characters MUST remain mapped when the peer sends them. The peer MAY still send any other octets in mapped format, if it is necessary because of constraints known to the peer. The peer SHOULD Configure-Nak with the logical union of the sets of mapped octets, so that when such octets are spuriously introduced they can be ignored on receipt. A summary of the Async-Control-Character-Map Configuration Option format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Length Async-Control-Character-Map +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ACCM (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 2 Length: 6 Async-Control-Character-Map The Async-Control-Character-Map field is four octets and indicates the set of control characters to be mapped. The map is sent most significant octet first. Each numbered bit corresponds to the octet of the same value. If the bit is cleared to zero, then that octet need not be mapped. If the bit is set to one, then that octet MUST remain mapped. For example, if bit 19 is set to zero, then the ASCII control character 19 (DC3, Control-S) MAY be sent in the clear. Note: The least significant bit of the least significant octet (the final octet transmitted) is numbered bit 0, and would map to the ASCII control character NUL. 10

6.3 Authentication-Protocol Description On some links it may be desirable to require a peer to authenticate itself before allowing network-layer protocol packets to be exchanged. This Configuration Option provides a method to negotiate the use of a specific authentication protocol. By default, authentication is not required. An implementation MUST NOT include multiple Authentication- Protocol Configuration Options in its Configure-Request packets. Instead, it SHOULD attempt to configure the most desirable protocol first. If that protocol is Configure-Nak'd, then the implementation SHOULD attempt the next most desirable protocol in the next Configure-Request. If an implementation sends a Configure-Ack with this Configuration Option, then it is agreeing to authenticate with the specified protocol. An implementation receiving a Configure-Ack with this Configuration Option SHOULD expect the peer to authenticate with the acknowledged protocol. There is no requirement that authentication be full duplex or that the same protocol be used in both directions. It is perfectly acceptable for different protocols to be used in each direction. This will, of course, depend on the specific protocols negotiated. A summary of the Authentication-Protocol Configuration Option format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Length Authentication-Protocol +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data... +-+-+-+-+ Type: 3 Length: >= 4 Authentication-Protocol The Authentication-Protocol field is two octets and indicates the authentication protocol desired. Values for this field are always the same as the PPP Protocol field values for that same authentication protocol. Up-to-date values of the Authentication-Protocol field are specified in the most recent "Assigned Numbers" RFC [2]. Current values are assigned as follows: Value (in hex) c023 c223 Protocol Password Authentication Protocol Challenge Handshake Authentication Protocol 11

Data The Data field is zero or more octets and contains additional data as determined by the particular protocol. 6.6 Protocol-Field-Compression Description This Configuration Option provides a method to negotiate the compression of the PPP Protocol field. By default, all implementations MUST transmit packets with two octet PPP Protocol fields. PPP Protocol field numbers are chosen such that some values may be compressed into a single octet form which is clearly distinguishable from the two octet form. This Configuration Option is sent to inform the peer that the implementation can receive such single octet Protocol fields. As previously mentioned, the Protocol field uses an extension mechanism consistent with the ISO 3309 extension mechanism for the Address field; the Least Significant Bit (LSB) of each octet is used to indicate extension of the Protocol field. A binary "0" as the LSB indicates that the Protocol field continues with the following octet. The presence of a binary "1" as the LSB marks the last octet of the Protocol field. Notice that any number of "0" octets may be prepended to the field, and will still indicate the same value (consider the two binary representations for 3, 00000011 and 00000000 00000011). When using low speed links, it is desirable to conserve bandwidth by sending as little redundant data as possible. The Protocol- Field-Compression Configuration Option allows a trade-off between implementation simplicity and bandwidth efficiency. If successfully negotiated, the ISO 3309 extension mechanism may be used to compress the Protocol field to one octet instead of two. The large majority of packets are compressible since data protocols are typically assigned with Protocol field values less than 256. Compressed Protocol fields MUST NOT be transmitted unless this Configuration Option has been negotiated. When negotiated, PPP implementations MUST accept PPP packets with either double-octet or single-octet Protocol fields, and MUST NOT distinguish between them. The Protocol field is never compressed when sending any LCP packet. This rule guarantees unambiguous recognition of LCP packets. When a Protocol field is compressed, the Data Link Layer FCS field is calculated on the compressed frame, not the original uncompressed frame. 12

A summary of the Protocol-Field-Compression Configuration Option format is shown below. The fields are transmitted from left to right. Type: 7 Length: 2 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Length +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.7 Address-and-Control-Field-Compression Description This Configuration Option provides a method to negotiate the compression of the Data Link Layer Address and Control fields. By default, all implementations MUST transmit frames with Address and Control fields appropriate to the link framing. Since these fields usually have constant values for point-to-point links, they are easily compressed. This Configuration Option is sent to inform the peer that the implementation can receive compressed Address and Control fields. If a compressed frame is received when Address-and-Control-Field- Compression has not been negotiated, the implementation MAY silently discard the frame. The Address and Control fields MUST NOT be compressed when sending any LCP packet. This rule guarantees unambiguous recognition of LCP packets. When the Address and Control fields are compressed, the Data Link Layer FCS field is calculated on the compressed frame, not the original uncompressed frame. A summary of the Address-and-Control-Field-Compression configuration option format is shown below. The fields are transmitted from left to right. Type: 8 Length: 2 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Length +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 13