Son of IPSO A Generic IP Sensitivity Labeling Option Michael C. StJohns Department of Defense 1. STATUS - ------ This is an incomplete draft provided at this time for discussion at the Boston IETF. This document describes an IP Option which may be used to label IP datagrams as to sen- sitivity within a particular security labeling and protec- tion "system". This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts). Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. 2. INTRODUCTION - ------------ 2.1. History - - ------- This document is a direct descendent of RFC1038 and RFC1108 and is a close cousin to the work done in the Com- mercial IP Security Option (CIPSO) Working Group of the Trusted Systems Interoperability Group. The original IP Security options defined by 1038 and 1108 were designed with one specific purpose in mind - to support the fielding of an IP packet encryption device called a BLACKER. Because of this, the definitions and assumptions in those documents were necessarily US Department of Defense and BLACKER cen- tric. This document is meant to serve a larger community, Draft - Expires 15 Nov 92 -1- Network Working Group M. StJohns, DOD while still meeting the needs of the 1038/1108 audience. 2.2. Intent - - ------ This document describes a generic way of marking datagrams as to their particular sensitivity. Provision is made for separating data based on relative sensitivity (i.e. security levels) and need-to-know or formal access programs (i.e. compartments or categories). This document is meant to replace and obsolete RFC1108, the current CIPSO draft and the current drafts of the various extended security options by incorporating their functionality into a single, generic marking standard. Admittedly this document and protocol are not "all things to all people", but there is enough func- tionality in the protocol to implement a broad subset of all the possible mandatory access control policies. 2.3. Definitions - - ----------- 2.3.1. Domain of Interpretation - - - ------ -- -------------- A Domain of Interpretation (DOI) is a shorthand way of identifying the use of a particular marking, classification and handling system with respect to data, the computers and people who process it and the networks that carry it. The DOI policies, combined with a particular marking (which is defined to have meaning within that DOI) applied to a datum or collection of data, dictates which systems, and ulti- mately which persons may receive that data. In other words a marking of "SECRET" by itself is not meaningful - you also have to know the document or data belongs to the Department of Energy before you can decide on who is allowed to receive the data. An IPSO DOI is a quantity (name/number) which is used as a pointer to a particular set of policies which define the security levels and categories present within the DOI, and by inference, the "real world" equivalent markings (See "Security Marking" below). Registering or defining a set of real world security policies as an IPSO DOI results in a standard way of marking IP data originating from hosts "accredited" or "approved" to operate within that DOI and the constraints of those security policies. For example, if you did this for the US Department of Defense, you would list all the acceptable markings such as "Secret" and "Top Secret", and you would link the IPSO DOI to "DOD 5200.28" and "DOD 5200.1R" documents which define how to mark and protect data with the DoD. The scope of the DOI is dependent on the organization establishing it. For example, the US might establish a DOI with specific meanings which correspond to the normal way its marks classified documents and which would apply pri- marily to the DOD, but might also apply to other associated Draft - Expires 15 Nov 92 -2- Network Working Group M. StJohns, DOD agencies. A company (or department within a company) might establish a DOI which applies only to itself. 2.3.2. Security Level/Sensitivity Level - - - -------- ----- ----------- ----- A security level represents a horizontal separation of data based on relative sensitivity. Security levels ALWAYS have a specific ordering within a DOI. Clearance to access a specific level of data also implies access to all levels whose sensitivity is less than that level. E.g. if the A, B and C are levels and A is more sensitive than B which is in turn more sensitive than C (A > B > C), access to data at the B level implies access to C as well. 2.3.3. Compartment/Category - - - ----------- -------- A compartment represents a vertical separation of data based on formal access programs for specific types of data. E.g. a small startup company creates "Finance" and "R&D" compartments to protect data critical to its success -- only employees with a specific need to know (the accountants and controller for "Finance", specific engineers for "R&D") are given access to each compartment. Each compartment is separate and distinct and access to one compartment does not imply access to any other compartment. Data may be pro- tected in multiple compartments ("Finance" data about a new "R&D" project), in which case access to ALL of those com- partments is required to access the data. 2.3.4. Security Marking - - - -------- ------- A tuple consisting of a DOI, a Security Level and a Compartment Set (which may be the empty set).. A DOI may be implicit or explicit depending on its use. A system which does not store a DOI as part of its internal security mark- ings must be considered to have an implicit DOI -- usually that of its primary "accrediting" authority; all objects on such a system inherit this implicit DOI. An IPSO security marking consists of a security marking of a particular for- mat (defined below) and ALWAYS contains an explicit DOI. 2.3.5. Range - - - ----- A range is a pair of security markings which indicate variously a minimum and maximum acceptable security marking for objects compared against it. A range is usually expressed as : and always has the pro- perty that the minimum marking is less than or equal to the maximum marking. A range where equals may be expressed simply as ; in this case, the only acceptable marking is . Ranges may also have associated with them an "Ignored Compartment Set" (in which case they are expressed as Draft - Expires 15 Nov 92 -3- Network Working Group M. StJohns, DOD ::. Compartments within the ignored set are "don't care" bits for the purpose of a com- parison against the range. Not all compartments within a DOI are necessarily eligible as ignorable compartments. The DOI owner must identify ignorable compartments as well as the circumstances under which they may be ignored. See Appendix X for an example use of ignorable compartments to implement a release marking system as one possible use. 2.3.6. Import - - - ------ The act of receiving a datagram and translating the IPSO markings into the appropriate internal (host specific) marking. 2.3.7. Export - - - ------ The act of selecting an appropriate DOI for an outbound datagram, translating the internal (host specific) marking into an IPSO marking based on that DOI, and sending the datagram. The selection of the appropriate DOI may be based on many factors including, but not necessarily limited to: Destination Port, Protocol, Host, Subnet, Network; Sending Interface; Upper Level Protocol Information; System Implicit/Default DOI. Regardless of the DOI selected, the marking of the outbound datagram must be consistent with the security policy monitor of the originating system. 2.3.8. End System - - - --- ------ An End System is a host or router from which a datagram originates or to which a datagram is ultimately delivered. 2.3.9. Intermediate System - - - ------------ ------ An Intermediate System is a router or host which receives and transmits a particular datagram without being either the source or destination of that datagram. N.B. Any given system can be both an end system and an intermedi- ate system -- which it is at any given time depends on the address of the datagram you are considering. Also, an intermediate system may handle ("forward") a datagram without necessarily importing or exporting the datagram to/from itself. 3. ARCHITECTURE - ------------ 3.1. General - - ------- This document describes a standard system for security marking a datagram within a particular security or classifi- cation system. The markings are designed for use within a "Mandatory Access Control" system. A real world example is the security classification system in use within the US Draft - Expires 15 Nov 92 -4- Network Working Group M. StJohns, DOD Government. Some data held by the government is "classi- fied", and is by law restricted to those people who have the appropriate "clearances". An IPSO security marking is the network instantiation of a particular information security policy and its related markings, classifications and com- partments. ---------------------------------------------------------- With respect to an internet, each distinct security marking represents a separate virtual internet which ------- shares the same physical internet. There are rules for -------- moving information between the various virtual inter- nets. The model we use within this document is based on the Bell-LaPadula model, but is extended to cover the concept of differing Domains of Interpretation. Please see Appendix A for a brief example of permitted information flows between and within DOIs. Those internet entities implementing this protocol must enforce this separation of data. ---------------------------------------------------------- The IPSO provides for both horizontal and vertical separation of data, as well as separation based on DOI. The basic rule is that data must not be delivered to a user or system that is not approved to receive it ("cleared", "cer- tified", "accredited"...). Within a particular DOI, information may only AUTOMATI- CALLY move from less sensitive to more sensitive virtual internets. I.e. information may only have its security marking iincreased (called "Upgrading"). Even this movement may be administratively restricted. Security policies may allow some limited downgrading, but this most usually requires the intervention of some human entity and is usu- ally done within a host with respect to the internal mark- ing, rather than on a network. Automatic downgrading is outside the scope of this protocol. Moving information between any two DOI's is permitted if and only if the owners of the DOI's: 1) Agree to the exchange, 2) Publish a table of equivalencies which maps the IPSO values of one DOI into the other. The DOI owners may choose to permit the exchange on or between any of their systems, or may restrict exchange to a small subset of the systems they own/accredit. N.B.: One way agreements are permissible as are agreements which are a subset of the full table of equivalences. Actual administration of inter-DOI agreements is outside the scope of this document. When data leaves an end system it is "exported" to the network, and marked with a particular DOI, security level and compartment set. This security marking is derived from Draft - Expires 15 Nov 92 -5- Network Working Group M. StJohns, DOD the internal marking (the host specific implementation of a security marking), and the export DOI. The export DOI is selected based on any of: the destination host, the desti- nation network, the current DOI for an upper level protocol (e.g. TCP), or the system default. See the rules under "USAGE - Export" later in this document. When data arrives at an end system, it is "imported" from the network to the host. The data from the datagram takes on an internal marking based on the security marking contained in the datagram. This assumes the datagram is marked with a recognizable DOI, there is a corresponding internal marking equivalent to the IPSO security marking, and the datagram is "within range" for the receiving logical interface. In transit, a datagram is handled based on its IPSO security marking and is usually neither imported to or exported from the various intermediate systems it transits. There is the concept of "IPSO Gateways" which import data from one DOI and export it to another. In other words, they provide on-the-fly remarking of datagrams at the boundaries between complete systems of hosts within a single DOI. 4. FORMAT - ------ 4.1. Body - - ---- ------------------------------------------------------------ | Type | Length | Level | DOI | +-------------------------------------------+--------------+ | DOI Continued | DOI Ext | ------------------------------------------------------------ | Tags... | ------------------------------------------------------------ 4.1.1. Type - - - ---- 1 Octet - Value is xxx (per IANA). This option must be copied on fragmentation. It appears at most once in a datagram. 4.1.2. Length - - - ------ 1 Octet - Variable. Minimum value is 4. Length of option in octets. 4.1.3. Sensitivity - - - ----------- 1 Octet - Variable. Bit field indicating relative sen- sitivity of the data contained in this datagram WITHIN the indicated DOI. Note there is no particular implied ordering of the values of this field with respect to the actual sen- sitivity. This field acts a pointer into the DOI's table of Draft - Expires 15 Nov 92 -6- Network Working Group M. StJohns, DOD values to determine actual sensitivity. I.e. a value of "00000010" (2) does not necessarily indicate higher sensi- tivity than a field value of "00000001" This is in some ways an artifact of the sensitivity level values in RFC1108. They are not ordered in any way (in 1108) which means this document may not require any ordering if it expects to main- tain backward compatibility. This value must be translated into an actual sensi- tivity level before any comparisons of relative sensitivity are done. Some DOI's may have "strictly increasing" Sensitivity Level values. If the DOI is known to have strictly ordered values, some short cuts MAY be made when comparing two sen- sitivity levels within a DOI; instead of mapping to an actual value and comparing those values as above, the sensi- tivity levels may be compared directly. N.B. The system must still ensure the sensitivity level(s) is/are valid for the DOI. 4.1.4. DOI & DOI Extension - - - --- --- --------- 4 + 1 Octets - Domain of Interpretation. This is a 5 octet field, 4 octets of which are assigned by the IANA and the fifth set by the owner of the DOI (DOI Extension). The DOI and DOI Extension taken together identifies the rules under which this datagram must be handled and protected. The owner of the DOI may use the DOI extension to indicate different communities of interest, differing compartment/category sets or perhaps an annual change of value meanings for the DOI. This effectively gives the DOI owner control of 256 different DOIs. Each unique 5 octet value represents a different DOI and all rules for informa- tion transfer between different DOI's apply. A DOI is nor- mally represented in dotted octet format (e.g. 128.5.6.12.4). Trailing zeros may be omitted and are under- stood (e.g.196.32.0.0.0 may be represented as 196.32 with no loss of information). There is also the concept of a "null" DOI. A datagram which is unmarked is considered to exist in the null Domain of Interpretation. The IPSO DOI value "0.0.0.0.0" is reserved to represent this DOI. The NULL DOI has no com- partments and has a single level whose value and IPSO representation are both zero. There is exactly one valid IPSO marking in the NULL DOI - the appropriate type and length fields followed by all zero octets. 4.1.5. Tags - - - ---- Variable number of "Tag" suboptions, each of a variable length - see next section. Draft - Expires 15 Nov 92 -7- Network Working Group M. StJohns, DOD 4.2. Tags - - ---- In addition to the DOI and sensitivity level carried in the body of this option, there is the provision to provide extra data or functionality in the form of "tags". The two defined tag suboptions are the compartment tag, and the checksum tag. Tag types 1 and 6 are defined below -- all other tag types are reserved at this time but may eventually be allo- cated. A datagram which contains an unrecognized tag (e.g. not type 1 or type 6 or one defined in a later version of this document) or which contains multiple instances of a particular tag type MUST be silently discarded. It SHOULD be logged. DISCUSSION: Under the general robustness principle, unrecognized tags should be accepted and ignored. However, this document describes an IP option which will be used as a basis for making access control decisions. Accepting and ignoring an unrecognized tag could result in delivery of a datagram to destinations not specifically approved to receive it. 4.2.1. Type 1 - Compartment (Bitmap) - - - ---- - ----------- ------ ------------------------------------------------------------------------ | Tag Type (1) | Tag Length (3-?)| Compartment Bitmap | +----------------------------------------------------------------------+ | Compartment Bitmap (cont) | ------------------------------------------------------------------------ | ooo | ------------------------------------------------------------------------ This tag consists of one octet of tag type (always 1), an octet indicating the tag length in octets (including the Tag Type and Tag length fields) and a number of octets representing compartments within the DOI. Each "1" bit within an octet in the "Compartment Bitmap" field represents a separate compartment under whose rules this data must be protected. 4.2.2. Type 6 - IPSO Checksum - - - ---- - ---- -------- ------------------------------------------------------------ |Tag Type (6) |Tag Length (4)| Checksum | ------------------------------------------------------------ This tag consists of one octet of tag type (always 6), an octet indicating the tag length in octets (always 4), and 2 octets treated as a 16 bit quantity which represents the checksum over the IP Source Address and this IP security option. The checksum algorithm is a 16 bit CRC with a Draft - Expires 15 Nov 92 -8- Network Working Group M. StJohns, DOD generating polynomial of .... For purposes of computing the checksum only, the checksum field is considered to be zero. 4.3. Optimized Format - - --------- ------ Because the basic option is variable length, with a variable number of sub-options, each also of variable lengths, and because routers and other intermediate systems work best processing fixed length, fixed location items this section describes three "optimized" formats -- all fixed length and fixed format. The first optimized format consists of the base option with NO attached tags. The DOI & DOI Extension fields are present and right zero filled if necessary. The option is 8 Octets in length. The second optimized format consists of the base option, one instance of tag type 1 where the tag is 12 octets in length (leaving 10 octets or 80 bits to represent compartments). The option is 20 Octets in length. The third and last optimized format consists of the base option, one instance of tag type 1 where the tag is 12 octets in length, and one instance of tag type 6 (the check- sum). The option is 24 octets in length. Any system which labels a datagram or modifies a label on a datagram SHOULD use one of the optimized formats upon output. All systems MUST be able to accept and process IPSOs which differ in length and tag ordering from the above. 4.4. Canonical Format - - --------- ------ If one of the above optimized formats is not usable (due to header space considerations, etc.) the canonical format SHOULD be used. The canonical format is simply the option with trailing octets of zero removed and the length field(s) adjusted appropriately. 5. USAGE - ----- 5.1. Security Marking Comparisons - - -------- ------- ----------- 5.1.1. "Within Range" - - - ------ ----- A marking, "M" is "within range" for a particular range "A:B:IGNOR" if and only if: 1. The range is a valid range, and the DOI for the marking matches the DOI for both the low and high end of the range and, (M.DOI = A.DOI = B.DOI) Draft - Expires 15 Nov 92 -9- Network Working Group M. StJohns, DOD 2. The marking has a security level which is greater than or equal to the security level contained in the low end marking from the range and which is less than or equal to the security level contained in the high end marking from the range and, (A.LEV <= M.LEV <= B.LEV) 3. The marking has a compartment set which is a superset (proper or otherwise) of the compartment set contained in the low end marking from the range and which is a subset (proper or otherwise) of the compartment set contained in the high end marking from the range. ((A.COMP & ^IGNOR) <= (M.COMP & ^IGNOR) <= (B.COMP & ^IGNOR)) 5.1.2. "Less Than" or "Below Range" - - - ---- ---- -- ----- ----- A marking, "M" is "less than" a marking "A" while con- sidering a set of ignorable compartments IGNOR if and only if: 1. Their DOI's are identical (M.DOI = A.DOI), and 2. M's level is less than A's level while M's com- partment set is a subset (proper or otherwise) of A's compartment set (M.LEV < A.LEV & (M.COMP & ^IGNOR) <= (A.COMP & ^IGNOR)), or 3. M's level is less than or equal to A's level while M's compartment set is a proper subset of A's com- partment set (M.LEV <= A.LEV & (M.COMP & ^IGNOR) < (A.COMP & ^IGNOR)). A marking, "M" is "below range" for a marking "A:B:IGNOR" if M is less than A. 5.1.3. "Greater Than" or "Above Range" - - - ------- ---- -- ----- ----- A marking, "M" is "greater than" a marking "B" while considering a set of ignorable compartments IGNOR if and only if: 1. Their DOI's are identical (M.DOI = B.DOI), and 2. M's level is greater than B's level while M's com- partment set is a superset (proper or otherwise) of B's compartment set (M.LEV > B.LEV & (M.COMP & ^IGNOR) >= (A.COMP & ^IGNOR)), or 3. M's level is geater than or equal to A's level while M's compartment set is a proper superset of A's compartment set (M.LEV >= B.LEV & (M.COMP & ^IGNOR) > (B.COMP & ^IGNOR)). Draft - Expires 15 Nov 92 -10- Network Working Group M. StJohns, DOD A marking, "M" is "above range" for a marking "A:B:IGNOR" if M is greater than B. 5.1.4. "Equal To" - - - ----- -- A marking "A" is "equal to" another marking "B" while considering a set of ignorable compartments IGNOR if and only if: They have the exact same DOI, they have identical secu- rity levels and their compartment sets are identical (A.DOI = B.DOI & A.LEV = B.LEV & (A.COMP & ^IGNOR) = (B.COMP & IGNOR)). 5.1.5. "Disjoint" - - - -------- A marking "A"is disjoint from another marking "B" while considering a set of ignorable compartments IGNOR either if: 1. Their DOI's differ (A.DOI <> B.DOI) or, 2. They are neither less than, nor greater than nor equal to each other (^((A < B) | (A > B) | (A = B))) or, 3. Their compartment sets are disjoint from each other (^(((A.COMP & ^IGNOR) <= (B.COMP & ^IGNOR)) | ((A.COMP & ^IGNOR) => (B.COMP & ^IGNOR)))). 5.2. Export - - ------ An end system which sends data to the network is said to "export" it to the network. Before a datagram can leave an end system and be transmitted over a network the follow- ing must occur: 1. Selection of the export DOI: a) If the system implements or permits only one DOI, that DOI is the export DOI. b) elseIf the Upper Level Protocol selects a DOI, that DOI is the one used. Note that a TCP connection must have the same DOI and marking for the life of the connection - the DOI is selected at con- nection initiation and may not change. c) elseIf there are tables defining a specific default DOI for the specific destination host address or for the network address, then that DOI is selected. d) elseIf there is a specific DOI associated with the sending logical interface (i.e. IP address), ------- Draft - Expires 15 Nov 92 -11- Network Working Group M. StJohns, DOD then that DOI is selected. e) Else the default DOI for the system is selected. 2. Export Marking: Once the DOI is selected, the IPSO marking and values are determined based on the internal marking and the DOI. In the event the internal marking does not map to a valid IPSO marking, an error should be returned to the upper level protocol and MAY be logged. No further attempt to send this datagram should be made. 3. Access Control: Once the datagram is marked and the sending logi- cal interface is selected (by the routing code), the marking of the datagram is compared against the range(s) associated with that logical interface. For the datagram to be sent, the interface must list the DOI of the datagram marking as one of the permissible DOI's and the datagram marking must be within range for the range associated with that DOI. If the datagram fails this access test an error should be returned to the upper level protocol and MAY be logged. No further attempt to send this datagram should be made. 5.3. Import - - ------ When a datagram arrives at an interface on an end sys- tem, the ES MUST: 1. Verify the IPSO checksum if it occurs within the option. Datagrams with invalid checksums MUST be silently dropped. They MAY be logged. 2. Verify the IPSO has a known and valid DOI. Datagrams with unrecognized or illegal DOIs MUST be silently dropped. They SHOULD be logged. 3. Verify the DOI is a permitted one for the receiv- ing interface. Datagrams with prohibited DOIs MUST be silently dropped. They SHOULD be logged. 4. Verify the marking within the IPSO is within the permitted range for the receiving interface. N.B. EACH permitted DOI on an interface has a separate table describing the permitted range for that DOI: A datagram which has a marking within the permit- ted range is accepted for further processing. A datagram which has a marking disjoint with the Draft - Expires 15 Nov 92 -12- Network Working Group M. StJohns, DOD permitted range MUST be silently discarded. It SHOULD be logged. A datagram which has a marking below the permitted range MAY (configuration + implementation depen- dent) be accepted for further processing. The datagram is silently upgraded and imported as if it had been marked with the minimum of the accept- able range. An indication this datagram was upgraded on acceptance MUST be given to the upper level protocol and the indication SHOULD reflect the original marking of the datagram. The choice of whether or not to permit an upgrade if imple- mented, MUST be configurable and MUST default to OFF. A datagram with a marking above the permitted range MUST be discarded. It SHOULD be logged. It MAY (configuration + implementation dependent) result in an appropriate ICMP error message sent at the maximum permitted marking for the interface for that DOI. The choice of whether or not to send an ICMP message, if implemented, MUST be con- figurable, and SHOULD default to OFF. Standard conditions about generating ICMP error messages (i.e. no error message about an error message) apply. 5. Once the datagram has been accepted, the import marking and DOI are used to associate the appropriate internal marking with the data con- tained in the datagram. This information MUST be carried as part of the information returned to the upper level protocol. 5.4. Intermediate System Rules - - ------------ ------ ----- 5.4.1. Input - - - ----- Intermediate Systems (ISs) have slightly different rules for processing marked datagrams than do end systems. Primarily, ISs do not IMPORT or EXPORT transit datagrams, they just switch them. The following checks should generally occur AFTER the IP Header checksum is verified, but before any other pro- cessing. Upon reception an IS must: 1. Determine whether or not this datagram is destined for (addressed to) this IS. If so, the IS becomes an ES for the purposes of receiving this datagram and the rules for IMPORTing described above are followed. Draft - Expires 15 Nov 92 -13- Network Working Group M. StJohns, DOD 2. Verify the IPSO checksum if it occurs within the option. Datagrams with invalid checksums MUST be silently dropped. They MAY be logged. 3. Verify the IPSO has a known and valid DOI. Datagrams with unrecognized or illegal DOIs MUST be silently dropped. They SHOULD be logged. 4. Verify the DOI is a permitted one for the receiv- ing interface. Datagrams with prohibited DOIs MUST be silently dropped. They SHOULD be logged. 5. Verify the marking within the IPSO is within the permitted range for the receiving interface. N.B. EACH permitted DOI on an interface has a separate table describing the permitted range for that DOI: A rejected datagram which has a marking below or disjoint with the permitted range MUST be silently discarded. It SHOULD be logged. A rejected datagram with a marking above the per- mitted range MUST be discarded. It SHOULD be logged. It MAY (configuration + implementation dependent) result in an appropriate ICMP error message sent at the maximum permitted marking for the interface for that DOI. The choice of whether or not to send an ICMP message, if implemented, MUST be configurable, and SHOULD default to OFF. Standard conditions about generating ICMP error messages (i.e. no error message about an error message) apply. If and only if all the above conditions are met is the datagram accepted for further processing and forwarding. At this point, the datagram is within the permitted range for the IS, and appropriate ICMP error messages may be generated by the IP module back to the originating host regarding the forwarding of the datagram. These ICMP mes- sages MUST be sent with the exact same marking as the datagram causing the error. Note that these generated mes- sages must go through the same outbound checks as a for- warded datagram as described in the following paragraphs. 5.4.2. Translation - - - ----------- It is at this point that TRANSLATION of the IPSO takes place if at all. Please see the following section for a discussion of the appropriate processing. 5.4.3. Output - - - ------ Once the forwarding code has selected the interface Draft - Expires 15 Nov 92 -14- Network Working Group M. StJohns, DOD through which the datagram will be transmitted the following takes place: Verify the DOI is a permitted one for the sending interface and that the datagram is within the permitted range for the DOI and interface . Datagrams with prohibited DOIs or out of range MUST be dropped. They SHOULD be logged. They MAY (configuration + implemen- tation dependent) result in an appropriate ICMP error message sent with the same marking as the rejected datagram The choice of whether or not to send an ICMP message, if implemented, MUST be configurable, and SHOULD default to OFF. Standard conditions about gen- erating ICMP error messages (i.e. no error message about an error message) apply. 5.5. Translation - - ----------- A system which provides on-the-fly remarking is said to "translate" from one DOI to another. There are basically two ways a datagram can be remarked; either the marking can be converted from an external (IPSO) marking, to an internal marking and then back to a new external marking, or an external marking can be directly remapped into another external marking. The first of these methods is the func- tional equivalent of "importing" the datagram then "export- ing" it and is covered in detail in the "Import" and "Export" sections above. This section describes direct remarking. The choice of which method to use for remarking is an implementation decision outside the scope of this document. A system which provides on-the-fly remarking without importing or exporting is basically a special case of the Intermediate System rules listed above. Translation or remarking takes place AFTER all input checks take place, but before any output checks are done. Once a datagram has been accepted (passing all the appropriate checks described in section 5.4), it may be remarked. To determine the new marking, first determine the new DOI. The selection of the new DOI may be based on any of DESTINATION HOST, DESTINATION NETWORK, DESTINATION SUB- NET, SENDING INTERFACE, or RECEIVING INTERFACE or combina- tions thereof. Exact details on how the output DOI is selected is implementation dependent with the caveat that it should be consistent and reversible. I.e. If a datagram from host A to host B with DOI X maps into DOI Y, then a datagram from B to A with DOI Y should map into DOI X. Once the output DOI is selected, the output marking is determined based on the input marking and DOI and the output DOI. In the event the input marking does not map to a valid output marking for that DOI, the datagram SHOULD be silently Draft - Expires 15 Nov 92 -15- Network Working Group M. StJohns, DOD dropped, it MAY be logged. Once the datagram is remarked, the output procedures under section 5.4 "Intermediate Systems" are followed with the exception that any error that would cause a ICMP error message to be generated back to the originating host instead MUST drop the datagram, it MAY be logged. Note that it is possible to map to and from the NULL DOI. This is equivalent to adding or deleting a IPSO. 6. IMPLEMENTATION ISSUES AND HINTS - -------------- ------ --- ----- The following are "hints" not "requirements". Imple- mentation experience may eventually turn all or some of them into implementation requirements. 6.1. Intermediate Systems - - ------------ ------- 6.2. End Systems - - --- ------- 6.3. Upper-Level Protocols - - ----- ----- --------- 6.3.1. TCP - - - --- With respect to an internet, each discinct secu- rity marking represents a separate virtual inter- net which shares the same physical internet. The above statement taken from section 3.1 has a non- obvious but critical corollary. If there are separate vir- tual internets then it is possible for a system which exists in multiple virtual internets to have identical TCP connec- tions, each one existing in a different virtual internet. TCP connections are normally identified by source and destination port, and source and destination address. If a system marks datagrams (which it must do if it exists in multiple virtual internets - e.g. a "multi-level secure" system), then TCP connections are identified by source and destination port, source and destination address and IPSO Security Marking. 6.3.2. UDP - - - --- Datagrams addressed to a UDP port should be delivered to all listeners whose equivalent security marking is greater than or equal to the security marking of the UDP datagram. APPENDIX A - A SAMPLE MARKING SYSTEM -------- - - ------ ------- ------ Information Flow Rules - Intra DOI Example Draft - Expires 15 Nov 92 -16- Network Working Group M. StJohns, DOD Information Flow Rules - Inter DOI Example APPENDIX B - RFC1108/1038 COMPATIBILITY ISSUES -------- - ------- ---- ------------- ------ Mapping of Protection Authorities to DOIs ------- -- ---------- ----------- -- ---- Receiving --------- Sending ------- APPENDIX C - A SAMPLE DOI DEFINITION - US DEPT OF DEFENSE -------- - - ------ --- ---------- -- ---- -- ------- The following is the DOI equivalent of the information presented in RFC1108. This section defines 4 primary DOIs and x secondary DOI's. All of these DOIs use the same IPSO markings and relative values to indicate sensitivity/security levels. There is an implicit equivalence between all of these DOIs; e.g. US DOD GENSER Top Secret is equivalent to US SCI Top Secret and to US DOD NSA SCI Top Secret, etc. They MAY in some cases have some equivalences within their compart- ments but neither the compartments nor equivalences are listed here at this time. Notwithstanding any of these equivalances, the ability of a system to accept and process information in differing DOI's is a matter of configuration and policy. E.g. a sys- tem accredited as US DOD GENSER may accept and process datagrams from US DOD NSA only after specific permission is given and the appropriate configuration changes have been made. ------------------------------------------ Name DOI ID ------------------------------------------ US DOD GENSER 128.0.0.0.0 ------------------------------------------ US DOD SIOP ESI 64.0.0.0.0 ------------------------------------------ US DOD SCI 32.0.0.0.0 ------------------------------------------ US DOD NSA 16.0.0.0.0 ------------------------------------------ US DOD GENSER SIOP 192.0.0.0.0 ------------------------------------------ US DOD GENSER SCI 160.0.0.0.0 ------------------------------------------ US DOD GENSER NSA 144.0.0.0.0 ------------------------------------------ US DOD GENSER SIOP SCI 224.0.0.0.0 ------------------------------------------ US DOD GENSER SIOP NSA 208.0.0.0.0 ------------------------------------------ US DOD GENSER SIOP NSA SCI 240.0.0.0.0 ------------------------------------------ US DOD SIOP SCI 96.0.0.0.0 ------------------------------------------ US DOD SIOP NSA 80.0.0.0.0 ------------------------------------------ Draft - Expires 15 Nov 92 -17- Network Working Group M. StJohns, DOD | US DOD SIOP NSA SCI | 112.0.0.0.0| |---------------------------+-------------+ | US DOD SCI NSA | 48.0.0.0.0| ------------------------------------------ DOI Levels ------------------------------------------------------------ | Name | Relative Value | IPSO Marking | +-----------------+---------------------+------------------+ | Reserved (4) | 7 | "00000001"B | ------------------------------------------------------------ | Top Secret | 6 | "00111101"B | +-----------------+---------------------+------------------+ | Secret | 5 | "01011010"B | ------------------------------------------------------------ | Confidential | 4 | "10010110"B | +-----------------+---------------------+------------------+ | Reserved (3) | 3 | "01100110"B | ------------------------------------------------------------ | Reserved (2) | 2 | "11001100"B | +-----------------+---------------------+------------------+ | Unclassified | 1 | "10110111"B | ------------------------------------------------------------ | Reserved (1) | 0 | "11110001"B | ------------------------------------------------------------ APPENDIX D - CONFIGURATION PARAMETERS Host Wide DOI Table(s) DOI Name: STRING (32) ->"HotStuff-INC" DOI Value: OCTET (5) -> 161.3.99.23.1 DOI Levels: ----------------------------------------------------------------- |Name| Relative Value (0-255)| IPSO Marking| Internal Marking| +----+------------------------+--------------+------------------+ ----------------------------------------------------------------- |Cold| 2 | "01001010"B | ?? | +----+------------------------+--------------+------------------+ |Hot | 89 | "00100101"B | ?? | ----------------------------------------------------------------- |Warm| 4 | "00010010"B | ?? | ----------------------------------------------------------------- DOI Compartments Draft - Expires 15 Nov 92 -18- Network Working Group M. StJohns, DOD ------------------------------------------------------------ | Name | IPSO Bit | Ignorable? | Internal | +-------------+-------------+----------------+-------------+ | | Number | | Marking | ------------------------------------------------------------ | | | | | +-------------+-------------+----------------+-------------+ | Personnel | 0 | N | ?? | ------------------------------------------------------------ | R&D | 1 | N | ?? | +-------------+-------------+----------------+-------------+ | Rel-IBM | 2 | Y | ?? | ------------------------------------------------------------ Default DOI - "HotStuff-INC" Per (Logical) Interface Permitted DOI(s) Level Min Level Max Compartment Set Min Compartment Set Max Compartment Set Ignore Interface Default DOI (if any) Host: TABLE OF { DoiTable: TABLE OF { DoiName: STRING (32) DoiValue: OCTET-STRING (5) DoiLevels: TABLE OF { DoiLevelName: STRING(32) DoiLevelMarking: OCTET-STRING(1) DoiLevelRelValue: INTEGER (0..255) DoiLevelInternal: OCTET-STRING } DoiComps: TABLE OF { DoiCompName: STRING(32) DoiCompBit: INTEGER DoiCompIgnoreable: BIT (1) DoiCompInternal: OCTET-STRING } } DoiHostDefault: DoiID OCTET-STRING (5) } Interface: TABLE OF { IpsoIfDoiTable: TABLE OF { IpsoIfDoi: DoiID IpsoIfDoiMinLevel: INTEGER (0..255) Draft - Expires 15 Nov 92 -19- Network Working Group M. StJohns, DOD IpsoIfDoiMaxLevel: INTEGER (0..255) IpsoIfDoiMinComp: TABLE OF INTEGER IpsoIfDOIMaxComp: TABLE OF INTEGER IpsoIfDoiIgnorComp: TABLE OF INTEGER } IpsoIfDoiDefault: DoiID } Draft - Expires 15 Nov 92 -20-