tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5570

 
 
 

Common Architecture Label IPv6 Security Option (CALIPSO)

Part 3 of 3, p. 41 to 52
Prev RFC Part

 


prevText      Top      Up      ToC       Page 41 
7.  Architectural and Implementation Considerations

   This section contains "implementation considerations"; it does not
   contain "requirements".  Implementation experience might eventually
   turn some of them into implementation requirements in some future
   version of this specification.

   This IPv6 option specification is only a small part of an overall
   distributed Multi-Level Secure (MLS) deployment.  Detailed
   instructions on how to build a Multi-Level Secure (MLS) device are
   well beyond the scope of this specification.  Additional information
   on implementing a Multi-Level Secure operating system, for example
   implementing an MLS End System, is available from a range of sources
   [TCSEC] [TNI] [CMW] [CC] [ISO-15408] [MLOSPP].

Top      Up      ToC       Page 42 
   Because the usual 5-tuple (i.e., Source IP address, Destination IP
   address, Transport protocol, Source Port, and Destination Port) do
   not necessarily uniquely identify a flow within a labeled MLS network
   deployment, some applications or services might be impacted by
   multiple flows mapping to a single 5-tuple.  This might have
   unexpected impacts in a labeled MLS network deployment using such
   application protocols.  For example, Resource Reservation Protocol
   (RSVP), Session Initiation Protocol (SIP), and Session Description
   Protocol (SDP) might be impacted by this.

   A number of Commercial-Off-The-Shelf (COTS) applications (e.g.,
   Remote Access Dial-In User Service (RADIUS), Hyper-Text Transfer
   Protocol (HTTP), and Transport-Layer Security (TLS) web content
   access) have been included in MLS network deployments for about two
   decades, without operational difficulties or a need for special
   modifications.  The ability to use these common applications
   demonstrates that the basic Internet architecture remains unchanged
   in an MLS deployment, although certain details (e.g., adding labels
   to IP datagrams) do change.

7.1.  Intermediate Systems

   Historically, RFC 1108 was supported by one commercial label-aware IP
   router.  Neither RFC 1038 nor FIPS-188 were supported in any
   commercial IP router, so far as the authors are aware.  A label-aware
   router does not necessarily use an MLS operating system.  Instead, a
   label-aware router might use a conventional router operating system,
   adding extensions to permit application of per-logical-interface
   label-oriented Access Control Lists (ACLs) to IP packets entering and
   leaving that router's network interface(s).

   This proposal does not change IP routing in any way.  Existing
   label-aware routers do not use Sensitivity Labels in path
   calculations, Routing Information Base (RIB) or Forwarding
   Information Base (FIB) calculations, their routing protocols, or
   their packet forwarding decisions.

   Similarly, existing MLS network deployments use many protocols or
   specifications, for example, Differentiated Services, without
   modification.  For Differentiated Services, this might mean that
   multiple IP flows (i.e., flows differing only in their CALIPSO label
   value) would be categorized and handled by Intermediate Systems as if
   they were a single flow.

   Router performance is optimized if there is hardware support for
   applying the Mandatory Access Controls based on this label option.
   An issue with CIPSO is that the option syntax is remarkably complex
   [FIPS-188].  So this label option uses a simplified syntax.  This

Top      Up      ToC       Page 43 
   should make it more practical to create custom logic (e.g., in
   Verilog) with support for this option and the associated Mandatory
   Access Controls.

7.2.  End Systems

   It is possible for a system administrator to create two DOIs with
   different overlapping compartment ranges.  This can be used to reduce
   the size of the IPv6 Sensitivity Label option in some deployments.

7.3.  Upper-Layer Protocols

   As CALIPSO is an IP option, this document focuses upon the network-
   layer handling of IP packets containing CALIPSO options.  This
   section provides some discussion of some upper-layer protocol issues.

   This section is not a complete specification for how an MLS End
   System handles information internally after the decision has been
   made to accept a received IPv6 packet containing a CALIPSO option.
   Implementers of MLS systems might wish also to consult [TCSEC],
   [TNI], [CMW], [CC], [ISO-15408], and [MLOSPP].

   In a typical MLS End System, the information received from the
   network (i.e., information not dropped by the network layer as a
   result of the CALIPSO processing described in this document) is
   assigned an internal Sensitivity Label while inside the End System
   operating system.  The MLS End System uses the Bell-LaPadula
   Mandatory Access Control policy [BL73] to determine how that
   information is processed, including to which transport-layer sessions
   or to which applications the information is delivered.

   Within this section, we use one additional notation, in an attempt to
   be both clear and concise.  Here, the string "W:XY" defines a
   Sensitivity Label where the Sensitivity Level is W and where X and Y
   are the only compartments enabled, while the string "W::" defines a
   Sensitivity Label where the Sensitivity Level is W and there are no
   compartments enabled.

7.3.1.  TCP-Related Issues

   With respect to a network, each distinct Sensitivity Label represents
   a separate virtual network, which shares the same physical network.

   The above statement, taken from Section 3, has a non-obvious, but
   critical, corollary.  If there are separate virtual networks, then it
   is possible for a system that exists in multiple virtual networks to
   have identical TCP connections, each one existing in a different
   virtual network.

Top      Up      ToC       Page 44 
   TCP connections are normally identified by source and destination
   port, and source and destination address.  If a system labels
   datagrams with the CALIPSO option (which it must do if it exists in
   multiple virtual networks - e.g., a "Multi-Level Secure" system),
   then TCP connections are identified by source and destination port,
   source and destination address, and an internal Sensitivity Label
   (optionally, a Sensitivity Label range).  This corrects a technical
   error in RFC 793, and is consistent with all known MLS operating
   system implementations [TNI] [RFC793].  There are no known currently
   deployed TCP instances that actually comply with this specific detail
   of RFC 793.

7.3.2.  UDP-Related Issues

   Unlike TCP or SCTP, UDP is a stateless protocol, at least
   conceptually.  However, many implementations of UDP have some session
   state (e.g., Protocol Control Blocks in 4.4 BSD), although the UDP
   protocol specifications do not require any state.

   One consequence of this is that in widely used End System
   implementations of UDP and IPv6, a UDP listener might be bound only
   to a particular UDP port on its End System -- without binding to a
   particular remote IP address or local IP address.

   UDP can be used with unicast or with multicast.  Some existing UDP
   End System implementations permit a single UDP packet to be delivered
   to more than one listener at the same time.  Except for the
   application of Mandatory Access Controls, the behavior of a given
   system should remain the same (so that application behavior does not
   change in some unexpected way) with respect to delivery of UDP
   datagrams to listeners.

   For example, if a listener on UDP port X has a Sensitivity Label
   range with a minimum of "S:AB" and a maximum of "S:AB", then only
   datagrams with a destination of UDP port X and a Sensitivity Label of
   "S:AB" will be delivered to that listener.

   For example, if a listener on UDP port Y has a Sensitivity Label
   range with a minimum of "W::" and a maximum of "X:ABC" (where X
   dominates W), then a datagram addressed to UDP port Y with a
   Sensitivity Label of "W:A" normally would be delivered to that
   listener.

7.3.3.  SCTP-Related Issues

   With respect to a network, each distinct Sensitivity Label represents
   a separate virtual network, which shares the same physical network.

Top      Up      ToC       Page 45 
   The above statement, taken from Section 3, has a non-obvious, but
   critical, corollary.  If there are separate virtual networks, then it
   is possible for a system that exists in multiple virtual networks to
   have identical SCTP connections, each one existing in a different
   virtual network.

   As with TCP, SCTP is a connection-oriented transport protocol and has
   substantial session state.  Unlike TCP, SCTP can support session-
   endpoint migration among IP addresses at the same end node(s), and
   SCTP can also support both one-to-one and one-to-many communication
   sessions.

   In single-level End Systems, in the one-to-one mode, the SCTP session
   state for a single local SCTP session includes the set of remote IP
   addresses for the single remote SCTP instance, the set of local IP
   addresses, the remote SCTP port number, and the local SCTP port
   number.

   In single-level End Systems, in the one-to-many mode, the SCTP
   session state for a single local SCTP instance can have multiple
   concurrent connections to several different remote SCTP peers.  There
   cannot be more than one connection from a single SCTP instance to any
   given remote SCTP instance.  Thus, in single-level End Systems, in
   the one-to-many mode, the local SCTP session state includes the set
   of remote IP addresses, the set of local IP addresses, the remote
   SCTP port number for each remote SCTP instance, and the (single)
   local SCTP port number.

   In MLS End Systems, for either SCTP mode, the SCTP session state
   additionally includes the Sensitivity Label for each SCTP session.  A
   single SCTP session, whether in the one-to-one mode or in the one-
   to-many mode, MUST have a single Sensitivity Label, rather than a
   Sensitivity Label range.

   Unlike TCP, SCTP has the ability to shift an existing SCTP session
   from one endpoint IP address to a different IP address that belongs
   to the same endpoint, when one or more endpoints have multiple IP
   addresses.  If such shifting occurs within an MLS deployment, it is
   important that it only move to an IP address with a Sensitivity Label
   range that includes that SCTP session's own Sensitivity Label.

   Further, although a node might be multi-homed, it is entirely
   possible that only one of those interfaces is reachable for a given
   Sensitivity Label value.  For example, one network interface on a
   node might have a Sensitivity Label range from "A::" to "B:XY" (where
   B dominates A), while a different network interface on the same node
   might have a Sensitivity Label range from "U::" "U::" (where A
   dominates U).  In that example, if a packet has a CALIPSO label of

Top      Up      ToC       Page 46 
   "A:X", then that packet will not be able to use the "U"-only network
   interface.  Hence, an SCTP implementation needs to consider the
   Sensitivity Label of each SCTP instance on the local system when
   deciding which of its own IP addresses to communicate to the remote
   SCTP instance(s) for that SCTP instance.  This issue might lead to
   novel operational issues with SCTP sessions.  Implementers ought to
   give special attention to this SCTP-specific issue.

7.3.4.  Security Logging

   This option is recommended for deployment only in well-protected
   private networks that are NOT connected to the global Internet.  By
   definition, such private networks are also composed only of trusted
   systems that are believed to be trustworthy.  So the risk of a
   denial-of-service attack upon the logging implementation is much
   lower in the intended deployment environment than it would have been
   for general Internet deployments.

8.  Security Considerations

   This document describes a mechanism for adding explicit Sensitivity
   Labels to IPv6 datagrams.  The primary purpose of these labels is to
   facilitate application of Mandatory Access Controls (MAC) in End
   Systems or Intermediate Systems that implement this specification.

   As such, correct implementation of this mechanism is very critical to
   the overall security of the systems and networks where this
   mechanisms is deployed.  Use of high-assurance development techniques
   is encouraged.  End users should carefully consider the assurance
   requirements of their particular deployment, in the context of that
   deployment's prospective threats.

   A concern is that since this label is used for Mandatory Access
   Controls, some method of binding the Sensitivity Label option to the
   rest of the packet is needed.  Without such binding, malicious
   modification of the Sensitivity Label in a packet would go
   undetected.  So, implementations of this Sensitivity Label option
   MUST also implement support for the IP Authentication Header (AH).
   Implementations MUST permit the system administrator to configure
   whether or not AH is used.

   ESP with null encryption mechanism can only protect the payload of an
   IPv6 packet, not any Hop-by-Hop Options.  By contrast, AH protects
   all invariant headers and data of an IPv6 packet, including the
   CALIPSO Hop-by-Hop Option.  The CALIPSO option defined in this
   document is always an IPv6 Hop-by-Hop Option, because the CALIPSO
   option needs to be visible to, and parsable by, IPv6 routers and
   security gateways so that they can apply MAC policy to packets.

Top      Up      ToC       Page 47 
   It is anticipated that if AH is being used with a symmetric
   authentication algorithm, then not only the recipient End System, but
   also one or more security gateways along the path, will have
   knowledge of the symmetric key -- so that AH can be used to
   authenticate the packet, including the CALIPSO label.  In this case,
   all devices knowing that symmetric authentication key would need to
   be trusted.  Alternatively, AH may be used with an asymmetric
   authentication algorithm, so that the recipient and any security
   gateways with knowledge of the authentication key can authenticate
   the packet, including the CALIPSO label.

   If AH or ESP are employed to provide "labeled IP Security" within
   some CALIPSO deployment, then the Sensitivity Label of the IP
   Security Association used for a given packet MUST have the same
   meaning as the Sensitivity Label carried in the CALIPSO option of
   that packet, in order that MAC policy can and will be correctly
   applied.

   Because the IP Authentication Header will include the CALIPSO option
   among the protected IPv6 header fields, modification of a CALIPSO-
   labeled packet that also contains an IP Authentication Header will
   cause the resulting packet to fail authentication at the destination
   node for the AH security session.  Therefore, CALIPSO labels cannot
   be inserted, deleted, or translated for IPv6 packets that contain an
   IP Authentication Header.

   NOTE WELL: The "not modified during transit" bit for IPv6 option
   types was really created to be the "include in AH calculations"
   signal.  There was no other reason to define that bit in IPv6.

   In situations where a modification by an Intermediate System is
   required by policy, but is not possible due to AH, then the packet
   MUST be dropped instead.  If the packet must be dropped for this
   reason, then an ICMP "Destination Unreachable" error message SHOULD
   be sent back to the originator of the dropped packet with a reason
   code of "Administratively Prohibited".  If the packet can be
   forwarded properly without violating the MLS MAC policy of the
   Intermediate System, then (by definition) such a packet modification
   is not required.

   Note that in a number of error situations with labeled networking, an
   ICMP error message MUST NOT be sent in order to avoid creating
   security problems.  In certain other error situations, an ICMP error
   message might be sent.  Such ICMP handling details have been
   described earlier in this document.  Even if an ICMP error message is
   sent, it might be dropped along the way before reaching its intended
   destination -- due to MAC rules, DOI differences, or other configured
   security policies along the way from the node creating the ICMP error

Top      Up      ToC       Page 48 
   message to the intended destination node.  In turn, this can mean
   operational faults (e.g., fibre cut, misconfiguration) in a labeled
   network deployment might be more difficult to identify and resolve.

   This mechanism is only intended for deployment in very limited
   circumstances where a set of systems and networks are in a well-
   protected operating environment and the threat of external or
   internal attack on this mechanism is considered acceptable to the
   accreditor of those systems and networks.  IP packets containing
   visible packet labels ought never traverse the public Internet.

   This specification does not seek to eliminate all possible covert
   channels.  The TCP specification clarification in Section 7.3.1
   happens to reduce the bandwidth of a particular known covert channel,
   but is present primarily to clarify how networked MLS systems have
   always been implemented [TNI] [MLOSPP].

   Of course, subject to local security policies, encrypted IPv6 packets
   with CALIPSO labels might well traverse the public Internet after
   receiving suitable cryptographic protection.  For example, a
   CALIPSO-labeled packet might travel either through a Tunnel-mode ESP
   (with encryption) VPN tunnel that connects two or more MLS-labeled
   network segments.  Alternatively, a CALIPSO-labeled IPv6 packet might
   travel over some external link that has been protected by the
   deployment of evaluated, certified, and accredited bulk encryptors
   that would encrypt the labeled packet before transmission onto the
   link and decrypt the labeled packet after reception from the link.

   Accreditors of a given CALIPSO deployment should consider not only
   personnel clearances and physical security issues, but also
   electronic security (e.g., TEMPEST), network security (NETSEC),
   communications security (COMSEC), and other issues.  This
   specification is only a small component of an overall MLS network
   deployment.

9.  IANA Considerations

9.1.  IP Option Number

   An IPv6 Option Number [RFC2460] has been registered for CALIPSO.

      HEX             BINARY
                act   chg   rest
      ---       ---   ---   -----
        7        00     0   00111          CALIPSO

Top      Up      ToC       Page 49 
   For the IPv6 Option Number, the first two bits indicate that the IPv6
   node skip over this option and continue processing the header if it
   does not recognize the option type.  The third bit indicates that the
   Option Data must not change en route.

   This document is listed as the reference document.

9.2.  CALIPSO DOI Values Registry

   IANA has created a registry for CALIPSO DOI values.  The initial
   values for the CALIPSO DOI registry, shown in colon-separated quad
   format, are as follows:

      DOI Value                     Organization or Use
      =======================       ============================
      0:0:0:0                       NULL DOI.  This ought not
                                    be used on any network.

      0:0:0:1 to 0:255:255:255      For private use among
                                    consenting parties within
                                    private networks.

      1:0:0:0 to 254:255:255:255    For assignment by IANA to
                                    organizations following the
                                    Expert Review procedure
                                    [RFC5226].

      255:0:0:0 to 255:255:255:255  Reserved to the IETF for
                                    future use by possible
                                    revisions of this specification.

   The CALIPSO DOI value 0:0:0:0 is the NULL DOI and is not to be used
   on any network or in any deployment.

   All other CALIPSO DOI values beginning with decimal 0:  are reserved
   for private use amongst consenting parties; values in this range will
   not be allocated by IANA to any particular user or user community.

   For the CALIPSO DOI values 1:0:0:0 through 254:255:255:255
   (inclusive), IANA should follow the Expert Review procedure when DOI
   Allocation requests are received.

   CALIPSO DOI values beginning with decimal 255 are reserved to the
   IETF for potential future use in revisions of this specification.
   IESG approval is required for allocation of DOI values within that
   range.

Top      Up      ToC       Page 50 
10.  Acknowledgments

   This document is directly derived from an Internet-Draft titled "Son
   of IPSO (SIPSO)" written by Mike StJohns circa 1992.  Various changes
   have been made since then, primarily to support IPv6 instead of IPv4.
   The concepts, most definitions, and nearly all of the processing
   rules here are identical to those in that earlier document.

   Steve Brenneman, L.C. Bruzenak, James Carlson, Pasi Eronen, Michael
   Fidler, Bob Hinden, Alfred Hoenes, Russ Housley, Suresh Krishnan,
   Jarrett Lu, Dan McDonald, Paul Moore, Joe Nall, Dave Parker, Tim
   Polk, Ken Powell, Randall Stewart, Bill Sommerfeld, and Joe Touch
   (listed in alphabetical order by family name) provided specific
   feedback on earlier versions of this document.

   The authors also would like to thank the several anonymous reviewers
   for their feedback, and particularly for sharing their insights into
   operational considerations with MLS networking.

   The authors would like to thank the IESG as a whole for providing
   feedback on earlier versions of this document.

11.  References

11.1.  Normative References

   [RFC1662]     Simpson, W., Ed., "PPP in HDLC-like Framing", STD 51,
                 RFC 1662, July 1994.

   [RFC2460]     Deering, S. and R. Hinden, "Internet Protocol, Version
                 6 (IPv6) Specification", RFC 2460, December 1998.

   [RFC5226]     Narten, T. and H. Alvestrand, "Guidelines for Writing
                 an IANA Considerations Section in RFCs", BCP 26, RFC
                 5226, May 2008.

11.2.  Informative References

   [BL73]       Bell, D.E. and LaPadula, L.J., "Secure Computer Systems:
                 Mathematical Foundations and Model", Technical Report
                 M74-244, MITRE Corporation, Bedford, MA, May 1973.

   [CW87]        D.D. Clark and D.R. Wilson, "A Comparison of Commercial
                 and Military Computer Security Policies", in
                 Proceedings of the IEEE Symposium on Security and
                 Privacy, pp. 184-194, IEEE Computer Society, Oakland,
                 CA, May 1987.

Top      Up      ToC       Page 51 
   [CMW]         US Defense Intelligence Agency, "Compartmented Mode
                 Workstation Evaluation Criteria", Technical Report
                 DDS-2600-6243-91, Washington, DC, November 1991.

   [DoD5200.1-R]
                 US Department of Defense, "Information Security Program
                 Regulation", DoD 5200.1-R, 17 January 1997.

   [DoD5200.28]  US Department of Defense, "Security Requirements for
                 Automated Information Systems," Directive 5200.28, 21
                 March 1988.

   [MLOSPP]      US Department of Defense, "Protection Profile for
                 Multi-level Operating Systems in Environments requiring
                 Medium Robustness", Version 1.22, 23 May 2001.

   [ISO-15408]  International Standards Organisation, "Evaluation
                 Criteria for IT Security", ISO/IEC 15408, 2005.

   [CC]          "Common Criteria for Information Technology Security
                 Evaluation", Version 3.1, Revision 1, CCMB-2006-09-001,
                 September 2006.

   [TCSEC]       US Department of Defense, "Trusted Computer System
                 Evaluation Criteria", DoD 5200.28-STD, 26 December
                 1985.

   [TNI]         (US) National Computer Security Center, "Trusted
                 Network Interpretation (TNI) of the Trusted Computer
                 System Evaluation Criteria", NCSC-TG-005, Version 1, 31
                 July 1987.

   [FIPS-188]    US National Institute of Standards and Technology,
                 "Standard Security Labels for Information Transfer",
                 Federal Information Processing Standard (FIPS) 188,
                 September 1994.

   [IEEE802.1Q]  IEEE, "Virtual Bridged Local Area Networks", IEEE
                 Standard for Local and metropolitan area networks,
                 802.1Q - 2005, ISBN 0-7381-4876-6, IEEE, New York, NY,
                 USA, 19 May 2006.

   [RFC791]      Postel, J., "Internet Protocol", STD 5, RFC 791,
                 September 1981.

   [RFC793]      Postel, J., "Transmission Control Protocol", STD 7, RFC
                 793, September 1981.

Top      Up      ToC       Page 52 
   [RFC1038]     St. Johns, M., "Draft revised IP security option", RFC
                 1038, January 1988.

   [RFC1108]     Kent, S., "U.S. Department of Defense Security Options
                 for the Internet Protocol", RFC 1108, November 1991.

   [RFC1825]     Atkinson, R., "Security Architecture for the Internet
                 Protocol", RFC 1825, August 1995.

   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4301]     Kent, S. and K. Seo, "Security Architecture for the
                 Internet Protocol", RFC 4301, December 2005.

   [RFC4302]     Kent, S., "IP Authentication Header", RFC 4302,
                 December 2005.

   [RFC4303]     Kent, S., "IP Encapsulating Security Payload (ESP)",
                 RFC 4303, December 2005.

Authors' Addresses

   Michael StJohns
   Germantown, MD
   USA

   EMail: mstjohns@comcast.net


   Randall Atkinson
   Extreme Networks
   3585 Monroe Street
   Santa Clara, CA
   USA 95051

   EMail: rja@extremenetworks.com
   Phone: +1 (408)579-2800


   Georg Thomas
   US Department of Defense
   Washington, DC
   USA