/* * Protocol Vulnerabilities within the X.25 Networking suite * (encompassing Basic introduction to X.25 network operation) * * by Keltic Phrost (kp@closed-networks.com) * http://closed-networks.com/~kp * kp on irc, usually found lurking in #phuk, #phsc and #2600-uk * * Many thanks to the closed-networks.com team for the services they provide, * including floorspace, beer and bandwidth. * * Thanks to the posse for relentlessly ripping the piss out of my * pre-DNSCON unconsciousness. Bastards, the lot of you. ;-) * */ ------------ Introduction ------------ This paper is meant to serve as both an introduction to the world of the X.25 network and to highlight several critical flaws inherent in the networking architecture applied therein. Understanding of basic data communications is the only pre-requisite. I'd like this paper to have been far more in-depth. However; Until such time as I can prove (beyond doubt) the vulnerabilities discussed exist and are workable outside of a lab enviroment, I'll save both myself and you the reader, the grinding boredom of reading proof-of-concept code that actually proves sweet fuck all. References to the former CCITT should be read as ITU. I suppose it helps clarify the chronology of the protocol to keep the two seperate, YMMV. -------- Contents -------- 1. The history of X.25 and it's architecture 2. Related protocols and reccomendations 3. Previous security flaws and issues 4. Current Issues affecting X.25 networks 5. Risk Assessment and worst case scenario 6. Bibliography and footnotes Appendices Chapter one goes into *considerable* technical detail with regard to the underlying architecture of the protocol suite; If you understand the suite intrinsically, skip the history lesson and go to Chapter 5. Chapter two allies those mysterious X additions X.3, X.28 and X.29 to those layers of the OSI protocol stack not already covered in previous chapters, and goes some way towards clarifying their application and nuances. Chapter three briefly covers notable security breaches in X.25 networks since its inception. Chapter four is an overview of the "State of Address" with regard to the current status of X.25, and a short illustration of the extent to which X.25 is embedded in the core functionality of the UK's core IT infrastructure. Chapter five is the tail of the paper, and examines possible scenarios with regards to X.25 packet / frame level security, their ramifications and possible outcomes. Caffeine started to have a detrimental effect on the paper at this stage, so please reserve judegement for the technical content. :-) ---------------------------------------------------------------------------- 1. The history of X.25 and its architecture ---------------------------------------------------------------------------- X.25 is, contary to popular belief, not a networking architecture, but merely a reccomendation to end implementers of WANs and their associated hardware / software. X.25 merely governs the interfacing of DTE to DCE for connection to Wide Area Network packet switched networks. The operation of the core network itself is transparent to the end users, and can safely be "glossed over" by those involved in installation and operation of the end nodes. For the purposes of this paper, however, and to ease the learning curve for the beginner, packet switching networks which provide X.25 interfacing shall be referred to hereby simple as XPDNs. To the layman, X.25 may also seem like an archaic choice for networking, bringing as it does a whole swathe of problems associated with routing, billing, internetworking, systems integration and security to the administrator firmly rooted in the TCP/IP environment. There are several reasons why an operating agency would choose X.25 however, and these shall be discussed later in this text. X.25 was initially conceived as a child project of the ARPA, whose aim was to provide a network architecture that would survive the cataclysmic destruction of one or more critical nodes by using intelligent routing principles and data division into packets, allowing one data element, for example, a simple file with order details, to be split into packets upon leaving the sender, and to be re-assembled un-scathed at the receiving end, regardless of the state of flux within the network itself. However, X.25 itself was not produced from the above work, and it was the later work of the National Physical Laboratory at Teddington and their research into Packet switching research that gave birth to the concept of the PDN, thus making previously research level technology available to the commercial sector. Early commerical XPDNs to go operational were Telenet (USA) in 1975, Datapac (Canada) and Tymnet in 1977, Transpac (France) and Accunet (US) in 1978 and EPSS (UK) in 1975. Clearly, a standard was needed across the board to interface hardware and software to these networks. The result was CCITT reccomendation X.25, described as: "Interface between data terminal equipment and data circuit-terminating equipment for terminals operating in the packet mode on public data networks" Furthermore, there was also a need for Inter-XPDN networking to provide inter-operability between these networks, lest they remain isolated and commercially stale. Thus, reccomendation X.75 was drafted, and is described as: "Terminal and transit call control procedures and data transfer systems on international circuits between packet switched data networks" To examine the overall architecture of such a network, the following point must be stated again; X.25 does not define the internal architecture of a XPDN, nor does it define it's operation. This is left to the implementor or Registered Private Operating Agency (RPOA). Figure 1.1 - XPDN Architecture ------------------------------ Server Workstations +--+ +----+ +----+ | | | WS | | WS | | | +----+ +----+ +--+ IEEE 802.3 | | | LAN ---+------+------+-------+------ | | +----------------+ | X.25 Gateway | +----------------+ | .......................|...................... . | . . +---+ . . +--------------|DCE|-------------+ . . | +---+ | . . | | | . . +-+ | | . . |N|------+ | +-+ . . +-+ | | |N| . . | | | +-+ . . | +-+ +-+ | . . | |N|------|N| | . . +-+ +-+ +-+ | . . | | | | . . +-+ | | +-+ . . |N|--------------------------------|N| . +---+ . +-+ | | +-+ . +----|DTE| . | | | | . | +---+ . +-------+ | | +---+ . +---+ . | +--+ +------------|DCE|----|PAD| . | | +---+ . +---+ . +---+ | . | +---+ . |DCE|--+ . +-----|DTE| . +---+ . +---+ .............|................................ | +----------+----+ Key: | OO |||| | | |----------| | . Denotes XPDN cloud | | | N Denotes Switching node +----------+----+ WS Denotes Workstation Host Computer --- The XPDN can use one of two methods for internal communications. One is the datagram service, where each packet is given a destination and source address and dropped into the network to arrive at it's destination. Each packet may find it's own route to the end host; delivery is not guaranteed however, being that it is a stateless connection between the receiver and sender. Datagram service was elminated from X.25 operation in 1980 and replaced with the Fast Select facility. The second method of internal communication is known as a virtual circuit, as demonstrated in Figure 1.2 . This is a DTE<->DTE circuit, established in much the same way as a telephone call. Ciruit connection is established prior to any data transfer, and the circuit provides a dedicated virtual route through the XPDN for all packets associated with the circuit. There is a slight propagation delay (inherent within any wide area or long distance networking methodology), but all packets arrive in sequence without duplication. Figure 1.2 - Virtual Circuit Connection --------------------------------------- |<- X.25 ->| |<- X.25 ->| ........................................ . . +---+ . +---+ +---+ . +---+ |DTE|----------|DCE| |DCE|----------|DTE| +---+ . +---+ +---+ . +---+ Host A . XPDN . Host B ........................................ |<-------------- Virtual Circuit ---------------->| The "virtual" description arises from the appearance of a continuous physical circuit; it is simply a series of routing table entries within the various switching nodes within the XPDN, allocated and de-allocated with each virtual call setup and cleardown. From the OSI Protocol perspective, all 7 layers are employed for Host <-> Host communications. However, only the lower 3 layers are applied for the XPDN. These lower three layers are the *essence* of the X.25 protocol suite. Figure 1.3 - OSI <-> X.25 protocol layer substrate -------------------------------------------------- OSI X.25 +------------------+ | Application | +------------------+ | Presentation | +------------------+ | Session | +------------------+ | Transport | +------------------+ +-------------------+ | Packet Level | <---------------> | Network layer (3) | +------------------+ +-------------------+ | Frame Level | <---------------> | Link Layer (2) * | +------------------+ +-------------------+ | Physical Level | <---------------> | Physical Layer (1)| +------------------+ +-------------------+ DTE customer side DTE/DCE Interface DCE network side --- X.25 Physical Layer ------------------- The X.25 Physical Layer offers a variety of hardware options provided by the CCITT for accomodation of hardware disparity over several continents and RPOAs. Pan-european XPDNs utilise the X.21 interface, defined as: "General purpose interface between data terminal equipment and data circuit terminating equipment for synchronous operation on public data networks." X.21 is an electrically balanced interface similar to EIA-422, and is utilised in host countries where the access to the XPDN can be facilitated through digital rather than analogue lines. Within the UK RPOA operated primarily by British Telecom plc, the X.21 bearer service is known as Kilostream; An analysis of a Kilostream interface unit and relevant information can be found at the end of this paper in Appendice A. X.21 is interfaced by means of a DB-15 connector, allowing a maximum DTE<->DCE cabling distance of 1,000 meters, and may operate in synchronous, half or full-duplex modes with transmission rates up to 10Mbps. X.21bis may also be used, defined as: "Use on public data networks of data terminal equipments which are designed for interfacing to synchronous V-series modems." X.21bis specifies the use of V.24/V.28 interfaces, similar to EIA-232-D. (Note : RS232C is an earlier standard, but also similar). Most XPDN applications in the US utilise EIA-232-D or RS232C as the physical layer interface. Another third option is V.35 used for transmission speeds of 48kbps in Europe or 56kbps in the US. V.35 is an electrically balanced 34 pin connector, and typically utilised in DSU/CSUs connected to 56kbps digital leased lines. X.25 Data Link Layer -------------------- Link Access Procedure Balanced (LAPB) protocol is structured after the ISO HDLC (High Level Data Link Control) format. LAPB was initially conceived as a point-to-point connection between the DTE (Host) and the DCE (attaching network node). Transmission is serial, synchronous, and full-duplex. Balanced designation within LAPB indicates that either DTE ir DCE may initiate a call-setup or cleardown. The following text regarding the encapsulation is derived from an earlier text on LAPB framing and sequencing. Frame sequence -------------- Both flags are 01111110. Frame header consists of address and control fields, one octet each; Frame trailer consists of 16 bit CRC sequence (two octets). One PLP Packet per frame as demonstrated. Figure 1.4 - LAPB Framing of X.25 PLP ------------------------------------- |< 1 Packet >| +------+-----+ |Header|User | | |Data | | |Field| Packet layer +------+-----+ +----+ +-----------------+ +------------+ +-----------+ +----+ |Flag| |Frame layer | |Info | |Frame check| |Flag| | | |control & address| |Field | |sequence | | | Frame Layer +----+ +-----------------+ +------------+ +-----------+ +----+ |<-------------- 1 Frame --------------------->| +------------------------------------------------------------+ | Synchronous Bit Stream | Physical Layer +------------------------------------------------------------+ Here's the framing in more detail. The Address field contains one of two possible addresses - - a (03H) for DTE - B (01H) for DCE Command frames carry the address of the opposite device, eg: If the DTE initiates a command, the address field must contain a 01H (DCE). Response (R) frames carry the address of the responder. Eg: If the DCE issues a response, a 01H would be placed in the address field. Figure 1.5 - LAPB Frame Structure --------------------------------- +--------+-------+-------+------+-----------+--------+ | Flag |Address|Control|Info |Frame Check| Flag | | |Field |Field |Field |Sequence | | +--------+-------+-------+------+-----------+--------+ |01111110|8 bits |8 Bits |N-bits| FCS |01111110| | F | A | C | I | 16 bits | F | +--------+--+----+---+---+----+-+-----------+--------+ | | | | | | Address Field| | | | | +---------+-+------+---------+| |Direction|Commands|Responses|| +---------+--------+---------+| |DTE->DCE | 01(B) | 03(A) || |DCE->DTE | 03(A) | 01(B) || +---------+--------+---------+| | | Control Field | | | +-------------+------+------+----------------+-------------+-----------------+ |Format | Commands | Responses | Hex Coding | Encoding | +-------------+-------------+----------------+-------------+-----+-----+-----+ | | | | | 876 | 5 | 4321| | | | | +-----+-----+-----+ |Supervisory | RR | RR | X1 | N(R)| P/F | 0001| | | RNR (LAPB) | RNR | X5 | N(R)| P/F | 0101| | | REJ (ONLY) | REJ | X9 | N(R)| P/F | 1001| | | | | | | | | +-------------+-------------+----------------+-------------+-----+-----+-----+ |Un-numbered | SARM(LAP) | DM(LAPB) | 0F or 1F | 000| P/F | 1111| | | SABM(LAPB) | - | 2F or 3F | 001| P | 1111| | | SABME(LAPB) | - | 6F or 7F | 011| P | 1111| | | DISC | - | 43 or 53 | 010| P | 0011| | | | UA | 63 or 73 | 011| F | 0011| | | | CMDR(LAP) > | | | | | | | | FRMR(LAPB)> | 87 or 97 | 100| F | 0011| | | | | | | | | +-------------+-------------+----------------+-------------+-----+-----+-----+ |Information | I | - | Even Number| N(R)| P |N(S)0| +-------------+-------------+----------------+-------------+-----+-----+-----+ | | Information Field | +-------------------+-----+ | Information Field | FCS | +-------------------+-----+ Information Frame : Contains one Packet Level Packet FRMR / CMDR Frame : +-----------+--------+------+--------+-----+---------+-----+-----+-----+-----+ | 8-bits | 876 | 5 | 432 | 1 | 8765 | 4 | 3 | 2 | 1 | +-----------+--------+------+--------+-----+---------+-----+-----+-----+-----+ | REJECTED | | | | | | | | | | | CONTROL | | | | | | | | | | | FIELD | V(R) | C/R | V(S) | 0 | 0000 | Z | Y | X | W | +-----------+--------+------+--------+-----+---------+-----+-----+-----+-----+ | | 0 = COMMAND | 1 = RESPONSE | | W When set, indicates Control field was invalid X When set, indicates the frame received contained and info field which is not permitted with the command. Bit W must be set in conjunction with Bit X. Y When set, N1 of receiving station was exceeded. Z When set, indicates invalid N/R count. The control field specifies the format the frame contains; Information (I) frames are used for the sequenced transfer of data between DTE and DCE. The LSB of the control field is zero (indicates I format). Two frame sequence counters - N(S) for sending and N(R) for receiving or ACK'ing - are also included within the control field. Supervisory frames (S) are used to supervise the exchange of information frames by ACK'ing good frames and Rejecting bad ones. The two LSBs of the Supervisory frame control field are set to 01, and the remaining bits carry a code indicating the frame type and acknowledgement number N(R). Unnumbered (U) frames are used to establish and disconnect the DTE/DCE link. U frames are indicated when the two LSBs of the control field are set to 11. The remaining bits are encoded to indicate the type of frame being sent. Common to all three frame types is the Poll/Final bit (P/F) that indicates the urgency of the command or response. X.25 Network / Packet Layer --------------------------- The network (or in this context, packet) level protocol holds the defintion for the formatting of packets that are to sent into the XPDN by the local DTE for delivery to the target remote DTE. 17 different packet types are defined, designated by the third octet (packet type) of the packet itself. Several sub-categories exist within these 17 types: Table 1.1 - X.25 Packet types / categories ------------------------------------------ Packet type Service DCE to DTE DTE to DCE SVC PVC - Call setup / clearing Incoming Call Call request X Call Connected Call accepted X Clear Indication Clear request X DCE Clear Confirmation DTE clear confirmation X - Data & Interrupt DCE Data DTE data X X DCE Interrupt DTE interrupt X X DCE interrupt confirm DTE interrupt confirm X X - Flow control and Reset DCE RR DTE RR X X DCE RNR DTE RNR X X DTE REJ X X Reset Indication Reset Request X X DCE Reset Confirmation DTE Reset Confirmation X X - Restart Restart Indication Restart Request X X DCE Restart confirm DTE Restart confirm X X - Diagnostic Diagnostic X X - Registration Registration Confirm X X Registration Request X X --- Call setup packets are used for establishing virtual circuits (end to end interconnection between via the PDN) between DTEs. Data and interrupt packets are used to transfer information; Expedited data, such as urgent messages from layers above the packet layer, use the interrupt packet format. Routine information is transferred in data packets. Flow control and reset packets provide control mechanisms for the virtual circuits. The restart packet is used to re-initialize the DTE/DCE interface following an error condition. Diagnostic packets are generated by the network (DCE) in response to erroneous packets received from a DTE, or if one of the PLP watchdog timers expires. Registration packets are used to request or obtain specific parameters of user facilities, such as non-default packet or window size, where service provided may be either switched or permanent. The format of the first two octets of each packet is identical. The first four bits are referred to as the GFI (General Format Identifier), which is responsible for determining data packet format, acknowledgement parameters and sequencing counter sizes. The next twelve bits are the Logical Channel Identifier, which indicates which of the 4096 possible logical channels is currently in use for this packet. This LCI includes the Logical Group Number (LGN) comprised of four bits, and the Logical Channel Number which is comprised of 8 bits. To describe the exact format bit by bit of each packet used within the packet layer is far beyond the scope of this paper, but Figure 1.6 contains an overview of each packet and general content / Identifiers. Figure 1.6 - Packet Layer Protocol Encoding ------------------------------------------- 4 BITS 4 BITS 8 BITS 8 BITS +-----+------+------+-------------+ | GFI | LGN | LCN | PACKET TYPE | +-----+------+------+-------------+ Variable lengths 0 through F BCD | +---+---+ | | +--+-------+------+------+-------+-----+----+---+---------+ CALL REQUEST |0B|CALLING|CALLED|CALLED|CALLING|FAC. |FAC.|PID|USER DATA| | |ADDR |ADDR |ADDR |ADDR |0 LEN| | 1 | 15 | | |LEN |LEN | | | | | | | +--+-------+------+------+-------+-----+----+---+---------+ +--+-------+------+------+-------+-----+----+ CALL ACCEPT |0F|CALLING|CALLED|CALLED|CALLING|FAC. |FAC.| | |ADDR |ADDR |ADDR |ADDR |0 LEN| | | |LEN |LEN | | | | | +--+-------+------+------+-------+-----+----+ 876 5 432 1 +----+-+----+-+-------------------------------------------+ DATA |P(R)|M|P(S)|0|USER DATA (UP TO 128 BYTES DEFAULT) | +----+-+----+-+-------------------------------------------+ 8 bits +----+---------------+-----------------+ RESET REQ. | 1B | RESET CAUSE | DIAGNOSTIC CODE | +----+---------------+-----------------+ +----+---------------+-----------------+ RESTART REQ. | FB | RESTART CAUSE | DIAGNOSTIC CODE | +----+---------------+-----------------+ +----+----------------+-----------------+ CLEAR REQ. | 13 | CLEARING CAUSE | DIAGNOSTIC CODE | +----+----------------+-----------------+ +----+-----------------+------------------------+ DIAGNOSTIC | F1 | DIAGNOSTIC CODE | DIAGNOSTIC EXPLANATION | +----+-----------------+------------------------+ +----+-----------------------------------------+ INTERRUPT | 23 | INTERRUPT USER DATA (32 OCTETS MAXIMUM) | +----+-----------------------------------------+ +------+-------+ RECEIVE READY | P(R) | 00001 | +------+-------+ +------+-------+ RECEIVE NOT READY | P(R) | 00101 | +------+-------+ +------+-------+ REJECT | P(R) | 01001 | +------+-------+ +----+ INTERRUPT CONF. | 27 | +----+ +----+ CLEAR CONF. | 17 | +----+ +----+ RESTART CONF. | FF | +----+ +----+ RESET CONF. | 1F | +----+ 8 bits 8 bits 109 octet maximum +----+-------+--------+------------------+ REGISTRATION REQ. | F3 | 00 | 0 LEN | REGISTRATION | +----+-------+--------+------------------+ 8 bits 8 bits 8 bits 4 bits 109 octet max +----+-------+------------+------+-------+------------+ REGISTRATION CONF. | F7 | CAUSE | DIAGNOSTIC | 00 | 0 LEN |REGISTRATION| +----+-------+------------+------+-------+------------+ --- Protocol Identifer Table +----------+----------------------------+ | Bits 8,7 | Reccomended use | +----------+----------------------------+ | 0 0 | CCITT Recs. (eg X.29) | | 0 1 | XPDN Specific | | 1 0 | Res. for international use | | 1 1 | User defined | +----------+----------------------------+ GFI (General Format Identifier) Bit 8 Q bit (Data Packets only) Q = 0 (Data Packet, contains user data) Q = 1 (Data Packet, contains control data) Bit 7 D Bit (Delivery confirmation) D = 0 (End to end ACK not required) D = 1 (End to end ACK required) Bit 6 When set, P(S) and P(R) counters in the DATA Packet are modulo 128 (Bit 5 = 0) Bit 5 When set, P(S) and P(R) counters in the DATA packets are modulo 8 (Bit 6 = 0) Explanations of X.25 Clear, reset and diagnostic codes can be found at the end of this paper in Appendice B. --- ---------------------------------------------------------------------------- 2. Related protocols and reccomendations ---------------------------------------------------------------------------- For the immediate context of this paper, the following reccomendations relate to the implementations of X.25; X.3 Defines operation of a PAD X.28 Defines interface between an async. terminal and PAD X.29 Utilised by remote DTE to communicate with a PAD X.121 Defines International and XPDN addressing scema To demonstrate (in absence of X.121 which is explained below) consult Figure 2.1. Figure 2.1 - X.25 related protocols and their context ----------------------------------------------------- .......... . . . . +---+ +---+ . XPDN . +--------------+-------------+ |DTE|--|PAD|------. .------| X.25 and PAD | Host system | +---+ +---+ . . | support | DTE | | | | .......... +--------------+-------------+ | | | X.25 | | X.25 | | | |X.3| | | | | | | | | | | | | | |<X.28>| | | | |<------------ X.29 --------------------->| X.3 --- The PAD must handle the setup and clearing of virtual calls, assemble packets for transmission to the PDN, and dis-assemble packets for delivery to the attached terminal. Within X.3, there are 22 parameters that specify PAD behaviour and profile. Primarily, these are Transmission speed, parity, flow control between terminal and PAD and linefeeding. X.3 parameters and settings can be found in Appendice C. X.28 ---- Defining the interface between an asynchronous terminal and PAD and the manner in which the PAD interacts with that terminal is reccomendation X.28. This interface is bi-directional, and it is the commands sent to the PAD to specify X.3 parameters that are known as X.28 commands. The PAD responds in kind with PAD control signals. X.28 commands can be found in Appendice C. X.29 ---- X.29 is utilised by a remote DTE to communicate with a PAD. This may occur when a remote host needs to read and / or set various PAD parameters, such as the BREAK signal. X.29 is a layer above the X.25 PLP but utilises the X.25 packet and XPDN as the bearer between host and PAD. X.29 messages can be found in Appendice C. X.121 ----- X.121 is the addressing format required by the CCITT/ITU for routing, switching and transmission of data over an XPDN. X.121 Addresses take the following format: ABC D XXX YYYYY ZZ Where : ABC Country D XPDN or RPOA within country XXX Packet Switching Exchange designation YYYYY Subscriber Address ZZ Subscriber sub-address Certain XPDNs or RPOAs may add extraneous digits to the above address format as a prefix for routing outwith their own XPDN; This in effect renders the address non-X.121 compliant. It should also be noted that within the host XPDN or RPOA zone, the DNIC may be omitted as packets are not being routed outwith the immediate network. The simplest way to visualise this concept is to imagine the network like a telephone network, with each XPDN representing a country or OLO. To call another country or into another OLO's network or exchange, you must supply the full X.121 address so that the DNIC may be used to route out through the host network's gateway. Each PSE can be thought of as a high capacity local exchange, and each subscriber address as the final customer directory number. Eah customer directory number may be either a direct-dial line or a PBX, denoted by the subscriber sub-address (a similar concept would be DISA or DDI trunking). --------------------------------------------------------------------------- 3. Previous security flaws and issues --------------------------------------------------------------------------- X.25 networks have a long and chequered history with regards to security, but many (90%) of the incidents that have occured have been due to human error in administration and implementation rather than flaws within the protocol layers. Without exception, almost every major X.25 switcing network has had at least one significant security breach in it's history, whether documented or (most likely in the private and finance sector) undocumented and unacknowledged. These breaches are at best, poorly documented. They have all, however, afforded the intruders ridiculous amounts of control over the network infrastructure. Two such instances that are brought immediately to mind are the penetration of the TAMS authorisation and network database for SprintNet (by persons unknown), which provided (almost) every single user ID and/or associated NUI alongside the entire Sprint subscriber database, and the penetration and subsequent full control gained over BT's Tymnet by the infamous LOD and MOD. There have been several major incidents in the UK also. In recent years, the entire PAKNET infrastructure was open to attack; explorers of the relatively new network found they could blythely skip across the country from radio PAD to radio PAD, capturing sensitive financial transaction data ranging from basic EPOS information to APACS and BACS transfers. Why? PAKNET had simply omitted basic security procedures from their implementation plan, and left all their network access points outwith CUGs (Closed User Groups) and wide open in terms of user ID and password authentication. Prior to this, there was the case of 8LGM (Neil Woods, Karl Strickland, Paul Bedworth) who were subsequently caught and convicted under the computer misuse act for their 'crimes'. Prior to their apprehension, they had privileged access to hitherto uncharted (and strictly non-public) areas of the Packet Switch Stream network and the Joint Academic Network, including switching systems and authentication centres. And even further back in our history, there is of course the fledgling exploration of the then PRESTEL system and it's connection to PSS/IPSS. Early explorers found they could make a misformed call to the PSS gateway, thereby crashing the authentication engine, and allowing calls to glide through unchecked (and no doubt, heavily privileged). But these are only a few of the documented or reported cases. Rest unassured, X.25 security is not taken seriously in many organisations, for no better reason than gross misconfiguration or misunderstanding of the basic principles involved. One particularly interesting flaw within several X.25 implementations that should be highlighted is of course PAD to PAD; Skirting the boundary between user action and sheer protocol idiocy, it worked/works like so: PAD A connects to PAD B; A channel is assigned by B to allow the connection; HOWEVER - The channel remains flagged as unassigned to other PADs; User J.Bloggs connects from C to B; PAD A, idling on the "unassigned" channel, sees all the data from C -> B. Grossly simplified but highly effective. Interested readers should examine the following issues of Phrack for details of X.25 security issues past: Phrack issues 30 31 42 (An X.25 "special") --------------------------------------------------------------------------- 4. Current Issues affecting X.25 networks --------------------------------------------------------------------------- Todays security problems are just as ludicrously exploitable as they were all those years ago when just about everyone ran DECNET/DECNET, bin/bin, or whatever your local OS flavour was. However, they require delving into the guts of the network architecture somewhat. To this end, the entry level for protocol level attack on X.25 networks is increased such that you must be competent enough to understand *intriniscally* the protocol, call setup and operation, and furthermore, have very fine C skills. Script kids need not apply. Think back to when IP Spoofing was the preserve of the few, and SYN flooding and DoS tools had yet to find their way into the hands of keyboard wielding mongoloids. We'll discuss RNR attacks, Stream Termination and a basic "real-world" example of the above with some packet injection. 1. (Not)SYN Flooding -------------------- One very simplistic attack principle is detailed as follows, and a rough analogy could be drawn to SYN flood attacks. Nodes within the XPDN indicate that their incoming packet buffers are full by issuing what is known as an RNR (Receive - Not Ready) packet to the node sending data. Any packets in transit after this packet is received are discarded, and the receiving node is then free to process / empty it's buffers. Upon emptying the received buffer, the receiving node then issues an RR (Receive - Ready) packet to the sending node with a sequence number set to resume sending +1 after the last acknowledged packet received. The sending node merrily resumes sending data until it is requsted to stop again or tear the connection down. Consider the following scenario; A is communicating freely with B, along the principle of the preceeding paragraph. Node X decides to interject at a critical stage in the transfer by sending an RNR packet to A with a forged source address indicating B. A immediately stops sending data while B continues to process data. B waits, and waits, and waits. Eventually, a watchdog timer should expire the connection (in an ideal world) and tear down the connection ready to resume anew. A however, is no state whatsoever to send data, as it is still awaiting an RR packet from B that will *never* arrive. Repeated enough times, you could conceivably tie up every LCN available, rendering the node useless until reset / reboot. An interesting aside to the above is the use of sequence numbering with the resume packet to resend data already discarded / in transit. In short, data can be resent to the receiver 'n' packets back in the acknowledged sequence. Rapid switching between RR / RNR packet sending with varying sequence numbers could see the reciver overwhelmed by reams of data it neither expects, wants or can process. Furthermore, this could be further amplified by continuously RR'ing the node spewing out data so that even when asked for mercy by B via the RNR packet, it is immediately told to resume sending by our rogue node X. 2. Stream Termination --------------------- Very simple - send a forged packet to a receiving node with the M (More) bit set to 0. This indicates the end of the stream in progress, and as a result, Channels are un-assigned and sequences reset. Of course, the sender continues to send data, but where does it go? Definitely one for the boys at the lab. 3. X.25 Packet Injection ------------------------ For our next trick, ladies and gentlemen, watch us convince a telephone network it's thrashing horribly, and watch the ensuing chaos as Tributary routes are hastily brought online. It's common practise for digital telephone switches to communicate via X.25 both with management centres and other switches - not for call setup or other tasks required from day to day, but to spool out report data, call levels, AMA Records, System logs, etc. Invariably this information will be viewed by a human operator at some point; The switches are more than happy to talk to each other without human intervention via SS7. Imagine a management centre as node A, and our target switch as node B. A "real world" application of theory will now follow: We sit at node X, and decide that we want to force a login on our switch. We know from previous experience that certain call details outwith AMA are sent from B to A for human analysis on an hourly basis. We are bad people; We use bastardised PAD source to send a packet out from Node X to Node B with the source address forged to that of A, containing, you guessed it : RNR. Mid stream as well, nasty. Node B shuts up. We now start sending spurious (and grossly alarming) information to A with the source address set to B. Just for good measure, we periodically send corrupted data. Now the engineer is alarmed. He logs into the switch. Using a box previously attacked, backdoored and monitored. We own the switch. (all the phones in London now ring continuously :-) ) --------------------------------------------------------------------------- 5. Risk Assessment and worst case scenario --------------------------------------------------------------------------- Why, why, why is the above even remotely possible? X.25 still utilises address based authentication as the *cornerstone* of it's network level authentication, that's why. Furthermore, very few cryptographic solutions exist for X.25 networks; Even GOSIP compliant X.25 nets push data through the network in the clear. What inflames matters further is that from experience, most admins will leave source code, library or debugging utilities for the particular implementation lying around without a second thought as to it's use - it's childs play to recompile a network PAD to store addresses, CUG data, NUIs and even remote logins in a file for later viewing. Surprisingly few penetration tests even examine the avenues of attack provided by X.25 networks, and this attitude is only exacerbated by the companies under audit refusing to consider X.25 as a possible chink in their armour. The icing on the cake is the distinct leaning towards X.25 as security through obscurity. Wake Up! The majority of financial networks today use X.25; Our public telephone system relies on it so heavily it's scary; A sizeable percentage of state interest computing facilities and services utilise it to great effect. In short - since the inception of wide area networks, X.25 has been at the core of the UK's IT backbone, albeit hidden under the stairs and given a regular shoeing by TCP/IP and ATM. Banks, telephone companies and the state would have you believe that their networks are secure, infallable and impervious to the actions of motivated individuals with the right tools. Lies, fat lies, and even greater bigger whopping great big fecking lies with bells on. If I'm wrong, then sue me, I'll gladly take the stand in court and spill my guts. The alarming thing is that as time continues apace, people are so keen to promote the 'new' technologies such as SDH and ATM and jump on the full disclosure bandwagon, that they've missed the boat completely on issues that the public at large aren't so ready to understand (presumably because it just isn't urban-modernist enough). People are so up in arms about web defacement and suchlike, but how genuinely terrifed would you be if someone happened to think it a jape to re-assign emergency numbers to chatlines, and you happened to be bleeding to death at the time? Stepping back from the alarmist approach, isn't it about time people paid attention to the crucial rather than the frivolous? --------------------------------------------------------------------------- 6. Bibliography --------------------------------------------------------------------------- Internetworking : A guide to Network Communications ISBN 1-55851-143-1 Newnes Data Communications Pocket Book ISBN 0-7506-0427-1 British Telecommunications Engineering Vol 2, Part 1, April 1983 Testing Packet Switched Networks B.R Spiegelhalter, C.G. Miller Post Office Electrical Engineers Journal Oct 1981, 74, p 216 Packet Switched Data Communications Networks P.T.F Kelly Experience in Software Test Techniques for Packet Switching Exchanges: Proceedings of the Third International Conference on Software Engineering for Telecommunications Switching Systems, M.J. Norton AutoFlood - A flexible Test System for Packet Switched Networks NATO Advanced Study Institute on Advances in Distributed Computing, 1980 M.J. Norton, C.G. Miller ITU Reccomendations : X.110, X.115, X.116, X.121, X.139, X.25, X.28, X.29, X.3, X.32, X.70, X.71, X.75, X.96. --------------------------------------------------------------------------- Appendix A Kilostream / X.21 Bearer Unit & Combined line-driver menu system --------------------------------------------------------------------------- This is present here merely as an aside, if you have one of these units, get another one because they're fuck all use otherwise. Apparently you can have an end to end link of circa 2km with two units. Unit Is Kilostream X.21 NTE 8A. Password is UUTDPUUP. UP UP TOGGLE DOWN PROG UP UP PROG 1. Power on 2. Display shows : ######## TESTING SELF TEST OK S/W VERSION 3.7 OPTIONS MENU > 3. Menus are as follows: OPTIONS MENU ----+---- CUSTOMER ---- No Cust Options | +---- LOCAL LINE ----+---- OL: HBER 1 in 10^4 * | | | +---- OL: LBER: 1 in 10^8 * | | | +---- OL: L/Alm -> L/AIS | | | +---- OL: Z = 75 Ohm | | | +---- OL: CRC4 | +---- CLOCK ---- No Clock Options | +---- PASSWORD ---- OP: Enter Password TESTS MENU ----+---- T:Binary ----+---- TBin : Inject 1's | | | +---- TBin : Inject 0's | +---- T: Loop ---- T: Loop : Rem. NTU ----+---- TL: Remote Loop | | +---- T: Self Test +---- TL: Remove R/Lp | +---- T: Lamp Test STATUS MENU ----+---- S: Nx64k: + C/I | +---- S: 128kbit/s | +---- S: Customer I/F ----+---- S: Cus I/F : Input ---- C-I/P: C = OFF | +---- S: Cus I/F : Output ---- C-O/P: I = OFF | +---- S: Loc. Line I/F ----+---- S: LL I/F: TxD in ---- LLTx : AIR Sent | +---- S: LL I/F: RxDir ---- LLRx : Input Fail After Password: OC: N x 64k N+1 x 64k M x 64k M+1 x 64k Set no of TS ---- No of TS = 2 T: G821 LL Stats ---- No CRC4 S: G821 Stats ---- No tests OP: M/S Mode OP: Standalone OCk: Nwk G703 OCk: Master Test OCk: Slave Test --------------------------------------------------------------------------- Appendix B X.25 Clear, Cause and Diagnostic codes (80/84) --------------------------------------------------------------------------- X.25 gives users messages back in the form: ERROR_TYPE DESCRIPTION CAUSE+DIAGNOSTIC Where ERROR_TYPE is one of RST, CLR or RESTART DESCRIPTION gives a plain English description of the diagnostic CAUSE is a Hexadecimal number, two characters DIAGNOSTIC is a Hexadecimal number, two characters eg : 1343 would be Local Procedure Error, Invalid Called Address. CLR Invalid call 1343 The following was taken from the Tymnet X.25 diagnostics code database: CAUSE ===== Decimal code: 19 Hexadecimal code: 13 Description: LOCAL PROCEDURE ERROR DIAGNOSTIC ========== Decimal code: 67 Hexadecimal code: 43 Issued by: CCITT Protocol: X.25 Year defined: 1980 Description: CALL SETUP/CLEARING PROBLEM INVALID CALLED ADDRESS RESET Cause and Diagnostics --------------------------- When the resulting cause field is zero, one of the DTEs has generated a RESET request. In this case the DTE originates the diagnostic code, and passes it unchanged to the remote DTE. Other resetting cause codes are generated by the network. The standard 1984 diagnostic codes are used also. CLEAR Cause and Diagnostics --------------------------- When the clearing cause is zero, one of the DTEs has generated a CLEAR request. In this case, the diagnostic code is generated by the DTE, and is passed unchanged to the remote DTE. Other clearing causes are generated by the network, and the standard diagnostic codes apply. RESTART Cause and Diagnostics ----------------------------- RESTART codes are generated by the network. =========== Bits Dec Hex Reset CAUSE 87654321 ----------- Reset request originated from DTE 00000000 0 0 Out of Order (PVC Only) 00000001 1 1 Remote Procedure Error 00000011 3 3 Local Procedure Error 00000101 5 5 Network Congestion 00000111 7 7 Remote DTE Operational (PVC Only) 00001001 9 9 Network Operational (PVC Only) 00001111 15 F Destination is not compatible with this call 00010001 17 11 Clear CAUSE ----------- Clear request originated from DTE 00000000 0 0 Number Busy 00000001 1 1 Facility request is invalid 00000011 3 3 Network congestion 00000101 5 5 Out of Order 00001001 9 9 Access is Barred 00001011 11 B DTE Not obtainable 00001101 13 D Remote Procedure Error 00010001 17 11 Local Procedure Error 00010011 19 13 RPOA Out of Order 00010101 21 15 Reverse Charging not agreed with Network Admin. 00011001 25 19 Destination is not compatible with this call 00100001 33 21 Fast select acceptance not agreed with Network Admin. 00101001 41 29 Restart CAUSE ------------- Local Procedure Error 00000001 1 1 Network Congestion 00000011 3 3 Network Operational 00000111 7 7 ===== Coding of X25 Generated diagnostic fields in CLEAR, RESET + RESTART indication, REGISTRATION, CONFIRMATION and DIAGNOSTIC packets. The diagnostic codes are CCITTT Rec. 1984, but I'm not sure of the rest. It shouldn't make much difference, really - there weren't that many changes between the two implementations. Bits Dec Hex 87654321 No additional information 00000000 0 0 Invalid P(S) 00000001 1 1 Invalid P(R) 00000010 2 2 ------------------- 13 Reserved fields ------------------- 00001111 15 F Packet type Invalid 00010000 16 10 For state r1 [ Packet type not valid ] 00010001 17 11 r2 [ Packet type not valid ] 00010010 18 12 r3 [ Packet type not valid ] 00010011 19 13 p1 [ Packet type not valid ] 00010100 20 14 p2 [ Packet type not valid ] 00010101 21 15 p3 [ Packet type not valid ] 00010110 22 16 p4 [ Packet type not valid ] 00010111 23 17 p5 [ Packet type not valid ] 00011000 24 18 p6 [ Packet type not valid ] 00011001 25 19 p7 [ Packet type not valid ] 00011010 26 1A d1 [ Packet type not valid ] 00011011 27 1A d2 [ Packet type not valid ] 00011100 28 1C d3 [ Packet type not valid ] 00011101 29 1D -------------------- 1 Reserved field -------------------- 00011111 31 1F Packet not allowed 00100000 32 20 Unidentifiable packet 00100001 33 21 Call on one-way logical channel 00100010 34 22 Invalid packet type on a Permanent Virtual Circuit 00100011 35 23 Packet on unassigned logical channel [No call request] 00100100 36 24 REJECT not subscribed to 00100101 37 25 Packet too short 00100110 38 26 Packet too long 00100111 39 27 Invalid general format identifier 00101000 40 28 RESTART with non-zero LCG or LCN 00101001 41 29 Packet type not compatible with facility 00101010 42 2A Unauthorised INTERRUPT Confirmation 00101011 43 2B Unauthorised INTERRUPT 00101100 44 2C Unauthorised REJECT 00101101 45 2D -------------------- 1 Reserved field -------------------- 00101111 47 2F Time expired 00110000 48 30 For INCOMING CALL 00110001 49 31 For CLEAR INDICATION 00110010 50 32 For RESET INDICATION 00110011 51 33 For RESTART INDICATION 00110100 52 34 -------------------- 11 Reserved fields -------------------- 00111111 63 3F Call set up, call clearing or registration problem 01000000 64 40 Facility / Registration code not allowed 01000001 65 41 Facility parameter not allowed 01000010 66 42 Invalid called address 01000011 67 43 Invalid calling address 01000100 68 44 Invalid facility / registration length 01000101 69 45 Incoming call barred 01000110 70 46 No logical channel available 01000111 71 47 Call Collision 01001000 72 48 Duplicate facility requested 01001001 73 49 Non-zero address length 01001010 74 4A Non-zero facility length 01001011 75 4B Facility not provided when expected 01001100 76 4C Invalid CCITT-specified DTE facility 01001101 77 4D -------------------- 1 Reserved field -------------------- 01001111 79 4F Miscellaneous 01010000 80 50 Improper cause code from DTE 01010001 81 51 Not aligned Octet 01010010 82 52 Inconsistent Q-bit setting 01010011 83 53 -------------------- 12 Reserved fields -------------------- 01011111 95 5F Not assigned 01100000 96 60 -------------------- 15 Reserved fields -------------------- 01101111 111 6F International Problem 01110000 112 70 Remote Network Problem 01110001 113 71 International protocol problem 01110010 114 72 International link out of order 01110011 115 73 International link busy 01110100 116 74 Transit Network facility problem 01110101 117 75 Remote Network facility problem 01110110 118 76 International Routing problem 01110111 119 77 Temprorary Routing problem 01111000 120 78 Unknown called DNIC 01111001 121 79 Maintennance Action 01111010 122 7A -------------------- 5 Reserved fields -------------------- 01111111 127 7F IMP is unavailable 10000000 128 80 Link level came up 10000010 130 82 Link level went down at remote DTE 10000011 131 83 Remote DTE restarted 10000100 132 84 Local resources not available for call establishment 10000101 133 85 Remote resources not available for call establishment 10000110 134 86 Remote host dead 10001000 136 88 Remote IMP dead 10001001 137 89 Logical subnetwork access barred 10001010 138 8A Connection lost 10001011 139 8B Response lost 10001100 140 8C Calling logical address not enabled or not authorized 10001101 141 8D Calling logical name incorrect for this DTE 10001110 142 8E Called logical name not authorized 10001111 143 8F Called logical name not enabled 10010000 144 90 Called logical name has no enabled DTEs 10010001 145 91 Use of logical addresses invalid in this network 10010010 146 92 Declared logical name now in effect 10010011 147 93 Declared logical name was already in effect 10010100 148 94 Declared logical name is now disabled 10010101 149 95 Declared logical name was already disabled 10010110 150 96 Incoming calls barred 10010111 151 97 Outgoing calls barred 10011000 152 98 Non Zero Reset Cause from DTE 10100000 160 A0 Data Packet too Long 10100001 161 A1 Interrupt Packet too Long 10100010 162 A2 INT Packet too Short; No User Data 10100011 163 A3 INT Confirmation Packet too Long 10100100 164 A4 RR Packet too Long 10100101 165 A5 RNR Packet too Long 10100110 166 A6 Reset Packet too Long 10100111 167 A7 Reset Conf Packet too Long 10101000 168 A8 Invalid 'Q' Bit in Data Packet 10101001 169 A9 Packet Window Range Exceeded 10101010 170 AA Unable to transmit packet 10101011 171 AB 'Q' Bit set in Non-Data Packet 10101100 172 AC Outstanding Packet Count less than Zero 10101101 173 AD Retransmission Error 10101110 174 AE Reset Packet too Short (No Cause) 10101111 175 AF Reject Packet too long 10110000 176 B0 Invalid 1D Packet 10110001 177 B1 Unsuccessful reconnection RESNC 10110010 178 B2 Non-Reconnect Call in State C1 10110011 179 B3 Second 1D Packet from DTE 10110100 180 B4 Bad Data Transfer State in Re-connect 10110101 181 B5 Packet Format Invalid 10110110 182 B6 Facility Byte Count too Large 10110111 183 B7 Invalid Packet Detected 10111000 184 B8 Facility / Utility Field Byte Count > 63 10111001 185 B9 Outgoing Calls Barred 10111010 186 BA Incoming Calls Barred 10111011 187 BB Clearing of PVC 10111100 188 BC Called Address too Long 10111101 189 BD Called Address too Short 10111110 190 BE Calling Address too Long 10111111 191 BF Calling Address too Short 11000000 192 C0 BCD Error in Call Address 11000001 193 C1 BCD Error in Calling Address 11000010 194 C2 User Data Field too long 11000011 195 C3 No Buffer Available 11000100 196 C4 Local DTE is not enhanced 11000101 197 C5 Facility negotiation invalid 11000110 198 C6 Mandatory Utility not input 11000111 199 C7 Buffer not available for TNIC 11001000 200 C8 Overflow of TNIC in buffer 11001001 201 C9 DTE Line Congested 11001010 202 CA Table error in Packet Procedures 11001011 203 CB Insert Table Overflow 11001100 204 CC Delete Table Overflow 11001101 205 CD Trunk Line Restart 11010000 208 D0 Invalid Event in State p2 11010001 209 D1 Invalid Event in State p3 11010010 210 D2 Invalid 1D Event in State d1 11010011 211 D3 Call Collision on Trunk Line 11010100 212 D4 No Buffer Available 11010101 213 D5 Call Collision on DTE Line 11010110 214 D6 DTE Restart 11010111 215 D7 Call Request to Trunk Timeout 11011000 216 D8 Reconnect Set-up Timed Out 11011001 217 D9 Invalid Output Side State 11011010 218 DA Error Detected in Blink Packet Queue Procedure 11011011 219 DB Reset Indication Retransmission Count Expired 11011100 220 DC Invalid Output Side State 11011101 221 DD Blind Buffer Queue Overflow in State d4 11011110 222 DE Blind Buffer Queue Overflow in State c1 11011111 223 DF Blind Buffer Queue Overflow in State c2 11100000 224 E0 Clear Packet Byte Count Too Large or too small 11100001 225 E1 Non-zero Clear Cause 11100010 226 E2 Clear Conf Packet Byte Count too small or too large 11100011 227 E3 Call Collision 11100100 228 E4 Invalid TP Load Request Call Packet 11100101 229 E5 Maximum HopCount Exceeded 11100110 230 E6 Routing Loop Detected 11100111 231 E7 PVC Call Request Failure 11101000 232 E8 Reconnect Call Request Failed 11101001 233 E9 No LC Available on Output Side 11101010 234 EA No Buffer Available 11101011 235 EB Call Redirection Clear 11101100 236 EC No Path Route Call 11101101 237 ED Call Routed to DTE Line 11101110 238 EE Call cannot be Re-routed 11101111 239 EF Address not in routing Tables 11110000 240 F0 Routing Table Change during call routing 11110001 241 F1 No LC Available on fake trunk 11110010 242 F2 Remote DTE Down on a PVC 11110011 243 F3 Invalid event detected 11110100 244 F4 Invalid Packet Received; State d4 11110101 245 F5 Invalid Packet Received; State d5 11110110 246 F6 Invalid Packet Received; State p8 11110111 247 F7 Internal Processing Failure 11111000 248 F8 Invalid Restart Indication 11111001 249 F9 Line Status Change in State r4 11111010 250 FA Invalid Packet Received; State r4 11111011 251 FB Invalid Packet Received; State r3 11111100 252 FC Line Status Change in State r2 11111101 253 FD Line Status Change in State r1 11111110 254 FE Line Status Change in State r0 11111111 255 FF -------------------- 11 Reserved fields -------------------- 11111111 255 FF --------------------------------------------------------------------------- Appendix C X.3, X.28 commands and X.29 messages --------------------------------------------------------------------------- > X.3 < Parameter Function CCITT Values 1 PAD Recall Character 0 or 1 32-128 2 Local Echo 0 or 1 3 Data forwarding characters 0, 2, 6, 18, 126 4 Idle Timer Delay 0-255 5 PAD to terminal flow control 0-2 6 Control of PAD service signals 0, 1, 5, 8-15 7 PAD action on receipt of break from term 0, 1, 2, 5, 8, 21 8 Discard output 0 or 1 9 Padding after carriage return 0 - 255 10 Lind folding 0 - 255 11 Async speed (Read only parameter) 0 - 18 12 Terminal to PAD flow control 0 or 1 13 Line feed insertion 0, 1, 4 - 7 14 Padding after line feed 0 - 255 15 Editing 0 or 1 16 Character delete defined character 0 - 127 17 Buffer delete defined character 0 - 127 18 Buffer display defined character 0 - 127 19 Editing service signals 0, 1, 2, 8, 32 - 126 20 Echo mask 0 - 128 21 Parity Treatment 0 - 3 22 Page wait 0 - 255 > X.28 < Function Command -------- ------- Establish Call Call Selection [optional_facilities] - address[user_data] [optional_facilities] - abbreviated_address[user_data] optional_facilities precede address: N(NUI), T(RPOA), G(CUG), R(Reverse Charging), C(Charging Information) User_data follows address: Character P or D, followed by up to 12 characters. These two fields are optional. Clear call CLR Check User Profile PROF Set User profile PROF n Set PAD Parameter(s) SET para_#:value Set & read PAD Parameter(s) SET? para_#:value Display PAD Parameter(s) PAR? Display Call Status STAT Reset Virtual Call RESET Send INTERRUPT packet INT > X.29 < X.29 Messages +---- 8 - Bits ------+ 4 - Bits 4 - Bits 8 - Bits | | +----------+----------+----------+------+---+------+---+ | GFI | LGN | LCN | P(R) | M | P(S) | 0 | +----------+----------+----------+------+---+------+---+ +----+-------+-------+ SET | 02 | PARM | VALUE | +----+-------+-------+ +----+-------+-------+ SET & READ | 06 | PARM | VALUE | +----+-------+-------+ +----+-------+-------+ PARAMETER INDICATION | 00 | PARM | VALUE | +----+-------+-------+ +----+-------+-------+ READ | 04 | PARM | 00 | +----+-------+-------+ +----+ INVITATION TO CLEAR | 01 | +----+ +----+------+------+ ERROR | 05 | TYPE | CODE | +----+------+------+ +----+------+------+ INDICATION OF BREAK | 03 | 08 * | 01 * | +----+------+------+ +----+---------+------------+ RESELECTION | 07 | ADDRESS | FACILITIES | +----+---------+------------+ * optional --- EOF