rfc874.txt

RFC 的详细文档！

     give rise to the interesting observation that DCE's seem to need
     a protocol as strong as TCP amongst themselves, but 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"*

          Although it was at least implied in the discussion of
     conceptual model problems, one aspect of X.25/X.75 internetting
     is sufficiently significant to deserve a section of its own:  Not
     only does the link-by-link approach taken by CCITT make it
     unlikely that alternate routing can take place, but it is also
     the case that ARPANET Internet Protocol (IP) based internetting
     not only permits alternate routing but also could alt-route over
     an "X.25 Subnet."  That is, in IP's conceptual model, Gateways
     attach to two or more comm subnets "as if they (the Gateways)
     were Hosts."  This means that they interpret the appropriate
     Host-comm subnet processor protocol of whatever comm subnets
     they're attached to, giving as the "proximate net address" of a
     given transmission either the ultimate (internet addressed)
     destination or the address of another Gateway "in the right
     direction."  And an implementation of IP can certainly employ an
     implementation of ("DTE") X.25 to get a proximate net, so ... at
     least "in an emergency" X.25 interface presenting Public Data
     Networks can indeed carry IP traffic.  (Note also that only the
     proximate net's header has to be readable by the nodal processor
     of/on the proximate net, so if some appropriate steps were taken
     to render the data portion of such transmissions unintelligible
     to the nodal processors, so much the better.)

     ________________
     *  This section was added to address the ill-founded concerns of
        several ISORMites that "TCP/IP won't let you use Public Data
        Nets in emergencies."







                                     9
     RFC 874                                            September 1982


          (Further evidence that X.75 internetting is undesirable is
     found in the fact that the U.S. National Bureau of Standards has,
     despite its nominal adoption of the ISORM, inserted IP at
     approximately L3.5 in its version of the Reference Model.)

     The Off-Blue Blanket

          Although touched on earlier, and not treatable at much
     length in the present context, the topic of security deserves
     separate mention.  We are familiar with one reference in the open
     literature [1] which appears to make a rather striking point
     about the utility of X.25 in a secure network.   Dr. Kent's point
     that the very field sizes of X.25 are not acceptable from the
     point of view of encryption devices would, if correct (and we are
     neither competent to assess that, nor in a position to even if we
     were), almost disqualify X.25 a priori for use in many arenas.
     Clearly, uncertified "DCE's" cannot be permitted to read
     classified (or even "private") data and so must be "encrypted
     around," after all.

          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 this is only one
     problem out of a potentially large number of problems, and,
     returning briefly to our concern with the interplay of X.25 and
     the DoD, those persons in the DoD who know best what the problems
     are and/or could be are debarred from discussing them with the
     specifiers of X.25.  Perhaps a sufficiently zealous ISORM
     advocate would be willing to suggest that Professor Kuo's
     publisher be subsidized to come out with a new edition whenever a
     problem arises so that if Dr. Kent happens to spot it advantage
     can continue to be taken of his ability to write for the open
     literature--but we certainly hope and trust that no ISORMite
     would be so tone-deaf as to fail to recognize the facetiousness
     of that suggestion.

          In short, it appears to be difficult to dispute 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 touched on earlier which deserves separate
     mention, if only to collect the scattered data in a single
     section, is that of what have been called space-time
     considerations.  That is, we are concerned about how well X.25 in
     particular and the ISORM-derived protocols in general will
     implement, both in terms of size of protocol interpreters (PI's)
     and in terms of execution and delay times.






                                    10
     RFC 874                                            September 1982


          On the space heading, certainly the fact that X.25 offers
     more functionality in its end-to-end guise than is required to
     fulfill its network interface role suggests that X.25 PI's will
     be bigger than they need be.  As an aside--but a striking one--it
     should be noted that X.25's end-to-end functions are at variance
     with the ISORM itself, for the "peer entity" of a DTE X.25 entity
     must surely be the local DCE X.25.  Perhaps a later version of
     the ISORM will introduce the polypeer and give rise to a whole
     new round of Layering-Theologic controversy.*  Speaking of the
     ISORM itself, those who hold that each layer must be traversed on
     each transmission are implicitly requiring that space (and time)
     be expended 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 Session functionality
     be avoided for many applications, on the other hand--unless ISORM
     L5 is 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 heading, X.25's virtual circuit view can be
     debilitating--or even crippling--to applications such as
     Packetized Speech where prompt delivery is preferred over ordered
     or even reliable delivery.  (Some hold that the X.25 datagram
     option will remedy 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 in order 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 again
     to the ISORM itself, it must be noted that the principle that
     "N-entities" must communicate with one another even in the same
     Host via "N-1 entities" even in the same Host is an over-zealous
     application of the Principle of Layering that must consume more
     time in the interpreting of the N-1 protocol than would a direct
     interface between N-level PI's or such process-level protocols as
     FTP and Telnet, as is done in the ARPANET-derived model.

          Other space-time deficiencies could be adduced, but perhaps
     a shortcut will suffice.  There is 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.








                                    11
     RFC 874                                            September 1982


     clear when it is realized that (with the possible exception of
     X.25) ISORM PI's are in general either first implementations or
     not even implemented yet (thus, 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 over
     X.25/ISORM space-time inefficiency become clear irrespective of
     corroborative detail. Factor in the consideration that space-time
     efficiency may be viewed as contrary to the corporate interests
     of the progenitors of X.25 ("the PTT's") and at least the current
     favorite for ISORM Level 4 (ECMA--the European Computer
     Manufacturers' Association), and it should become clear why we
     insist that space-time considerations be given separate mention
     even though touched upon elsewhere.*

     Getting Physical

          Still another area of concern over X.25 is that it dictates
     only one means of attaching a "DTE" to a "DCE."  That is, earlier
     references to "the X.25 protocol(s)" were not typographical
     errors. Most of the time, "X.25" refers to ISORM Level 3;
     actually, though, the term subsumes L2 and L1 as well.  Indeed,
     the lowest levels constitute particular bit serial interfaces.
     This is all very well for interfacing to "Public Data Nets"
     (again, it must be recalled that X.25's roots are in CCITT), but
     is scarcely appropriate to environments where the communications
     subnetwork may consist of geosynchronous communications satellite
     channels, "Packet Radios," or whatever.  Indeed, even for
     conventional Local Area Networks it is often the case that a
     Direct Memory Access arrangement is desired so as to avoid
     bottlenecking--but DMA isn't HDLC, and the "vendor supported X.25
     interface" so prized by some won't be DMA either, one imagines.
     (Speaking of LAN's, at least the evolving standard in that
     arena--"IEEE 802"--apparently will offer multiple physical
     interfaces depending on comm subnet style [although there is 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.)  X.25,
     then, imposes constraints upon 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.










                                    12
     RFC 874                                            September 1982


     Other Observers' Concerns

          This paper owes much to conversations with a number of
     people, although the interpretations of their concerns are the
     author's responsibility.  Mention should be made, however, of a
     few recent documents in the area:  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 made a contribution to the former which
     contains a particularly lucid exposition of the desirability of
     proper "datagram" capability in DoD comm subnets [3]; Mr. Ray
     McFarland of the DoD Computer Security Evaluation Center has also
     explored the limitations of X.25 [4]. Whether because these
     authors are inherently more tactful than the present author, or
     whether their positions are more constraining, or even whether
     they have been more insulated from and hence less provoked by
     uninformed ISORMite zealots, none 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 contained in 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.

     














                                    13