+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ [------ Libnet-X.25 #1: The Preamble ---------------------------------------] [------ by udp, with Keltic Phr0st and Dan Moniz ---------------------------] [------ Friday May 26th 2000 ------------------------------- First Draft ---] -------------[ Table of Contents ]------------------------------------------- ------------------------- -0x00 [ IPR / BSD License ] -0x01 [ Executive Summary ] -0x02 [ Introduction ] -0x03 [ Rationale ] -0x04 [ Link Layer Protocols ] -0x05 [ Packet Layer Protocol ] -0x06 [ X.121 Addressing ] -0x07 [ Routing in X.25 ] -0x08 [ PADs ] -0x09 [ Conclusions ] -0x0A [ Glossary ] -0x0B [ References ] -0x0C [ Acknowledgements ] -0x0D [ Contact Info ] -0x0E [ Appendix A: LLC/SNAP ] ------------------------- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -0x00-------------------[ IPR / BSD License ] This document and its contents are comprised of our own research, and are (c) Copyright 2000 Bruce M. Simpson, Keltic Phr0st, and Dan Moniz [hereafter refered to as 'Team LX25']. All Rights Reserved Worldwide. Redistribution and use in ASCII text format and other formats, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of this document must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in any other format must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. All advertising materials mentioning features or use of this document must display the following acknowledgement: This work is based in part of the work of Team LX25. 4. The names of members of Team LX25 may NOT be used to endorse or promote works derived from this work without specific prior written permission. No warranty or representation is made regarding the reliability, suitability, or correctness of the information within this document. Use of any code or information within this document is completely at your own risk; members of Team LX25 will not be held liable for any form of compensation for financial loss caused directly or indirectly by the use of information within this document. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -0x01-------------------[ Executive Summary ] "Security is mistakenly seen as a cost, when its actually a competitive enabler." -- Lindsay Nicolle, Digital Britain, "The e-Commerce Survivors" As discussed in my earlier paper, 'A Libnet Precis', Libnet is a library for abstracting away the low level details of constructing and injecting protocol data units (PDUs), which most of us call network packets. This series of documents, and source code releases, explores the adaptation of Libnet into Libnet-X.25. The intention behind this is to radically enhance Libnet by turning it into a viable platform for attacking X.25 network infrastructure. Given Libnet's rapidly growing ubiquity within the information security community, this would permit more rapid development of X.25 penetration and auditing tools. This, in turn, will help us to locate the weak spots within such X.25 infrastructure. The Preamble is the first document of a series. It is intended to provide an overview of the X.25 world for those striving to understand it from the perspective of an IP-dominated world. We hope you find it incisive, informative, and a heck of a lot easier to get to grips with than the jargon- laden documents of the ITU. -0x02-------------------[ Introduction ] X.25 is as much an adventure into the unknown for me as a trip to the Mojave Desert would be for someone who had lived in the Scottish Hebridean Islands for most of his life. With this in mind, I ask you to bear with me. My knowledge and experience of X.25 are extremely limited. Much of this document in its initial incarnation will be concerned with understanding and explaining X.25 networks to the IP-savvy reader. The terms and analogies used will assume an existing understanding of TCP/IP based networks, as this is where most of my knowledge currently resides. As the document progresses, however, you'll notice less of a reliance on IP abstractions, and more of a reliance on how telco networks work, as this is where X.25 inherits many of its idiosyncrasies from. One can see that this is the natural way to go about such things. If one already posesses in-depth knowledge of one subject, and groks it fully, then it makes sense to try to assimilate new concept maps in terms of the existing map within one's mind. I ask you to bear with me, and to give me feedback, where possible, on the use of IP-world idioms used as abstractions to understand the X.25 world; any and all constructive feedback will be assimilated, and credited. Consideration of specific networks whose architecture is based around X.25 will be limited to another document. Its distribution will be restricted to trusted third parties. -0x03-------------------[ Rationale ] "Take three months to prepare your machines and three months to complete your siege engineering." -- Sun Tzu, Art of War, Chapter 3: Planning a Siege Libnet-X.25 has the potential to turn Libnet into a viable attack platform for aiming at the following kinds of targets: o Legacy networks, o Financial networks, o and the Defense Data Network (DDN). All of these networks are known to have a significant X.25 component in their infrastructure. Although these are legacy networks, they still comprise the core network infrastructure of large companies, governments, health services and financial institutions. In information security terms, they may potentially be weak spots for some time to come, as many of them are unlikely to be replaced with IP-based alternatives in the foreseeable future. Once we know what problems exist within such infrastructure, then we, as security practitioners, can begin to suggest how the IT/IS managers in charge of these ailing systems should go about fixing lax security. -[----------------------- High Level Overview X.25 specifies both link-layer and network-layer protocols. There is also a very tight specification of the electrical characteristics of the physical interfaces used with LAPB. Layer +--------------------------------------------------------+ 7 | Application | +--------------------------------------------------------+ 6 | Presentation | +--------------------------------------------------------+ 5 | Session | +--------------------------------------------------------+ 4 | Transport | +--------------------------------------------------------+ | +--------+ +--------+ | 3 | Network | X.25 | | X.75 | | | +--------+ +-----+ +--------+ | +------------------------!-----| MLP |------!------------+ | +----+ | +-----+ | | 2 | Data Link |HDLC| +-+--------!---------+-+ | | +----+ | LAPB & LAP-D | | | +----------------------+ | +--------------------------------------------------------+ 1 | Physical | +--------------------------------------------------------+ Figure 1: X.25 in relation to the OSI Model Before considering the X.25 Packet Layer Protocol (PLP), we examine the more common link-layer protocols and encapsulations in use to permit the transmission of X.25 PLP across LAN and WAN links. -0x04-------------------[ Link Layer Protocols ] ------------------------[ LAPB (Link Access Protocol Balanced) LAPB is X.25's commonly used data link layer (layer 2) protocol. It is a point to point protocol. It is actually a variation of HDLC, which, in turn, is the protocol upon which most WAN framing formats are based. It is a peer-to-peer protocol, i.e. it has no concept of master/slave, unlike HDLC NRM (also known as SDLC). Most of the sliding window, full duplex WAN and LAN protocols in use today are derived from HDLC. Further derivations of LAPB include Link Access Procedure, D-Channel (LAP-D), a variant which allows the transmission of frames over the D-channel of an ISDN link. Also of interest is the Logical Link Control (LLC) encapsulation, part of the IEEE 802 standard, which allows X.25 packets to be transmitted over Ethernet. LAPB is available in the following flavors: modulo 8, modulo 128, and modulo 32768. For brevity's sake, only the LAPB Basic frame format will be presented here - all other formats, together with the behavior of the control field (which is different for each), can be found in the X.25 Recommendation. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delimiter | Address | Control | Data (1..n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .. Data .. | FCS | Delimiter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 - LAPB Basic frame format (modulo 8) - the Delimiter, or Flag fields, are always set to the bit sequence 0x7E, or %01111110 in binary. These are used to delimit the beginning and end of an LAPB frame as it is seen on the wire. Obviously, to prevent this bit sequence from occurring within the data, some form of escaping has to be used within the frame format.To prevent the delimiter sequence from occurring, the transmitting station will 'stuff' an extra zero whenever it sees five contiguous bits about to go out on the wire. - the Address field gets its name from HDLC, where it may be 1..n octets long. However, as LAPB is a point-to-point protocol, valid values are: o 0x01 denotes a command from DTE->DCE, or a response from DCE->DTE. o 0x03 denotes a command from DCE->DTE, or a response from DTE->DCE. - the Control field identifies the type of the frame. The X.25 recommendation states that the control field is 8 bits wide for modulo 8 (or basic) operation. Most of the time, you aren't likely to see modulo 32768 LAPB PDUs, because X.25 is often implemented with a maximum user data field of 128 octets. - the Data encapsulated within LAPB may be any length of bits, zero-padded to a multiple of 8 bits, when transmitting from DCE to DTE. The DTE, according to the X.25 standard, must only send octet-aligned data. - the Frame Check Sequence (FCS) field is a 16-bit CRC, calculated using the standard CRC-16 divisor polynomial (as specified in ITU-T X.25). You can find sample source code for a lookup-table based implementation of CRC-16 at this URL: http://wannabe.guru.org/alg/node191.html ------[ LAPB PDU Classes The above frame format gives rise to the following classes of PDU within LAPB: - Information: The encapsulated data. Here, the control field contains the frame sequence number. - Supervisory: These frames also contain sequence numbers. - RR: Receive Ready. Acknowledgment frame indicating the next frame expected. - REJ: Reject. Negative acknowledgment frame used to indicate transmission error detection. - RNR: Receive Not Ready. A form of flow control; the peer's window may be full. - Unnumbered: - DISC: Request Disconnection. - DM: Response to DISC indicating that disconnection has taken place. - FRMR: Frame reject. - UA: Acknowledgement frame. - SABM: Initiator for asynchronous balanced mode. - SABME: Initiator for asynchronous balanced extended mode. [This is used in the other HDLC variants such as LLC and LAP-D.] Other PDU classes exist for the other HDLC variants; these are not listed here, however, these PDUs fall into the three categories listed above. LAPB is used via X.21 and V.24 links. The maximum speed specified for X.21 interfaces is 64Kbps. As will be evident, this is pitifully slow compared to the WAN speeds attainable with SDH/SONET and DWDM technology. Due to the point- to-point nature of LAPB, it can't be used with Ethernet, or with ISDN. This is where LAP-D and LLC both come in. ------------------------[ LAP-D It's worth noting that the LAP-D frame format only differs from the LAPB format in that the address field is longer. It is 16 bits wide rather than 8; 6 bits are used for the Service Access Point Identifier (SAPI), and 7 bits are used for the Terminal Endpoint Identifier (TEI). The LAP-D protocol specifies a WAN link layer frame format used for the transmission of messages over the ISDN D-channel; however, an explanation of ISDN is outside the scope of this document. LAP-D is only detailed here to illustrate that one can speak X.25 directly over an ISDN D channel using LAP-D as the link layer encapsulation. ------------------------[ LAP-M Link Access Procedure for Modems (LAP-M) is the good old fashioned protocol specified within the ITU V.42 recommendation to implement error detection and correction with modems. Again, it is a bit-oriented protocol like the others in the LAPB family. It is an HDLC-based error correcting protocol. It makes use of these HDLC primitives: XID, SABME, UA, I, RR, UI, and DISC. Further information about LAP-M's operation can be found in the ITU V.42 recommendation, and in Chapter 5 of Fred Halsall's "Data Communications" as listed in the bibliography. ------------------------[ MLP Multi-Link Procedure (MLP) is an extension to LAPB which allows multiple physical links to be used. It is roughly analogous to the use of Multilink PPP within the TCP/IP family, or the use of some other physical/link layer multiplexing device; such devices are often implemented within hardware. It allows multiple physical links to be aggregated into one at the link layer. It is inserted before the information field in the LAPB frame. It is described in section 2.5 of the ITU X.25 Recommendation. ------------------------[ X.25 on LANs: LLC Logical Link Control (LLC) is an IEEE 802 Local Area Network (LAN) protocol which enables X.25 packets to be transmitted through a LAN channel. Because the use of LLC would duplicate much of the functionality of TCP and UDP, it is specified that IP should use the Ethernet II encapsulation whenever possible. An explanation of LLC and SNAP encapsulation within 802.3 is given in Appendix A of this document. ------[ LLC PDU Classes Note that LLC PDUs fall into the same three categories as the PDUs for all the other HDLC-derived protocols: Information, Supervisory, and Unnumbered. The Unnumbered PDUs will have an 8-bit control word in the frame, whereas all other PDUs will have a 16-bit control word. This is illustrated in the diagram below. 0 +------------------------ Modifier Function Bits 0 1 2|3 4 5|6 7 +-+-+-+-+-+-+-+-+ Unnumbered |1|1| MM|P| MMM | +-+-+-+-+-+-+-+-+ | +--------------------- Poll/Final bit 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Supervisory |1|0|S| XXXX |P| N(R) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Unnumbered |0| N(S) |P| N(R) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N(R) specifies the transmitter's send sequence number; N(S) specifies the transmitter's receive sequence number. The Modifier Function Bits in the Unnumbered PDUs specify the class of the PDU. The table below lists the mnemonic given for each PDU class according to its bit pattern, for the LLC variant of HDLC. +--------+--------------+ | MM-MMM | Class of PDU | +--------+--------------+ | 00-000 | UI | | 11-101 | XID | | 00-111 | TEST | | 11-110 | SABME | | 00-110 | UA | | 11-000 | DM | | 00-010 | DISC | | 10-001 | FRMR | +--------+--------------+ Table 1: Modifier Function bits for Unnumbered LLC PDUs - Type 1 LLC specifies the connectionless datagram service. It makes use of the UI, XID, and TEST PDUs from the HDLC family. - Type 2 LLC specifies the connection-oriented service. It uses the I, RR, RNR, REJ, SABME, DISC, UA, DM and FRMR PDUs from HDLC. Thus concludes our overview of the Logical Link Control protocol. Next, we'll review the X.25 protocol itself, beginning with an overview of X.25 addressing, as specified in ITU recommendation X.121. -0x05-------------------[ Packet Layer Protocol ] ------------------------[ X.25 Itself: Exploring the PSPDN We consider the X.25 Packet Layer Protocol, in terms of addressing, PDUs, sequence and state transition scenarios. Wherever possible, we try to express things using IP-like abstractions. However, some things in the X.25 world are simply different from the IP world no matter which way they are viewed. To kick off, let's look at how a typical X.25 network might be constructed. -----[------------------- A Typical X.25 Network +---+---+---+---++---+ +===+===+===+===++===+ Legacy |---|---|---|---||---| mainframe |---|---|---|---||---| system +-+-+-+-+-+-+-+-++-+-+ | +++++ +---+ \--+DCE+ +===+ IBM AS/400 +++++ |---| { or similar : |---| midrange : +-+-+ server } ::::::: | ::::::::: | :::::::::::: | ::::::::::::::: +----+-----+ :::::: :::: | | ::::: X. 25 ::::: | | ===== ::::: W A N ::::: + +-----------------+=IWU=:::::::::::::::: C L O U D ::::: | | +----+ ===== :::::: (PSPDN) ::::: | +----|PS/2| :::::::::::::::::: +----------+ +----+ ::::::::::::::::: :::::::::::: Subnet B :::::::: [Token Ring 8mbps] : [w/Concentrator && MAUs] Sun E450 : +---+ : +-----+ +-----+ +===+ : | P C | | P C | |---| ===== | 1 | | 2 | |---| =IWU= +--+--+ +--+--+ +-+-+ ===== | | | + {----+---+--------+--------+----------+------------} | | Subnet A [Ether_10base2] +--+--+ +--+--+ | P C | | P C | | 3 | | 4 | +-----+ +-----+ Figure 3 - Typical X.25 LAN/WAN Internetwork. The above diagram depicts, albeit somewhat simplistically, several LANs interconnected via the X.25 PSPDN. Note the use of the IWU units to interconnect the LANs, which will be discussed shortly. Note also that one of the nodes is directly connected to the WAN via the DCE interface. This is an interface typically conforming to the X.21bis physical interface, also specified in ITU-T X.25. It could alternatively use V.24 or V.35. +-------------------------------------------------+ 7 | Application | +-------------------------------------------------+ 6 | Presentation | +-------------------------------------------------+ 5 | Session | +-------------------------------------------------+ 4 | Transport | +-------------------------------------------------+ | +-----------+ +-----------+ | 3 | Network | X.25 PLP | | X.25 PLP | | | +-----------+ +-----------+ | +---------------------||---------------||---------+ 2 | Data Link +-----------+ +------------+ | | | LAPB | | 802.2 SNAP | | | +-----------+ +------------+ | | || | 802.2 LLC | | | || +------------+ | | || | 802.3 MAC | | | || +------------+ | +---------------------||---------------||---------+ | +-----------+ +------------+ | | Physical | X.21bis | | 10baseT | | 1 | +-----------+ +------------+ | +-------------------------------------------------+ Figure 4: X.25 OSI View - LAN and WAN Implementations Above is a quick OSI eye's view of the protocols that go into making the above network work. X.75 has been deliberately left out of the picture at this stage: trunk routing and switching will be covered in a bit. The X.25 PLP has two main roles: - virtual circuit multiplexing over a packet switched network layer; - provide a means for these virtual circuits to be switched/routed between nodes within the WAN. Notice that it does NOT specify transport or application protocols, which we'll discuss later. ------------------------[ X.25 Packet Layer Protocol (PLP) --------------[ PPDU Classes +-----------+---------------------------------------------------------+ | Kind | Direction | | | DTE->DCE DCE->DTE | +-----------+----------------------------+----------------------------+ | Call | 1 Call Request |~1 Incoming Call | | Setup | 2 Call Accepted |~2 Call Confirmation | +-----------+---------------------------------------------------------+ | Call | 3 Clear Request |~3 Clear Indication | | Clearing | 4 DTE Clear Confirmation |~4 DCE Clear Confirmation | +-----------+----------------------------+----------------------------+ | Data | 5 DTE Data |~5 DCE Data | | Transfer | 6 Interrupt Request |~6 Interrupt Confirmation | +-----------+----------------------------+----------------------------+ | | 7 DTE Receiver Ready |~7 DCE Receiver Ready | | Flow | 8 DTE Receiver Not Ready |~8 DCE Receiver Not Ready | | Control | 9 DTE Reject |~9 n/a | | | A Reset Request |~A Reset Indication | | | B DTE Reset Confirmation |~B DCE Reset Confirmation | +-----------+----------------------------+----------------------------+ | Resync | C Restart Request |~C Restart Indication | | | D DTE Restart Confirmation |~D DCE Restart Confirmation | +-----------+----------------------------+----------------------------+ | Network | E Diagnostic |~E Diagnostic | | Error | | | | Reports | | | +-----------+----------------------------+----------------------------+ Table 2: X.25 Packet Protocol Data Unit (PPDU) Classes by Kind --------------[ PPDU Wire Frame Formats When transmitted over the wire, the PPDU classes described above in Table 2 look like this: Common Header 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GFI | LGN | LCN | TYPE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : :0 : : : :0 1 2 3: : : +-+-+-+-+ 1 0 == Modulo 128 : : |Q|D|Mod| 0 1 == Modulo 8 frame: : +-+-+-+-+ : : ______________________________/ / / _____________________________/ : / : : : : PPDU [1] - Call Request/Incoming Call : : :0 : 1 0 32/128 :0 1 2 3 4 5 6 7:8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 Bytes +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------+-+-+-+-+-+-+-+-+-----+-----+ | Hex 0x0B |Calling|Called |Called|Calling|0 0 Facilities |Facil|Data | | |AddrLen|AddrLen|Addr |Addr | Length |ities| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------+-+-+-+-+-+-+-+-+-----+-----+ : : : : : : PPDU [2] - Call Accepted/Confirmation :0 : 1 0 :0 1 2 3 4 5 6 7:8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------+-+-+-+-+-+-+-+-+-----+ | Hex 0x0F |Calling|Called |Called|Calling|0 0 Facilities |Facil| | |AddrLen|AddrLen|Addr |Addr | Length |ities| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------+-+-+-+-+-+-+-+-+-----+ : : : : : : PPDU [3] - Clear Request/Indication : : :0 : 1 2 :0 1 2 3 4 5 6 7:8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 <128 bytes +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hex 0x13 | Clear Cause | Diag. Code | User Data | | | | (Optional) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : :0 : :0 1 2 3 4 5 6 7: +-+-+-+-+-+-+-+-+ | Hex 0x17 | PPDU [4] - Clear Confirmation | | +-+-+-+-+-+-+-+-+ : : : : PPDU [5] - Data : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P(R)|M| P(S)|0| User data - 128/256/512/2048/4096 Bytes | | | | | | ................................ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : PPDU [6] - Interrupt Request : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hex 0x27 | User data < 32 bytes | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+ | Hex 0x27 | PPDU [~6] - Interrupt Confirmation | | +-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+ | P(R)|0 0 0 0 1| PPDU [7] - Receiver Ready | | | +-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+ | P(R)|0 0 1 0 1| PPDU [8] - Receiver Not Ready | | | +-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+ | P(R)|0 1 0 0 1| PPDU [9] - Reject | | | +-+-+-+-+-+-+-+-+ : : : : PPDU [A] - Reset Request :0 : 1 2 :0 1 2 3 4 5 6 7:8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hex 0x1B | Reset Cause | Diag. Code | | | | (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : :0 : :0 1 2 3 4 5 6 7: +-+-+-+-+-+-+-+-+ | Hex 0x1F | PPDU [B] - Reset Confirmation | | +-+-+-+-+-+-+-+-+ : : : : PPDU [C] - Restart Request : : :0 : 1 2 :0 1 2 3 4 5 6 7:8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hex 0xFB | Reset Cause | Diag. Code | | | | (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : :0 : :0 1 2 3 4 5 6 7: +-+-+-+-+-+-+-+-+ | Hex 0xFF | PPDU [D] - Restart Confirmation | | +-+-+-+-+-+-+-+-+ : : PPDU [E] - Diagnostic : : :0 : 1 2 :0 1 2 3 4 5 6 7:8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hex 0xF1 | Diagnostic | Explanation | | | Code | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------[ Abbreviations ] D: Delivery confirmation bit Q: Qualifier bit GFI: Group Format Identifier LCN: Logical Channel Number VCI: Virtual Circuit Identifier LCN: Logical Group Number TYPE: Specified for each numbered PPDU below. P(R): Packet receive sequence number P(S): Packet send sequence number --------------[ PVCs and SVCs Being a network which provides virtual circuit-oriented services on top of a packet-switched network layer, X.25 must provide for call setup. The process of call setup only applies to Switched Virtual Circuits (SVCs). X.25 also has provision for Permanent Virtual Circuits (PVCs). These are VCs for which VCIs have already been assigned - there is no need to explicitly establish the VC using the Call Setup procedure. An IP analogy would be something like a permanently established IP tunnel for which no dynamic setup is performed - the control information has been set up in advance at both endpoints. PVCs are of particular note because the route taken by the packets which make up a PVC conversation is static - it does not change for the duration of the PVC, unlike an SVC, which behaves more like IP in this respect. ------[ VCIs: Remember, This Isn't TCP As can be seen above, all X.25 PPDUs are at least 3 octets long. The Logical Channel Number (LCN) and Logical Group Number (LGN) are a tuple which specify the Switched Virtual Circuit (SVC) or the Permanent Virtual Circuit (PVC) to which the PDU applies (in IP: think TCP or UDP port number - it specifies a particular instance of the protocol endpoint). The LGN is 4 bits wide, whilst the LCN is 8 bits wide, which yields a 12-bit tuple (ie 4096 possible values). Taken together, these are referred to as the Virtual Channel Identifier (VCI). According to X.25's Annex A, the way in which this tuple's addressing space is divided up varies according to the administration of the network concerned. Therefore, which VCIs specify a PVC, and which specify an SVC, is administratively scoped to the local portion of the PSPDN you're in. Like TCP within a modern BSD, port ranges are broken down in a similar manner to the way the IP world breaks the TCP port space into a range of Well Known Ports, Registered Ports, and Outgoing Ports. Instead of the WKPs, we have incoming channel ranges, two-way channel ranges, and outgoing channel ranges. Compare this to a range of channels defined for the local network as hands-off (for incoming calls only, just like the WKPs), laissez-faire (two-way, for example, any port above 1024 in the traditional UNIX TCP permission model), and outgoing only (high port values are often used by many TCP implementations, such as Solaris). Feel free to experiment. This brings us to the X.25 equivalent of portscanning. Think of TCP as only having a 12-bit, rather than a 16-bit, port address space. Virtually all X.25- type networks which we have encountered over the years support LCN addressing. Probing and exploration would be necessary to determine which VCIs specify a PVC in the network under consideration. We anticipate that certain PVCs may be set aside between nodes in a particular network for purposes specific to that network. In this case, the call setup/clearing PDUs will be invalid and non- applicable to the PVC VCIs, so some alternative means of scanning would be necessary. The Interrupt and Restart primitives may be of use in this case. ------[ Max PPDU size and Window Negotiation Packet sizes may vary from 64 bytes to 4096 bytes, although 128 bytes is the most common size on most networks. The maximum PDU size (in IP: think MTU), and packet level windows (in IP: think TCP's window advertisements) in X.25 may be negotiated during the call set-up phase. Call set-up will be examined in the next section. --------------[ State Diagrams State Diagrams describe the states of a protocol and the possible transitions between them, as well as the triggers which cause such transitions, and any side effects. They are essential for visualizing how a protocol actually operates, however, they are not a replacement for watching a protocol actually doing its stuff on the wire. I don't hold much truck with simulations - I personally believe people should learn how protocols work by running sniffers and watching the real thing. I also believe in taking the same pragmatic approach towards learning how operating systems work. There is no replacement for carefully stepping through how things work at machine level using a symbolic debugger and watching how system calls operate, and so on. So it is with network architecture. ------[ Call Setup T1 +---------+ T3 +----<-----| S1 |----->----+ | | Ready | | | +---------+ | Transition Table ! ! ---------------------- +-----+-----+ +------+----+ T1 DTE: Call Request | S2 | | S2 | T2 DCE: Call Connected |DCE Waiting| |DCE Waiting| T3 DCE: Incoming Call +-----------+ +-----------+ T4 DTE: Call Accepted | | | | T5 DCE: Incoming Call | | +---------------+ | | T6 DTE: Call Request | +---->| S5 |<----+ | T7 DCE: Call Connected | T5 | Call Collision| T6 | | +---------------+ | | | | | T2 T7 | T4 | | ! | | +-------+-------+ | +--------->| S5 |<--------+ | Data Transfer | +---------------+ Figure 5: State-Transition diagram for X.25 Call Setup ------[ X.25 on LANs: IWUs When X.25 is in use over a LAN, the LLC protocol is used to encapsulate the X.25 PLP frames. In ITU parlance, an InterWorking Unit (IWU) is used to connect the LAN nodes to the WAN. The equivalent picture in the IP world which most of us are used to is that of a normal Ethernet (or other 802 LAN technology supporting LLC) with a single IP router at one end; this router's IP address is specified as the 'default route' to the outside world for IP- speaking hosts on the Ethernet. The IWU can be regarded roughly in this way - it is a relay which forwards X.25 PLP PDUs from the LAN to the WAN. -0x06-------------------[ X.121 Addressing ] X.25 networks are point addressable, as specified in the X.121 recommendation. At the packet/network layer, each node has an X.121 address - known as a Network User Address (NUA). These are much like IP address, but with a twist; the LCN, or Logical Channel Number component of the X.121 address, can be regarded as roughly analogous to the port number in an IP 5-tuple. Here's a point we should clarify early on: because the PADs used to access many different X.25 networks may vary in their user interface somewhat, this may affect the methods used to enter NUAs, as well as their notation. The idiosyncrasies of specific X.25 networks, in this respect, are not considered in this document (but may be covered within a future document in this series). [ What's a 5-tuple, for those unfamiliar with this notation? 4 dot-quad octets specifying IP address, followed by a 16-bit integer specifying the port number. If you're stuck, think 'database row' or 'hash table entry'. Dictionary dot com has a nice definition of the word tuple if you're still stuck. ] :::::::::::::::::::::: Data Network Identification Code (DNIC) [1] : : :Digit : 1 2 3 4: A: 2-7 denotes country/regional network +-+-+-+-+ 1 denotes a global or satellite network |A|B|B|B| +-+-+-+-+ B: Any decimal digit (0-9) = = : ===== :::::::::::::::::::::::::::::: Network Digit [2] = ================================== Data Country Code (DCC) [2] Figure 6: Digits 1 to 4 of an X.121 NUA X.121 addresses, when specified internationally, are anything from 5 to 14 digits long. You can treat the first 4 digits in two different ways: either the first 3 digits specify a Data Country Code (DCC), or the first 4 digits specify a Data Network Identification Code (DNIC). Which scheme is used depends on whether or not the number you have been assigned, or wish to call, is part of a national X.121 numbering plan. ::::::::::::::::::::::::::::::::: 'zero handler': denotes international : form of X.121 address on SprintNet : 1 :1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|D|D|D|D|A|A|A|H|H|H|H|P|P|:::: Port Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : : :::::::::::::::: DTE Host Address : : : ::::::::::::::::::::: Area Code : :::::::::::::::::::::::::::::: DNIC Figure 7: Example format of an NUA entered into a SprintNet PSN PAD The canonical X.121 address assigned to an X.25 DTE/DCE node, which the ITU refers to as the 'International Data Number', is given by the DNIC together with the Network Terminal Number (NTN). However, the X.25 'phonebook' works much like the national phonebook of the PSTN. You don't need to dial the country code if you're dialling a number in the same country. You might, however, need to dial an 'escape code' of some kind to speak internationally. Just like the PSTN. X.121 does actually specify escape digits for calling nodes addressed in a different numbering plan, e.g. ISDN. This is felt to be beyond the scope of presently envisaged applications for Libnet-X.25, but constructive feedback would be appreciated if this is not the case. - PADs on the more popular PSNs will generally let you specify a particular LCN to connect to during call setup. This is used for subaddressing, which will be discussed in a moment. - It may also be possible, by using the 'Facilities' field of the Call Setup PPDU, to specify particular _network facilities_ to be used for placing and routing your call. This is not unlike dialing a slightly different US country code from the UK to request a marine cable link instead of a satellite link, however, it is nowhere nearly as elaborate as IPv4's Source Routing features, for example. The 'ROA selection' Facility is what makes this possible. The use of User Facilities is often PSN/network specific. Section 6 of the X.25 Recommendations has extensive information on the kinds of facilities which may be available. Of particular interest are the Network User Identification (NUI) and related facilities, which will be described in more detail further on. One good point in X.25's favor is that because the CCITT (and now ITU) specified the network to use a global addressing scheme, it doesn't suffer from the problems which IPv4 does with its 32-bit flat address space. Have a look at the E.146 and X.121 recommendations; specifying details such as country codes as part of a hierarchical addressing scheme can make for more efficient routing. Then again, one might argue that one of IP's very strengths is that it isn't tied to a hierarchical addressing scheme. -----[------------------- LCNs within NUAs: Making an NTN go further. We've already looked at LCNs above, however, a little further explanation is needed. You will often find that an organization or office has a single NUA, as buying NUAs costs money, just like IP addresses. Therefore, it is quite possible that each X.25 node will not have an NUA of its own. In this case, it is possible to specify a Logical Channel Number directly to call into. This is where the difference between DCE and DTE raises its head. The DCE, often an Interworking Unit (IWU, which we'll discuss shortly), will be responsible for the remote end routing - mapping an LCN which you've called in with to a physical device. It's much like talking to a remote IP network of machines which are using a single IP address via NAT, yet indirectly being able to specify which machine behind the NAT you're talking by specifying a port number (where such port mappings exist). This also implies that there will be logic within the DCE to handle the mapping of VCIs with a certain LCN to particular DTEs which are either attached directly via LAPB, or on an attached network, via LLC/SNAP. Again, this brings up the subject of NUA/LCN scanning - if you aren't able to call out to an NUA which has no LCN specified after it, then you may well need to probe further. Common LCN ranges which have often been found by other people to be in use as subaddresses include 1-2, 50-1, 91-93, 98-99. The valid range for subaddressing LCNs is from 1 to 99. -----[------------------- NUA Encoding within the Call Setup PPDUs The digits of an NUA are packed into the Call Request PPDU using good old Binary Coded Decimal (BCD). If you don't know what this is, it's quite possible that you shouldn't be reading this document. If, however, you've simply forgotten, a quick look at Chapter 4 of Brumm & Brumm's _80386 Assembly Language_ textbook will remind you - it's just the binary encoding of individual decimal digits into hex nibbles. Meaning that the bit patterns for A-F are wasted in this encoding, but it generally isn't a big deal, and besides, BCD is easy to handle in silicon. Notice that in the PPDU wire diagrams, the caller/callee address fields are prefixed by length fields, 4 bits wide each. This allows one to specify up to 15 digits of length. In practice, usually only 14 digits are used for the X.121 addresses. The length field specifies the number of hex nibbles (or 4- bit, semi-octets). Each digit is encoded into a BCD nibble. When an odd number of digits is present, the last encoded digit will have the low-order bits padded with zeroes, thus ensuring an even number of octets. Here's a [completely fictional] example: NUA: 2341123756491 [a 234 DCC/DNIC. Looks like it's one in the UK.] The 'Called Address Length' field will look like this: %1101 [13 digits] And, the 'Called Address' field will be formatted like this: closed-networks % ./nua-encode 2341123756491 Length: 13 nibbles (1 padding) Hex: 23 41 12 37 56 49 10 The nua-encode.c program is extremely simple, but it will be made available in the first source code release of Libnet-X.25 in contrib for reference. -----[------------------- X.25 Transports (TPDUs) X.25 has been used in the past with the OSI transport protocols (TP0-TP4), and on its own. Other higher layer protocols have been specified for X.25 such as T3POS (used within credit card authorization systems), ODETTE FTP (used for the transfer of EDI information, and originally specified by the French and German automotive industries), and OSI VT (virtual terminal service for the OSI suite, roughly analogous to telnet). These are application protocols, but they're included here for completeness. As X.25 specifies an end-to-end, reliable, stream-oriented network layer, many applications may not require an additional transport protocol. Such is the case with a simple end-to-end connection functioning as a 'data pipe' which may or may not involve the use of terminal control codes compatible with the terminal equipment in use as the DTE. -0x07-------------------[ Routing in X.25 ] -----[------------------- Routing within X.25 Noticed something? Unlike IP, X.25 PLP frames do NOT contain the NUA you call. In the IP world, every single network-layer PDU, or IP datagram, contains its source and destination address. X.25 PLP PDUs do not. They contain the VCI and nothing else - only the PDUs related to call setup contain the NUAs. This means that something needs to maintain an NUA-to-VCI mapping to ensure X.25 routing happens. You'll find that X.25 protocol stacks on the host end maintain such a mapping, and that the status of current VCIs can be inquired using a command such as netstat (on platforms which may have native support for an X.25 protocol stack exposing a socket interface, such as certain BSDs), or x25stat (found on HP-UX installations with the X.25 packages installed). It's a trap for the unwary - because it isn't like IP. It has more in common with the protocol families seen in the world of telecoms. This telco heritage can also be seen within ATM, which possesses many similar abstractions, even if its cell-oriented, best-effort structure is completely different from X.25. XXX - The protocol used by switches for communication within an X.25 network is not actually specified by the X.25 recommendation - and this is worth bearing in mind. Much as I hate leaving this section unfinished, I have a lack of material here at this time. Rest assured, I will be revisiting this. --------------[ Dynamic Rerouting - Mystery X.25 is known to support dynamic rerouting, given its telco heritage. However, we lack information on how this is achieved, and the PDUs which are used to communicate the route drop-and-reassignment information at this time. We are making every effort to find out how this mechanism works - none of the printed references we've come across document this technique. -0x08-------------------[ PADs ] -----[------------------- PAD: What is a PAD? PAD stands for Packet Assembler/Disassembler. It's a device which allows a simple dumb terminal (or a host running terminal emulation) to participate in an X.25 network, by taking care of the multiplexing behind-the-scenes, and providing well-defined means of control and messaging. The ITU-T recommendations X.3, X.28 and X.29 are related to PADs. A rough IP analog of the PAD: Many IP-based terminal server products are available. Examples of these include the Shiva Lanrover, Xylogics Annex Dialup server, and Hewlett-Packard DTC terminal servers. All of these are capable of performing TCP/IP and Telnet protocol services on behalf of the DTE terminal equipment. This can roughly be regarded as performing the same function as an X.25 PAD does for its attached DTE. Say you dial in with a modem from a machine which isn't immediately capable of running an IP stack, such as a dumb terminal, or a low spec 16-bit machine. Terminal servers solve your problem - and this is essentially what a PAD is. The 4.4BSD-Lite netccitt suite comes with two daemons, nimd and x29d, which allow a BSD UNIX host to provide PAD services. This code can be modified to provide PAD services over modem, or potentially even a 'telnet PAD', allowing people to telnet into the PAD and speak to an X.25 PSN directly from an IP network. [ As the LX25 project is primarily concerned with providing native X.25 services, we focus on this, rather than attempting to deliver PAD services at the same time. ] -----[------------------- X.25 User Facilities As mentioned earlier, section 6 of the X.25 Recommendations describe 'User Facilities' which may be available on an X.25 PSN. Think of them as IP/TCP header options - on methylated spirits, that is. The rationale and description of the facilities themselves can be found in section 6. Wire formats for transitting the facility information can be found in section 7. A few of these are of particular interest to network security personnel developing auditing and probe tools using Libnet-X.25. These are described here briefly. ------[ NUI - Network User Identification The NUI facilities are never transmitted to the remote node - but they may be checked by the switches on the network your packets are transiting. The format of an NUI is typically specific to the PSN you're using, but a recommended NUI format is specified within X.25. ------[ ROA Selection The closest IP analog I can think of to ROA selection is of being able to choose manually which Autonomous Systems are used to forward your packets. Think of loose source routing. You can effectively control call routing and placement if this network facility is supported. ------[ Hunt Group This is a form of load balancing. It works just like hunt groups within a PBX or other telco network. It allows incoming calls destined for a particular address, associated with the hunt group, to be distributed amongst the DTE/DCE nodes making up the group. Compare with LSNAT in IP routing. ------[ Call Redirection & Deflection These should go without saying. If you can obtain access to these facilities, you can end up having a lot of fun with those switches. -0x09-------------------[ Conclusions ] "Glean from rich fields, and the armies will have enough to eat. Take care of your health and avoid stress, consolidate your energy and build up your strength. maneuver your troops and assess strategies so as to be unfathomable." -- Sun Tzu, Art of War, Chapter 11: Nine Grounds We've reviewed several technical topics. Not all of the topics have been explored in riveting close-up action. We have, however, tried to present a broad overview of what goes on in the X.25 family of protocols for an audience more familiar with the DoD Internet Protocols which seem to be very popular nowadays. Hopefully, this document forms a body of information, insights, and links to more in-depth technical data. Just what we need to get started on coding Libnet-X.25, even if this document doesn't actually specify, as of yet, what LX25 will be. That's for future documents in this series to present. Also, we're wary of placing a loaded gun in the hands of the skr1pt k1dd1e menace. This is why you're unlikely to see tools which compile straight out of the box for LX25 just yet. We certainly plan to deliberately break anything we publish which doesn't form part of the core LX25 code. We hope you realize why such measures are necessary. We wish to pursue the benefits of full disclosure in the X.25 arena which has hitherto been dominated by corporate entities. However, full disclosure means that idiots get access to your code, too. I make no representation or warranty about the things we write for this project, and I take no responsibility _other than obfuscating the code in this way_, and exercising my discretion over the release of code which would be truly embarassing for certain parties. Enjoy this initial offering - we will be back with more. Soon. *** Console Message from Caenobite Process ::pinhead:: :: the system... you booted it... we initialised, now you must :: work with us, taste OUR pleasure! :: :: we have such sights to show you! - User Datagram Protocol Keltic Phr0st Dan Moniz "yeah... those blue skies are ahead... blue skies in my head" Dundee, Scotland Friday, May 26th 2000 -0x0A-------------------[ Glossary ] DCE Data Circuit-terminating Equipment DNIC Data Network Identification Code. The country-specific portion of the NUA, ie the first 4 characters. Each X.25 provider in each country has a unique ID. DTE Data Terminal Equipment NUA Network User Address. Similar to an IP address. The format of an NUA is specified in the ITU standard X.121. NUI Network User Identification. The user name/password that you use to get access to (and use) a commercial packet switched network. PAD Packet Assember/Disassember: Hardware or software device for splitting a data stream into discrete packets for transmission over some medium and then reforming the stream(s) at the receiver. The term is most often used for interfaces to X.25 lines. PSN Packet Switching Networks, such as GNS Dialplus, SprintNet, JANET, and other European/International networks, usually encorporating the X.25 protocol. X.25 An ITU-T standard protocol suite for the DTE-DCE interface in a packet- switched network, approved by ISO. X.25 defines standard physical layer, data link layer and network layers (layers 1 through 3). It was developed to describe how data passes into and out of public data communications networks. X.25 networks are in use throughout the world. X.28 Roughly analogous to a dial-up version of X.25. -0x0B-------------------[ References ] ------[ Books ] 80386 Assembly Language: A Complete Tutorial and Subroutine Library by Penn Brumm & Don Brumm McGraw-Hill ISBN 0-07-155992-2 Data Communications, Computer Networks and Open Systems - 4th Edition Fred Halsall Addison-Wesley ISBN 020142293x http://cseng.aw.com/bookdetail.qry?ISBN=0-201-42293-X&ptype=0 Computer Networks, 3rd Edition Andrew S. Tanenbaum Prentice-Hall International Editions ISBN 0133942481 http://www.prenhall.com/tanenbaum/ ------[ Web ] The Packet Factory Project http://www.packetfactory.net/ udp's home page http://www.packetfactory.net/~udp/ Digital Britain: The e-Commerce Survivors By Lindsay Nicolle http://www.syncordia.bt.com/we_are/microsoft/digital_britain/article3.htm Dennis Jackson, X.25 Network Tracing For Internet Users, August 1992 http://www.ja.net/CERT/Jackson/X25_tracing.txt Various DNIC listings http://www.hackcanada.com/canadian/hacking/datapacothernet.txt http://www.orionltd.co.uk/reference/x25dnic.htm http://www.f41th.com/F08-11.TXT HDLC - A Technical Overview http://members.tripod.com/~vkalra/hdlc.html comp.dcom.lans.ethernet FAQ http://www.faqs.org/faqs/LANs/ethernet-faq/index.html The Complete Introductory Guide To SprintNet ... and similar PSNs By Doctor Dissector c/o Black Crawling Systems Archives @ L0pht Heavy Industries http://www.l0pht.com/pub/blackcrwl/telecom/psnintro.txt The Great CRC Mystery by Terry Ritter http://www.io.com/~ritter/ARTS/CRCMYST.HTM The 4.4BSD Lite Source Code [ WARNING: 39.3Mb. ] http://sunsite.org.uk/packages/4.4bsd-lite/4.4BSD-Lite.tar.gz ------[ Internet RFCs ] The UK's main local mirror of IETF RFCs is kept at http://www.sunsite.org.uk/packages/rfc. Your mileage may vary. 0874 Critique of X.25. M.A. Padlipsky. Sep-01-1982. (Format: TXT=36386 bytes) (Status: UNKNOWN) 1042 Standard for the transmission of IP datagrams over IEEE 802 networks. J. Postel, J.K. Reynolds. Feb-01-1988. (Format: TXT=34359 bytes) (Obsoletes RFC0948) (Also STD0043) (Status: STANDARD) 1053 Telnet X.3 PAD option. S. Levy, T. Jacobson. Apr-01-1988. (Format: TXT=48952 bytes) (Status: PROPOSED STANDARD) 1086 ISO-TP0 bridge between TCP and X.25. J.P. Onions, M.T. Rose. Dec-01-1988. (Format: TXT=19934 bytes) (Status: UNKNOWN) 1090 SMTP on X.25. R. Ullmann. Feb-01-1989. (Format: TXT=6141 bytes) (Status: UNKNOWN) 1183 New DNS RR Definitions. C.F. Everhart, L.A. Mamakos, R. Ullmann, P.V. Mockapetris. Oct-01-1990. (Format: TXT=23788 bytes) (Updates RFC1034, RFC1035) (Status: EXPERIMENTAL) 1209 Transmission of IP datagrams over the SMDS Service. D.M. Piscitello, J. Lawrence. Mar-01-1991. (Format: TXT=25280 bytes) (Also STD0052) (Status: STANDARD) 1226 Internet protocol encapsulation of AX.25 frames. B. Kantor. May-01-1991. (Format: TXT=2573 bytes) (Status: EXPERIMENTAL) 1236 IP to X.121 address mapping for DDN. L. Morales, P. Hasse. Jun-01-1991. (Format: TXT=12626 bytes) (Status: INFORMATIONAL) 1356 Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode. A. Malis, D. Robinson, R. Ullmann. August 1992. (Format: TXT=32043 bytes) (Obsoletes RFC0877) (Status: DRAFT STANDARD) 1381 SNMP MIB Extension for X.25 LAPB. D. Throop, F. Baker. November 1992. (Format: TXT=71253 bytes) (Status: PROPOSED STANDARD) 1382 SNMP MIB Extension for the X.25 Packet Layer. D. Throop. November 1992. (Format: TXT=153877 bytes) (Status: PROPOSED STANDARD) 1461 SNMP MIB extension for Multiprotocol Interconnect over X.25. D. Throop. May 1993. (Format: TXT=47945 bytes) (Status: PROPOSED STANDARD) 1598 PPP in X.25. W. Simpson. March 1994. (Format: TXT=13835 bytes) (Status: PROPOSED STANDARD) 1613 cisco Systems X.25 over TCP (XOT). J. Forster, G. Satz, G. Glick, R. Day. May 1994. (Format: TXT=29267 bytes) (Status: INFORMATIONAL) 1700 Assigned Numbers. J. Reynolds, J. Postel. October 1994. (Format: TXT=458860 bytes) (Obsoletes RFC1340) (Also STD0002) (Status: STANDARD) 2364 PPP Over AAL5. G. Gross, M. Kaycee, A. Li, A. Malis, J. Stephens. July 1998. (Format: TXT=23539 bytes) (Status: PROPOSED STANDARD) ------[ ITU Standards ] X.3 Packet Assembly/Disassembly Facility (PAD) in a Public Data Network X.25 Interface between DTE and DCE, for terminals operating in the packet mode, and connected to public data networks by dedicated circuit X.28 DTE/DCE interface for a start-stop mode DTE accessing the PAD facility, in a public data network, situated in the same country X.29 Procedures for the exchange of control information and user data between a PAD facility and a packet mode DTE or another PAD X.32 Interface between DTE and DCE for terminals operating in the packet mode and accessing a packet PSDN through a PSTN or an ISDN or a circuit switched public data network [i.e. Using a modem to speak packet-mode X.25 directly] X.70 Terminal and Transit Control Signalling System for Start-Stop Services on International Circuits between Anisochronous Data Networks X.71 Decentralized Terminal and Transit Control Signalling System on International Circuits between Synchronous Data Networks X.75 Packet Switched Signalling System between public networks providing data transmission services X.96 Call Progress Signals in Public Data Networks X.110 International routing principles and routing plan for public data networks X.115 Definition of Address Translation Capability in public data networks X.116 Address Translation and Resolution Protocol X.121 International Numbering Plan for public data networks X.139 Echo, Drop, Generator and test DTEs for measurement of performance values in public data networks when providing international packet-switched services -0x0C-------------------[ Acknowledgements ] Libnet-X.25 was brought to you by the combined talents of: udp Documentation, original concept, and C code. Keltic Phr0st Extensive source material, code, and advanced concepts. dnm Intellectual quarterbacker. This project may also contain code which has been previously released under the 'Tewlz 4 Fewlz' banner, and all author credits therein are acknowledged. Libnet-X.25 would not have been possible without the assistance of various people, some of whom have chosen not to be named. Given the sensitivity of some of the material, readers will understand that this is necessary. Thanks and shout-outs to: route for the original Libnet concept. par for his comments and suggestions. b00ger for his valuable input & support. Darkcyde for his ideas. cjunky for providing shell & hosting services. scanner for moral support & proofing assistance. O0 for providing encouragement. gamma for other suggestions. Special thanks are due to Szyzyg, without whose trance playlist at Myplay.com continually filling my ears, big chunks of this paper simply wouldn't have been possible. -0x0D-------------------[ Contact Info ] Bruce M. Simpson aka 'udp' Keltic Phr0st Dan 'dnm' Moniz Mike D. Schiffman aka 'route' Canonical URL for this document: http://www.low-level.net/pub/udp/papers/x25-preamble.txt -0x0E-------------------[ Appendix A: LLC/SNAP ] The IEEE 802 series of LAN standards only specify a best-effort, connectionless, datagram-oriented service. This is sufficient for encapsulating a protocol such as IP, however, other protocol families may require the services defined within the LLC. Because LLC effectively provides us with an HDLC-derived means of encapsulating X.25 within Ethernet, we'll take a more detailed look at it before proceeding. LLC defines both a connectionless, datagram-oriented service, and a connection- oriented, stream-like service. Let's just recap on the structure of an Ethernet frame, as specified by IEEE ANSI/802.3 1933-00: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 48-bit Source MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 48-bit Destination MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 16-bit Length or Type ** | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Data unit and padding (46-1500 bytes) | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame Check Sequence (32 bits, CRC32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ** If the Length field is > 0x0600 hex (1536 decimal), then it specifies the protocol used inside the Data Unit (this is Ethernet behavior). If the length is between 46 and 1500 decimal, then it specifies the length of an encapsulated LLC frame (this is IEEE 802.3 behavior). _This is the difference between Ethernet-II and IEEE 802.3_ as will be explained below. Here's the structure of a typical Ethernet frame with LLC inside: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 48-bit Source MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 48-bit Destination MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 16-bit Length | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | 8-bit DSAP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 8-bit SSAP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 16-bit or 8-bit Control word | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Data | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame Check Sequence (32 bits, CRC32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note the addition of the LLC-specific fields which have been illustrated below: 0 0 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ |I|Address Bits | |C|Address Bits | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 8-bit DSAP 8-bit SSAP The Service Access Point (SAP) fields provide a simple demultiplexing capability for IEEE 802.3 frames. They are similar in purpose to the Ethernet II 'type' code. Recall from previous diagrams that Ethernet II is the most common encapsulation for IP which you are likely to find in use in the wild. Fire up your sniffer. Chances are, 99.9% of the traffic on many networks these days is going to consist of IP within Ethernet-II framing. This is where the confusion between Ethernet and 802.3 framing begins. At this point, you may be confused as to what all these fields are for. If you're familiar with Novell NetWare's IPX/SPX, all will be cleared up in a moment. Because, damn, I always wondered what that SNAP thing was. ------------------------[ SAP codes and NetWare: A brief aside If you've ever configured a Novell NetWare IPX/SPX based network, on legacy PCs using the ODI protocol stack, you'll be familiar with keywords like "Ethernet_802.3", "Ethernet_802.2", "Ethernet_SNAP" and so on for specifying the framing to use on the physical medium for Novell traffic in the LSL/ODI/NLM configuration file NET.CFG. Each framing is different. "Ethernet_II" selects an encapsulation similar to that which has already been described for IP. This is the most common kind of IPX framing, and it uses a 'Type' field code of 0x8137. "Ethernet_802.3" selects a "raw" 802.3 framing, whereby the 'Type/Length' field specifies packet length, and the first two bytes of the Information field in the Ethernet frame are 0xFF-0xFF. This sequence is used because it makes no sense in 802.2 LLC. It is something of a hack, however, it was Novell's default framing until NetWare 4.0 was released (!). "Ethernet_802.2" uses a proper 802.2 header, with the DSAP and SSAP fields set to 0xE0, which has been recognized as standing for IPX. It sets the Control byte to 0x03 - therefore it encapsulates IPX within the connectionless Type 1 LLC Datagram. "Ethernet_SNAP" sets the DSAP and SSAP fields to 0xAA, which implies the use of a Subnetwork Access Protocol (SNAP) header. The Organizational Unit ID code is almost always 0x00-0x00-0x00, and the EtherType within the SNAP is set to the same code used for Ethernet-II framing, which is 0x8137. Confused? Hopefully, you won't be. This is just to clear up what the SAP field is for and what it does, and why two apparently congruent standards (whose names are often interchangably used - albeit incorrectly) disagree where a 16- bit field is concerned - is it a length, or a type code? 0x0600 decides. For more information about how IP is carried within IEEE 802 series networks, see RFC 1042. ------------------------[ SAP and SNAP Basically, the SAP fields in LLC are used to specify a particular protocol family or layer for demultiplexing purposes. The SNAP header was specified as an extension to the LLC SAP encoding - it was felt that a 7-bit code wasn't wide enough - and a 5 byte tuple ought to be enough for anybody. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Organization Code [3 Bytes] | EtherType [2 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: the IEEE 802.2 SNAP header. This is roughly analogous to the 'protocol' field in an IP header, albeit the IEEE specified something far more extensible, and probably far less useful. SNAP is used for encapsulating IP itself, as well as ARP, on strictly 802 compliant networks. This includes SMDS (often used as the basis for a DQDB- based MAN), and Fibre Channel, the new SCSI bus physical interface. Such encapsulation is detailed in RFC 1209 and RFC 2625 respectively. +------+-------------------------------------------+ | Code | Protocol | +------+-------------------------------------------+ | 00 | Null SAP | | 02 | LLC Sublayer Management: Individual | | 03 | LLC Sublayer Management: Group | | 06 | DoD IP (Internet Protocol) | | 42 | BPDU (Spanning Tree) | | 7E | X.25 PLP (ISO 8208) | | 8E | Proway Active Station List Maintenance | | AA | SNAP (Sub-Network Access Protocol - SNAP) | | E0 | Novell IPX | | F0 | NBF (NetBIOS Framing Protocol / NetBEUI) | | FE | ISO Network Layer Protocols | | FF | Global DSAP | +------+-------------------------------------------+ Table 3: Typical IEEE 802.2 SAP codes. A SAP can also be thought of as the address of a software port, as defined by the OSI model. +0xFF+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++[ EOF ]