RFC 874

Critique of X.25

📅 published September 1982, from ietf

A Critique of X.25 🎀

Part 1 of 3 🦋

Title block: the stamp on this copy reads < INC-PROJECT, MAP-CRITIQUE.NLS.10, >, 12-Aug-83 11:46 AMW ;;;;. The author is M. A. Padlipsky of The MITRE Corporation in Bedford, Massachusetts 💜. The copy I was given doesn't list a category, status, or any "obsoletes" or "updates" entries, so I'm not going to make any up 🙈

Abstract ✨

okay so the big headline here is that X.25 📡, the network interface protocol everyone was hyping, plus its whole framework (the International Standards Organization's Reference Model for Open System Interconnection, or ISORM), gets put under the microscope and... it does NOT pass 💀. The paper is a companion piece to M82-48 and M82-51 🫶

Introduction 🌸

so according to some sources, the International Standards Organization's (ISO) "Open System Interconnection" (OSI) effort has adopted the X.25 protocol(s), which were developed by the International Consultative Committee on Telephony and Telegraphy (CCITT), as its Levels 1-3 🤔 Like, "loose constructionists" of the ISORM would argue that X.25 is a mechanization of L1-L3 rather than the mechanization, and at least one British source says "we in the U.K. don't believe that ISO have adopted X.25." so even the people who should know are kinda not agreeing 💅

over in the U.S. Government arena, which is where the author spends a lot of his time, the Government Accounting Office (GAO) has suggested that the Department of Defense (DoD) ought to consider adopting "X.25 networks" 👀 apparently over networks built on protocols from the DoD-sponsored intercomputer networking research community. and that research community has, with a few recent exceptions, stuck to its commitment to the Oral Tradition and hasn't really taken up the cudgels against X.25 in the open literature 😭 even though X.25 is getting plenty of scorn in personal conversations, lowkey iconic behavior 🙈

the DoD Protocol Standards Technical Panel has started evolving a "Reference Model" that's different from ISO's, for reasons we'll touch on below 🧚 but there's a need to deal with X.25's problems on their own merits, asap. the paper says it isn't pretending to be complete*, but it's gonna try 💖

the overall plan is to look at X.25 in the abstract. BUT because of who pays the bills 💸, we first have to sketch the broad reasons why the DoD in particular should not

* Various versions of X.25 and ISO documentation were employed. One incompleteness of note is that no attempt has been made to do proper bibliographic citation. Another incompleteness lies in the area of "tutoriality"; that is, appropriate prior knowledge is assumed on the part of the reader. (The author apologizes for the omissions but hasn't the time or the energy to be overly scholarly. Reference [3] might be of use to the reader who feels slighted.)

employ intercomputer networks that base their protocol suites on the ISO Reference Model (ISORM) with X.25 as Levels 1-3. (heads up, this is a different formulation from "use communications subnetworks which present an X.25 interface." don't mix them up, bestie 🫶)

very briefly, the DoD has concerns about "survivability," reliability, security, and investment in prior art (its research community already has a working protocol suite running on lots of different operating systems ✅). there's also procurability: ISORM-related protocol suites don't fully exist yet, not even on paper, and even the advocates admit the international standardization process needs several years just to finish the full suite spec, let alone offer interoperable implementations 😩. and then there's interoperability with a much wider range of systems than will ever get vendor-supplied ISORM protocol suites. no matter which of these concerns you think dominates, the DoD can't really be expected to wait around for what happens in the ISO arena 🕰️ (and it's extra striking that DoD reps aren't even allowed, under current doctrine, to present their specific security concerns in the kind of unclassified environment the ISO arena is 🙃)

some zealous ISORM advocates say the DoD research community has a "Not Invented Here" syndrome when it comes to ISORM-related protocols 🙄 so even if all those reasons won out, there'd still be an open question at some level. and at least one or two zealous members of the research community have claimed the problem isn't Not Invented Here but Not Invented Right 💅 so it seems fair to judge the apparent keystone of the ISORM suite, X.25, on whether it's "good art." that's what we're doing here ✨

Problems With the Conceptual Model 🦋

okay this part is kinda messy, bestie 😭 there's confusion even among X.25's advocates about what the real conceptual model of X.25-based ISO networking even is. some people draw the Reference Model as two "highrises," and others draw "parking garages" beside each highrise 🏢

the highrise crowd draws the seven ISORM layers as big rectangles (representing Hosts) sitting next to each other, with each layer talking to its "peer" in the other Host/Open System. that implies an "end-to-end" view of X.25 🌈 the parking garage crowd draws smaller rectangles between the big ones, with Levels 1-3 having peer relationships from the Host-OS ("Data Terminal Equipment") to the Comm Subnet Node ("Data Circuit Terminating Equipment"). that implies a "link-by-link" view of X.25 🚗

the author says this ambiguity doesn't exactly inspire confidence in the architects, but maybe the real problem is the spectators 🙈 still, it's indisputable that when you internet with X.75, the model becomes "hop-by-hop" 🦘, and it's likely it's meant to be link-by-link even on a single comm subnet.

now the major problem with this model: the designers chose to read it as requiring them to break the "virtual circuit" it's supposed to support whenever there's trouble with any one of the links 💀 so if you're internetting (and on some readings, even on your own proximate net), messages won't get rerouted when they're needed. instead, all the upper levels of protocols have to burn space-time resources rebuilding their own connections with their counterparts 😤 (and fun fact: the success of that reconstitution after a DCE failure seems to assume a certain routing flexibility that the Model doesn't actually guarantee 👀). honestly, that can scarcely be called sound design for an intercomputer networking environment, though many have guessed it probably makes sense to telephonists 📞

* We're assuming an ISO-oriented model rather than a CCITT-oriented one (X.25/X.28/X.29), because the latter appears to offer only "remote access" functionality, whereas the sort of intercomputer networking we're interested in is concerned with the full "resource-sharing" functionality the former is striving for. This might be somewhat unfair to X.25, in that it takes the protocol(s) somewhat out of context. however, it's what ISO has done before us, and if what we're really accomplishing is demonstrating that ISO has erred in doing so, so be it. as a matter of fact, it can also be argued that X.25 is itself somewhat unfair--to its users, who are expecting real networking and getting only communication. cf. Padlipsky, M. A., "The Elements of Networking Style", M81-41, The MITRE Corporation, October 1981, for more on the extremely important topic of resource sharing vs. remote access.

indeed, the virtual circuit metaphor seems to be taken almost literally (with the emphasis on the "circuit" part) 🔌. what should be an environment that gives you the benefits of packet-switching ends up, at the X.25 level, reduced to the limitations of circuit-switching 😩. on the other hand, the metaphor isn't taken literally enough in another sense (with the emphasis on the "virtual" part), because lots of people read it as implying the logical connection is "only as strong as a wire." 🪢 whether the whole mess comes from wanting to "save bits" by not making addresses explicitly available on every transmission is just a guess, but if so, that's also unfortunate 🥲

(as an aside, there's some evidence that bit saving reaches fetish--if not pathological--proportions in X.25 💀 for instance, there doesn't even seem to be a Packet Type field in data packets. instead, as best anyone can tell, for data packets the low order bit of the "P(R)" field, which overlaps and stands in the place of the Packet Type, is always 0, whereas in "real" Packet Type fields it's always 1. [that may, by the way, not even be how they do it. it's hard to tell... or care. 🙃])

there's also confusion among the advocates about what implications, if any, the protocol(s) have for comm subnet node to comm subnet node (CSN) processing 🤷‍♀️. the two-highrise folks seem to be implying that, from their view, the CSN (or "DCE") is invisible. that might make a bit of sense, except they also claim each floor of a highrise has a "peer-relationship" with the matching floor of the other highrise. that implies excessively long wires, well beyond the state of the wire-drawing art, once you notice that the first floor is the physical level 📏 (it also seems to rule out concatenated comm subnets forming an internet, or "catenet," unless all the CSNs are identically constituted. and folks who think the ISORM dictates single protocols at each level are gonna have a hard time making an HDLC interface into a Packet Radio Net, most likely 📻)

the parking garage crowd, on the other hand, seems to be dictating that the internal structure of the CSN also has to follow X.25 link and physical protocols. that implies Packet Radio or satellite CSNs, for example, can't "be X.25" 🛰️ which might be heartening news to the designers of those comm subnets, but it presumably wasn't what those who claim universality for X.25 (or even for the ISO Reference Model) intended 🙈

even granting that ambiguities in the conceptual model don't count as prima facie grounds for rejecting the protocol(s), they almost assuredly will lead to vendor implementations built on differing interpretations that won't interoperate properly 😭 and the unambiguous position that virtual circuits break whenever X.25 says so is a flaw at least as grave as any of the ambiguities 💔

Okay, bestie, the next problem is seriously rough 😭. X.25 never says how the programs that interpret its protocols are supposed to plug into the operating systems they live in 💀. That's worse than the X.25 specs just skipping it, because even the ISORM fans, who have (at least hypothetically) adopted X.25 for their Levels 1-3, get weirdly quiet about it in their own writing 🙈. But if higher level protocols are gonna be built on X.25, there has to be some shared way of hooking X.25 modules into operating systems, at least for certain things. The biggest example we can think of is that "out-of-band signals" need to happen. If the X.25 protocol spec doesn't show any awareness of that kind of use, implementers don't have to wire their X.25 modules into the OS in a way that lets the higher level protocols keep working properly when/if an X.25 Interrupt packet arrives 😤.

Yet much of the problem with the conceptual model might turn out to be our own misunderstandings, or somebody else's. After all, it's not easy to infer a philosophy from a specification 🧚. (And when it comes to recognizing data packets, it's not easy even to infer the specification. But it might well say something somewhere on that particular point that we just overlooked because we were so eager to get the spec back on the shelf fast 🙃.) So what other aspects of X.25 seem to be "bad art"? 🎨

"Personality Problems" 🎭

Viewed from a functionality perspective, X.25 is kind of schizophrenic 🌈. Sometimes it gives off a totally end-to-end "personality." Like, there are lots of people who think it's usable as an integral Host-Host, or Transport, and network interface protocol, even though its own specification (at least the CCITT "Fascicle" version) points out several functional omissions where a higher-level protocol is expected. We've even talked to one or two people who say they actually do use it as an end-to-end protocol, regardless 💅. Other times it gives off a comm subnet network interface personality, which everybody agrees it must. And sometimes (according to some observers) it gives off a "Host-Front End Protocol" personality 👀.

Not to push the "bad art" metaphor too hard, but this kind of violation of "the Unities" is, if demonstrable, grounds for censure not only from literary critics but also from people who believe in Layering 😭. Let's look at the evidence for the split-personality claim 🔍.

X.25 is not (and should not be) an "end-to-end" protocol in the sense of a Transport or Host-to-Host protocol. Yet it has several end-to-end features 🤨. These add to the space-time expense of implementation (i.e., they eat "core" and CPU cycles), and they reflect badly on the designers' skill if you believe in the design principles of Layering and Least Mechanism. (Examples of end-to-end mechanisms are cited below, as mechanisms superfluous to the network interface role.) The absence of a datagram mode that is both required and "proper" (e.g., not Flow Controlled, not Delivery Confirmed, not Non-delivery mechanized) may also be taken as evidence that the end-to-end view is very strong in X.25. So, in ISO Reference Model (ISORM) terms, even though X.25 "is" L1-3, it has delusions of L4-ness. In ARPANET Reference Model (ARM) terms, even though X.25 could "be" L I, it has delusions of L II-ness.* 🥴

X.25 is at least meant to specify an interface between a Host (or "DTE") and a comm subnet processor (or "DCE"), even though the conceptual model is ambiguous about whether it constrains the CSNP "on the network side." (Aside: that ambiguity probably reflects even worse on certain X.25 advocates than it does on the designers. There's a strong sense in which "of course it can't" is the only appropriate answer to whether it's meant to constrain generic CSN processors (CSNP's) in the general case 💀. Note, though, that it might well be meant to constrain specific DCE's. It started life as a protocol for PTT's, or Postal, Telephone, and Telegraph monopolies, and they are presumably entitled to constrain themselves all they want 💁‍♀️.) Still, the end-to-end features alluded to above are redundant to the interfacing role, and, as noted, extraneous features have space-time consequences. There are also several features that, though not end-to-end, seem superfluous to a "tight" interface protocol. Further, the designers' reluctance to put a proper "datagram" capability in the protocol is a whole thing. What they've got doesn't seem to be usable as a "pure" datagram (i.e., uncontrolled at L3 but usable without superfluous overhead by L4). Instead it entails delivery confirmation traffic, like it or not 🙄. (Note that "seem" is used advisedly: as usual, it's not easy to interpret the Fascicle.) That suggests at least that they were confused about what higher-level protocols need from interfaces to CSNP's. At worst, there's some merit to the suggestion that, to paraphrase Louis Pouzin, "the PTT's are just trying to drum up more business for themselves by forcing you to take more service than you need" 💸.

For more on the ARM, see Padlipsky, M. A., "A Perspective on the ARPANET Reference Model", M82-47, The MITRE Corporation, September 1982; also available in Proc. INFOCOM '83. (Some light may also be cast by the paper on the earlier-mentioned topic of Who Invented What.)

Examples of mechanisms superfluous to the interface role 📝:

  1. The presence of a DTE-DTE Flow Control mechanism.
  2. The presence of an "interrupt procedure" involving the remote DTE.
  3. The presence of "Call user data" as an end-to-end item (i.e., as "more" than IP's Protocol field).
  4. The "D bit" (unless construed strictly as a "RFNM" from the remote DCE).
  5. The "Q bit" (which we find nearly incomprehensible, but which is stated to have meaning of some sort to X.29). That means it at least violates Layering by having a higher-level protocol depend on a lower level mechanism, so it can't be strictly a network interface mechanism 🤯.

The final "personality problem" of X.25 is that some of its advocates claim it can and should be used as if it were a Host-Front End protocol.* Yet if that kind of use were intended, surely the designers would have offered a way to tell apart control information meant for the outboard implementation of the relevant protocols from data that's supposed to go through X.25. There's no evidence of any such mechanism in the protocol 🫠. "Borrowing" a Packet Type id for H-FP would be risky, because the spec is subject to arbitrary alteration. Using some fictitious DTE address to indicate the proximate DCE is also risky, for the same reason. And using "Call user data" to "talk to" the counterpart H-FP module only allows 15 octets (plus, presumably, the 6 spare bits in the 16th octet) for the conversation, whereas various TCP and IP options might need many more octets than that 😬.

Granted, with enough ingenuity (or even by the simple expedient of conveying the entire H-FP as data), X.25 might be used to "get at" outboard protocol interpreters. You'd use X.25 only to get channels to demultiplex on, plus DTE-DCE flow control, with the "DCE" actually being an Outboard Processing Environment that gets its commands in the data fields of X.25 data packets 🧠. But its failure to address the issue explicitly, again, reflects badly on its designers' grasp of intercomputer networking issues. (Another possibility is that the whole H-FP notion stems from using X.25 as a Host-Host

That is, as a distributed processing mechanism which allows Host operating systems to be relieved of the burden of interpreting higher level protocols "inboard" of themselves, by virtue of allowing Host processes to manipulate "outboard" interpreters of the protocols on their behalf. Note that the outboarding may be to a separate Front-End processor or to the CSNP itself. (The latter is likely to be found in microprocessor-based LAN "BIU's.") Note also that when dealing with "process-level" protocols (ARM L III; approximately ISORM L5-7), only part of the functionality is outboarded (e.g., there must be some Host-resident code to interface with the native File System for a File Transfer Protocol). Even when outboarding Host-Host protocols (ARM L II; approximately ISORM L4 plus some of 5), the association of logical connections (or "sockets") with processes must be performed inboard. That's why, by the way, it's annoying to find ISO L5 below ISO L6: you'd like to outboard "Presentation" functionality, but its protocol expects to interact with the "Session" protocol, the functionality of which can't be outboarded. (Although this approach is not the proper context for a full treatment of the H-FP approach, it's also of interest that it can effectively insulate the Host from changes in the protocol suite, which can be a major advantage in some environments.)

protocol so that some might think of it in its Host aspect as "simply" a way of getting at the H-HP. This interpretation does give rise to the interesting observation that DCE's seem to need a protocol as strong as TCP amongst themselves. But it doesn't strike the author as particularly convincing evidence for viewing X.25 as anything like a proper H-FP, if for no other reason than that a central premise of Outboard Processing is that the Host-side H-FP module must be compact relative to an inboard generic Network Control Program.)

X.25, then, is rather schizophrenic! 🌈 It exceeds its brief as an interface protocol by pretending to be end-to-end (Host-Host) in some respects. It is by no means a full end-to-end protocol (its spec very properly insists on that point on several occasions). It's at once too full and too shallow to be a good interface, and it's poorly structured to be treated as if it were "just" an H-FP. (Some would phrase the foregoing as "It's extremely ill layered"; we wouldn't argue 💖.)

A Note on "Gateways"* 🌉

The Off-Blue Blanket 🧣

Okay, so this one is a little bit spicy 🌶️. Security needs its own moment, even though we touched on it earlier, and we're not going to go deep here because this isn't the place for it. We know of one reference in the open literature [1] that makes a pretty striking point about X.25 in a secure network. Dr. Kent's point is that X.25's very field sizes aren't acceptable from the point of view of encryption devices. If that's correct (and honestly, we're not the ones who can judge that, and we wouldn't be in a position to even if we tried 🙈), then X.25 is almost disqualified a priori for a lot of arenas. Like, uncertified "DCE's" can't be allowed to read classified (or even "private") data, so they have to be "encrypted around" instead. Not a vibe. 💀

It would probably be the case, if we understand Dr. Kent's point, that X.25 could be changed appropriately, if its specifiers were willing to go along 🙃. But that's only one problem out of a potentially large number of problems. And, going back to our concern about how X.25 interacts with the DoD, the people in the DoD who know best what the problems are (and/or could be) are barred from discussing them with the specifiers of X.25. Sooo... 🫠 Maybe a sufficiently zealous ISORM advocate would want to suggest that Professor Kuo's publisher get subsidized to come out with a new edition every time a problem pops up, so that if Dr. Kent happens to spot one, we can keep taking advantage of his ability to write for the open literature. We're really hoping and trusting that no ISORMite is so tone-deaf that they fail to notice how facetious that suggestion is 💅.

In short, it seems hard to argue with the assertion that whatever sort of security blanket X.25 could represent would, at best, be an off shade of blue 💙.

Space-Time Considerations

Another topic we touched on earlier that deserves its own spotlight, if only to collect the scattered data in one place, is what people have been calling space-time considerations ⏳. We're concerned about how well X.25 in particular, and the ISORM-derived protocols in general, will implement. That's both in terms of the size of protocol interpreters (PI's) and in terms of execution and delay times.

On the space front, X.25 offers more functionality in its end-to-end guise than it needs in order to fulfill its network interface role. That suggests X.25 PI's will be bigger than they need to be 📦. As an aside (but a striking one 👀), X.25's end-to-end functions are at variance with the ISORM itself, because the "peer entity" of a DTE X.25 entity must surely be the local DCE X.25. Maybe a later version of the ISORM will introduce the polypeer and kick off a whole new round of Layering-Theologic controversy.* Speaking of the ISORM itself, people who hold that each layer must be traversed on each transmission are implicitly requiring that space (and time) be spent in the Session and Presentation Levels, even for applications that have no need of their services 😤. The Well-Known Socket concept of the ARM's primary Host-Host protocol, the Transmission Control Protocol (TCP), lets applications avoid Session functionality for many uses, on the other hand. That's unless ISORM L5 is going to usurp the Host's user identification/authentication role at some point. (Yes, we've heard the rumors that "null layers" might be introduced into the ISORM. No, we don't want to get into the theology of that either 🙅‍♀️.)

On the time front, X.25's virtual circuit view can be debilitating, or even crippling, for applications like Packetized Speech, where prompt delivery is preferred over ordered or even reliable delivery 🎙️. (Some people hold that the X.25 datagram option will fix that. Others hold that it's not "really datagrams." We note the concern, agree with the others, and pass on 🤷‍♀️.) Speaking of reliable delivery: as noted earlier, some observers hold that to present an acceptable virtual circuit, X.25 must have a protocol as strong as TCP "beneath" itself. Again, we're in sympathy with them 🫶. Shifting focus back to the ISORM itself, it has to be noted that the principle that "N-entities" must communicate with one another, even on the same Host, via "N-1 entities," also on the same Host, is an over-zealous application of the Principle of Layering. It must consume more time in interpreting the N-1 protocol than a direct interface between N-level PI's would, or than process-level protocols like FTP and Telnet would, as is done in the ARPANET-derived model 🐢.

Other space-time deficiencies could be adduced, but a shortcut will probably do. There's a Law of Programming (attributed to Sutherland) to the effect that "Programs are like waffles: you should always throw the first one out." 🧇 Its relevance should become

*And perhaps we now know why some just draw the highrises.

clear once you realize that (with the possible exception of X.25) ISORM PI's are, in general, either first implementations or not even implemented yet. So the batter, as it were, is still being mixed 🥣. Contrast this with the iterations the ARPANET-derived PI's (and, for that matter, protocols) have gone through over the years, and the grounds for our concern about X.25/ISORM space-time inefficiency become clear, irrespective of any corroborative detail 📈. Factor in that space-time efficiency may be viewed as contrary to the corporate interests of the progenitors of X.25 ("the PTT's") and of at least the current favorite for ISORM Level 4 (ECMA, the European Computer Manufacturers' Association), and it should be pretty obvious why we insist that space-time considerations get separate mention, even though they're touched on elsewhere 🧐.*

Getting Physical 🔌

Still another area of concern about X.25 is that it dictates only one means of attaching a "DTE" to a "DCE" 😬. Earlier references to "the X.25 protocol(s)" were not typographical errors. Most of the time, "X.25" refers to ISORM Level 3, but the term actually subsumes L2 and L1 as well. The lowest levels constitute particular bit serial interfaces. This is all very well for interfacing to "Public Data Nets" (again, it must be remembered that X.25's roots are in CCITT). But it's scarcely appropriate for environments where the communications subnetwork might be geosynchronous communications satellite channels, "Packet Radios," or whatever else 🛰️📡. Even for conventional Local Area Networks, it's often the case that a Direct Memory Access arrangement is desired to avoid bottlenecking. But DMA isn't HDLC, and the "vendor supported X.25 interface" that some people are obsessed with won't be DMA either, one imagines 🙃. (Speaking of LAN's: the evolving standard in that arena, "IEEE 802," apparently will offer multiple physical interfaces depending on comm subnet style [although there's some disagreement on this point amongst readers of their draft specs]. We understand, however, that their Level 2 shares X.25's end-end aspirations, and we haven't checked up on DMA capability 🤔.) So X.25 imposes constraints on its users, with regard to interface technology, that are inappropriate 🚫.

*The broad issue of design team composition is amplified in Padlipsky, M. A., "The Illusion of Vendor Support", M82-49, The MITRE Corporation, September 1982.

Other Observers' Concerns 👀

This paper owes a lot to conversations with a bunch of people. The interpretations of their concerns are the author's responsibility, though 🫡. Still, a few recent documents in the area deserve a mention. The Defense Communications Agency (DCA Code J110) has sent a coordinated DoD position [2] to NBS holding that X.25 cannot be the DoD's sole network interface standard 🪖. Dr. Vinton Cerf of the ARPA Information Processing Technology Office contributed to the former, and his contribution contains a particularly lucid exposition of why proper "datagram" capability in DoD comm subnets is desirable [3] 💜. Mr. Ray McFarland of the DoD Computer Security Evaluation Center has also explored the limitations of X.25 [4] 🔍. Whether these authors are inherently more tactful than the present author, or their positions are more constraining, or they've simply been more insulated from, and hence less provoked by, uninformed ISORMite zealots, none of them has seen fit to address the "quality" of X.25 😌. That this paper chooses to do so may be attributed to any one of a number of reasons. But the author believes the key reason is the following:

Conclusion 🎬

X.25 is not a good thing. 🙅‍♀️💥

References 📚

[1] Kent, S. T., "Security in Computer Networks," in Kuo, F., Ed., Protocols and Techniques for Data Communications Networks, Prentice-Hall, 1981, pp. 369-432.

[2] Letter to NBS from P. S. Selvaggi, Chief, Interoperability and Standards Office, 7 April 1982.

[3] Cerf, V. G., "Draft DoD Position Regarding X.25" in undated letter to P. S. Selvaggi.

[4] Personal communications.

📦 where this page comes from