Course: Semester: ELE437 Introduction Ethereal Exercise 2 (Part B): Link Control Protocol In this half of Exercise 2, you will look through a more complete capture of a dial-up connection being established. This includes the authentication and IP protocol setup. In addition, connection termination will be covered. Background Some of the information from Part A will be needed for this half of the exercise. This includes the LCP Configuration Option format as well as the meanings of the Code and Identifier fields. Additionally, some definitions are presented here that should be useful. NBNS NetBIOS Name Service Maps a computer or networking device s NetBIOS name to an IP address. WINS Windows Internet Naming Service WINS is the NBNS for Windows users. DNS Domain Name Server Server that maps alphanumeric addresses to IP addresses. Section 1: More LCP Packet Types In Part A of this exercise, details on the Configure-Request, Configure-Ack, and Configure-Reject packet types were given. In this section, details on two more LCP packets will be given: Identification and Configure-Nak. 1.1 - Identification The Identification packet type is used to allow users to identify themselves to their peers. The packet format is shown below, as given in the RFC 1570 documentation. Magic-Number Message... +-+-+-+-+-+-+-+-+ The Code field is equal to 12 (0x0C). The Identifier and Length fields have the same meaning as in all previous packet types.
The Magic-Number (MN) field is a 32-bit number that should almost uniquely identify a user. It is typically used to determine if the modem is connected to itself or a remote device. If the client s MN is equal to the server s MN (which is in the latest received Config-Request packet) then there is almost definitely a looped-back connection, meaning that the client s modem is connected to itself. The Message field is 0 or more bytes, typically in the form of ASCII characters, which identify the sender in some way. The information in this message can be anything including OS version, PPP revision number, and network hardware identifiers. For more information on the Identification packet type, see the RFC 1570 selection on page 14 of this handout. 1.2 Configure-Nak The Configure-Nak (Configuration Negative Acknowledgement) packet type is used when a Configure-Request arrives, all of the Configuration Options are recognized, but the value of one or more Configuration Options isn t acceptable. This is different from the Configure-Reject packet type, which is sent when one or more Configuration Options aren t even recognized. The packet format for Configure-Nak is shown below, as given in the RFC 1570 documentation. Options... +-+-+-+-+ The Code field is equal to 3 (0x03). The Identifier and Length fields have the same meaning as in all previous packet types. The Options field contains the Configuration Options that were recognized but contained unacceptable values. They must be in the same order as they were received in the Configure-Request that carried the unacceptable Configuration Options, just with the accepted Options excluded. For more information on the Configure-Nak packet type, see the RFC 1548 selection on page 11 of this handout. 2
Section 2: Authentication with CHAP Before configuring PPP to carry IP packets for the Internet connection, authorization to set up such a connection must first be obtained. Since this isn t a network security course, this will not be an in-depth study. If an authentication protocol was negotiated during the configuration process then the user must be authenticated before any network protocol can be used over PPP. If no authentication protocol was configured then this process can be skipped. 2.1 CHAP Packet Formats The Authentication packet format for CHAP (Challenge-Handshake Authentication Protocol) is given below. Data... +-+-+-+-+ The Code field is one byte and has four possible values shown in the table below. Table 2.1 CHAP Packet Codes CHAP Code Meaning 1 Challenge 2 Response 3 Success 4 Failure The Identifier and Length fields have the same size and meaning as in all previous packet types. The contents of the Data field depends on the value in the Code field. shown below. The format for Challenge (Code = 1) and Response (Code = 2) is the same, and is Value-Size Value... Name... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3
The Identifier and Length fields have the same size and meaning as in all previous packet types. The Value-Size field is an 8-bit field that specifies how many bytes long the Value field is. The Value field for Challenge is a 128-bit value that is ideally unpredictable and globally random when the MD5 algorithm is used. The Value field for Response is a 128-bit value that is a function of the Identifier field, the Challenge value, and the user s password. Finally, the Name field may contain information such as a user name or the name of a computer or networking device. The format for Success (Code = 3) and Failure (Code = 4) is the same, and is shown below. Message... +-+-+-+-+-+-+-+-+-+-+-+-+- The Identifier and Length fields have the same size and meaning as in all previous packet types. The Message field is 0 or more bytes, typically in the form of ASCII characters. It is more likely to be used for Failure packets so that a specific error message can be included. 2.2 Authentication Procedure The procedure for authentication is as follows: 1) The service provider sends a Challenge to the client 2) The client uses the Challenge Value, Identifier field, and their Password to calculate a Response to the Challenge 3) The Response is sent to the service provider 4) The service provider accepts the Response and sends a Success message, or the provider rejects the Response and sends a Failure message. 5) If a Success message was received, then network layer protocols can be configured. If a Failure message was received, the connection may be terminated or the link may be retained but the client will be limited to a subset of network layer protocols. Note that the LCP configuration may be changed during the authentication process. This may result in a Configuration Request being received rather than a Success or Failure packet after sending a Response to a Challenge. Once the configuration has been updated, the authentication process will be started over. 4
Section 3: IP Control Protocol (IPCP) Once the link has been configured and the client has been authenticated, they can configure and enable one or more network layer protocols for use over PPP. For each supported network layer protocol there is a corresponding network control protocol (NCP). The NCP for IP is called the IP Control Protocol, or IPCP. IPCP uses the same Configuration Option format as LCP, but it provides different options. Several of these options are shown in the table below. Table 3.1: IPCP Configuration Option Types Option Type Option ID IP Addresses 1 (0x01) IP Compression Protocol 2 (0x02) IP Address 3 (0x03) Primary DNS Server Address 129 (0x81) Primary WINS Server Address 130 (0x82) Secondary DNS Server Address 131 (0x83) Secondary WINS Server Address 132 (0x84) 3.1 IP Compression Configuration Option Format Table 3.2: Compression Configuration Option Format Byte Offset 0 1 2 4 Field Size (Bytes) 1 1 2 Length-4 Field Name Option ID Length IP Compression Protocol ID Data The Option ID and Length fields have the same meanings as in all Configuration Options. The IP Compression Protocol ID is a 16-bit value. This ID will be 0x002D in this exercise for the Van Jacobson (VJ) protocol. The Data field contains additional data specific to the compression protocol being used. 3.2 Address Configuration Option Format The IP, DNS, and WINS options all have the same Configuration Option format. Table 3.3: Address Configuration Option Format Byte Offset 0 1 2 Field Size (Bytes) 1 1 4 Field Name Option ID Length Address The Option ID and Length fields have the same meanings as in all Configuration Options. The Address field is a 32-bit address structured as four 8-bit values. 5
3.3 IPCP Configuration Procedure The configuration of IPCP is done the same way as for LCP. The client and server exchange Configuration Request packets and accept or reject the received configuration. Once both parties have agreed on a configuration, IP packets can be sent over the PPP link. Section 4: Compression Control Protocol (CCP) The Compression Control Protocol (CCP) is another network layer protocol that can be used over a PPP link. Several different compression types have been defined, including the Microsoft Point-to-Point Compression (MPPC) protocol. MPPC and a few other types are shown in the table below. Table 4.1 CCP Compression Types Compression Hewlett-Packard PPC Stac Electronics LZS Microsoft PPC Gandalf FZA V.42bis compression BSD LZW Compress The CCP packet format is shown below. CCP Type 16 (0x10) 17 (0x11) 18 (0x12) 19 (0x13) 20 (0x14) 21 (0x15) Type Length Values... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- The Type field is one of the CCP type values from Table 4.1. The Length field has the same meaning as in all previous packet types. The format of the Values field depends on the CCP type. Section 5: Link Termination Eventually, either the client or server will want to break the connection between them. While you could rip the phone cord out of the wall or turn off the modem, it is much better if both parties agree to terminate the link. To initiate the link termination process, a Termination Request packet is sent. Once this request is received by the current peer, they must send a Termination Acknowledgement packet. Both parties can then shut down the physical link between them over the phone line. 6
If a Terminate-Ack packet is not received after sending a Terminate-Request packet several times or after a wait time has elapsed, the user may assume that the link has already been lost and that the loss hasn t been detected yet at the physical layer. In this case, it is acceptable for the user to terminate the link from their end without acknowledgement from the other party. The format for the Terminate-Request (Code = 5) and Terminate-Ack (Code = 6) packets is shown below. Data... +-+-+-+-+ The Identifier and Length fields have the same size and meaning as in all previous packet types. The Data field is any amount of data that can fit in the LCP packet. The meaning of this data is not defined and can therefore be used for anything. One possible use of this field is to specify the next time a connection can be established to a particular server. This would be useful if a service provider is temporarily shutting off equipment for maintenance. For more information on the Terminate-Request and Terminate-Ack packet types, see the RFC 1548 selection on page 13 of this handout. 7
Questions 1) Which of the four CHAP packet types isn t in the capture? 2) How does the client obtain an IP address and DNS server address from the server? (Hint: Look at packets 30, 31, 32, and 33) 3) In Packet 25, the server sends its IP address to the client. a. What is the IP address? b. Go to http://remote.12dt.com/rns. Enter the IP address, and then press the Lookup button. What domain name does the IP address resolve to? 4) The follow three questions are on Magic Numbers (from Page 2): a. What is the server s magic number? b. What is the dial-up user s magic number? c. Is the connection looped-back to the client? 5) Read the information on Page 9 about the Protocol-Reject LCP packet format, then answer the following questions: a. Which network protocol is rejected in the packet trace? b. Which compression protocol is rejected? c. At what offset (in bytes) is the CCP Type in Packet 24? d. What is the CCP Type value? Grading - 16 points - The questions for Part B have the following point values: 1) 1 point 2) 4 points 3) 4 points (1 for a, 3 for b) 4) 3 points (1 for each) 5) 4 points (1 for each) 8
Protocol-Reject LCP Packet Format Details Selection from RFC 1548 (http://www.ietf.org/rfc/rfc1548.txt) 5.7 Protocol-Reject Description Reception of a PPP packet with an unknown Protocol field indicates that the peer is attempting to use a protocol which is unsupported. This usually occurs when the peer attempts to configure a new protocol. If the LCP state machine is in the Opened state, then this error MUST be reported back to the peer by transmitting a LCP packet with the Code field set to 8 (Protocol- Reject), the Rejected-Protocol field set to the received Protocol, and the inducing packet copied to the Rejected-Information field. Upon reception of a Protocol-Reject, the implementation MUST stop sending packets of the indicated protocol at the earliest opportunity. Protocol-Reject packets can only be sent in the LCP Opened state. Protocol-Reject packets received in any state other than the LCP Opened state SHOULD be silently discarded. A summary of the Protocol-Reject packet format is shown below. The fields are transmitted from left to right. Rejected-Protocol Rejected-Information... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 8 for Protocol-Reject. Identifier The Identifier field MUST be changed for each Protocol-Reject sent. Rejected-Protocol The Rejected-Protocol field is two octets and contains the PPP Protocol field of the packet which is being rejected. Rejected-Information The Rejected-Information field contains a copy of the packet which is being rejected. It begins with the Information field, and does not include any Data Link Layer headers nor an FCS. The Rejected-Information MUST be truncated to comply with the peer's established MRU. 9
Authentication, Network Layer, and Link Termination Details Selections from RFC 1548 (http://www.ietf.org/rfc/rfc1548.txt) 3.5 Authentication Phase On some links it may be desirable to require a peer to authenticate itself before allowing network-layer protocol packets to be exchanged. By default, authentication is not mandatory. If an implementation desires that the peer authenticate with some specific authentication protocol, then it MUST negotiate the use of that authentication protocol during Link Establishment phase. Authentication SHOULD take place as soon as possible after link establishment. However, link quality determination MAY occur concurrently. An implementation MUST NOT allow the exchange of link quality determination packets to delay authentication indefinitely. Advancement from the Authentication phase to the Network-Layer Protocol phase MUST NOT occur until authentication has completed, using the negotiated authentication protocol. If authentication fails, PPP SHOULD proceed instead to the Link Termination phase. Any Network Control Protocol or network-layer protocol packets received during this phase MUST be silently discarded. 3.6 Network-Layer Protocol Phase Once PPP has finished the previous phases, each network-layer protocol (such as IP, IPX, or AppleTalk) MUST be separately configured by the appropriate Network Control Protocol (NCP). Each NCP MAY be Opened and Closed at any time. Implementation Note: Because an implementation may initially use a significant amount of time for link quality determination, implementations SHOULD avoid fixed timeouts when waiting for their peers to configure a NCP. After a NCP has reached the Opened state, PPP will carry the corresponding network-layer protocol packets. Any network-layer protocol packets received when the corresponding NCP is not in the Opened state MUST be silently discarded. 10
Implementation Note: There is an exception to the preceding paragraphs, due to the availability of the LCP Protocol-Reject (described below). While LCP is in the Opened state, any protocol packet which is unsupported by the implementation MUST be returned in a Protocol- Reject. Only protocols which are supported are silently discarded. During this phase, link traffic consists of any possible combination of LCP, NCP, and network-layer protocol packets. 3.7 Link Termination Phase PPP can terminate the link at any time. This might happen because of the loss of carrier, authentication failure, link quality failure, the expiration of an idle-period timer, or the administrative closing of the link. LCP is used to close the link through an exchange of Terminate packets. When the link is closing, PPP informs the network-layer protocols so that they may take appropriate action. After the exchange of Terminate packets, the implementation SHOULD signal the physical-layer to disconnect in order to enforce the termination of the link, particularly in the case of an authentication failure. The sender of the Terminate-Request SHOULD disconnect after receiving a Terminate-Ack, or after the Restart counter expires. The receiver of a Terminate-Request SHOULD wait for the peer to disconnect, and MUST NOT disconnect until at least one Restart time has passed after sending a Terminate-Ack. PPP SHOULD proceed to the Link Dead phase. Any non-lcp packets received during this phase MUST be silently discarded. Configure-Nak LCP Packet Format Details Selection from RFC 1548 (http://www.ietf.org/rfc/rfc1548.txt) 5.3 Configure-Nak Description If every element of the received Configuration Options is recognizable but some values are not acceptable, then the implementation MUST transmit a LCP packet with the Code field set to 3 (Configure-Nak), the Identifier field copied from the received Configure-Request, and the Options field filled with only the unacceptable Configuration Options from the Configure-Request. All acceptable Configuration Options are filtered out of the Configure-Nak, but otherwise the Configuration Options from the Configure-Request MUST NOT be reordered. 11
Options which have no value fields (boolean options) MUST use the Configure-Reject reply instead. Each Configuration Option which is allowed only a single instance MUST be modified to a value acceptable to the Configure-Nak sender. The default value MAY be used, when this differs from the requested value. When a particular type of Configuration Option can be listed more than once with different values, the Configure-Nak MUST include a list of all values for that option which are acceptable to the Configure-Nak sender. This includes acceptable values that were present in the Configure-Request. Finally, an implementation may be configured to request the negotiation of a specific Configuration Option. If that option is not listed, then that option MAY be appended to the list of Nak'd Configuration Options in order to prompt the peer to include that option in its next Configure-Request packet. Any value fields for the option MUST indicate values acceptable to the Configure-Nak sender. On reception of a Configure-Nak, the Identifier field MUST match that of the last transmitted Configure-Request. Invalid packets are silently discarded. Reception of a valid Configure-Nak indicates that a new Configure-Request MAY be sent with the Configuration Options modified as specified in the Configure-Nak. When multiple instances of a Configuration Option are present, the peer SHOULD select a single value to include in its next Configure-Request packet. Some Configuration Options have a variable length. Since the Nak'd Option has been modified by the peer, the implementation MUST be able to handle an Option length which is different from the original Configure-Request. A summary of the Configure-Nak packet format is shown below. The fields are transmitted from left to right. Options... +-+-+-+-+ Code 3 for Configure-Nak. Identifier The Identifier field is a copy of the Identifier field of the Configure-Request which caused this Configure-Nak. 12
Options The Options field is variable in length and contains the list of zero or more Configuration Options that the sender is Nak'ing. All Configuration Options are always Nak'd simultaneously. Terminate-Request and Terminate-Ack LCP Packet Format Details Selection from RFC 1548 (http://www.ietf.org/rfc/rfc1548.txt) 5.5 Terminate-Request and Terminate-Ack Description LCP includes Terminate-Request and Terminate-Ack Codes in order to provide a mechanism for closing a connection. A LCP implementation wishing to close a connection SHOULD transmit a LCP packet with the Code field set to 5 (Terminate-Request), and the Data field filled with any desired data. Terminate-Request packets SHOULD continue to be sent until Terminate-Ack is received, the lower layer indicates that it has gone down, or a sufficiently large number have been transmitted such that the peer is down with reasonable certainty. Upon reception of a Terminate-Request, a LCP packet MUST be transmitted with the Code field set to 6 (Terminate-Ack), the Identifier field copied from the Terminate-Request packet, and the Data field filled with any desired data. Reception of an unelicited Terminate-Ack indicates that the peer is in the Closed or Stopped states, or is otherwise in need of re-negotiation. A summary of the Terminate-Request and Terminate-Ack packet formats is shown below. The fields are transmitted from left to right. Data... +-+-+-+-+ Code 5 for Terminate-Request; 6 for Terminate-Ack. Identifier On transmission, the Identifier field MUST be changed whenever the content of the Data field changes, and whenever a valid reply has 13
been received for a previous request. For retransmissions, the Identifier MAY remain unchanged. On reception, the Identifier field of the Terminate-Request is copied into the Identifier field of the Terminate-Ack packet. Data The Data field is zero or more octets and contains uninterpreted data for use by the sender. The data may consist of any binary value and may be of any length from zero to the peer's established MRU minus four. LCP Identification Packet Format Details Selection from RFC 1570 (http://www.networksorcery.com/enp/rfc/rfc1570.txt) 1.1. Identification Description This Code provides a method for an implementation to identify itself to its peer. This Code might be used for many diverse purposes, such as link troubleshooting, license enforcement, etc. Identification is a Link Maintenance packet. Identification packets MAY be sent at any time, including before LCP has reached the Opened state. The sender transmits a LCP packet with the Code field set to 12 (Identification), the Identifier field set, the local Magic-Number (if any) inserted, and the Message field filled with any desired data, but not exceeding the default MRU minus eight. Receipt of an Identification packet causes the RXR or RUC event. There is no response to the Identification packet. Receipt of a Code-Reject for the Identification packet SHOULD generate the RXJ+ (permitted) event. Rationale: This feature is defined as part of LCP, rather than as a separate PPP Protocol, in order that its benefits may be available during the earliest possible stage of the Link Establishment phase. It allows an operator to learn the identification of the peer even when negotiation is not converging. Non-LCP packets cannot be sent during the Link Establishment phase. 14
This feature is defined as a separate LCP Code, rather than a Configuration-Option, so that the peer need not include it with other items in configuration packet exchanges, and handle "corrected" values or "rejection", since its generation is both rare and in one direction. It is recommended that Identification packets be sent whenever a Configure-Reject is sent or received, as a final message when negotiation fails to converge, and when LCP reaches the Opened state. A summary of the Identification packet format is shown below. The fields are transmitted from left to right. Magic-Number Message... +-+-+-+-+-+-+-+-+ Code 12 for Identification Identifier Length The Identifier field MUST be changed for each Identification sent. >= 8 Magic-Number The Magic-Number field is four octets and aids in detecting links which are in the looped-back condition. Until the Magic-Number Configuration Option has been successfully negotiated, the Magic- Number MUST be transmitted as zero. See the Magic-Number Configuration Option for further explanation. Message The Message field is zero or more octets, and its contents are implementation dependent. It is intended to be human readable, and MUST NOT affect operation of the protocol. It is recommended that the message contain displayable ASCII characters 32 through 126 decimal. Mechanisms for extension to other character sets are the topic of future research. The size is determined from the Length field. Implementation Note: The Message will usually contain such things as the sender's hardware type, PPP software revision level, and PPP product 15
serial number, MIB information such as link speed and interface name, and any other information that the sender thinks might be useful in debugging connections. The format is likely to be different for each implementor, so that those doing serial number tracking can validate their numbers. A robust implementation SHOULD treat the Message as displayable text, and SHOULD be able to receive and display a very long Message. 16
Exercise 2b: - Protocol Encapsulation (CHAP, IP, CCP, etc) - LCP Connection Termination - Ask for info from the Challenge, Response, Success items without providing packet formats - Return the book to Professor Tufts http://wiki.ethereal.com/capturesetup/ppp On Linux, you won't be able to capture control protocol traffic, as that's not supplied to the networking stack. You will be able to capture IP traffic, for example, but you won't be able to see the PPP headers, as the PPP code doesn't supply them to the networking stack. (XXX - add pppd information.) On Mac OS X, you won't be able to capture on a PPP interface until it's set up, so you won't be able to see initial control protocol traffic. - Brief coverage of CHAP - Brief coverage of CCP o Notice that CCP is rejected and NOT used in the end - Explain what Magic Numbers are - LCP packet for config renegotiation and NAK packet - Explain the IPCP packets including: o The NAK packet o What WINS is o What DHCP is o What DNS servers are o What the 63.3.18.130 address is (backbone address) an4.bos24.da.uu.net [63.3.18.130] ipt-mtcc04 (IP Telephony dial-up router s ID) ANSWERS 1) Failure (4) 2) By sending out 0 s and getting them filled in by a Configure-Nak message 3) i. 63.3.18.130 ii. an4.bos24.da.uu.net 4) Q: Ask about the backbone address - ipt-mtcc04 (IP Telephony dial-up router s ID) 17