Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5570

Common Architecture Label IPv6 Security Option (CALIPSO)

Pages: 52
Informational
Errata
Part 3 of 3 – Pages 41 to 52
First   Prev   None

Top   ToC   RFC5570 - Page 41   prevText

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   ToC   RFC5570 - 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   ToC   RFC5570 - 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   ToC   RFC5570 - 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   ToC   RFC5570 - 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   ToC   RFC5570 - 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   ToC   RFC5570 - 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   ToC   RFC5570 - 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   ToC   RFC5570 - 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   ToC   RFC5570 - 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   ToC   RFC5570 - 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   ToC   RFC5570 - 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