rfc1457.txt

RFC 的详细文档！

   hiding principles apply.  Further, security labels which are to be
   parsed only by end systems should not be visible to physical, data
   link, or network layer protocols, where intermediate systems will
   have to examine them.

   Intermediate systems do not usually translate the security labels to
   a local format.  They use them "as is" to make their routing/discard
   decisions.  However, when two classification authorities share a
   network by bilateral agreement, the intermediate systems may be
   required to perform security label translation.  Security label
   translations should be avoided whenever possible by using a security
   label format that is supported by all systems that will process the
   security label.  Since end systems do not generally know which
   intermediate systems will process their traffic, security label
   translation cannot always be avoided.



Housley                                                         [Page 5]

RFC 1457       Security Label Framework for the Internet        May 1993


   Since security labels which are to be parsed only by end systems
   should not be carried by protocols interpreted by intermediate
   systems, such security labels should be carried by upper layer
   protocols, and end systems which use different formats for such
   security labels cannot rely on an intermediate systems to perform
   security label translation.  Neither the Internet nor the OSI
   architecture includes such transformation functions in the transport,
   session, or presentation layer, which means that application layer
   gateways should be used to translate between different end system
   security label formats.  Such application gateways should be avoided
   because they impinge on operation, especially when otherwise
   compatible protocols are used.  This complication is another reason
   why the use of a security label format that is supported by all
   systems is desirable.  A standard label syntax with registered
   security label semantics goes a long way toward avoiding security
   label translation [10].

4.0  Approaches to Labeling

   There are several tradeoffs to be made when determining how a
   particular network will perform security labeling.  Explicit or
   implicit labels can be used.  Also, security labels can either be
   connectionless or connection-oriented.  A combination of these
   alternatives may be appropriate.

4.1  Explicit Versus Implicit Security Labels

   Explicit security labels are actual bits in the protocol control
   information (PCI).  The IP Security Option (IPSO) is an example of an
   explicit security label [7].  Explicit security labels may be either
   connectionless or connection-oriented.  The syntax and semantics of
   the explicit security label may be either tightly or loosely coupled.
   If the syntax and semantics are tightly coupled, then the explicit
   security label format supports a single security policy.  If the
   syntax and semantics are loosely coupled, then the explicit security
   label format can support multiple security policies through
   registration.  In both cases, software enforces the security policy,
   but the label parsing software can be written once if the syntax and
   semantics are loosely coupled.  Fixed length explicit security label
   format parsers are generally faster than parsers for variable length
   formats.  Intermediate systems suffer less performance impact when
   fixed length explicit security labels can be used, but end systems
   often need variable length explicit security labels to express data
   handling requirements.

   Implicit security labels are not actual bits in the PCI; instead,
   some attribute is used to determine the security label.  For example,
   the choice of cryptographic key in the SP4 protocol [11] can



Housley                                                         [Page 6]

RFC 1457       Security Label Framework for the Internet        May 1993


   determine the security label.  Implicit security labels may be either
   connectionless or connection-oriented.

4.2  Connectionless Versus Connection-oriented Security Labels

   When connectionless security labels are used, the security label
   appears in every protocol data unit (PDU).  The IP Security Option
   (IPSO) [7] is an example of connectionless labeling.  All protocols
   have limits on the size of their PCI, and the explicit security label
   cannot exceed this size limit.  It cannot use the entire PCI space
   either; the protocol has other fields that must be transferred as
   well.  This size limitation may prohibit explicit connectionless
   security labels from meeting the requirements of end systems.
   However, the requirements of intermediate systems are more easily
   satisfied by explicit connectionless security labels.

   Connection-oriented security labels are attributes of virtual
   circuits, connections, and associations.  For simplicity, all of
   these are subsequently referred to as connections.  Connection-
   oriented security labels are used when the SDNS Key Management
   Protocol (KMP) [12] is used to associate security labels with each of
   the transport connection protected by the SP4 protocol [10,11] (using
   SP4C).  The security label is defined at connection establishment,
   and all data transferred over the connection inherits that security
   label.  This approach is more compatible with end system requirements
   than intermediate system requirements.  One noteworthy exception is
   X.25 packets switches; these intermediate systems could associate
   connection-oriented labels with each virtual circuit.

   Connectionless security labels may be used in conjunction with
   connectionless or connection-oriented data transfer protocols.
   However, connection-oriented security labels may only be used in
   conjunction with connection-oriented data transfer protocols.

5.0  Labeling Within the OSI Reference Model

   This section examines each of the seven OSI layers with respect to
   security labels.

5.1  Layer 1, The Physical Layer

   Explicit security labels are not possible in the Physical Layer.  The
   Physical Layer does not include any protocol control information
   (PCI), so there is no place to include the bits which represent the
   label.

   Implicit security labels are possible in the Physical Layer.  For
   example, all of the data that comes in through a particular physical



Housley                                                         [Page 7]

RFC 1457       Security Label Framework for the Internet        May 1993


   port could inherit one security label.  Most Physical Layer
   communication is connectionless, supporting only bit-at-a-time or
   byte-at-a-time operations.  Thus, these implicit security labels are
   connectionless.

   Implicit security labels in the Physical Layer may be used to meet
   the requirements of either end systems or intermediate systems so
   long as the communication is single level.  That is, only one
   security label is associated with all of the data received or
   transmitted through the physical connection.

5.2  Layer 2, The Data Link Layer

   Explicit security labels are possible in the Data Link Layer.  In
   fact, the IEEE 802.2 Working Group is currently working on an
   optional security label standard for the Logical Link Control (LLC)
   protocol (IEEE 802.2) [13].  These labels will optionally appear in
   each LLC frame.  These are connectionless security labels.

   Explicit connection-oriented security labels are also possible in the
   Data Link Layer.  One could imagine a security label standard which
   worked with LLC Type II.

   Of course, implicit security labels are also possible in the Data
   Link Layer.  Such labels could be either connectionless or
   connection-oriented.  One attribute that might be used in IEEE 802.3
   (CSMA/CD) [14] to determine the implicit security label is the source
   address of the frame.

   Security labels in the Data Link Layer may be used to meet the
   requirements of end systems and intermediate systems (especially
   bridges).  Explicit security labels in this layer tend to be small
   because the protocol headers for data link layer protocols are
   themselves small.  Therefore, when end systems require large security
   labels, a higher protocol layer should used to carry them.  However,
   when end systems do not require large security labels, the data link
   layer is attractive because in many cases the data link layer
   protocol supports several protocol suites simultaneously.  Label-
   based routing/relay decisions made by bridges are best supported in
   this layer.

5.3  Layer 3, The Network Layer

   Explicit security labels are possible in the Network Layer.  In fact,
   the IP Security Option (IPSO) [7] has been used for many years.
   These labels optionally appear in each IP datagram.  IPSO labels are
   obviously connectionless security labels.




Housley                                                         [Page 8]

RFC 1457       Security Label Framework for the Internet        May 1993


   Explicit connection-oriented security labels are also possible in the
   Network Layer.  One could easily imagine a security label standard
   for X.25 [15], but none exists.

   Of course, implicit security labels are also possible in the Network
   Layer.  These labels could be either connectionless or connection-
   oriented.  One attribute that might be used to determine the implicit
   security label is the X.25 virtual circuit.

   Security labels in the Network Layer may be used to meet the
   requirements of end systems and intermediate systems.  Explicit
   security labels in this layer tend to be small because the protocol
   headers for network layer protocols are themselves small.  Small
   fixed size network layer protocol headers allow efficient router
   implementations.  Therefore, when end systems require large security
   labels, a higher protocol layer should used to carry them.
   Alternatively, the Network Layer (especially the Subnetwork
   Independent Convergence Protocol (SNICP) sublayer) is an excellent
   place to carry a security label to support trusted demultiplexing,
   because many implementations demultiplex from an system-wide daemon
   to a user process after network layer processing.  The SNICP is end-
   to-end, yet it is low enough in the protocol stack to aid trusted
   demultiplexing.

   Label-based routing/relay decisions made by routers and packet
   switches are best supported in the Network Layer.  Routers can also
   add labels at subnetwork boundaries.  However, placement of these
   security labels must be done carefully to ensure that their addition
   does not degrade overall network performance by forcing routers that
   do not make label-based routing decisions to parse the security
   label.  Also, performance will suffer if the addition of security
   labels at subnet boundaries induces fragmentation/segmentation.

5.4  Layer 4, The Transport Layer

   Explicit security labels are possible in the Transport Layer.  For
   example, the SP4 protocol [10,11] includes them.  These labels can be
   either connectionless (using SP4E) or connection-oriented (using
   SP4C).  SP4 is an addendum to the TP [16] and CLTP [17] protocols.

   Implicit security labels are also possible in the Transport Layer.
   Such labels could be either connectionless or connection-oriented.
   One attribute that might be used to determine the implicit label in
   the SP4 protocol (when explicit labels are not used as discussed
   above) is the choice of cryptographic key.

   Security labels in the Transport Layer may be used to meet the
   requirements of end systems. The Transport Layer cannot be used to



Housley                                                         [Page 9]

RFC 1457       Security Label Framework for the Internet        May 1993


   meet the requirements of intermediate systems because intermediate
   systems, by definition, do not process protocols above the Network
   Layer.  Connection-oriented explicit security labels in this layer
   are especially good for meeting end system requirements where large
   labels are required.  The security label is transmitted only at
   connection establishment, so overhead is kept to a minimum.  Of
   course, connectionless transport protocols may not take advantage of
   this overhead reduction technique.  Yet, in many implementations the
   Transport Layer is low enough in the protocol stack to aid trusted
   demultiplexing.

5.5  Layer 5, The Session Layer

   Explicit security labels are possible in the Session Layer.  Such
   labels could be either connectionless or connection-oriented.
   However, it is unlikely that a standard will ever be developed for