rfc928.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,198 行 · 第 1/5 页

      what I meant for "mediation level" to Joel and Dick.)  Again,
      suggestions are solicited.

   Security

      During the detailed design pass, we had an intensive discussion
      with some of the Blacker design team on the interplay between the
      new H-FP and a meant-to-be multilevel-secure OPE such as Blacker.
      The conclusion was that by and large "Security" is to be an aspect
      of an enhanced H-FP, rather than the standard one. The reasoning
      was rather involved, but seems to amount to the following:  Hosts
      that are NOT MLS (or "Compartmented") have two significant
      properties in our context: They're in the vast majority of
      present-day systems.  They have no legitimate need even to tell
      their OPEs what they "think" their current System High or
      Dedicated Mode level is; that information should be furnished by
      some trusted portion of a network security architecture (e.g., a
      security enhanced OPE, or a table in a "secure" comm subnet
      processor).

      Thus, even having the optional security label/level field in the
      Begin command is in some sense overkill, because we're not sure of
      any sensible circumstances in which it would be useful, but we put
      it in "just in case".  On the other hand, Hosts that ARE
      MLS/Compartmented by definition can be permitted to assert what
      the level of a given transmission (or perhaps of a given
      connection) should be, and their OPEs need to have a mechanism for
      learning this.  But it is by no means clear that a given Host (or
      even a given OPE) will be so structured as to make the H-FP PI,


Padlipsky                                                       [Page 9]



RFC 928                                                    December 1984
Introduction to H-FP


      the Channel PI, and the Link PI ALL trustworthy--as they'd have to
      be if the security labeling were part of H-FP.  So, we envision
      the labeling's being handled by trusted code in both Host and OPE
      that will be inserted into the normal processing route at the
      appropriate point for the given architecture (presumably "at the
      very bottom" of the Host, and "the very top" of the OPE), and that
      will place the label in a convenient, known position in the
      Host-OPE transmission "chunk" (block/packet/data unit) as the
      circumstances dictate. (It's likely--but we wouldn't swear to
      it--that a good place would be just before the H-FP command, and
      if that's the case then semi-clearly the security enhanced H-FP
      PIs would have to "make room" for it in the sense of handing the
      Channel Layer a suitably lengthened "chunk".)

      The Host and its OPE should be viewed as a single entity with
      regard to labeling requirements in the non-MLS/C case, and either
      the OPE will be conditioned to emit the right label or the CSNP
      will "know" anyway; in the MLS/C Host and OPE case (and it should
      be noted that it's just about impossible to envision a MLS/C Host
      which IS outboarded which DOESN'T have a MLS/C OPE) it will depend
      on the given security architectures as to whether each "chunk"
      needs labeling (i.e., there COULD be trusted H-FP, Channel, and
      Link PIs, so that only at channel establishment time does the
      label need to be passed), but it seems likely each "chunk" would
      need labeling, and we can see how that would happen (as sketched
      above).

      This is all, of course, subject to reappraisal when the full-time
      Security folks get in the act, but for now, H-FP per se is viewed
      as playing no direct role in "Security"--except indirectly, as
      noted below under the Symmetric Begins Non-Issue.  (In case
      anybody's worrying about the case where the OPE is physically
      remote from its Host, by the way, that line would have to be
      protected anyway, so the Host/OPE-asa-single-unit view should hold
      up.)

   How It Implements

      The final issue to take note of is that one of the central
      premises of the Outboard Processing approach has always been that
      H-FPs can be invented which implement more compactly on the Host
      side than the code they're allowing to be offloaded.  We certainly
      think the new H-FP will fulfill that condition, but we'd certainly
      like to hear of any evidence to the contrary.





Padlipsky                                                      [Page 10]



RFC 928                                                    December 1984
Introduction to H-FP


Non-Issues

   The following items are declared to be non-issues, in the sense that
   even though some people have expressed concern over them we believe
   that they are either "not part of the protocol" or resolved already
   for reasons that were overlooked by those worried about them:

   Fabrication

      Who builds OPEs isn't within our purview, except to the extent of
      hoping a few volunteers come forward to do testcase
      implementations of what is, at present, only a paper protocol.
      However, beyond agreeing that a few points should be marked as
      "Notes to Entrepreneurs" in the spec, we didn't attempt to dictate
      how an OPE vendor would behave, beyond the explicit and implicit
      dictates of the protocol per se. For example, if a given OPE
      doesn't offload SMTP, it jolly well ought to respond with the
      appropriate "Function not implemented" code, and if a vendor
      claims to accept X.25 for Channel and Link disagreements over what
      X.25 "is" are the province of the vendor and the customer, not of
      the H-FP spec.  As OPE'S are supposed to be offloading COMMON
      protocols in a COMMON fashion, a given OPE should be able to
      interoperate with another Host irrespective of whether that Host
      even has an OPE, much less whose OPE it is if it's there. Thus,
      for example, even though you'd expect to find OPEs that "come
      with" their own LANs as a fairly frequent product, we don't appeal
      to the notion in the conceptual model; nor do we attempt to
      dictate "chunk" sizes at the Channel level. A protocol spec isn't
      an implementation spec.

   Symmetric Begins

      For almost as long as there have been H-FPs, there has been
      disagreement over whether only the Host can begin a connection or
      if the OPE can also take the initiative.  I am delighted to be
      able to resolve this one finally:  It turns out there IS a
      compelling reason for insisting that THE PROTOCOL include
      provision for OPE --> Host Begins, so it's "in" the protocol--but
      any Host that doesn't need to deal with them doesn't have to (just
      "spell" the "Function not implemented" response code correctly).

      (In case anybody cares, the compelling reason is that if you HAD
      an MLS OPE which happened to use a security kernel and a process
      per level, you'd need IT to be listening for incoming connection
      requests "from the net" rather than having the Host tell it to do
      so, for various esoteric reasons--but in order to cater to the
      possibility, we want the function in the protocol from the


Padlipsky                                                      [Page 11]



RFC 928                                                    December 1984
Introduction to H-FP


      beginning, on the grounds that we can envision SOME other uses for
      it even in non-MLS environments [unlike the security labeling
      trick discussed above, which only seems to make sense for MLS
      Hosts/OPEs--that is, it doesn't burden the Host to reject a Begin
      every once in a while but it would to go around labeling "chunks"
      unnecessarily all the time].)

   Routing

      Concern has been voiced over the issue of what provisions the
      protocol should make to deal with the situation where a Host,
      probably for traffic/load reasons, has multiple OPEs and the
      question arises of which OPE to use/route to.  I claim this is a
      non-issue at the protocol level.  If the Host-side H-FP PI gets a
      "No resources" response to a Begin, it can go off to another OPE
      if it wants to.  "Not our department".  The conceptual model is
      that of a Host and AN OPE--which "ought to" be expandable to carry
      more load at some level.  If you want multiple links for some
      reason, the simplest solution would seem to be to have multiple
      Channel Layers as well, but the whole thing just gets too iffy to
      have anything sensible to prescribe in the protocol.  In other
      words, extending the concept to deal with discrete multiple OPEs
      is either a Fabrication sort of thing, or a Notes to Host-side
      Implementors sort of thing on a per specific OPE basis.

   Operator Interface

      It's probably implicit in the foregoing, but it might be worth
      saying explicitly that the operator interface to a specific OPE is
      a non-issue in terms of the protocol, beyond the provision we're
      made for "Shutdown coming" responses as a reflection of a probable
      operator interface action we imagine most operator interfaces
      would provide.  (It might also be worth noting that if your Host
      does "color changes", your OPE had better have a trustworthy way
      of being told to change the label it plops on all IP datagrams it
      emits, but that comes under the heading of an Aside to Specialized
      Implementors.)












Padlipsky                                                      [Page 12]



RFC 928                                                    December 1984
Introduction to H-FP


Fine Points

   There are a couple of known "loose ends" which are exceedingly fine
   points in some sense that do bear separate mention:

   The Allocate Event

      While mentally testing to see if the new H-FP would indeed
      off-load TCP, we came up against an interesting question: Viewing
      H-FP as "just an interface at a distance" to a TCP PI, what about
      the Allocate "Interface Event" in the TCP spec?  As far as I'm
      concerned, this could be classed as a non-issue, because I submit
      that the spec is wrong in declaring that there is such a thing as
      a MANDATORY Interface Event whereby the user of a TCP PI lets the
      PI know how much data it can take. Granted, you might find such a
      thing in most implementations, but what if you were in a virtual
      memory environment with segment sharing (or a distributed
      supervisor) and you wanted to avoid copies, so all that passed at
      the interface to the PI (or even at the interface from the PI) was
      a pointer?  That is, the "DOD version" of the TCP spec has fallen
      into the trap of assuming things about the execution environment
      that it shouldn't have.

      One moral of this is that

         AN INTERFACE TO AN INTERPRETER OF A PROTOCOL IS N*O*T "THE
         PROTOCOL".

      Another moral is that the interface to the Host-side H-FP PI is
      hard to say much about, but is where the equivalent functionality