/*
* 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