[要約] RFC 5570は、IPv6セキュリティオプションであるCALIPSOの共通アーキテクチャラベルに関するものです。その目的は、IPv6パケットにセキュリティラベルを追加することで、セキュリティポリシーの適用と情報フローの制御を可能にすることです。
Network Working Group M. StJohns
Request for Comments: 5570 Consultant
Category: Informational R. Atkinson
Extreme Networks
G. Thomas
US Department of Defense
July 2009
Common Architecture Label IPv6 Security Option (CALIPSO)
一般的なアーキテクチャラベルIPv6セキュリティオプション（Calipso）
Abstract
概要
This document describes an optional method for encoding explicit packet Sensitivity Labels on IPv6 packets. It is intended for use only within Multi-Level Secure (MLS) networking environments that are both trusted and trustworthy.
このドキュメントでは、IPv6パケット上の明示的なパケット感度ラベルをエンコードするためのオプションの方法について説明します。これは、信頼され、信頼できるマルチレベルSecure（MLS）ネットワーク環境内でのみ使用することを目的としています。
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
IESG Note
IESGノート
This RFC specifies the use of an IPv6 hop-by-hop option. The IESG notes that general deployment of protocols with hop-by-hop options are problematic, and the development of such protocols is consequently discouraged. After careful review, the IETF has determined that a hop-by-hop option is an appropriate solution for this specific limited environment and use case. Furthermore, the mechanism specified in this RFC is only applicable to closed IP networks. It is unsuitable for use and ineffective on the global public Internet.
このRFCは、IPv6ホップバイホップオプションの使用を指定します。IESGは、ホップバイホップオプションを使用したプロトコルの一般的な展開に問題があり、その結果、そのようなプロトコルの開発は落胆していることを指摘しています。慎重なレビューの後、IETFは、ホップバイホップオプションがこの特定の限定環境とユースケースに適したソリューションであると判断しました。さらに、このRFCで指定されたメカニズムは、閉じたIPネットワークにのみ適用できます。使用するのに適しておらず、グローバルなパブリックインターネットでは効果がありません。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Table of Contents
目次
1. Introduction ....................................................4
1.1. History ....................................................4
1.2. Intent and Applicability ...................................6
1.3. Deployment Examples ........................................7
2. Definitions .....................................................9
2.1. Domain of Interpretation ...................................9
2.2. Sensitivity Level .........................................10
2.3. Compartment ...............................................10
2.4. Releasability .............................................11
2.5. Sensitivity Label .........................................16
2.6. Import ....................................................17
2.7. Export ....................................................17
2.8. End System ................................................18
2.9. Intermediate System .......................................18
2.10. System Security Policy ...................................19
3. Architecture ...................................................19
4. Defaults .......................................................24
5. Format .........................................................26
5.1. Option Format .............................................27
5.2. Packet Word Alignment Considerations ......................30
6. Usage ..........................................................31
6.1. Sensitivity Label Comparisons .............................31
6.2. End System Processing .....................................34
6.3. Intermediate System Processing ............................37
6.4. Translation ...............................................40
7. Architectural and Implementation Considerations ................41
7.1. Intermediate Systems ......................................42
7.2. End Systems ...............................................43
7.3. Upper-Layer Protocols .....................................43
8. Security Considerations ........................................46
9. IANA Considerations ............................................48
9.1. IP Option Number ..........................................48
9.2. CALIPSO DOI Values Registry ...............................49
10. Acknowledgments ...............................................50
11. References ....................................................50
11.1. Normative References .....................................50
11.2. Informative References ...................................50
The original IPv4 specification in RFC 791 includes an option for labeling the sensitivity of IP packets. That option was revised by RFC 1038 and later by RFC 1108 [RFC791] [RFC1038] [RFC1108]. Although the IETF later deprecated RFC 1108, that IPv4 option continues to be in active use within a number of closed Multi-Level Secure (MLS) IP networks.
RFC 791の元のIPv4仕様には、IPパケットの感度にラベルを付けるオプションが含まれています。そのオプションは、RFC 1038によって改訂され、後にRFC 1108 [RFC791] [RFC1038] [RFC1108]によって修正されました。IETFは後にRFC 1108を廃止しましたが、そのIPv4オプションは、多くの閉じたマルチレベルのセキュア（MLS）IPネットワークで積極的に使用され続けています。
One or another IP Sensitivity Label option has been in limited deployment for about two decades, most usually in governmental or military internal networks. There are also some commercial sector deployments, where corporate security policies require Mandatory Access Controls be applied to sensitive data. Some banks use MLS technology to restrict sensitive information, for example information about mergers and acquisitions. This IPv6 option, like its IPv4 predecessors, is only intended for deployment within private internetworks, disconnected from the global Internet. This document specifies the explicit packet labeling extensions for IPv6 packets.
1つまたは別のIP感度ラベルオプションは、約20年間、展開が限られており、ほとんどは通常、政府または軍事の内部ネットワークです。また、企業のセキュリティポリシーでは、機密データに必須のアクセス制御を適用する必要がある商業部門の展開もあります。一部の銀行は、MLSテクノロジーを使用して、合併や買収に関する情報など、機密情報を制限しています。このIPv6オプションは、IPv4の前身と同様に、グローバルインターネットから切断されたプライベートインターネットワーク内での展開のみを目的としています。このドキュメントは、IPv6パケットの明示的なパケットラベル拡張機能を指定します。
This document is a direct descendent of RFC 1038 and RFC 1108 and is a close cousin to the work done in the Commercial IP Security Option (CIPSO) Working Group of the Trusted Systems Interoperability Group (TSIG) [FIPS-188]. The IP Security Option defined by RFC 1038 was designed with one specific purpose in mind: to support the fielding of an IPv4 packet-encryption device called a BLACKER [RFC1038]. Because of this, the definitions and assumptions in those documents were necessarily focused on the US Department of Defense and the BLACKER device. Today, IP packet Sensitivity Labeling is most commonly deployed within Multi-Level Secure (MLS) environments, often composed of Compartmented Mode Workstations (CMWs) connected via a Local Area Network (LAN). So the mechanism defined here is accordingly more general than either RFC 1038 or RFC 1108 were.
このドキュメントは、RFC 1038およびRFC 1108の直接の子孫であり、信頼できるシステム相互運用性グループ（TSIG）[FIPS-188]の商用IPセキュリティオプション（CIPSO）ワーキンググループで行われた作業の緊密ないとこです。RFC 1038で定義されたIPセキュリティオプションは、1つの特定の目的を念頭に置いて設計されています。Blacker[RFC1038]と呼ばれるIPv4パケット暗号化デバイスのフィールドをサポートするためです。このため、これらの文書の定義と仮定は、必然的に米国国防総省とBlackerデバイスに焦点を当てていました。今日、IPパケット感度ラベリングは、ローカルエリアネットワーク（LAN）を介して接続されたコンパートメントモードワークステーション（CMW）で構成されるマルチレベルセキュア（MLS）環境内で最も一般的に展開されています。したがって、ここで定義されているメカニズムは、RFC 1038またはRFC 1108よりも一般的です。
Also, the deployment of Compartmented Mode Workstations ran into operational constraints caused by the limited, and relatively small, space available for IPv4 options. This caused one non-IETF specification for IPv4 packet labeling to have a large number of sub-options. A very unfortunate side effect of having sub-options within an IPv4 label option was that it became much more challenging to implement Intermediate System support for Mandatory Access Controls (e.g., in a router or MLS guard system) and still be able to forward traffic at, or near, wire-speed.
また、コンパートメントモードのワークステーションの展開は、IPv4オプションで利用可能な限られた、比較的小さいスペースによって引き起こされる運用上の制約に遭遇しました。これにより、IPv4パケットラベル付けが多数のサブオプションを持つための1つの非EITF仕様が発生しました。IPv4ラベルオプションにサブオプションを持つことの非常に不幸な副作用は、必須のアクセス制御（例：ルーターまたはMLSガードシステム）に中間システムサポートを実装することがはるかに難しくなり、それでもトラフィックを転送できることでした。、または近く、ワイヤスピード。
In the last decade or so, typical Ethernet link speeds have changed from 10 Mbps half-duplex to 1 Gbps full-duplex. The 10 Gbps full-duplex Ethernet standard is widely available today in routers, Ethernet switches, and even in some servers. The IEEE is actively developing standards for both 40 Gbps Ethernet and 100 Gbps Ethernet as of this writing. Forwarding at those speeds typically requires support from Application-Specific Integrated Circuits (ASICs); supporting more complex packet formats usually requires significantly more gates than supporting simpler packet formats. So the pressure to have a single simple option format has only increased in the past decade, and is only going to increase in the future.
過去10年ほどで、典型的なイーサネットリンク速度は10 Mbpsの半分二重から1 Gbpsフルダップレックスに変化しました。10 Gbpsフルダプレックスイーサネット標準は、今日、ルーター、イーサネットスイッチ、さらには一部のサーバーでも広く利用できます。IEEEは、この執筆時点で40 Gbpsイーサネットと100 Gbpsイーサネットの両方の標準を積極的に開発しています。これらの速度での転送には、通常、アプリケーション固有の統合回路（ASIC）からのサポートが必要です。より複雑なパケット形式をサポートするには、通常、よりシンプルなパケット形式をサポートするよりも大幅に多くのゲートが必要です。したがって、単一の簡単なオプション形式を持つというプレッシャーは、過去10年間で増加しており、将来的には増加するだけです。
When IPv6 was initially being developed, it was anticipated that the availability of IP Security, in particular the Encapsulating Security Payload (ESP) and the IP Authentication Header (AH), would obviate the need for explicit packet Sensitivity Labels with IPv6 [RFC1825] [RFC4301] [RFC4302] [RFC4303]. For MLS IPv6 deployments where the use of AH or ESP is practical, the use of AH and/or ESP is recommended.
IPv6が最初に開発されたとき、IPセキュリティの可用性、特にカプセル化セキュリティペイロード（ESP）とIP認証ヘッダー（AH）は、IPv6 [RFC1825]を使用した明示的なパケット感度ラベルの必要性を排除すると予想されていました[RFC1825] [RFC1825] [RFC4301] [RFC4302] [RFC4303]。AHまたはESPの使用が実用的であるMLS IPv6の展開の場合、AHおよび/またはESPの使用が推奨されます。
However, some applications (e.g., distributed file systems), most often those not designed for use with Compartmented Mode Workstations or other Multi-Level Secure (MLS) computers, multiplex different transactions at different Sensitivity Levels and/or with different privileges over a single IP communications session (e.g., with the User Datagram Protocol). In order to maintain data Sensitivity Labeling for such applications, to be able to implement routing and Mandatory Access Control decisions in routers and guards on a per-IP-packet basis, and for other reasons, there is a need to have a mechanism for explicitly labeling the sensitivity information for each IPv6 packet.
ただし、一部のアプリケーション（分散ファイルシステムなど）、ほとんどの場合、コンパートメントモードのワークステーションまたはその他のマルチレベルのセキュア（MLS）コンピューターで使用するように設計されていないもの、異なる感度レベルでの多重化されたトランザクション、および/または単一の特権を超えて異なる特権を使用しますIP通信セッション（ユーザーデータグラムプロトコルなど）。このようなアプリケーションのデータ感度ラベル付けを維持するために、IPパケットごとにルーターとガードにルーティングと必須のアクセス制御決定を実装できるようにします。各IPv6パケットの感度情報のラベル付け。
Existing Layer 3 Virtual Private Network (VPN) technology can't solve the set of issues addressed by this specification, for several independent reasons. First, in a typical deployment, many labeled packets will flow from an MLS End System through some set of networks to a receiving MLS End System. The received per-packet label is used by the receiving MLS End System to determine which Sensitivity Label to associate with the user data carried in the packet. Existing Layer 3 VPN specifications do not specify any mechanism to carry a Sensitivity Label. Second, existing Layer 3 VPN technologies are not implemented in any MLS End Systems, nor in typical single-level End System operating systems, but instead typically are only implemented in routers. Adding a Layer 3 VPN implementation to the networking stack of an MLS End System would be a great deal more work than adding this IPv6 option to that same MLS End System. Third, existing Layer 3 VPN specifications do not support the use of Sensitivity Labels to select a VPN to use in carrying a packet, which function is essential if one wanted to obviate this IPv6 option. Substantial new standards development, along with significant new implementation work in End Systems, would be required before a Layer 3 VPN approach to these issues could be used. Developing such specifications, and then implementing them in MLS systems, would need substantially greater effort than simply implementing this IPv6 label option in an MLS End System (or in a label-aware router). Further, both the MLS user community and the MLS implementer community prefer the approach defined in this specification.
既存のレイヤー3仮想プライベートネットワーク（VPN）テクノロジーは、いくつかの独立した理由で、この仕様で対処された一連の問題を解決することはできません。第一に、典型的な展開では、多くのラベル付きパケットは、いくつかのネットワークセットを介してMLSエンドシステムから受信MLSエンドシステムに流れます。受信したパケットごとのラベルは、受信MLSエンドシステムで使用され、パケットに掲載されたユーザーデータに関連する感度ラベルを決定します。既存のレイヤー3 VPN仕様では、感度ラベルを運ぶメカニズムを指定しません。第二に、既存のレイヤー3 VPNテクノロジーは、MLSエンドシステムではなく、典型的なシングルレベルエンドシステムオペレーティングシステムではなく、通常はルーターにのみ実装されます。MLSエンドシステムのネットワークスタックにレイヤー3 VPN実装を追加することは、この同じMLSエンドシステムにこのIPv6オプションを追加するよりも多くの作業になるでしょう。第三に、既存のレイヤー3 VPN仕様は、このIPv6オプションを削除する場合に不可欠なパケットを運ぶ際に使用するVPNを選択するための感度ラベルの使用をサポートしていません。実質的な新しい標準開発は、これらの問題に対するレイヤー3 VPNアプローチを使用する前に、エンドシステムでの重要な新しい実装作業とともに必要です。このような仕様を開発し、MLSシステムに実装するには、MLSエンドシステム（またはラベル認識ルーター）にこのIPv6ラベルオプションを単に実装するよりも、実質的に大きな努力が必要です。さらに、MLSユーザーコミュニティとMLS実装コミュニティの両方が、この仕様で定義されているアプローチを好みます。
Nothing in this document applies to any system that does not claim to implement this document.
このドキュメントには、このドキュメントの実装を主張していないシステムには何も適用されません。
This document describes a generic way of labeling IPv6 datagrams to reflect their particular sensitivity. Provision is made for separating data based on domain of interpretation (e.g., an agency, a country, an alliance, or a coalition), the relative sensitivity (i.e., Sensitivity Levels), and need-to-know or formal access programs (i.e., compartments or categories).
このドキュメントでは、特定の感度を反映するためにIPv6データグラムにラベルを付ける一般的な方法について説明します。解釈の領域（たとえば、機関、国、同盟、または連合）、相対的な感度（つまり、感度レベル）、および知識が必要または正式なアクセスプログラム（すなわち、。、コンパートメントまたはカテゴリ）。
A commonly used method of encoding Releasabilities as if they were Compartments is also described. This usage does not have precisely the same semantics as some formal Releasability policies, but existing Multi-Level Secure operating systems do not contain operating system support for Releasabilities as a separate concept from compartments. The semantics for this sort of Releasability encoding is close to the formal policies and has been deployed by a number of different organizations for at least a decade now.
それらがコンパートメントであるかのようにリリース性をエンコードする一般的に使用される方法についても説明します。この使用法は、いくつかの正式な解放可能性ポリシーとまったく同じセマンティクスを持っていませんが、既存のマルチレベルの安全なオペレーティングシステムには、コンパートメントとは別の概念としてのリリース性のオペレーティングシステムサポートが含まれていません。この種のリリース性エンコーディングのセマンティクスは、正式なポリシーに近く、少なくとも10年間、多くの異なる組織によって展開されています。
In particular, the authors believe that this mechanism is suitable for deployment in United Nations (UN) peace-keeping operations, in North Atlantic Treaty Organisation (NATO) or other coalition operations, in all current US Government MLS environments, and for deployment in other similar commercial or governmental environments. This option would not normally ever be visible in an IP packet on the global public Internet.
特に、著者は、このメカニズムは、国連（国連）平和維持事業、北大西洋条約機関（NATO）またはその他の連合作戦、現在のすべての米国政府MLS環境、およびその他の展開に適していると考えています。同様の商業または政府の環境。このオプションは、通常、グローバルパブリックインターネット上のIPパケットでは表示されません。
Because of the unusually severe adverse consequences (e.g., loss of life, loss of very large sums of money) likely if a packet labeled with this IPv6 Option were to escape onto the global public Internet, organizations deploying this mechanism have unusually strong incentives to configure security controls to prevent labeled packets from ever appearing on the global public Internet. Indeed, a primary purpose of this mechanism is to enable deployment of Mandatory Access Controls for IPv6 packets.
このIPv6オプションでラベル付けされたパケットがグローバルなパブリックインターネットに逃げた場合、非常に深刻な悪影響（例えば、生命の喪失、非常に多額のお金の損失）のために、このメカニズムを展開する組織は異常に強いインセンティブを構成するための異常に強いインセンティブを持っていますラベル付きパケットがグローバルパブリックインターネットに表示されないようにするためのセキュリティ制御。実際、このメカニズムの主な目的は、IPv6パケットの必須アクセス制御の展開を可能にすることです。
However, to ensure interoperability of both End Systems and Intermediate Systems within such a labeled deployment of IPv6, it is essential to have an open specification for this option.
ただし、IPv6のラベル付き展開内のエンドシステムと中間システムの両方の相互運用性を確保するには、このオプションのオープン仕様を持つことが不可欠です。
This option is NOT designed to be an all-purpose label option and specifically does not include support for generic Domain Type Enforcement (DTE) mechanisms. If such a DTE label option is desired, it ought to be separately specified and have its own (i.e., different) IPv6 option number.
このオプションは、汎用ラベルオプションになるようには設計されておらず、具体的には一般的なドメインタイプエンダンス（DTE）メカニズムのサポートは含まれていません。このようなDTEラベルオプションが必要な場合は、個別に指定され、独自の（つまり、異なる）IPv6オプション番号を持つ必要があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
Two deployment scenarios for IP packet Sensitivity Labels are most common. We should first note that in typical deployments, all people having access to an unencrypted link are cleared for all unencrypted information traversing that link. Also, MLS system administrators normally have previously been cleared to see all of the information processed or stored by that MLS system. This specification does not seek to eliminate all potential covert channels relating to this IPv6 option.
IPパケット感度ラベルの2つの展開シナリオが最も一般的です。まず、典型的な展開では、暗号化されていないリンクにアクセスできるすべての人が、そのリンクを横断するすべての暗号化されていない情報に対してクリアされていることに注意する必要があります。また、MLSシステム管理者は通常、そのMLSシステムによって処理または保存されているすべての情報を確認するために以前にクリアされています。この仕様では、このIPv6オプションに関連するすべての潜在的な秘密チャネルを排除しようとはしていません。
In the first scenario, all the connected nodes in a given private internetwork are trusted systems that have Multi-Level Secure (MLS) operating systems, such as Compartmented Mode Workstations (CMWs), that support per-packet Sensitivity Labels [TCSEC] [TNI] [CMW] [MLOSPP]. In this type of deployment, all IP packets carried within the private internetwork are labeled, the IP routers apply mandatory access controls (MAC) based on the packet labels and the sensitivity ranges configured into the routers, all End Systems include packet Sensitivity Labels in each originated packet, and all End Systems apply Mandatory Access Controls to each received packet. Packets received by a router or End System that have a Sensitivity Label outside the permitted range for the receiving interface (or, in the case of a router, outside the permitted range for either the incoming or the outgoing interface) are dropped because they violate the MAC policy.
最初のシナリオでは、特定のプライベートインターネットワークの接続されたすべてのノードは、コンパートメントモードワークステーション（CMW）などのマルチレベルセキュア（MLS）オペレーティングシステムを備えた信頼できるシステムであり、パケットごとの感度ラベル[TCSEC] [TNI] [CMW] [MLOSPP]。このタイプの展開では、プライベートインターネットワーク内で運ばれるすべてのIPパケットにラベルが付けられ、IPルーターはパケットラベルに基づいて必須アクセスコントロール（MAC）を適用し、ルーターに構成された感度範囲、すべてのエンドシステムにはそれぞれのパケット感度ラベルが含まれます。起源のパケット、およびすべてのエンドシステムは、受信した各パケットに必須アクセス制御を適用します。ルーターまたはエンドシステムが受信したパケットは、受信インターフェイスの許可範囲外に感度ラベルを持つ（または、ルーターの場合、入っているインターフェイスまたは発信インターフェイスのいずれかの許可範囲外）を削除します。Macポリシー。
The second scenario is a variation of the first, where End Systems with non-MLS operating systems are present on certain subnetworks of the private internetwork. By definition, these non-MLS End Systems operate in "system high" mode. In "system high" mode, all information on the system is considered to have the sensitivity of the most sensitive data on the system. If a system happens to contain data only at one Sensitivity Level, this would also be an example of "system high" operation. In this scenario, each subnetwork that contains any single-level End Systems has one single "default" Sensitivity Label that applies to all single-level systems on that IP subnetwork. Because those non-MLS End Systems are unable to create packets containing Sensitivity Labels and are also unable to apply MAC enforcement on received packets, security gateways (which might, for example, be label-aware IP routers) connected to such subnetworks need to insert sensitivity labels to packets originated by the "system high" End Systems that are to be forwarded off subnet. While the CALIPSO IPv6 option is marked as "ignore if unrecognized", there are some deployed IPv6 End Systems with bugs. Users can't fix these operating system bugs; some users need to be able to integrate their existing IPv6 single-level End Systems to have a useful overall MLS deployment. So, for packets destined for IP subnetworks containing single-level End Systems, those last-hop security gateways also apply Mandatory Access Controls (MAC) and then either drop (if the packet is not permitted on that destination subnet) exclusive-or remove Sensitivity Labels and forward packets onto those "system high" subnetworks (if the packet is permitted on that destination subnetwork).
2番目のシナリオは、最初のシナリオであり、非MLSオペレーティングシステムを備えたエンドシステムがプライベートインターネットワークの特定のサブネットワークに存在します。定義上、これらの非MLSエンドシステムは「System High」モードで動作します。「System High」モードでは、システム上のすべての情報は、システム上の最も感度の高いデータの感度があると見なされます。システムがたまたま1つの感度レベルでデータを含める場合、これは「システムハイ」操作の例でもあります。このシナリオでは、単一レベルのエンドシステムを含む各サブネットワークには、そのIPサブネットワーク上のすべての単一レベルシステムに適用される単一の「デフォルト」感度ラベルがあります。これらの非MLSエンドシステムは、感度ラベルを含むパケットを作成できず、受信パケットにMac施行を適用できないため、そのようなサブネットワークに接続されたセキュリティゲートウェイ（ラベル認識IPルーターになる可能性があります）は挿入する必要があります。サブネットから転送される「System High」エンドシステムによって発生するパケットへの感度ラベル。Calipso IPv6オプションは「認識されていない場合は無視する」とマークされていますが、バグ付きの展開されたIPv6エンドシステムがいくつかあります。ユーザーはこれらのオペレーティングシステムのバグを修正できません。一部のユーザーは、既存のIPv6シングルレベルエンドシステムを統合して、全体的なMLS展開を有用である必要があります。したがって、シングルレベルのエンドシステムを含むIPサブネットワーク用に運命づけられているパケットの場合、これらの最終ホップセキュリティゲートウェイは必須アクセスコントロール（MAC）も適用し、その後（その宛先サブネットでパケットが許可されていない場合）排他性または感度を削除します。ラベルと「システムハイ」サブネットワークへのパケットを転送します（その宛先サブネットワークでパケットが許可されている場合）。
The authors are not aware of any existing MLS network deployments that use a commercial Network Address Translation (NAT), Network Address and Port Translation (NAPT), or any other commercial "middlebox" device. For example, NAT boxes aren't used, unlike practices in some segments of the public Internet.
著者は、商用ネットワークアドレス翻訳（NAT）、ネットワークアドレスとポート翻訳（NAPT）、またはその他の商用「ミドルボックス」デバイスを使用する既存のMLSネットワーク展開を認識していません。たとえば、パブリックインターネットの一部のセグメントのプラクティスとは異なり、NATボックスは使用されていません。
Similarly, the authors are not aware of any existing MLS network deployments that use a commercial firewall. MLS networks normally are both physically and electronically isolated from the global Internet, so operators of MLS networks are not concerned about external penetration (e.g., by worms, viruses, or the like). Similarly, all users of the MLS network have been cleared using some process specific to that organization, and hence are believe to be trustworthy. In a typical deployment, all computers connected to the MLS network are in a physically secure room or building (e.g., protected by guards with guns). Electronic equipment that enters such a space typically does not leave. Items such as USB memory sticks are generally not permitted; in fact, often the USB ports on MLS computers have been removed or otherwise made inoperable to prevent people from adding or removing information.
同様に、著者は、商用ファイアウォールを使用する既存のMLSネットワーク展開を認識していません。MLSネットワークは通常、グローバルなインターネットから物理的および電子的に分離されているため、MLSネットワークのオペレーターは外部浸透（ワーム、ウイルスなどによる）を心配していません。同様に、MLSネットワークのすべてのユーザーは、その組織に固有のプロセスを使用してクリアされているため、信頼できると考えられています。典型的な展開では、MLSネットワークに接続されているすべてのコンピューターは、物理的に安全な部屋または建物にあります（たとえば、銃で警備員によって保護されています）。そのようなスペースに入る電子機器は通常、離れません。USBメモリスティックなどのアイテムは一般に許可されていません。実際、多くの場合、MLSコンピューターのUSBポートが削除されたか、その他の方法で人々が情報を追加または削除するのを防ぐために動作できなくなっています。
Also, for security reasons, content transformation in the middle of an MLS network is widely considered undesirable, and so is not typically undertaken. Hypothetically, if such content transformation were undertaken, it would be performed by a certified MLS system that has been suitably accredited for that particular purpose in that particular deployment.
また、セキュリティ上の理由から、MLSネットワークの中央でのコンテンツ変換は望ましくないと広く見なされているため、通常は実施されません。仮説的に、そのようなコンテンツ変換が行われた場合、それはその特定の展開においてその特定の目的に対して適切に認定された認定MLSシステムによって実行されます。
This section defines several terms that are important to understanding and correctly implementing this specification. Because of historical variations in terminology in different user communities, several terms have defined synonyms.
このセクションでは、この仕様を理解し、正しく実装するために重要ないくつかの用語を定義します。さまざまなユーザーコミュニティの用語の歴史的変動のため、いくつかの用語が同義語を定義しています。
The verb "dominate" is used in this document to describe comparison of two Sensitivity Labels within a given Domain of Interpretation. Sensitivity Label A dominates Sensitivity Label B if the Sensitivity Level of A is greater than or equal to the Sensitivity Level of B AND the Compartment Set of A is a superset (proper or improper) of the Compartment Set of B. This term has been used in Multi-Level Secure circles with this meaning for at least two decades.
このドキュメントでは、「支配」という動詞は、特定の解釈ドメイン内の2つの感度ラベルの比較を説明するために使用されています。感度ラベルA Aの感度ラベルBがBの感度レベル以上であり、AのコンパートメントセットがBのスーパーセット（適切または不適切）をBのスーパーセット（適切または不適切）している場合、感度ラベルB Bが支配的です。少なくとも20年にわたってこの意味を持つマルチレベルの安全なサークルで。
A Domain of Interpretation (DOI) is a shorthand way of identifying the use of a particular labeling, 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 Sensitivity Label (which is defined to have meaning within that DOI) applied to a datum or collection of data, dictates which systems, and ultimately which persons may receive that data.
解釈の領域（DOI）は、データ、コンピューター、それを処理する人々、およびそれを運ぶネットワークに関する特定のラベル付け、分類、および取り扱いシステムの使用を識別する速記です。DOIポリシーは、特定の感度ラベル（DOI内に意味があると定義されている）と組み合わせて、データのデータまたはデータの収集に適用され、どのシステムを決定し、最終的にはどの人がそのデータを受信できるかを決定します。
In other words, a label of "SECRET" by itself is not meaningful; one also must know that the document or data belongs to some specific organization (e.g., US Department of Defense (DoD), US Department of Energy (DoE), UK Ministry of Defence (MoD), North Atlantic Treaty Organisation (NATO), United Nations (UN), a specific commercial firm) before one can decide on who is allowed to receive the data.
言い換えれば、「秘密」のラベル自体は意味がありません。また、文書またはデータが特定の組織（例：米国国防総省（DOD）、米国エネルギー省（DOE）、英国国防省（MOD）、北大西洋条約機関（NATO）（NATO）に属していることも知っている必要があります。特定の商業会社である国（UN））が、誰がデータを受け取ることを許可されるかを決定することができます。
A CALIPSO DOI is an opaque identifier that is used as a pointer to a particular set of policies, which define the Sensitivity Levels and Compartments present within the DOI, and by inference, to the "real-world" (e.g., used on paper documents) equivalent labels (See "Sensitivity Label" below). Registering or defining a set of real-world security policies as a CALIPSO DOI results in a standard way of labeling IP data originating from End Systems "accredited" or "approved" to operate within that DOI and the constraints of those security policies. For example, if one did this for the US Department of Defense, one would list all the acceptable labels such as "SECRET" and "TOP SECRET", and one would link the CALIPSO DOI to the [DoD5200.28] and [DoD5200.1-R] documents, which define how to mark and protect data with the US Department of Defense (DoD) [DoD5200.28] [DoD5200.1-R].
Calipso doiは、DOI内に存在する感度レベルとコンパートメントを「現実世界」に推論することで定義する特定のポリシーセットへのポインターとして使用される不透明な識別子です）同等のラベル（以下の「感度ラベル」を参照）。一連の現実世界のセキュリティポリシーをCalipso DOIとして登録または定義すると、そのDOIおよびそれらのセキュリティポリシーの制約内で動作するために「認定された」または「承認された」という最終システムに由来するIPデータにラベルを付ける標準的な方法が得られます。たとえば、米国国防総省のためにこれを行った場合、「秘密」や「トップシークレット」などの許容可能なすべてのラベルをリストし、Calipso doiを[dod5200.28]および[dod5200にリンクします。1-R]ドキュメント。米国国防総省（DOD）[DOD5200.28] [DOD5200.1-R]でデータをマークして保護する方法を定義します。
The scope of the DOI is dependent on the organization creating it. In some cases, the creator of the DOI might not be identical to a given user of the DOI. For example, a multi-national organization (e.g., NATO) might create a DOI, while a given member nation or organization (e.g., UK MoD) might be using that multi-national DOI (possibly along with other DOIs created by others) within its private networks. To provide a different example, the United States might establish a DOI with specific meanings, which correspond to the normal way it labels classified documents and which would apply primarily to the US DoD, but those specific meanings might also apply to other associated agencies. A company or other organization also might establish a DOI, which applies only to itself.
DOIの範囲は、それを作成する組織に依存しています。場合によっては、DOIの作成者は、DOIの特定のユーザーと同一ではない場合があります。たとえば、多国籍組織（NATOなど）はDOIを作成する可能性がありますが、特定の加盟国または組織（UK MODなど）は、その多国籍DOI（おそらく他のDOIが作成した他のDOIと一緒に）を使用している可能性があります。そのプライベートネットワーク。別の例を提供するために、米国は特定の意味を持つDOIを確立する可能性があります。これは、分類されたドキュメントをラベル付けし、主に米国のDODに適用される通常の方法に対応する可能性がありますが、これらの特定の意味は他の関連機関にも適用される場合があります。会社または他の組織もDOIを確立する可能性があります。これはそれ自体にのみ適用されます。
NOTE WELL: A CALIPSO Domain of Interpretation is different from, and is disjoint from, an Internet Security Association and Key Management Protocol (ISAKMP) / Internet Key Exchange (IKE) Domain of Interpretation. It is important not to confuse the two different concepts, even though the terms might superficially appear to be similar.
注意事項：解釈のCalipsoドメインは、インターネットセキュリティ協会と主要な管理プロトコル（ISAKMP） /インターネットキーエクスチェンジ（IKE）の解釈ドメインとは異なり、それとは異なります。表面的には類似しているように見えるかもしれませんが、2つの異なる概念を混同しないことが重要です。
A Sensitivity Level represents a mandatory separation of data based on relative sensitivity. Sensitivity 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. For example, 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. As an example, common UK terms for a Sensitivity Level include (from low to high) "UNCLASSIFIED", "RESTRICTED", "CONFIDENTIAL", "SECRET", and "MOST SECRET".
感度レベルは、相対感度に基づいたデータの必須の分離を表します。感度レベルは、常にDOI内で特定の順序を持っています。特定のレベルのデータにアクセスするためのクリアランスは、感度がそのレベルよりも少ないすべてのレベルへのアクセスを意味します。たとえば、a、b、およびcがレベルであり、aがbよりも感度が高い場合、これはc（a> b> c）よりも敏感である場合、bレベルでのデータへのアクセスは、cへのアクセスを意味します。良い。例として、感度レベルの一般的な英国の用語には、（低から高へ）「分類されていない」、「制限された」、「機密」、「秘密」、および「最も秘密」が含まれます。
NOTE WELL: A Sensitivity Level is only one component of a Sensitivity Label. It is important not to confuse the two terms. The term "Sensitivity Level" has the same meaning as the term "Security Level".
注意事項：感度レベルは、感度ラベルの1つのコンポーネントにすぎません。2つの用語を混同しないことが重要です。「感度レベル」という用語は、「セキュリティレベル」という用語と同じ意味を持っています。
A Compartment represents a mandatory segregation of data based on formal information categories, formal information compartments, or formal access programs for specific types of data. For example, 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 (e.g., the accountants and controller for "FINANCE", specific engineers for "R&D") are given access to each compartment. Each Compartment is separate and distinct. Access to one Compartment does not imply access to any other Compartment. Data may be protected in multiple compartments (e.g., "FINANCE" data about a new "R&D" project) at the same time, in which case access to ALL of those compartments is required to access the data. Employees only possessing clearance for a given Sensitivity Level (i.e., without having clearance for any specific compartments at that Sensitivity Level) do not have access to any data classified in any compartments (e.g., "SECRET FINANCE" dominates "SECRET").
コンパートメントは、正式な情報カテゴリ、正式な情報コンパートメント、または特定の種類のデータの正式なアクセスプログラムに基づいて、データの必須の分離を表します。たとえば、小規模なスタートアップ企業は、成功に重要なデータを保護するために「金融」と「R＆D」コンパートメントを作成します。特定の必要性を持つ従業員のみ（たとえば、「金融」の会計士とコントローラー、「R＆Dの特定のエンジニア」"）各コンパートメントへのアクセスが与えられます。各コンパートメントは別々で異なります。1つのコンパートメントへのアクセスは、他のコンパートメントへのアクセスを意味するものではありません。データは、データにアクセスするには、複数のコンパートメント（新しい「R＆D」プロジェクトに関する「ファイナンス」データ）で同時に保護される場合があります。従業員は、特定の感度レベルのクリアランスのみを持っている（つまり、その感度レベルで特定のコンパートメントのクリアランスを持たない）、コンパートメントに分類されたデータにアクセスできません（「シークレットファイナンス」は「秘密」を支配します）。
NOTE WELL: The term "category" has the same meaning as "compartment". Some user communities have used the term "category", while other user communities have used the term "compartment", but the terms have identical meaning.
注意事項：「カテゴリ」という用語は、「コンパートメント」と同じ意味を持っています。一部のユーザーコミュニティは「カテゴリ」という用語を使用していますが、他のユーザーコミュニティは「コンパートメント」という用語を使用していますが、用語には同一の意味があります。
A Releasability represents a mandatory segregation of data, based on a formal decision to release information to others.
解放性は、情報を他の人に公開するという正式な決定に基づいて、データの必須の分離を表します。
Historically, most MLS deployments handled Releasability as if it were an inverted Compartment. Strictly speaking, this provides slightly different semantics and behavior than a paper marked with the same Releasabilities would obtain, because the formal semantics of Compartments are different from the formal semantics of Releasability. The differences in behavior are discussed in more detail later in this sub-section.
歴史的に、ほとんどのMLS展開は、まるで逆コンパートメントであるかのように解放性を処理しました。厳密に言えば、これは、コンパートメントの正式なセマンティクスが解放可能性の正式なセマンティクスとは異なるため、同じ解放性がマークされた論文とはわずかに異なるセマンティクスと行動を提供します。行動の違いについては、このサブセクションの後半で詳しく説明します。
In practice, for some years now some relatively large MLS deployments have been encoding Releasabilities as if they were inverted Compartments. The results have been tolerable and those deployments are generally considered successful by their respective user communities. This description is consistent with these MLS deployments, so has significant operational experience behind it.
実際には、数年の間、比較的大きなMLS展開が、まるで逆コンパートメントであるかのように解放性をエンコードしてきました。結果は許容範囲であり、これらの展開は一般に、それぞれのユーザーコミュニティによって成功していると考えられています。この説明はこれらのMLS展開と一致しているため、その背後には重要な運用経験があります。
For example, two companies (ABC and XYZ) are engaging in a technical alliance. ABC labels all information present within its enterprise that is to be shared as part of the alliance as REL XYZ (e.g., COMPANY CONFIDENTIAL REL XYZ).
たとえば、2社（ABCとXYZ）は技術的な同盟に従事しています。ABCは、Allianceの一部としてRel XYZ（例：Company Confidential Rel XYZ）として共有される企業内に存在するすべての情報をラベル付けします。
However, unlike the compartment example above, COMPANY CONFIDENTIAL dominates COMPANY CONFIDENTIAL REL XYZ. This means that XYZ employees granted a COMPANY CONFIDENTIAL REL XYZ clearance can only access releasable material, while ABC employees with a COMPANY CONFIDENTIAL clearance can access all information.
ただし、上記のコンパートメントの例とは異なり、会社の機密は、会社の機密rel xyzを支配しています。これは、XYZの従業員が会社の機密のREL XYZクリアランスがリリース可能な資料のみにアクセスできるようにするため、会社の機密クリアランスを持つABCの従業員はすべての情報にアクセスできることを意味します。
If REL XYZ were managed as a compartment, then users granted a COMPANY CONFIDENTIAL REL XYZ clearance would have access to all of ABC's COMPANY CONFIDENTIAL material, which is undesirable.
Rel XYZがコンパートメントとして管理されている場合、ユーザーは会社の機密型REL XYZクリアランスがABCのすべての会社の機密資料にアクセスできるようにします。これは望ましくありません。
Releasabilities can be combined (e.g., COMPANY CONFIDENTIAL REL XYZ/ABLE). In this case, users possessing a clearance of either COMPANY CONFIDENTIAL, COMPANY CONFIDENTIAL REL XYZ, COMPANY CONFIDENTIAL REL ABLE, or COMPANY CONFIDENTIAL REL XYZ/ABLE can access this information.
解放性を組み合わせることができます（例：Companis Confidential Rel XYZ/Eableなど）。この場合、ユーザーは、会社の機密、会社の機密rel XYZ、Company Confidential Relable、またはCompanide Confidential rel XYZ/Ebleのいずれかのクリアランスを所有しています。この情報にアクセスできます。
Individual bits in this option's Compartment Bitmap field MAY be used to encode "releasability" information. The process for making this work properly is described below.
このオプションのコンパートメントビットマップフィールドの個々のビットを使用して、「リリース性」情報をエンコードできます。この作業を適切にするプロセスについては、以下に説明します。
This scheme is carefully designed so that intermediate systems need not know whether a given bit in the Compartment Bitmap field represents a compartment or a Releasability. All that an Intermediate System needs to do is apply the usual comparison (described in Section 2.5.1 and 2.5.2) to determine whether or not a packet's label is in-range for an interface. This simplifies both the configuration and implementation of a label-aware Intermediate System.
このスキームは、中間システムがコンパートメントビットマップフィールドの特定のビットがコンパートメントまたは解放性を表すかどうかを知る必要がないように慎重に設計されています。中間システムが行う必要があるのは、通常の比較（セクション2.5.1および2.5.2で説明）を適用して、パケットのラベルがインターフェイスの範囲内であるかどうかを判断することだけです。これにより、ラベル認識中間システムの構成と実装の両方が簡素化されます。
Unlike bits that represent compartments, bits that represent a Releasability are "active low".
コンパートメントを表すビットとは異なり、解放性を表すビットは「アクティブ低」です。
If a given Releasability bit in the Compartment Bitmap field is "0", the information may be released to that community. If the compartment bit is "1", the information may not be released to that community.
コンパートメントビットマップフィールドの特定の解放性ビットが「0」の場合、情報はそのコミュニティにリリースされる場合があります。コンパートメントビットが「1」の場合、情報はそのコミュニティに公開されない場合があります。
Only administrative interfaces used to present or construct binary labels in human-readable form need to understand the distinction between Releasability bits and non-Releasability bits. Implementers are encouraged to describe Releasability encoding in the documentation supplied to users of systems that implement this specification.
バイナリラベルを人間読み取り可能な形式で提示または構築するために使用される管理インターフェイスのみが、解放性ビットと非解放性ビットの区別を理解する必要があります。実装者は、この仕様を実装するシステムのユーザーに提供されたドキュメントでの解放性エンコードを説明することをお勧めします。
For objects, such as IP packets, let bits 0-3 of the Compartment Bitmap field be dedicated to controlling Releasability to the communities A, B, C, and D, respectively.
IPパケットなどのオブジェクトの場合、コンパートメントビットマップフィールドの0〜3のビットを、それぞれコミュニティA、B、C、およびDへの解放可能性を制御することに専念します。
Example 1: Not releasable to any community: This is usually how handling restrictions such as "No Foreigners (NO FORN)" are encoded. ABCD == 1111
例1：どのコミュニティにも解放できません：これは通常、「外国人なし（fornなし）」などの制限の取り扱いがエンコードされる方法です。ABCD == 1111
Example 2: Releasable only to community A and community C:
ABCD == 0101
Example 3: Releasable only to community B:
ABCD == 1011
Example 4: Releasable to communities A,B,C, & D:
ABCD == 0000
For subjects, such as clearances of users, the same bit encodings are used for Releasabilities as are used for objects (see above).
ユーザーのクリアランスなどの被験者の場合、オブジェクトに使用されるのと同じビットエンコーディングが解放に使用されます（上記参照）。
Example 1: Clearance not belonging to any community: This user can see information belonging to any Releasability community, since s/he is not in any Releasability community. ABCD = 1111
例1：コミュニティに属していないクリアランス：このユーザーは、放出可能性コミュニティにはないため、あらゆるリリース性コミュニティに属する情報を見ることができます。ABCD = 1111
Example 2: Clearance belonging to community A and C: This user can only see Releasable AC information, and cannot see Releasable A information. ABCD == 0101
例2：Community AおよびCに属するクリアランス：このユーザーは、解放可能なAC情報のみを見ることができ、解放可能な情報を見ることができません。ABCD == 0101
Example 3: Clearance belonging to community B: This user can only see Releasable B information. ABCD == 1011
例3：コミュニティBに属するクリアランス：このユーザーは、リリース可能なB情報のみを見ることができます。ABCD == 1011
Example 4: Clearance belongs to communities A,B,C, and D: This user can only see Releasable ABCD information, and cannot (for example) see Releasable AB or Releasable BD information. ABCD == 0000
例4：クリアランスはコミュニティA、B、C、およびDに属します。このユーザーは、リリース可能なABCD情報のみを見ることができ、（たとえば）解放可能なABまたは解放可能なBD情報を見ることができません。ABCD == 0000
Now we consider example comparisons for an IP router that is enforcing MAC by using CALIPSO labels on some interface:
次に、インターフェイスでCalipsoラベルを使用してMacを強制しているIPルーターの比較の例を検討します。
Let the MINIMUM label for that router interface be: CONFIDENTIAL RELEASABLE AC
そのルーターインターフェイスの最小ラベルを次のようにします：機密リリース可能なAC
Therefore, this interface has a minimum Releasability of 0101.
したがって、このインターフェイスの最小解放性は0101です。
Let the MAXIMUM label for that router interface be: TOP SECRET NOT RELEASABLE
そのルーターインターフェイスの最大ラベルを次のようにします：トップシークレットは解放できません
Therefore, this interface has a maximum Releasability of 1111.
したがって、このインターフェイスの最大解放性は1111です。
For the range comparisons, the bit values for the current packet need to be "greater than or equal to" the minimum value for the interface AND also the bit values for the current packet need to be "less than or equal to" the maximum value for the interface, just as with compartment comparisons. The inverted encoding scheme outlined above ensures that the proper results occur.
範囲の比較の場合、現在のパケットのビット値は、インターフェイスの最小値と現在のパケットのビット値を「最大値以下」にする必要があります。コンパートメントの比較と同様に、インターフェイスの場合。上記で概説した逆エンコードスキームは、適切な結果が発生することを保証します。
Consider a packet with label CONFIDENTIAL RELEASABLE AC: 1) Sensitivity Level comparison: (CONFIDENTIAL <= CONFIDENTIAL <= TOP SECRET) so the Sensitivity Level is "within range" for that router interface. 2) Compartment bitmap comparison: The test is [(0101 >= 0101) AND (0101 <= 1111)], so the Compartment bitmap is "within range" for that router interface.
ラベルConfidential Releasable ACを備えたパケットを考えてみましょう。2）コンパートメントビットマップ比較：テストは[（0101> = 0101）および（0101 <= 1111）]であるため、そのルーターインターフェイスのコンパートメントビットマップは「範囲内」です。
Consider a packet with label CONFIDENTIAL RELEASABLE ABCD: 1) Sensitivity Label comparison: (CONFIDENTIAL <= CONFIDENTIAL <= TOP SECRET) so the Sensitivity Level is "within range" for that router interface. 2) Compartment bitmap comparison: The test is [(0000 >= 0101) AND (0000 <= 1111)], so the Compartment Bitmap is NOT "within range" for that router interface.
ラベルConfidential Releasable ABCDを備えたパケットを検討してください。1）感度ラベルの比較：（ Confidential <= Confidential <= TOP Secret）。そのルーターインターフェイスの感度レベルは「範囲内」になります。2）コンパートメントビットマップ比較：テストは[（0000> = 0101）および（0000 <= 1111）]であるため、コンパートメントビットマップはそのルーターインターフェイスの「範囲内」ではありません。
Consider a packet with label SECRET NOT RELEASABLE: 1) Sensitivity Label comparison: (CONFIDENTIAL <= SECRET <= TOP SECRET) so the Sensitivity Level is "within range" for that router interface. 2) Compartment bitmap comparison: The test is [(1111 >= 0101) AND (1111 <= 1111)], so the Compartment bitmap is "within range" for that router interface.
ラベルシークレットが解放できないパケットを検討してください：1）感度ラベルの比較：（ Confidential <= Secret <= TOP Secret）。そのルーターインターフェイスの感度レベルは「範囲内」になります。2）コンパートメントビットマップ比較：テストは[（1111> = 0101）および（1111 <= 1111）]であるため、そのルーターインターフェイスのコンパートメントビットマップは「範囲内」です。
For example, if one considers a person "Jane Doe" who is a member of two Releasability communities (A and also B), she is permitted to see a paper document that is marked "Releasable A", "Releasable B", or "Releasable AB" -- provided that her Clearance and Compartments are in-range for the Sensitivity Level and Compartments (respectively) of the paper document.
たとえば、2つの解放可能性コミュニティ（AおよびB）のメンバーである「ジェーンドー」を考慮した場合、「解放可能なa」、「解放可能なb」、または「、または」とマークされた紙の文書を見ることができます。解放可能なab " - 条件文書の感度レベルとコンパートメント（それぞれ）のクリアランスとコンパートメントがそれぞれ範囲であることを条件にしてください。
Now, let us consider an equivalent electronic example implemented and deployed as outlined above. In this, we consider two Releasability communities (A and B). Those bits will be set to 00 for the electronic user ID used by user "Jane Doe".
次に、上記のように実装および展開された同等の電子例を考えてみましょう。これでは、2つの解放可能性コミュニティ（AとB）を検討します。これらのビットは、ユーザー「Jane Doe」が使用する電子ユーザーIDで00に設定されます。
However, the electronic Releasability approach above will ONLY permit her to see information marked as "Releasable AB". The above electronic approach will deny her the ability to read documents marked "Releasable A" or "Releasable B". This is because "Releasable A" is encoded as "01", "Releasable B" is encoded as "10", while "Releasable AB" is encoded as "00". If one looks at the compartment dominance computation, "00" dominates "00", but "00" does NOT dominate "01", and "00" also does NOT dominate "10".
ただし、上記の電子解放可能性アプローチは、「解放可能なAB」とマークされた情報を見ることができるだけです。上記の電子的アプローチは、「解放可能なa」または「解放可能なb」とマークされたドキュメントを読む能力を彼女に否定します。これは、「解放可能a」が「01」、「解放可能なb」が「10」としてエンコードされ、「解放可能なab」が「00」としてエンコードされるためにエンコードされるためです。コンパートメントのドミナンス計算を見ると、「00」は「00」を支配しますが、「00」は「01」を支配し、「00」も「10」を支配しません。
Users report that the current situation is tolerable, but not ideal. Users also report that various operational complexities can arise from this approach.
ユーザーは、現在の状況は許容できるが理想的ではないと報告しています。また、ユーザーは、このアプローチからさまざまな運用上の複雑さが生じる可能性があると報告しています。
Several deployments work around this limitation by assigning an electronic user several parallel clearances. Referring to the (fictitious) example above, the user "Jane Doe" might have one clearance without any Releasability, another separate clearance with Releasability A, and a third separate clearance with Releasability B. While this has implications (e.g., a need to be able to associate multiple separate parallel clearances with a single user ID) for implementers of MLS systems, this specification cannot (and does not) levy any requirements that an implementation be able to associate multiple clearances with each given user ID because that level of detail is beyond the scope of an IP labeling option.
電子ユーザーにいくつかの並行クリアランスを割り当てることにより、いくつかの展開がこの制限を回避します。上記の（架空の）例を参照すると、ユーザーの「Jane Doe」は、解放性のない1つのクリアランス、解放性Aの別の個別のクリアランス、および解放性Bの3番目の個別のクリアランスを持つ可能性がありますが、これには意味があります（例えば、MLSシステムの実装者向けに複数の個別の並列クリアランスを単一のユーザーIDに関連付けることができます。この仕様は、そのレベルの詳細があるため、実装が指定されたユーザーIDに複数のクリアランスを関連付けることができる要件を徴収することはできません（そしてそうではありません）IPラベル付けオプションの範囲を超えて。
Separating the Releasability bits into a separate bitmap within the CALIPSO option was seriously considered. However, existing MLS implementations lack operating system support for Releasability. So even if CALIPSO had a separate bitmap field, those bits would have been mapped to Compartment bits by the sending/receiving nodes, so the operational results would not have been different than those described here.
Calipsoオプション内のリリース性ビットを別のビットマップに分離することが真剣に考慮されました。ただし、既存のMLS実装には、解放性に対するオペレーティングシステムのサポートがありません。したがって、Calipsoに別のビットマップフィールドがあったとしても、これらのビットは、送信/受信ノードによってコンパートメントビットにマッピングされていたため、動作結果はここで説明したものとは変わりませんでした。
Several MLS network deployments connect MLS End Systems both to a labeled national network and also to a labeled coalition network simultaneously. Depending on whether the data is labeled according to national rules or according to coalition rules, the set of Releasability marks will vary. Some choices are likely to lead to more (or fewer) incorrect Releasability decisions (although the results of the above Releasability encodings are believed to be fail-safe).
いくつかのMLSネットワークの展開は、ラベル付きナショナルネットワークとラベル付き連合ネットワークの両方に同時にMLSエンドシステムを接続します。データが国家規則に従ってラベル付けされているか、連合規則に従ってラベル付けされているかどうかに応じて、解放性マークのセットは異なります。いくつかの選択肢は、より多くの（または少ない）誤った解放可能性の決定につながる可能性があります（ただし、上記の解放性エンコーディングの結果はフェイルセーフであると考えられています）。
A Sensitivity Label is a quadruple consisting of a DOI, a Sensitivity Level, a Compartment Set, and a Releasability Set. The Compartment Set may be the empty set if and only if no compartments apply. A Releasability Set may be the empty set if and only if no Releasabilities apply. A DOI used within an End System may be implicit or explicit depending on its use. CALIPSO Sensitivity Labels always have an explicit DOI. A CALIPSO Sensitivity Label consists of a Sensitivity Label in a particular format (defined below). A CALIPSO Sensitivity Label ALWAYS contains an explicit DOI value. In a CALIPSO Sensitivity Label, the Compartment Bitmap field is used to encode both the logical Compartment Set and also the logical Releasability Set.
感度ラベルは、DOI、感度レベル、コンパートメントセット、および解放可能性セットで構成される4倍です。コンパートメントが適用されない場合にのみ、コンパートメントセットが空のセットである場合があります。解放性セットは、解放性が適用されない場合にのみ空のセットである場合があります。エンドシステム内で使用されるDOIは、その使用に応じて暗黙的または明示的である場合があります。Calipsoの感度ラベルには、常に明示的なdoiがあります。Calipso感度ラベルは、特定の形式の感度ラベルで構成されています（以下に定義）。Calipso感度ラベルには、常に明示的なDOI値が含まれています。Calipso感度ラベルでは、コンパートメントビットマップフィールドを使用して、論理コンパートメントセットと論理リリース性セットの両方をエンコードします。
End Systems using operating systems with MLS capabilities that also implement IPv6 normally will be able to include CALIPSO labels in packets they originate and will be able to enforce MAC policy on the CALIPSO labels in any packets they receive.
IPv6を通常実装するMLS機能を備えたオペレーティングシステムを使用するエンドシステムは、発信するパケットにCalipsoラベルを含めることができ、受け取ったパケットのCalipsoラベルのMacポリシーを実施することができます。
End Systems using an operating system that lacks Multi-Level Secure capabilities operate in "system high" mode. This means that all data on the system is considered to have the Sensitivity Label of the most sensitive data on the system. Such a system normally is neither capable of including CALIPSO labels in packets that it originates nor of enforcing CALIPSO labels in packets that it receives.
マルチレベルのセキュア機能がないオペレーティングシステムを使用したエンドシステムは、「System High」モードで動作します。これは、システム上のすべてのデータが、システム上の最も感度の高いデータの感度ラベルを持つと見なされることを意味します。このようなシステムは通常、それが発生するパケットにCalipsoラベルを含めることも、受信するパケットにCalipsoラベルを施行することもできません。
NOTE WELL: The term "Security Marking" has the same meaning as "Sensitivity Label".
よく注意：「セキュリティマーキング」という用語は、「感度ラベル」と同じ意味を持っています。
Two Sensitivity Labels (A and B) can be compared. Indeed, Sensitivity Labels exist primarily so they can be compared as part of a Mandatory Access Control decision. Comparison is critical to determining if a subject (a person, network, etc.) operating at one Sensitivity Label (A) should be allowed to access an object (file, packet, route, etc.) classified at another Sensitivity Label (B). The comparison of two labels (A and B) can return one (and only one) of the following results:
2つの感度ラベル（AとB）を比較できます。実際、感度ラベルは主に存在するため、必須のアクセス制御決定の一部として比較できます。ある感度ラベル（a）で動作する被験者（個人、ネットワークなど）が別の感度ラベル（b）に分類されたオブジェクト（ファイル、パケット、ルートなど）にアクセスできるかどうかを判断するには、比較が重要です。。2つのラベル（AとB）の比較は、次の結果の1つ（および1つだけ）を返すことができます。
1) A dominates B (e.g., A=SECRET, B=UNCLASSIFIED); A can read B,
1) AはB（例：a = secret、b = classified）を支配します。aはbを読むことができます、
2) B dominates A (e.g., A=UNCLASSIFIED, B=SECRET); A cannot access B,
2) bはaを支配します（例：a = classified、b = secret）;Aはbにアクセスできません、
3) A equals B (e.g., A=SECRET, B=SECRET); A can read/write B,
3) aはb（例：a = secret、b = secret）;a can読み取り/書き込みb、
exclusive-or
排他的または
4) A is incomparable to B (e.g., A=SECRET R&D, B=SECRET FINANCE); A cannot access B, and also, B cannot access A.
4) AはBと比較できます（例：a = secret r＆d、b = secret Finance）;AはBにアクセスできません。また、BはAにアクセスできません。
By definition, if A and B are members of different DOIs, the result of comparison is always incomparable. It is possible to overcome this if and only if A and/or B can be translated into some common DOI, such that the labels are then interpretable.
定義上、AとBが異なるDOIのメンバーである場合、比較の結果は常に比較できません。Aおよび/またはbをいくつかの一般的なDOIに変換できる場合にのみ、これを克服することができます。そのため、ラベルは解釈可能です。
A range is a pair of Sensitivity Labels, which indicate both a minimum and a maximum acceptable Sensitivity Label for objects compared against it. A range is usually expressed as "<minimum> : <maximum>" and always has the property that the maximum Sensitivity Label dominates the minimum Sensitivity Label. In turn, this requires that the two Sensitivity Labels MUST be comparable.
範囲は一対の感度ラベルであり、それに比べてオブジェクトの最小値と最大許容性ラベルの両方を示します。通常、範囲は「<mulimby>：<maximum>」として表現され、最大感度ラベルが最小感度ラベルを支配するという特性を常に持っています。次に、これには2つの感度ラベルが匹敵する必要があります。
A range where <minimum> equals <maximum> may be expressed simply as "<minimum>"; in this case, the only acceptable Sensitivity Label is <minimum>.
<minotion>に等しい範囲は<musmag>を単に「<minom>」として表現できます。この場合、唯一の許容される感度ラベルは<mulimmen>です。
The act of receiving a datagram and translating the CALIPSO Sensitivity Label of that packet into the appropriate internal (i.e., end-system-specific) Sensitivity Label.
データグラムを受信し、そのパケットのCalipso感度ラベルを適切な内部（つまり、最終システム固有の）感度ラベルに変換する行為。
The act of selecting an appropriate DOI for an outbound datagram, translating the internal (end-system-specific) label into an CALIPSO Sensitivity Label 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:
アウトバウンドデータグラムに適したDOIを選択し、内部（エンドシステム固有の）ラベルをそのDOIに基づいてCalipso感度ラベルに変換し、データグラムを送信する行為。適切なdoiの選択は、以下を含むが必ずしも限定的ではない多くの要因に基づいている場合があります。
Source Port Destination Port Transport Protocol Application Protocol Application Information End System Subnetwork Network Sending Interface System Implicit/Default DOI
ソースポート宛先ポートトランスポートプロトコルプロトコルアプリケーション情報エンドシステムサブネットワークネットワークインターフェイスシステムの送信暗黙/デフォルトDOI
Regardless of the DOI selected, the Sensitivity Label of the outbound datagram must be consistent with the security policy monitor of the originating system and also with the DOI definition used by all other devices cognizant of that DOI.
選択されたDOIに関係なく、アウトバウンドデータグラムの感度ラベルは、発信システムのセキュリティポリシーモニター、およびそのdoiを認識する他のすべてのデバイスで使用されるDOI定義と一致する必要があります。
An End System is a host or router from which a datagram originates or to which a datagram is ultimately delivered.
エンドシステムは、データグラムが発信するか、データグラムが最終的に配信されるホストまたはルーターです。
The IPv6 community has defined the term Node to include both Intermediate Systems and End Systems [RFC2460].
IPv6コミュニティは、ノードという用語を定義して、中間システムとENDシステム[RFC2460]の両方を含めています。
An Intermediate System (IS) is a node that receives and transmits a particular datagram without being either the source or destination of that datagram. An Intermediate System might also be called a "gateway", "guard", or "router" in some user communities.
中間システム（IS）は、そのデータグラムのソースまたは宛先のいずれにせずに特定のデータグラムを受信および送信するノードです。中間システムは、一部のユーザーコミュニティでは「ゲートウェイ」、「ガード」、または「ルーター」とも呼ばれる場合があります。
So an IPv6 router is one example of an Intermediate System. A firewall or security guard device that applies security policies and forwards IPv6 packets that comply with those security policies is another example of an Intermediate System.
したがって、IPv6ルーターは中間システムの一例です。セキュリティポリシーを適用し、これらのセキュリティポリシーに準拠するIPv6パケットを転送するファイアウォールまたはセキュリティガードデバイスは、中間システムの別の例です。
An Intermediate System may handle ("forward") a datagram destined for some other node without necessarily importing or exporting the datagram to/from itself.
中間システムは、必ずしもそれ自体にデータグラムをインポートまたはエクスポートすることなく、他のノードに向けられたデータグラムを（「フォワード」）処理する場合があります。
NOTE WELL: Any given system can be both an End System and an Intermediate System -- which role the system assumes at any given time depends on the address(es) of the datagram being considered and the address(es) associated with that system.
注意事項：特定のシステムは、エンドシステムと中間システムの両方にすることができます。これは、システムが想定する役割は、考慮されているデータグラムのアドレスとそのシステムに関連するアドレスのアドレスに依存します。
A System Security Policy (SSP) consists of a Sensitivity Label and the organizational security policies associated with content labeled with a given security policy. The SSP acts as a bridge between how the organization's Mandatory Access Control (MAC) policy is stated and managed and how the network implements that policy. Typically, the SSP is a document created by the Information Systems Security Officer (ISSO) of the site or organization covered by that SSP.
System Security Policy（SSP）は、感度ラベルと、特定のセキュリティポリシーにラベルを付けるコンテンツに関連する組織セキュリティポリシーで構成されています。SSPは、組織の必須アクセス制御（MAC）ポリシーがどのように述べられ、管理されているか、およびネットワークがそのポリシーをどのように実施するかの間の橋渡しとして機能します。通常、SSPは、そのSSPの対象となるサイトまたは組織の情報システムセキュリティ担当者（ISSO）によって作成されたドキュメントです。
This document describes a convention for labeling an IPv6 datagram within a particular system security policy. The labels are designed for use within a Mandatory Access Control (MAC) system. A real-world example is the security classification system in use within the UK Government. Some data held by the government is "classified", and is therefore restricted by law to those people who have the appropriate "clearances".
このドキュメントでは、特定のシステムセキュリティポリシー内でIPv6データグラムにラベルを付けるための条約について説明しています。ラベルは、必須アクセス制御（MAC）システム内で使用するように設計されています。現実世界の例は、英国政府内で使用されているセキュリティ分類システムです。政府が保有するデータは「分類されている」ため、適切な「クリアランス」を持っている人々に法律によって制限されています。
Commercial examples of information labeling schemes also exist [CW87]. For example, one global electrical equipment company has a formal security policy that defines six different Sensitivity Levels for its internal data, ranging from "Class 1" to "Class 6" information. Some financial institutions use multiple compartments to restrict access to certain information (e.g., "mergers and acquisitions", "trading") to those working directly on those projects and to deny access to other groups within the company (e.g., equity trading). A CALIPSO Sensitivity Label is the network instantiation of a particular information security policy, and the policy's related labels, classifications, compartments, and Releasabilities.
情報ラベルのスキームの商業例も存在します[CW87]。たとえば、1つのグローバル電気機器会社には、「クラス1」から「クラス6」情報まで、内部データの6つの異なる感度レベルを定義する正式なセキュリティポリシーがあります。一部の金融機関は、複数のコンパートメントを使用して、特定の情報（例：「合併と買収」、「取引」）へのアクセスをそれらのプロジェクトに直接取り組んでいる人に制限し、会社内の他のグループへのアクセス（例：株式取引）を拒否します。Calipso感度ラベルは、特定の情報セキュリティポリシーのネットワークインスタンス化、およびポリシーに関連するラベル、分類、コンパートメント、および解放です。
Some years ago, the Mandatory Access Control (MAC) policy for US Government classified information was specified formally in mathematical notation [BL73]. As it happens, many other organizations or governments have the same basic Mandatory Access Control (MAC) policy for information with differing ("vertical") Sensitivity Levels. This document builds upon the formal definitions of Bell-LaPadula [BL73]. There are two basic principles: "no write down" and "no read up".
数年前、米国政府分類情報の必須アクセス制御（MAC）ポリシーは、数学表記法[BL73]で正式に指定されました。たまたま、他の多くの組織または政府は、異なる（「垂直」）感度レベルを持つ情報について、同じ基本的な必須アクセス制御（MAC）ポリシーを持っています。この文書は、ベル・ラパドゥラの正式な定義に基づいています[BL73]。2つの基本原則があります：「書き留めなし」と「読み取りなし」。
The first rule means that an entity having minimum Sensitivity Level X must not be able to write information that is marked with a Sensitivity Level below X. The second rule means that an entity having maximum Sensitivity Level X must not be able to read information having a Sensitivity Level above X. In a normal deployment, information downgrading ("write down") must not occur automatically, and is permitted if and only if a person with appropriate "downgrade" privilege manually verifies the information is permitted to be downgraded before s/he manually relabels (i.e., "downgrades") the information. Subsequent to the original work by Bell and LaPadula in this area, this formal model was extended to also support ("horizontal") Compartments of information.
最初のルールは、最小感度レベルxを持つエンティティがX未満の感度レベルでマークされた情報を記述してはならないことを意味します。2番目のルールは、最大感度レベルXを持つエンティティが情報を読み取ることができないことを意味します。Xを超える感度レベル。通常の展開では、情報の格下げ（「書き留め」）が自動的に発生する必要はありません。彼は情報を手動で解きます（つまり、「格下げ」）。この地域のベルとラパドゥラによる元の作品に続いて、この正式なモデルは、情報のコンパートメント（「水平」）もサポートするように拡張されました。
This document extends Bell-LaPadula to accommodate the notion of separate Domains of Interpretation (DOI) [BL73]. Each DOI constitutes a single comparable domain of Sensitivity Labels as stated by Bell-LaPadula. Sensitivity Labels from different domains cannot be directly compared using Bell-LaPadula semantics.
この文書は、ベルラパドゥラを拡張して、解釈の別々のドメイン（doi）[bl73]の概念に対応します。各DOIは、Bell-Lapadulaが述べたように、感度ラベルの単一の同等のドメインを構成します。異なるドメインからの感度ラベルは、Bell-Lapadulaセマンティクスを使用して直接比較することはできません。
This document is focused on providing specifications for (1) encoding Sensitivity Labels in packets, and (2) how such Sensitivity Labels are to be interpreted and enforced at the IP layer. This document recognizes that there are several kinds of application processing that occur above the IP layer that significantly impact end-to-end system security policy enforcement, but are out of scope for this document. In particular, how the network labeling policy is enforced within processing in an End System is critical, but is beyond the scope of a network (IP) layer Sensitivity Label encoding standard. Other specifications exist, which discuss such details [TCSEC] [TNI] [CMW] [ISO-15408] [CC] [MLOSPP].
このドキュメントは、（1）パケット内の感度ラベルをエンコードするための仕様を提供することに焦点を当てています。このドキュメントは、エンドツーエンドのシステムセキュリティポリシーの執行に大きな影響を与えるが、このドキュメントの範囲外であるIPレイヤーの上に発生するいくつかの種類のアプリケーション処理があることを認識しています。特に、エンドシステムの処理内でネットワークラベル付けポリシーが施行される方法は重要ですが、ネットワーク（IP）レイヤー感度ラベルをエンコードする範囲を超えています。そのような詳細[TCSEC] [TNI] [CMW] [ISO-15408] [CC] [MLOSPP]を議論する他の仕様が存在します。
This specification does not preclude an End System capable of providing labeled packets across some range of Sensitivity Labels. A Compartmented Mode Workstation (CMW) is an example of such an End System [CMW]. This is useful if the End System is capable of, and accredited to, separate processing across some range of Sensitivity Labels. Such a node would have a range associated with it within the network interface connecting the node to the network. As an example, an End System has the range "SECRET: TOP SECRET" associated with it in the Intermediate System to which the node is attached. SECRET processing on the node is allowed to traverse the network to other "SECRET : SECRET" segments of the network, ultimately to a "SECRET : SECRET" node. Likewise, TOP SECRET processing on the node is allowed to traverse a network through "TOP SECRET: TOP SECRET" segments, ultimately to some "TOP SECRET: TOP SECRET" node. The node in this case can allow a user on this node to access SECRET and TOP SECRET resources, provided the user holds the appropriate clearances and has been correctly configured.
この仕様は、ある範囲の感度ラベルにラベル付きパケットを提供できるエンドシステムを排除するものではありません。コンパートメントモードワークステーション（CMW）は、このようなエンドシステム[CMW]の例です。これは、エンドシステムが何らかの範囲の感度ラベル全体で処理が分離できる、および認定されている場合に役立ちます。このようなノードには、ノードをネットワークに接続するネットワークインターフェイス内に範囲が関連付けられます。例として、エンドシステムには、ノードが接続されている中間システムに関連付けられた「秘密：トップシークレット」の範囲があります。ノード上の秘密処理は、ネットワークを他の「秘密：秘密」セグメントに通過し、最終的には「秘密：秘密」ノードに通過できます。同様に、ノード上のトップシークレット処理は、「トップシークレット：トップシークレット」セグメントを介してネットワークを通過することができます。この場合のノードは、ユーザーが適切なクリアランスを保持し、正しく構成されている場合、このノード上のユーザーがシークレットおよびトップシークレットリソースにアクセスできるようにすることができます。
With respect to a given network, each distinct Sensitivity Label represents a separate virtual network, which shares the same physical network. There are rules for moving information between the various virtual networks. 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. Nodes that implement this protocol MUST enforce this mandatory separation of data.
特定のネットワークに関しては、それぞれの異なる感度ラベルは、同じ物理ネットワークを共有する個別の仮想ネットワークを表します。さまざまな仮想ネットワーク間で情報を移動するためのルールがあります。このドキュメント内で使用するモデルは、Bell-Lapadulaモデルに基づいていますが、異なる解釈ドメインの概念をカバーするために拡張されています。このプロトコルを実装するノードは、この必須のデータの分離を実施する必要があります。
CALIPSO provides for both horizontal ("Compartment") and vertical ("Sensitivity Level") separation of information, 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.
Calipsoは、情報の水平（「コンパートメント」）と垂直（「感度レベル」）分離の両方を提供し、DOIに基づく分離を提供します。基本的なルールは、データを受け取ることを承認されていないユーザーまたはシステムに配信してはならないということです。
NOTE WELL: Wherever we say "not approved", we also mean "not cleared", "not certified", and/or "not accredited" as applicable in one's operational community.
よく注意：「承認されていない」と言う場所では、「クリアされていない」、「認定されていない」、および/または「認定されていない」ということを意味します。
This specification does not enable AUTOMATIC relabeling of information, within a DOI or to a different DOI. That is, neither automatic "upgrading" nor automatic "downgrading" of information are enabled by this specification. Local security policies might allow some limited downgrading, but this normally requires the intervention of some human entity and is usually done within an End System with respect to the internal Sensitivity Label, rather than on a network or in an intermediate-system (e.g., router, guard). Automatic downgrading is not suggested operational practice; further discussion of downgrading is outside the scope of this protocol specification.
この仕様では、doi内または別のdoiへの情報の自動再溶解を有効にしません。つまり、情報の自動「アップグレード」も自動「ダウングレード」も有効になっていません。ローカルセキュリティポリシーにより、ある程度の格下げが可能になる場合がありますが、これには通常、一部の人間エンティティの介入が必要であり、通常はネットワークまたは中間システムではなく、内部感度ラベルに関してエンドシステム内で行われます（例えば、ルーターはルーター、 ガード）。自動ダウングレードは、運用慣行は推奨されません。格下げのさらなる議論は、このプロトコル仕様の範囲外です。
Implementers of this specification MUST NOT permit automatic upgrading or downgrading of information in the default configuration of their implementation. Implementers MAY add a configuration knob that would permit a System Security Officer holding appropriate privilege to enable automatic upgrading or downgrading of information. If an implementation supports such a knob, the existence of the configuration knob must be clearly documented and the default knob setting MUST be that automatic upgrading or downgrading is DISABLED. Automatic information upgrading and downgrading is not recommended operational practice.
この仕様の実装者は、実装のデフォルト構成で情報の自動アップグレードまたはダウングレードを許可してはなりません。実装者は、情報の自動アップグレードまたはダウングレードを可能にするための適切な特権を保持するシステムセキュリティ担当者が許可する構成ノブを追加する場合があります。実装がそのようなノブをサポートする場合、構成ノブの存在を明確に文書化する必要があり、デフォルトのノブ設定は、自動アップグレードまたはダウングレードが無効になっていることです。自動情報のアップグレードとダウングレードは、運用慣行を推奨していません。
Many existing MLS deployments already use (and operationally need to use) more than one DOI concurrently. User feedback from early versions of this specification indicates that it is common at present for a single network link (i.e., IP subnetwork) to carry traffic for both a particular coalition (or joint-venture) activity and also for the government (or other organization) that owns and operates that particular network link. On such a link, one CALIPSO DOI would typically be used for the coalition traffic and some different CALIPSO DOI would typically be used for non-coalition traffic (i.e., traffic that is specific to the government that owns and operates that particular network link). For example, a UK military network that is part of a NATO deployment might have and use a UK MoD DOI for information originating/terminating on another UK system, while concurrently using a different NATO DOI for information originating/terminating on a non-UK NATO system.
多くの既存のMLS展開は、既に複数のDOIを同時に使用しています（および運用上使用する必要があります）。この仕様の初期バージョンからのユーザーフィードバックは、特定の連合（またはジョイントベンチャー）活動の両方と政府（または他の組織の両方のトラフィックを運ぶための単一のネットワークリンク（つまり、IPサブネットワーク）が現在一般的であることを示しています。）それはその特定のネットワークリンクを所有および運用します。このようなリンクでは、1つのCalipso doiが連合交通に使用され、通常、非calのトラフィックに使用されます（つまり、特定のネットワークリンクを所有および運営する政府に固有のトラフィック）に使用されます。たとえば、NATOの展開の一部である英国の軍事ネットワークは、別の英国システムで発信/終了する情報に英国MOD DOIを使用し、非uk NATOで発信/終了する情報に異なるNATO doiを同時に使用します。システム。
Additionally, operational experience with existing MLS systems has shown that if a system only supports a single DOI at a given time, then it is impossible for a deployment to migrate from using one DOI value to a different DOI value in a smooth, lossless, zero downtime, manner.
さらに、既存のMLSシステムでの運用エクスペリエンスにより、システムが特定の時間に単一のDOIのみをサポートする場合、展開が1つのDOI値を使用して、スムーズでロスレス、ゼロで異なるDOI値に移行することが不可能であることが示されています。ダウンタイム、マナー。
Therefore, a node that implements this specification MUST be able to support at least two CALIPSO DOIs concurrently. Support for more than two concurrent CALIPSO DOIs is encouraged. This requirement to support at least two CALIPSO DOIs concurrently is not necessarily an implementation constraint upon MLS operating system internals that are unrelated to the network.
したがって、この仕様を実装するノードは、少なくとも2つのCalipso DOIを同時にサポートできる必要があります。2つ以上の同時Calipso Doisのサポートが奨励されています。少なくとも2つのCalipso DOIを同時にサポートするためのこの要件は、必ずしもネットワークとは関係のないMLSオペレーティングシステムの内部に対する実装の制約ではありません。
Indeed, use of multiple DOIs is also operationally useful in deployments having a single administration that also have very large numbers of compartments. For example, such a deployment might have one set of related compartments in one CALIPSO DOI and a different set of compartments in a different CALIPSO DOI. Some compartments might be present in both DOIs, possibly at different bit positions of the compartment bitmap in different DOIs. While this might make some implementations more complex, it might also be used to reduce the typical size of the IPv6 CALIPSO option in data packets.
実際、複数のDOIの使用は、非常に多数のコンパートメントを備えた単一の管理を持つ展開にも運用的に役立ちます。たとえば、このような展開には、1つのCalipso DOIに1つの関連コンパートメントがあり、異なるCalipso DOIに異なるコンパートメントのセットがある場合があります。いくつかのコンパートメントは、両方のDOIに、おそらく異なるDOIのコンパートメントビットマップの異なるビット位置に存在する場合があります。これにより、いくつかの実装がより複雑になる可能性がありますが、データパケットのIPv6 Calipsoオプションの典型的なサイズを削減するためにも使用される場合があります。
Moving information between any two DOIs is permitted -- if and only if -- the owners of the DOIs:
2つのDOIの間に情報を移動することは、DOIの所有者の所有者の間で許可されています。
1) Agree to the exchange,
1) 交換に同意する、
AND
と
2) Publish a document with a table of equivalencies that maps the CALIPSO values of one DOI into the other and make that document available to security administrators of MLS systems within the deployment scope of those two DOIs.
2) 1つのdoiのCalipso値を他のDOIにマッピングする等価表でドキュメントを公開し、これら2つのDOIの展開範囲内でMLSシステムのセキュリティ管理者がそのドキュメントを利用できるようにします。
The owners of two DOIs 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. One-way agreements are permissible, as are agreements that are a subset of the full table of equivalences. Actual administration of inter-DOI agreements is outside the scope of this document.
2つのDOIの所有者は、システムの上またはその間の交換を許可することを選択するか、所有/認定されたシステムの小さなサブセットへの交換を制限することができます。一方向契約は許可されており、同等の完全な表のサブセットである契約も同様です。DOI間契約の実際の管理は、この文書の範囲外です。
When data leaves an End System it is exported to the network, and marked with a particular DOI, Sensitivity Level, and Compartment Set. (This triple is collectively termed a Sensitivity Label.) This Sensitivity Label is derived from the internal Sensitivity Label (the end-system-specific implementation of a given Sensitivity Label), and the Export DOI. Selection of the Export DOI is described in detail in Section 6.2.1.
データがエンドシステムを離れると、ネットワークにエクスポートされ、特定のDOI、感度レベル、およびコンパートメントセットがマークされます。（このトリプルは、集合的に感度ラベルと呼ばれます。）この感度ラベルは、内部感度ラベル（特定の感度ラベルの最終システム固有の実装）およびエクスポートDOIから派生しています。輸出DOIの選択については、セクション6.2.1で詳しく説明しています。
When data arrives at an End System, it is imported from the network to the End System. The data from the datagram takes on an internal Sensitivity Label based on the Sensitivity Label contained in the datagram. This assumes the datagram is marked with a recognizable DOI, there is a corresponding internal Sensitivity Label equivalent to the CALIPSO Sensitivity Label, and the datagram is "within range" for the receiving logical interface.
データがエンドシステムに到着すると、ネットワークからエンドシステムにインポートされます。データグラムのデータは、データグラムに含まれる感度ラベルに基づいて内部感度ラベルを使用します。これは、データグラムが認識可能なDOIでマークされていることを前提としています。Calipso感度ラベルに相当する対応する内部感度ラベルがあり、データグラムは受信論理インターフェイスの「範囲内」です。
A node has one or more physical interfaces. Each physical interface is associated with a physical network segment used to connect the node, router, LAN, or WAN. One or more Sensitivity Label ranges are associated with each physical network interface. Sensitivity Label ranges from multiple DOIs must be enumerated separately. Multiple ranges from the same DOI are permissible.
ノードには、1つ以上の物理インターフェイスがあります。各物理インターフェイスは、ノード、ルーター、LAN、またはWANを接続するために使用される物理ネットワークセグメントに関連付けられています。1つ以上の感度ラベル範囲は、各物理ネットワークインターフェイスに関連付けられています。複数のDOIからの感度ラベルの範囲は、個別に列挙する必要があります。同じdoiからの複数の範囲は許されます。
Each node also might have one or more logical network interfaces.
各ノードには、1つ以上の論理ネットワークインターフェイスがある場合があります。
A given logical network interface might be associated with more than one physical interface. For example, a switch/router might have two separate Ethernet ports that are associated with the same Virtual Local Area Network (VLAN), where that one VLAN mapped to a single IPv6 subnetwork [IEEE802.1Q].
特定の論理ネットワークインターフェイスは、複数の物理インターフェイスに関連付けられている可能性があります。たとえば、スイッチ/ルーターには、同じ仮想ローカルエリアネットワーク（VLAN）に関連付けられている2つの独立したイーサネットポートがあり、1つのVLANが単一のIPv6サブネットワーク[IEEE802.1Q]にマッピングしました。
A given physical network interface might have more than one associated logical interface. For example, a node might have 2 logical network interfaces, each for a different IP subnetwork ("super-netting"), on a single physical network interface (e.g., on a single Network Interface Card of a personal computer). Alternatively, also as an example, a single Ethernet port might have multiple Virtual LANs (VLANs) associated with it, where each VLAN could be a separate logical network interface.
特定の物理ネットワークインターフェイスには、複数の関連する論理インターフェイスがある場合があります。たとえば、ノードには、単一の物理ネットワークインターフェイス（たとえば、パーソナルコンピューターの単一のネットワークインターフェイスカード上）で、それぞれ異なるIPサブネットワーク（「スーパーネット」）の2つの論理ネットワークインターフェイスがある場合があります。あるいは、例としても、単一のイーサネットポートには複数の仮想LAN（VLAN）が関連付けられている場合があり、各VLANは別の論理ネットワークインターフェイスになる可能性があります。
One or more Sensitivity Label ranges are associated with each logical network interface. Sensitivity Label ranges from multiple DOIs must be enumerated separately. Multiple ranges from the same DOI are permissible. Each range associated with a logical interface must fall within a range separately defined for the corresponding physical interface.
1つ以上の感度ラベル範囲は、各論理ネットワークインターフェイスに関連付けられています。複数のDOIからの感度ラベルの範囲は、個別に列挙する必要があります。同じdoiからの複数の範囲は許されます。論理インターフェイスに関連付けられた各範囲は、対応する物理インターフェイスに対して個別に定義された範囲内に収まる必要があります。
There is specific user interest in having IPv6 routers that can apply per-logical-interface mandatory access controls based on the contents of the CALIPSO Sensitivity Labels in IPv6 packets. The authors note that since the early 1990s, and continuing through today, some commercial IPv4 router products provide MAC enforcement for the RFC 1108 IP Security Option.
IPv6パケットのCalipso感度ラベルのコンテンツに基づいて、Logical-Interfaceごとに必須アクセス制御を適用できるIPv6ルーターを持つことには、特定のユーザーの関心があります。著者らは、1990年代初頭以降、今日まで継続して以来、一部の市販のIPv4ルーター製品は、RFC 1108 IPセキュリティオプションのMAC施行を提供していることに注目しています。
In transit, a datagram is handled based on its CALIPSO Sensitivity Label, and is usually neither imported to or exported from the various Intermediate Systems it transits. There also is the concept of "CALIPSO Gateways", which import data from one DOI and export it to another DOI such that the effective Sensitivity Label is NOT changed, but is merely represented using a different DOI. In other words, such devices would be trustworthy, trusted, and authorized to provide on-the-fly relabeling of packets at the boundaries between complete systems of End Systems within a single DOI. Typically, such systems require specific certification(s) and accreditation(s) before deployment or use.
トランジットでは、データグラムはそのCalipso感度ラベルに基づいて処理され、通常、通過するさまざまな中間システムにインポートまたはエクスポートされません。また、「Calipso Gateways」の概念もあります。これは、あるDOIからデータをインポートし、それを別のDOIにエクスポートして、効果的な感度ラベルが変更されないが、単に別のDOIを使用して表現されるだけです。言い換えれば、そのようなデバイスは、単一のDOI内のエンドシステムの完全なシステム間の境界でパケットをオンザフライでリラブルすることを信頼され、信頼され、許可されます。通常、そのようなシステムには、展開または使用前に特定の認証と認定が必要です。
This Section describes the default behavior of CALIPSO-compliant End Systems and Intermediate Systems. Implementers MAY implement configuration knobs to vary from this behavior, provided that the default behavior (i.e., if the system administrator does not explicitly change the configured behavior of the device) is as described below. If implementers choose to implement such configuration knobs, the configuration parameters and the behaviors that they enable and disable SHOULD be documented for the benefit of system administrators of those devices.
このセクションでは、Calipsoに準拠したエンドシステムと中間システムのデフォルトの動作について説明します。デフォルトの動作（つまり、システム管理者がデバイスの設定された動作を明示的に変更しない場合）が以下に説明されている場合、実装者はこの動作によって変化するように構成ノブを実装できます。実装者がそのような構成ノブを実装することを選択した場合、それらのデバイスのシステム管理者の利益のために、構成パラメーターとそれらが有効および無効にする動作を文書化する必要があります。
Each Intermediate System or End System is responsible for properly interpreting and enforcing the MLS Mandatory Access Control policy. Practically, this means that each node must evaluate the label on the inbound packet, ensure that this Sensitivity Label is valid (i.e., within range) for the receiving interface, and at a minimum only forward the packet to an interface and node where the Sensitivity Label of the packet falls within the assigned range of that node's receiving interface.
各中間システムまたはエンドシステムは、MLS必須アクセス制御ポリシーを適切に解釈および実施する責任があります。実際には、これは、各ノードがインバウンドパケットのラベルを評価し、この感度ラベルが受信インターフェイスに対して有効（つまり、範囲内）であることを確認する必要があることを意味します。パケットのラベルは、そのノードの受信インターフェイスの割り当てられた範囲内にあります。
Packets with an invalid (e.g., out-of-range) Sensitivity Label for the receiving interface MUST be dropped upon receipt. A Sensitivity Label is valid if and only if the Sensitivity Label falls within the range assigned to the transmitting interface on the sending system and within the range assigned to the receiving interface on the receiving system. These rules also need to be applied by Intermediate Systems on each hop that a CALIPSO-labeled packet traverses, not merely at the end points of a labeled IP session. As an example, it is a violation of the default MLS MAC policy for a packet with a higher Sensitivity Level (e.g., "MOST SECRET") to transit a link whose maximum Sensitivity Level is less than that first Sensitivity Level (e.g., "SECRET").
受信インターフェイスの無効な（例えば、範囲外）感度ラベルを備えたパケットは、受領時にドロップする必要があります。感度ラベルが、送信システム上の送信インターフェイスに割り当てられた範囲内および受信システム上の受信インターフェイスに割り当てられた範囲内にある場合にのみ、感度ラベルが有効です。また、これらのルールは、ラベル付きIPセッションの最後のポイントではなく、カリプソ標識パケットが横断する各ホップに中間システムによって適用される必要があります。例として、最大の感度レベルがその最初の感度レベルよりも低いリンクを通過するための、より高い感度レベル（「最も秘密」など）の高いパケットのデフォルトのMLS MACポリシーの違反です（例： "secret""）。
If an unlabeled packet is received from a node that does not support CALIPSO Sensitivity Labels (i.e., unable to assign Sensitivity Labels itself) and the packet is destined for a node that supports CALIPSO Sensitivity Labels, then the receiving intermediate system needs to insert a Sensitivity Label. This Sensitivity Label MUST be equal to the maximum Sensitivity Label assigned to the originating node if and only if that is known to the receiving node. If this receiving Intermediate System does not know which Sensitivity Label is assigned to the originating node, then the maximum Sensitivity Label of the interface that received the unlabeled packet MUST be inserted.
Calipso感度ラベルをサポートしないノード（つまり、感度ラベル自体を割り当てることができない）からのノードから、パケットがCalipso感受性ラベルをサポートするノード用に運命づけられている場合、受信中間システムは感度を挿入する必要があります。ラベル。この感度ラベルは、受信ノードに知られている場合にのみ、発信ノードに割り当てられた最大感度ラベルに等しくなければなりません。この受信中間システムでは、どの感度ラベルが発信元ノードに割り当てられているかがわからない場合、無効なパケットを受け取ったインターフェイスの最大感度ラベルを挿入する必要があります。
NOTE WELL: The procedure in the preceding paragraph is NOT a label upgrade -- because it is not changing an existing label; instead, it is simply inserting a Sensitivity Label that has the only "safe" value, given that no other information is known to the receiving node. In large-scale deployments, it is very unlikely that a given node will have any authoritative a priori information about the security configuration of any node that is NOT on a directly attached link.
よく注意：前の段落の手順は、既存のラベルを変更していないため、ラベルのアップグレードではありません。代わりに、受信ノードに他の情報が知られていないことを考えると、唯一の「安全な」値を持つ感度ラベルを挿入するだけです。大規模な展開では、特定のノードが、直接添付されていないリンクにないノードのセキュリティ構成に関する信頼できるアプリオリ情報を持つ可能性は非常に低いです。
If a packet is to be sent to a node that is defined to not be Sensitivity Label aware, from a node that is label aware, then the Sensitivity Label MAY be removed upon transmission if and only if local security policy explicitly permits this. The originating node is still responsible for ensuring that the Sensitivity Label on the packet falls within the Sensitivity Label range associated with the receiving node. If the packet will traverse more than one subnetwork between origin and destination, and those subnetworks are labeled, then the packet SHOULD normally contain a Sensitivity Label so that the packet will be able to reach the destination and the Intermediate Systems will be able to apply the requisite MAC policy to the packet.
ラベル認識のノードから、感度ラベルが認識しないと定義されているノードにパケットを送信する場合、現地のセキュリティポリシーがこれを明示的に許可している場合にのみ、伝送時に感度ラベルを削除することができます。発信元のノードは、パケットの感度ラベルが受信ノードに関連付けられた感度ラベル範囲内にあることを保証する責任があります。パケットが原点と宛先の間で複数のサブネットワークを通過し、それらのサブネットワークにラベルが付けられている場合、パケットには通常、パケットが宛先に到達できるように感度ラベルを含み、中間システムが適用できるようにする必要があります。パケットに必要なMacポリシー。
NOTE WELL: In some IPv4 MLS network deployments that exist as of the publication date, if a first-hop router receives an unlabeled IPv4 packet, the router inserts an appropriate Sensitivity Label into that IPv4 packet, in the manner described above. So sending a packet without a label across a multiple subnetwork path to a destination does not guarantee that the packet will arrive containing no Sensitivity Label.
注意事項：公開日時点で存在する一部のIPv4 MLSネットワーク展開では、最初のホップルーターがラベルのないIPv4パケットを受信した場合、ルーターは上記の方法でそのIPv4パケットに適切な感度ラベルを挿入します。したがって、宛先への複数のサブネットワークパスにラベルなしでパケットを送信しても、パケットが感度ラベルが含まれていないことを保証しません。
This section describes the format of the CALIPSO option for use with IPv6 datagrams. CALIPSO is an IPv6 Hop-By-Hop Option, rather than an IPv6 Destination Option, to ensure that a security gateway or router can apply access controls to IPv6 packets based on the CALIPSO label carried by the packet.
このセクションでは、IPv6データグラムで使用するためのCalipsoオプションの形式について説明します。Calipsoは、IPv6宛先オプションではなく、IPv6ホップバイホップオプションです。これは、セキュリティゲートウェイまたはルーターがパケットによって運ばれるCalipsoラベルに基づいてIPv6パケットにアクセスコントロールを適用できるようにすることです。
An IPv6 datagram that has not been tunneled contains at most one CALIPSO label. In the special case where (1) a labeled IPv6 datagram is tunneled inside another labeled IPv6 datagram AND (2) IP Security is NOT providing confidentiality protection for the inner packet, the outer CALIPSO Sensitivity Label must have the same meaning as the inner CALIPSO Sensitivity Label. For example, it would be invalid to encapsulate an unencrypted IPv6 packet with a Sensitivity Label of (SECRET, no compartments) inside a packet with an outer Sensitivity Label of (UNCLASSIFIED).
トンネルにされていないIPv6データグラムには、最大1つのCalipsoラベルが含まれています。（1）ラベル付きIPv6データグラムが別のラベルのIPv6データグラム内でトンネル化されている特別なケースでは、（2）IPセキュリティが内部パケットの機密保護を提供していない場合、外部カリプソ感度ラベルは内部カリプソ感度と同じ意味を持つ必要があります。ラベル。たとえば、パケット内の（秘密、コンパートメントなし）の感度ラベルを持つ、暗号化されていないIPv6パケットをパケット内に（非分類）の感度ラベルを持つ非暗号化されたIPv6パケットをカプセル化することは無効です。
If the inner IPv6 packet is tunneled inside the Encapsulating Security Payload (ESP) and confidentiality is being provided to that inner packet, then the outer packet MAY have a different CALIPSO Sensitivity Label -- subject to local security policy.
内側のIPv6パケットがカプセル化セキュリティペイロード（ESP）内でトンネル化され、その内部パケットに機密性が提供されている場合、外側のパケットには異なるCalipso感度ラベルがある場合があります。
As a general principle, the meaning of the Sensitivity Labels must be identical when one has a labeled cleartext IP packet that has been encapsulated (tunneled) inside another labeled IP packet. This is true whether one has IPv6 tunneled in IPv6, IPv4 tunneled in IPv6, or IPv6 tunneled in IPv4. This is essential to maintaining proper Mandatory Access Controls.
一般的な原則として、感度ラベルの意味は、別のラベル付きIPパケット内にカプセル化された（トンネリング）されたラベルのあるClearText IPパケットを持っている場合、同一でなければなりません。これは、IPv6、IPv6でIPv4でトンネル化されたIPv6、またはIPv4でトンネル化されたIPv6トンネルを備えているかどうかにかかわらず、これが当てはまります。これは、適切な必須アクセス制御を維持するために不可欠です。
This option's syntax has been designed with intermediate systems in mind. It is now common for an MLS network deployment to contain an Intermediate Systems acting as a guard (sometimes several acting as guards). Such a guard device needs to be able to very rapidly parse the Sensitivity Label in each packet, apply ingress interface MAC policy, forward the packet while aware of the packet's Sensitivity Label, and then apply egress interface MAC policy.
このオプションの構文は、中間システムを念頭に置いて設計されています。現在、MLSネットワークの展開がガードとして機能する中間システムを含むことが一般的です（時には警備員として機能することもあります）。このようなガードデバイスは、各パケットの感度ラベルを非常に迅速に解析し、Ingress Interface Macポリシーを適用し、パケットの感度ラベルを認識しながらパケットを転送し、Eugress Interface Macポリシーを適用できる必要があります。
At least one prior IP Sensitivity Label option [FIPS-188] used a syntax that was unduly complex to parse in IP routers, hence that option never was implemented in an IP router. So there is a deliberate effort here to choose a streamlined option syntax that is easy to parse, encode, and implement in more general terms.
少なくとも1つの以前のIP感度ラベルオプション[FIPS-188]は、IPルーターを解析するために過度に複雑な構文を使用したため、そのオプションはIPルーターに実装されていませんでした。そのため、ここでは、より一般的な用語で解析、エンコード、および実装しやすい合理化されたオプション構文を選択するための意図的な努力があります。
The CALIPSO option is an IPv6 Hop-by-Hop Option and is designed to comply with IPv6 optional header rules. Following the nomenclature of Section 4.2 of RFC 2460, the Option Type field of this option must have 4n+2 alignment [RFC2460].
Calipsoオプションは、IPv6ホップバイホップオプションであり、IPv6オプションのヘッダールールに準拠するように設計されています。RFC 2460のセクション4.2の命名法に従って、このオプションのオプションタイプフィールドには4N 2アライメント[RFC2460]が必要です。
The CALIPSO Option Data MUST NOT change en route, except when (1) "DOI translation" is performed by a trusted Intermediate System, (2) a CALIPSO Option is inserted by a trusted Intermediate System upon receipt of an unlabeled IPv6 packet, or (3) a CALIPSO Option is removed by a last-hop trusted Intermediate System immediately prior to forwarding the packet to a destination node that does not implement support for CALIPSO labels. The details of these three exceptions are described elsewhere in this document.
（1）「DOI翻訳」が信頼できる中間システムによって実行される場合を除き、Calipsoオプションデータは途中で変更してはなりません。3）Calipsoオプションは、Calipsoラベルのサポートを実装していない宛先ノードにパケットを転送する直前に、最終ホップ信頼できる中間システムによって削除されます。これら3つの例外の詳細は、このドキュメントの他の場所で説明されています。
If the option type is not recognized by a node examining the packet, the option is ignored. However, all implementations of this specification MUST be able to recognize this option and therefore MUST NOT ignore this option if it is present in an IPv6 packet.
オプションタイプがパケットを調べるノードによって認識されない場合、オプションは無視されます。ただし、この仕様のすべての実装は、このオプションを認識できる必要があるため、IPv6パケットに存在する場合、このオプションを無視してはなりません。
This option is designed to comply with the IPv6 optional header rules [RFC2460]. The CALIPSO option is always carried in a Hop-By-Hop Option Header, never in any other part of an IPv6 packet. This rule exists because IPv6 routers need to be able to see the CALIPSO label so that those routers are able to apply MLS Mandatory Access Controls to those packets.
このオプションは、IPv6オプションのヘッダールール[RFC2460]に準拠するように設計されています。Calipsoオプションは常にホップバイホップオプションヘッダーに携帯されており、IPv6パケットの他の部分ではありません。このルールは、IPv6ルーターがCalipsoラベルを確認できるため、それらのルーターがMLSの必須アクセスコントロールをそれらのパケットに適用できるためです。
The diagram below shows the CALIPSO option along with the required (first) two fields of the Hop-By-Hop Option Header that envelops the CALIPSO option. The design of the CALIPSO option is arranged to avoid the need for 16 bits of padding between the HDR EXT LEN field and the start of the CALIPSO option. Also, the CALIPSO Domain of Interpretation field is laid out so that it normally will be 32-bit aligned.
以下の図は、Calipsoオプションを包み込むホップバイホップオプションヘッダーの必要な（最初の）2つのフィールドとともに、Calipsoオプションを示しています。Calipsoオプションの設計は、HDR ext LenフィールドとCalipsoオプションの開始の間に16ビットのパディングが必要になるように配置されています。また、解釈フィールドのCalipsoドメインはレイアウトされているため、通常は32ビットに整列されます。
------------------------------------------------------------
| Next Header | Hdr Ext Len | Option Type | Option Length|
+-------------+---------------+-------------+--------------+
| CALIPSO Domain of Interpretation |
+-------------+---------------+-------------+--------------+
| Cmpt Length | Sens Level | Checksum (CRC-16) |
+-------------+---------------+-------------+--------------+
| Compartment Bitmap (Optional; variable length) |
+-------------+---------------+-------------+--------------+
This field contains an unsigned 8-bit value. Its value is 00000111 (binary).
このフィールドには、署名されていない8ビット値が含まれています。その値は00000111（バイナリ）です。
Nodes that do not recognize this option should ignore it. In many cases, not all routers in a given MLS deployment will contain support for this CALIPSO option. For interoperability reasons, it is important that routers that do not support the CALIPSO forward this packet normally, even though those routers do not recognize the CALIPSO option.
このオプションを認識していないノードは、それを無視する必要があります。多くの場合、特定のMLS展開のすべてのルーターにこのCalipsoオプションのサポートが含まれているわけではありません。相互運用性の理由から、これらのルーターがCalipsoオプションを認識していない場合でも、このパケットを正常にカリプソを前方にサポートしていないルーターが通常重要です。
In the event the IPv6 packet is fragmented, this option MUST be copied on fragmentation. Virtually all users want the choice of using the IP Authentication Header (a) to authenticate this option and (b) to bind this option to the associated IPv6 packet.
IPv6パケットが断片化されている場合、このオプションはフラグメンテーションでコピーする必要があります。実質的にすべてのユーザーは、IP認証ヘッダーを使用して（a）このオプションを認証し、（b）このオプションを関連するIPv6パケットにバインドする選択を選択しています。
This field contains an unsigned integer one octet in size. Its minimum value is eight (e.g., when the Compartment Bitmap field is absent). This field specifies the Length of the option data field of this option in octets. The Option Type and Option Length fields are not included in the length calculation.
このフィールドには、サイズが署名されていない整数1オクテットが含まれています。その最小値は8です（たとえば、コンパートメントビットマップフィールドがない場合）。このフィールドは、オクテットのこのオプションのオプションデータフィールドの長さを指定します。オプションのタイプとオプションの長さフィールドは、長さの計算に含まれていません。
This field contains an unsigned 8-bit integer. The field specifies the size of the Compartment Bitmap field in 32-bit words. The minimum value is zero, which is used only when the information in this packet is not in any compartment. (In that situation, the CALIPSO Sensitivity Label has no need for a Compartment Bitmap). Note that measuring the Compartment Bitmap field length in 32-bit words permits the header to be 64-bit aligned, following IPv6 guidelines, without wasting 32 bits. Using 64-bit words for the size of the Compartment Bitmap field length would force 32 bits of padding with every option in order to maintain 64-bit alignment; wasting those bits in every CALIPSO option is undesirable.
このフィールドには、署名されていない8ビット整数が含まれています。フィールドは、32ビット単語でコンパートメントビットマップフィールドのサイズを指定します。最小値はゼロです。これは、このパケットの情報がどのコンパートメントにない場合にのみ使用されます。（そのような状況では、Calipso感度ラベルにはコンパートメントビットマップが必要ありません）。コンパートメントビットマップフィールドの長さを32ビット単語で測定すると、32ビットを無駄にすることなく、IPv6ガイドラインに従って、ヘッダーを64ビットアライメントできることに注意してください。コンパートメントのサイズに64ビット語を使用すると、ビットマップフィールドの長さは、64ビットのアライメントを維持するために、すべてのオプションで32ビットのパディングを強制します。すべてのCalipsoオプションでこれらのビットを無駄にすることは望ましくありません。
Because this specification represents Releasabilities on the wire as inverted Compartments, the size of the Compartment Bitmap field needs to be large enough to hold not only the set of logical Compartments, but instead to hold both the set of logical Compartments and the set of logical Releasabilities.
この仕様は反転コンパートメントとしてのワイヤの放出を表すため、コンパートメントビットマップフィールドのサイズは、論理コンパートメントのセットだけでなく、論理コンパートメントのセットと論理解放のセットの両方を保持するのに十分な大きさである必要があります。
Recall that the overall length of this option MUST follow IPv6 optional header rules, including the word alignment rules. This has implications for the valid values for this field. In some cases, the length of the Compartment Bitmap field might need to exceed the number of bits required to hold the sum of the logical Compartments and the logical Releasabilities, in order to comply with IPv6 alignment rules.
このオプションの全長は、単語アラインメントルールを含むIPv6オプションのヘッダールールに従う必要があることを思い出してください。これは、このフィールドの有効な値に影響を与えます。場合によっては、IPv6アライメントルールに準拠するために、コンパートメントビットマップフィールドの長さは、論理コンパートメントと論理解放性の合計を保持するために必要なビットの数を超える必要がある場合があります。
This field contains an unsigned 32-bit integer. IANA maintains a registry with assignments of the DOI values used in this field. The DOI identifies the rules under which this datagram must be handled and protected. The NULL DOI, in which this field is all zeros, MUST NOT appear in any IPv6 packet on any network.
このフィールドには、署名されていない32ビット整数が含まれています。IANAは、このフィールドで使用されているDOI値の割り当てを備えたレジストリを維持しています。doiは、このデータグラムを処理して保護する必要があるルールを特定します。このフィールドがすべてゼロであるnull doiは、どのネットワーク上のIPv6パケットに表示されてはなりません。
NOTE WELL: The Domain Of Interpretation value where all 4 octets contain zero is defined to be the NULL DOI. The NULL DOI has no compartments and has a single level whose value and CALIPSO representation are each zero. The NULL DOI MUST NOT ever appear on the wire. If a packet is received containing the NULL DOI, that packet MUST be dropped and the event SHOULD be logged as a security fault.
よく注意：4オクテットがすべてゼロを含む解釈値のドメインは、null doiであると定義されています。null doiにはコンパートメントがなく、値とカリプソ表現がそれぞれゼロである単一のレベルがあります。null doiは、ワイヤーに表示されてはいけません。null doiを含むパケットを受信した場合、そのパケットはドロップし、イベントをセキュリティ障害として記録する必要があります。
This contains an unsigned 8-bit value. This field contains an opaque octet whose value indicates the relative sensitivity of the data contained in this datagram in the context of the indicated DOI. The values of this field MUST be ordered, with 00000000 being the lowest Sensitivity Level and 11111111 being the highest Sensitivity Level.
これには、署名されていない8ビット値が含まれています。このフィールドには、示されたDOIのコンテキストで、このデータグラムに含まれるデータの相対的な感度を示す値が不透明なオクテットを含んでいます。このフィールドの値は、00000000が最低の感度レベルであり、11111111が最も高い感度レベルであるため、注文する必要があります。
However, in a typical deployment, not all 256 Sensitivity Levels will be in use. So the set of valid Sensitivity Level values depends upon the CALIPSO DOI in use. This sensitivity ordering rule is necessary so that Intermediate Systems (e.g., routers or MLS guards) will be able to apply MAC policy with minimal per-packet computation and minimal configuration.
ただし、典型的な展開では、すべての256の感度レベルが使用されるわけではありません。したがって、有効な感度レベル値のセットは、使用中のCalipso DOIに依存します。中間システム（ルーターやMLSガードなど）が最小限のパケットあたりの計算と最小設定でMACポリシーを適用できるように、この感度順序付けルールが必要です。
This 16-bit field contains the a CRC-16 checksum as defined in Appendix C of RFC 1662 [RFC1662]. The checksum is calculated over the entire CALIPSO option in this packet, including option header, zeroed-out checksum field, option contents, and any required padding zero bits.
この16ビットフィールドには、RFC 1662 [RFC1662]の付録Cで定義されているA CRC-16チェックサムが含まれています。チェックサムは、オプションヘッダー、ゼロアウトチェックサムフィールド、オプションコンテンツ、および必要なパディングゼロビットなど、このパケットのCalipsoオプション全体にわたって計算されます。
The checksum MUST always be computed on transmission and MUST always be verified on reception. This checksum only provides protection against accidental corruption of the CALIPSO option in cases where neither the underlying medium nor other mechanisms, such as the IP Authentication Header (AH), are available to protect the integrity of this option.
チェックサムは常に送信時に計算する必要があり、常に受信時に検証する必要があります。このチェックサムは、このオプションの完全性を保護するために、IP認証ヘッダー（AH）などの基礎となるメカニズムも他のメカニズムもない場合、Calipsoオプションの偶発的な破損に対する保護のみを提供します。
Note that the checksum field is always required, even when other integrity protection mechanisms (e.g., AH) are used. This method is chosen for its reliability and simplicity in both hardware and software implementations, and because many implementations already support this checksum due to its existing use in various IETF specifications.
他の整合性保護メカニズム（AHなど）が使用されている場合でも、チェックサムフィールドが常に必要であることに注意してください。この方法は、ハードウェアとソフトウェアの両方の実装における信頼性とシンプルさのために選択され、多くの実装は、さまざまなIETF仕様での既存の使用により、このチェックサムをすでにサポートしているためです。
This contains a variable number of 64-bit words. Each bit represents one compartment within the DOI. Each "1" bit within an octet in the Compartment Bitmap field represents a separate compartment under whose rules the data in this packet must be protected. Hence, each "0" bit indicates that the compartment corresponding with that bit is not applicable to the data in this packet. The assignment of identity to individual bits within a Compartment Bitmap for a given DOI is left to the owner of that DOI.
これには、64ビット単語の可変数が含まれています。各ビットは、doi内の1つのコンパートメントを表します。コンパートメントビットマップフィールドのオクテット内の各「1」ビットは、このパケットのデータを保護する必要がある別のコンパートメントを表します。したがって、各「0」ビットは、そのビットに対応するコンパートメントがこのパケットのデータに適用できないことを示します。特定のdoiのコンパートメントビットマップ内の個々のビットへのアイデンティティの割り当ては、そのdoiの所有者に任されています。
This specification represents a Releasability on the wire as if it were an inverted Compartment. So the Compartment Bitmap holds the sum of both logical Releasabilities and also logical Compartments for a given DOI value. The encoding of the Releasabilities in this field is described elsewhere in this document. The Releasability encoding is designed to permit the Compartment Bitmap evaluation to occur without the evaluator necessarily knowing the human semantic associated with each bit in the Compartment Bitmap. In turn, this facilitates the implementation and configuration of Mandatory Access Controls based on the Compartment Bitmap within IPv6 routers or guard devices.
この仕様は、まるで倒立コンパートメントであるかのように、ワイヤーの解放可能性を表しています。したがって、コンパートメントビットマップは、特定のDOI値の論理解放性と論理コンパートメントの両方の合計を保持します。この分野の解放性のエンコードについては、このドキュメントの他の場所で説明しています。リリース性エンコーディングは、コンパートメントビットマップ内の各ビットに関連する人間のセマンティックを必ずしも把握せずにコンパートメントビットマップ評価を可能にするように設計されています。次に、IPv6ルーターまたはガードデバイス内のコンパートメントビットマップに基づいて、必須アクセス制御の実装と構成を容易にします。
The basic option is variable length, due to the variable length Compartment Bitmap field.
基本的なオプションは、可変長さのコンパートメントビットマップフィールドのため、可変長です。
Intermediate Systems that lack custom silicon processing capabilities and most End Systems perform best when processing fixed-length, fixed-location items. So the IPv6 base specification levies certain requirements on all IPv6 optional headers.
カスタムシリコン処理機能とほとんどのエンドシステムが、固定長の固定ロケーションアイテムを処理するときに最適に機能する中間システム。したがって、IPv6ベース仕様は、すべてのIPv6オプションヘッダーの特定の要件を課します。
The CALIPSO option must maintain this IPv6 64-bit alignment rule for the option overall. Please note that the Compartment Bitmap field has a length in quanta of 32-bit words (e.g., 0 bits, 32 bits, 64 bits, 96 bits), which permits the overall CALIPSO option length to be 64-bit aligned -- without requiring 32 bits of NULL padding with every CALIPSO option.
CALIPSOオプションは、オプション全体のこのIPv6 64ビットアライメントルールを維持する必要があります。コンパートメントビットマップフィールドは、32ビット単語（例：ビット、32ビット、64ビット、96ビットなど）の量子の長さを持っていることに注意してください。すべてのカリプソオプションを使用した32ビットのヌルパディング。
This section describes specific protocol processing steps required for systems that claim to implement or conform with this specification.
このセクションでは、この仕様に実装または準拠すると主張するシステムに必要な特定のプロトコル処理手順について説明します。
This section describes how comparisons are made between two Sensitivity Labels. Implementing this comparison correctly is critical to the MLS system providing the intended Mandatory Access Controls (MACs) to network traffic entering or leaving the system.
このセクションでは、2つの感度ラベル間で比較が行われる方法について説明します。この比較を正しく実装することは、MLSシステムにとって重要であり、システムに入力または去るネットワークトラフィックに、意図した必須アクセス制御（MAC）を提供します。
A Sensitivity Label consists of a DOI, a Sensitivity Level, and zero or more Compartments. The following notation will be used:
感度ラベルは、DOI、感度レベル、およびゼロ以上のコンパートメントで構成されています。次の表記が使用されます。
A.DOI = the DOI portion of Sensitivity Label A A.LEV = the Sensitivity Level portion of Sensitivity Label A A.COMP = the Compartments portion of Sensitivity Label A
a.doi =感度ラベルのDOI部分a.lev =感度ラベルの感度レベル部分a.comp =感度ラベルのコンパートメント部分a
A Sensitivity Label "M" is "within range" for a particular range "LO:HI" if and only if:
特定の範囲「lo：hi」の感度ラベル「m」は「範囲内」です。
1. M, LO, and HI are members of the same DOI.
1. m、lo、hiは同じdoiのメンバーです。
(M.DOI == LO.DOI == HI.DOI)
2. The range is a valid range. A given range LO:HI is valid if and only if HI dominates LO.
2. 範囲は有効な範囲です。与えられた範囲LO：HIは、HIがLOを支配している場合にのみ有効です。
((LO.LEV <= HI.LEV) && (LO.COMP <= HI.COMP))
3. The Sensitivity Level of M dominates the low-end (LO) Sensitivity Level AND the Sensitivity Level of M is dominated by the high-end (HI) Sensitivity Level.
3. Mの感度レベルはローエンド（LO）感度レベルを支配し、Mの感度レベルはハイエンド（HI）感度レベルによって支配されます。
(LO.LEV <= M.LEV <= HI.LEV)
AND
と
4. The Sensitivity Label M has a Compartment Set that dominates the Compartment Set contained in the Sensitivity Label from the low-end range (LO), and that is dominated by the Compartment Set contained in the high-end Sensitivity Label (HI) from the range.
4. 感度ラベルMには、ローエンド範囲（LO）の感度ラベルに含まれるコンパートメントセットを支配するコンパートメントセットがあり、それは範囲のハイエンド感度ラベル（HI）に含まれるコンパートメントセットが支配しています。。
(LO.COMP <= M.COMP <= HI.COMP)
A Sensitivity Label "M" is "less than" some other Sensitivity Label "LO" if and only if:
感度ラベル「M」は、「他の感度ラベル「LO」よりも「少ない」の場合のみです。
1. The DOI for the Sensitivity Label M is identical to the DOI for both the low-end and high-end of the range.
1. 感度ラベルMのDOIは、範囲のローエンドとハイエンドの両方のDOIと同じです。
(M.DOI == LO.DOI == HI.DOI)
AND EITHER
そしてどちらか
2. The Sensitivity Level of M is less than the Sensitivity Level of LO.
2. mの感度レベルは、LOの感度レベルよりも少ない。
(M.LEV < LO.LEV)
（m.lev <lo.lev）
OR
また
3. The Compartment Set of Sensitivity Label M is dominated by the Compartment Set of Sensitivity Label LO.
3. 感度ラベルMのコンパートメントセットは、感度ラベルLOのコンパートメントセットによって支配されています。
(M.COMP <= LO.COMP)
（m.comp <= lo.comp）
A Sensitivity Label "M" is "below range" for a Sensitivity Label "LO:HI", if LO dominates M and LO is not equal to M.
感度ラベル「M」は、感度ラベル「LO：HI」の感度ラベル「M」は「範囲以下」です。LOがMを支配し、LOがMに等しくない場合
A Sensitivity Label "M" is "greater than" some Sensitivity Label "HI" if and only if:
感度ラベル「M」は「感度ラベル「こんにちは」よりも大きい。
1. Their DOI's are identical.
1. 彼らのdoiは同一です。
(M.DOI == HI.DOI)
（m.doi == hi.doi）
AND EITHER
そしてどちらか
2A. M's Sensitivity Level is above HI's Sensitivity Level.
2a。Mの感度レベルは、HIの感度レベルを超えています。
(M.LEV > HI.LEV)
（m.lev> hi.lev）
OR
また
2B. M's Compartment Set is greater than HI's Compartment Set.
2b。Mのコンパートメントセットは、HIのコンパートメントセットよりも大きいです。
(M.COMP > HI.COMP)
（m.comp> hi.comp）
A Sensitivity Label "M" is "above range" for a Sensitivity Label, "LO:HI", if M dominates HI and M is not equal to HI.
感度ラベル「M」は、感度ラベル「LO：HI」の感度ラベル「M」は「範囲上」です。MがHIを支配し、MがHIに等しくない場合。
A Sensitivity Label "A" is "equal to" another Sensitivity Label "B" if and only if:
感度ラベル「A」は、「別の感度ラベル「B」に等しい」の場合のみです。
1. They have the exact same DOI.
1. 彼らはまったく同じdoiを持っています。
(A.DOI == B.DOI)
（a.doi == b.doi）
2. They have identical Sensitivity Levels.
2. 彼らは同一の感度レベルを持っています。
(A.LEV == B.LEV)
（a.lev == b.lev）
3. Their Compartment Sets are identical.
3. それらのコンパートメントセットは同一です。
(A.COMP == B.COMP)
（a.comp == b.comp）
A Sensitivity Label "A" is disjoint from another Sensitivity Label "B" if any of these conditions are true:
これらの条件のいずれかが真である場合、感度ラベル「A」は別の感度ラベル「B」からばらばらです。
1. Their DOI's differ.
1. 彼らのdoiは異なります。
(A.DOI <> B.DOI)
（a.doi <> b.doi）
2. B does not dominate A, A does not dominate B, and A is not equal to B.
2. bはaを支配せず、aはbを支配せず、aはBに等しくありません。
(^( (A < B) || (A > B) || (A == B) ))
3. Their Compartment Sets are disjoint from each other; A's Compartment Set does not dominate B's Compartment Set AND B's Compartment Set does not dominate A's Compartment Set.
3. 彼らのコンパートメントセットは互いに矛盾しています。AのコンパートメントセットはBのコンパートメントセットを支配せず、BのコンパートメントセットはAのコンパートメントセットを支配しません。
(^( (A.COMP >= B.COMP) || (A.COMP <= B.COMP) ))
This section describes CALIPSO-related processing for IPv6 packets imported or exported from an End System claiming to implement or conform with this specification. This document places no additional requirements on IPv6 nodes that do not claim to implement or conform with this document.
このセクションでは、この仕様に実装または準拠すると主張するエンドシステムからインポートまたはエクスポートされたIPv6パケットのCalipso関連処理について説明します。このドキュメントは、このドキュメントに実装または準拠すると主張していないIPv6ノードに追加要件を掲載していません。
An End System that 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 following ordered steps must occur:
データをネットワークに送信するエンドシステムは、ネットワークに「エクスポート」すると言われています。データグラムがエンドシステムを離れてネットワーク上に送信できるようにする前に、次の順序付けられた手順が発生する必要があります。
1. Selection of the export DOI:
1. 輸出doiの選択：
a) If the upper-level protocol selects a DOI, then that DOI is selected.
a) 上位レベルのプロトコルがDOIを選択すると、そのdoiが選択されます。
b) Else, if there are tables defining a specific default DOI for the specific destination End System address or for the network address, then that DOI is selected.
b) それ以外の場合、特定の宛先エンドシステムアドレスまたはネットワークアドレスの特定のデフォルトのDOIを定義するテーブルがある場合、そのdoiが選択されます。
c) Else, if there is a specific DOI associated with the sending logical interface (i.e., IP address), then that DOI is selected.
c) それ以外の場合、送信論理インターフェイス（つまり、IPアドレス）に関連付けられた特定のDOIがある場合、そのdoiが選択されます。
d) Else the default DOI for the system is selected.
d) それ以外の場合、システムのデフォルトのdoiが選択されます。
NOTE WELL: A connection-oriented transport-layer protocol session (e.g., Transmission Control Protocol (TCP) session, Stream Control Transmission Protocol (SCTP) session) MUST have the same DOI and same Sensitivity Label for the life of that connection. The DOI is selected at connection initiation and MUST NOT change during the session.
注意事項：接続指向の輸送層プロトコルセッション（たとえば、トランスミッションコントロールプロトコル（TCP）セッション、ストリーム制御伝送プロトコル（SCTP）セッション）には、その接続の寿命に合わせて同じDOIと同じ感度ラベルが必要です。DOIは接続開始時に選択され、セッション中に変更してはなりません。
A trusted multi-level application that possesses appropriate privilege MAY use multiple connection-oriented transport-layer protocol sessions with differing Sensitivity Labels concurrently.
適切な特権を持つ信頼できるマルチレベルアプリケーションは、複数の接続指向のトランスポートレイヤープロトコルセッションを使用して、同時に異なる感度ラベルを備えています。
Some trusted UDP-based applications (e.g., remote procedure call service) multiplex different transactions having different Sensitivity Levels in different packets for the same IP session (e.g., IP addresses and UDP ports are constant for a given UDP session). In such cases, the Trusted Computing Base MUST ensure that each packet is labeled with the correct Sensitivity Label for the information carried in that particular packet.
一部の信頼できるUDPベースのアプリケーション（リモートプロシージャコールサービスなど）多重は、同じIPセッションの異なるパケットに異なる感度レベルを持つ異なるトランザクション（例：IPアドレスとUDPポートは、特定のUDPセッションで一定です）。このような場合、信頼できるコンピューティングベースは、その特定のパケットに掲載された情報の正しい感度ラベルで各パケットがラベル付けされることを確認する必要があります。
In the event the End System selects and uses a specific DOI and that DOI is not recognized by the originating node's first-hop router, the packet MUST be dropped by the first-hop router. In such a case, the networking API should indicate the connection failure (e.g., with some appropriate error, such as ENOTREACH). This fault represents (1) incorrect configuration of either the Intermediate System or of the End System or (2) correct operation for a node that is not permitted to send IPv6 packets with that DOI through that Intermediate System.
エンドシステムが特定のDOIを選択および使用し、そのdoiが発信するノードの最初のホップルーターによって認識されない場合、パケットは最初のホップルーターによってドロップする必要があります。そのような場合、ネットワークAPIは接続の障害を示している必要があります（例えば、EnotReachなどの適切なエラーを使用）。この障害は、（1）中間システムまたはエンドシステムのいずれかの誤った構成、または（2）その中間システムを介してIPv6パケットをそのdoiで送信することは許可されていないノードの正しい動作を表します。
When an MLS End System is connected to an MLS LAN, it is possible that there would be more than one first-hop Intermediate System concurrently, with different Intermediate Systems having different valid Sensitivity Label ranges. Thoughtful use of the IEEE 802 Virtual LAN (VLAN) standard (e.g., with different VLAN IDs corresponding to different sensitivity ranges) might ease proper system configuration in such deployments.
MLSエンドシステムがMLS LANに接続されている場合、異なる中間システムが異なる有効な感度ラベル範囲を持つ異なる中間システムと同時に複数の最初のホップ中間システムがある可能性があります。IEEE 802仮想LAN（VLAN）標準の思慮深い使用（たとえば、異なる感度範囲に対応する異なるVLAN IDを使用）は、そのような展開における適切なシステム構成を緩和する可能性があります。
2. Export Labeling:
2. エクスポートラベル：
Once the DOI is selected, the CALIPSO Sensitivity Label and values are determined based on the internal Sensitivity Label and the DOI. In the event the internal Sensitivity Level does not map to a valid CALIPSO Sensitivity Label, then an error SHOULD be returned to the upper-level protocol and that error MAY be logged. No further attempt to send this datagram should be made.
DOIが選択されると、Calipso感度ラベルと値は、内部感度ラベルとDOIに基づいて決定されます。内部感度レベルが有効なCalipso感度ラベルにマッピングされない場合、エラーを上位レベルのプロトコルに返す必要があり、そのエラーが記録される場合があります。このデータグラムを送信する試みはこれ以上行わないでください。
3. Access Control:
3. アクセス制御：
Once the datagram is marked and the sending logical interface is selected (by the routing code), the datagram's Sensitivity Label is compared against the Sensitivity Label range(s) associated with that logical interface. For the datagram to be sent, the interface MUST list the DOI of the datagram Sensitivity Label as one of the permissible DOI's and the datagram Sensitivity Label must be within range for the range associated with that DOI. If the datagram fails this access test, then an error SHOULD be returned to the upper-level protocol and MAY be logged. No further attempt to send this datagram should be made.
データグラムがマークされ、送信論理インターフェイスが（ルーティングコードによって）選択されると、データグラムの感度ラベルは、その論理インターフェイスに関連付けられた感度ラベル範囲と比較されます。データグラムを送信するには、インターフェイスが許容されるDOIの1つとしてデータグラムの感度ラベルのDOIをリストする必要があり、データグラムの感度ラベルは、そのDOIに関連する範囲の範囲内でなければなりません。データグラムがこのアクセステストに失敗した場合、エラーを上位レベルのプロトコルに戻し、ログに記録する必要があります。このデータグラムを送信する試みはこれ以上行わないでください。
When a datagram arrives at an interface on an End System, the receiving End System MUST:
データグラムがエンドシステム上のインターフェイスに到着すると、受信エンドシステムは以下が必要です。
1. Verify the CALIPSO checksum. Datagrams with invalid checksums MUST be silently dropped. Such a drop event SHOULD be logged as a security fault with an indication of what happened.
1. Calipsoチェックサムを確認します。無効なチェックサムを持つデータグラムは静かに削除する必要があります。このようなドロップイベントは、何が起こったのかを示すセキュリティ障害として記録する必要があります。
2. Verify the CALIPSO has a known and valid DOI. Datagrams with unrecognized or illegal DOIs MUST be silently dropped. Such an event SHOULD be logged as a security fault with an indication of what happened.
2. Calipsoには既知の有効なdoiがあることを確認します。認識されていないまたは違法なDOIを備えたデータグラムは、静かに削除する必要があります。このようなイベントは、何が起こったのかを示すセキュリティ障害として記録する必要があります。
3. Verify the DOI is a permitted one for the receiving interface. Datagrams with prohibited DOI values MUST be silently dropped. Such an event SHOULD be logged as a security fault with an indication of what happened.
3. DOIが受信インターフェイスに許可されたものであることを確認します。禁止されているDOI値を持つデータグラムは静かに削除する必要があります。このようなイベントは、何が起こったのかを示すセキュリティ障害として記録する必要があります。
4. Verify the CALIPSO Sensitivity Label is within the permitted range for the receiving interface:
4. Calipso感度ラベルが受信インターフェイスの許可された範囲内であることを確認してください。
NOTE WELL: EACH permitted DOI on an interface has a separate table describing the permitted range for that DOI.
よく注意：インターフェイス上の許可されている各doiには、そのdoiの許可された範囲を説明する別のテーブルがあります。
A datagram with a Sensitivity Label within the permitted range is accepted for further processing.
許可された範囲内に感度ラベルを持つデータグラムは、さらなる処理のために受け入れられます。
A datagram with a Sensitivity Label disjoint with the permitted range MUST be silently dropped. Such an event SHOULD be logged as a security fault, with an indication that the packet was dropped because of a disjoint Sensitivity Label. An ICMP error message MUST NOT be sent in this case.
許可された範囲との感度ラベルの分離を備えたデータグラムは、静かに削除する必要があります。このようなイベントは、セキュリティ障害として記録する必要があります。これは、バッキングの感度ラベルのためにパケットが削除されたことを示しています。この場合、ICMPエラーメッセージを送信しないでください。
A datagram with a Sensitivity Label below the permitted range MUST be dropped. This event SHOULD be logged as a security fault, with an indication that the packet was below range. An ICMP error message MUST NOT be sent in this case.
許可された範囲の下に感度ラベルを持つデータグラムを削除する必要があります。このイベントは、パケットが範囲を下回っていることを示すセキュリティ障害として記録する必要があります。この場合、ICMPエラーメッセージを送信しないでください。
A datagram with a Sensitivity Label above the permitted range MUST be dropped. This event SHOULD be logged as a security fault, with an indication that the packet was above range. An ICMP error message MUST NOT be sent in this case.
許可された範囲の上に感度ラベルを持つデータグラムを削除する必要があります。このイベントは、パケットが範囲を超えていることを示すセキュリティ障害として記録する必要があります。この場合、ICMPエラーメッセージを送信しないでください。
5. Once the datagram has been accepted, the receiving system MUST use the import Sensitivity Label and DOI to associate the appropriate internal Sensitivity Label with the data in the received datagram. This label information MUST be carried as part of the information returned to the upper-layer protocol.
5. データグラムが受け入れられたら、受信システムはインポート感度ラベルとDOIを使用して、適切な内部感度ラベルを受信したデータグラムのデータに関連付ける必要があります。このラベル情報は、上層層プロトコルに返される情報の一部として伝える必要があります。
This section describes CALIPSO-related processing for IPv6 packets transiting an IPv6 Intermediate System that claims to implement and comply with this specification. This document places no additional requirements on IPv6 Intermediate Systems that do not claim to comply or conform with this document.
このセクションでは、この仕様を実装および準拠すると主張するIPv6中間システムを通過するIPv6パケットのCalipso関連処理について説明します。このドキュメントは、このドキュメントに準拠または準拠していないと主張するIPv6中間システムに追加の要件を掲載していません。
The CALIPSO packet format has been designed so that one can configure an Intermediate System with the minimum sensitivity level, maximum Sensitivity Level, minimum compartment bitmap, and maximum compartment bitmap -- and then deploy that system without forcing the system to know the detailed human meaning of each Sensitivity Level or compartment bit value. Instead, once the minimum and maximum labels have been configured, the Intermediate System can apply a simple algorithm to determine whether or not a packet is within range for a given interface. This design should be straight-forward to implement in Application-Specific Integrated Circuit (ASIC) or Field Programmable Gate Array (FPGA) hardware, because the option format is simple and easy to parse, and because only a single comparison algorithm (defined in this RFC, hence known in advance) is needed.
Calipsoパケット形式は、最小感度レベル、最大感度レベル、最小コンパートメントビットマップ、最大コンパートメントビットマップで中間システムを構成できるように設計されており、システムに詳細な人間の意味を把握することなくシステムを展開することができます。各感度レベルまたはコンパートメントビット値の値。代わりに、最小ラベルと最大ラベルが構成されると、中間システムは単純なアルゴリズムを適用して、特定のインターフェイスのパケットが範囲内であるかどうかを判断できます。この設計は、アプリケーション固有の統合回路（ASIC）またはフィールドプログラム可能なゲートアレイ（FPGA）ハードウェアに実装するために簡単にする必要があります。したがって、RFCが事前に知られている）が必要です。
Intermediate Systems have slightly different rules for processing marked datagrams than do End Systems. Primarily, Intermediate Systems do not IMPORT or EXPORT transit datagrams, they just forward them. Also, in most deployments intermediate systems are used to provide Mandatory Access Controls to packets traversing more than one subnetwork.
中間システムには、マークされたデータグラムを処理するためのルールがわずかに異なるルールが終了システムとは異なります。主に、中間システムはTransitデータグラムをインポートまたはエクスポートするのではなく、転送するだけです。また、ほとんどの展開では、複数のサブネットワークを横断するパケットに必須のアクセス制御を提供するために中級システムが使用されます。
The following checks MUST occur before any other processing. Upon receiving a CALIPSO-labeled packet, an Intermediate System must:
次のチェックは、他の処理の前に発生する必要があります。カリプソで覆われたパケットを受信すると、中間システムは以下を行う必要があります。
1. Determine whether or not this datagram is destined for (addressed to) this Intermediate System. If so, then the Intermediate System becomes an End System for the purposes of receiving this particular datagram and the rules for IMPORTing described above are followed.
1. このデータグラムがこの中間システムに運命づけられているかどうかを判断します。もしそうなら、この特定のデータグラムを受信する目的で中間システムが最終システムになり、上記のインポートのルールに従います。
2. Verify the CALIPSO checksum. Datagrams with invalid checksums MUST be silently dropped. The drop event SHOULD be logged as a security fault with an indication of what happened and MAY additionally be logged as a network fault.
2. Calipsoチェックサムを確認します。無効なチェックサムを持つデータグラムは静かに削除する必要があります。ドロップイベントは、何が起こったのかを示すセキュリティ障害として記録する必要があり、さらにネットワーク障害として記録される可能性があります。
NOTE WELL: A checksum failure could indicate a general network problem (e.g., noise on a radio link) that is unrelated to the presence of a CALIPSO option, but it also could indicate an attempt by an adversary to tamper with the value of a CALIPSO label.
注意事項：チェックサムの障害は、カリプソオプションの存在とは関係のない一般的なネットワークの問題（ラジオリンクのノイズなど）を示している可能性がありますが、敵がカリプソの値を改ざんしようとする試みを示すこともできます。ラベル。
3. Verify the CALIPSO has a known and valid DOI. Datagrams with unrecognized or illegal DOIs MUST be silently dropped. Such an event SHOULD be logged as a security fault with an indication of what happened.
3. Calipsoには既知の有効なdoiがあることを確認します。認識されていないまたは違法なDOIを備えたデータグラムは、静かに削除する必要があります。このようなイベントは、何が起こったのかを示すセキュリティ障害として記録する必要があります。
4. Verify the DOI is a permitted one for the receiving interface. Datagrams with prohibited DOIs MUST be silently dropped. Such a drop SHOULD be logged as a security fault with an indication of what happened.
4. DOIが受信インターフェイスに許可されたものであることを確認します。禁止されているDOIを備えたデータグラムは静かにドロップする必要があります。このようなドロップは、何が起こったのかを示すセキュリティ障害として記録する必要があります。
5. Verify the Sensitivity Label within the CALIPSO is within the permitted range for the receiving interface:
5. Calipso内の感度ラベルが、受信インターフェイスの許可された範囲内にあることを確認してください。
NOTE WELL: Each permitted DOI on an interface has a separate table describing the permitted range for that DOI.
よく注意：インターフェイス上の許可されている各doiには、そのdoiの許可された範囲を説明する別のテーブルがあります。
A rejected datagram with a Sensitivity Label below or disjoint with the permitted range MUST be silently dropped. Such an event SHOULD be logged as a security fault with an indication of what happened. An ICMP error message MUST NOT be sent in this case.
以下の感度ラベルを備えた拒否されたデータグラムまたは許可された範囲との否定を静かに削除する必要があります。このようなイベントは、何が起こったのかを示すセキュリティ障害として記録する必要があります。この場合、ICMPエラーメッセージを送信しないでください。
A rejected datagram with a Sensitivity Label above the permitted range MUST be dropped. The drop event SHOULD be logged as a security fault with an indication of what happened. An ICMP error message MUST NOT be sent in this case.
許可された範囲の上に感度ラベルを持つ拒否されたデータグラムを削除する必要があります。ドロップイベントは、何が起こったのかを示すセキュリティ障害として記録する必要があります。この場合、ICMPエラーメッセージを送信しないでください。
If and only if all the above conditions are met is the datagram accepted by the IPv6 Intermediate System for further processing and forwarding.
上記のすべての条件が満たされている場合にのみ、さらに処理と転送のためにIPv6中間システムに受け入れられたデータグラムがあります。
At this point, the datagram is within the permitted range for the Intermediate System, so appropriate ICMP error messages MAY be created by the IP module back to the originating End System regarding the forwarding of the datagram. These ICMP messages MUST be created with the exact same Sensitivity Label as the datagram causing the error. Standard rules about generating ICMP error messages (e.g., never generate an ICMP error message in response to a received ICMP error message) continue to apply. Note that these locally generated ICMP messages must go through the same outbound checks (including MAC checks) as any other forwarded datagram as described in the following paragraphs.
この時点で、データグラムは中間システムの許可された範囲内にあるため、IPモジュールによって適切なICMPエラーメッセージが作成され、データグラムの転送に関して元のエンドシステムに戻ることができます。これらのICMPメッセージは、データグラムとまったく同じ感度ラベルを使用してエラーを引き起こす必要があります。ICMPエラーメッセージの生成に関する標準ルール（たとえば、受信したICMPエラーメッセージに応じてICMPエラーメッセージを生成しないでください）は引き続き適用されます。これらのローカルで生成されたICMPメッセージは、次の段落で説明されている他の転送データグラムと同じアウトバウンドチェック（Macチェックを含む）を通過する必要があることに注意してください。
It is at this point, after input processing and before output processing, that translation of the CALIPSO from one DOI to another DOI takes place in an Intermediate System, if at all. Section 6.4 describes the two possible approaches to translation.
この時点で、入力処理後、出力処理前に、あるdoiから別のdoiへのcalipsoの翻訳は、あったとしても中間システムで行われます。セクション6.4では、翻訳に対する2つの可能なアプローチについて説明します。
Once the forwarding code has selected the interface through which the datagram will be transmitted, the following takes place:
転送コードがデータグラムが送信されるインターフェイスを選択したら、次のことが行われます。
1. If the output interface requires that all packets contain a CALIPSO label, then verify that the packet contains a CALIPSO label.
1. 出力インターフェイスですべてのパケットがCalipsoラベルを含む必要がある場合、パケットにCalipsoラベルが含まれていることを確認します。
2. Verify the DOI is a permitted one for the sending interface and that the datagram is within the permitted range for the DOI and for the interface.
2. DOIは、送信インターフェイスに許可されたものであり、データグラムがDOIおよびインターフェイスの許可範囲内にあることを確認します。
3. Datagrams with prohibited DOIs or with out-of-range Sensitivity Labels MUST be dropped. Any drop event SHOULD be logged as a security fault, including appropriate details about which datagram was dropped and why.
3. 禁止されているDOIまたは範囲外の感度ラベルを備えたデータグラムを削除する必要があります。ドロップイベントは、どのデータグラムが削除されたか、理由についての適切な詳細を含む、セキュリティ障害として記録する必要があります。
4. Datagrams with prohibited DOIs or out-of-range Sensitivity Labels MAY result in an ICMP "Destination Unreachable" error message, depending upon the security configuration of the system.
4. 禁止されているDOIまたは範囲外の感度ラベルを持つデータグラムは、システムのセキュリティ構成に応じて、ICMPの「宛先の到達不可能な」エラーメッセージになる場合があります。
If the cause of the dropped packet is that the DOI is prohibited or unrecognized, then a reason code of "No Route to Host" is used. If the dropped packet's DOI is valid, but the Sensitivity Label is out of range, then a reason code of "Administratively Prohibited" is used. If an unlabeled packet has been dropped because the packet is required to be labeled, then a reason code of "Administratively Prohibited" is used.
ドロップされたパケットの原因がDOIが禁止または認識されていないことである場合、「ホストへのルートなし」の理由が使用されます。ドロップされたパケットのdoiが有効であるが、感度ラベルが範囲外である場合、「管理上禁止」の理由が使用されます。パケットにラベルを付ける必要があるために非標識パケットが削除された場合、「管理上禁止」の理由が使用されます。
In all cases, if an ICMP Error Message is sent, then it MUST be sent with the same Sensitivity Label as the rejected datagram.
すべての場合において、ICMPエラーメッセージが送信される場合、拒否されたデータグラムと同じ感度ラベルで送信する必要があります。
The choice of whether or not to send an ICMP message, if sending an ICMP message for this case is implemented, MUST be configurable, and SHOULD default to not sending an ICMP message. Standard conditions about generating ICMP error messages (e.g., never send an ICMP error message about a received ICMP error message) continue to apply.
このケースにICMPメッセージを送信する場合、ICMPメッセージを送信するかどうかの選択は、設定可能である必要があり、デフォルトでICMPメッセージを送信しないようにする必要があります。ICMPエラーメッセージの生成に関する標準条件（たとえば、受信したICMPエラーメッセージに関するICMPエラーメッセージを送信しないでください）は引き続き適用されます。
A system that provides on-the-fly relabeling is said to "translate" from one DOI to another. There are basically two ways a datagram can be relabeled:
オンザフライの再溶接を提供するシステムは、あるdoiから別のdoiに「翻訳」すると言われています。基本的に、データグラムを再評価することができる2つの方法があります。
Either the Sensitivity Label can be converted from a CALIPSO Sensitivity Label, to an internal Sensitivity Label, and then back to a new CALIPSO Sensitivity Label, exclusive-or a CALIPSO Sensitivity Label can be directly remapped into a new CALIPSO Sensitivity Label.
感度ラベルは、Calipso感度ラベルから内部感度ラベルに変換でき、次に新しいCalipso感度ラベル、排他的またはCalipso感度ラベルに戻ることができます。
The first of these methods is the functional equivalent of "importing" the datagram then "exporting" it and is covered in detail in the "Import" (Section 6.2.2) and "Export" (Section 6.2.1) sections above.
これらの方法の最初は、データグラムを「インポート」し、それを「エクスポート」する「インポート」と同等であり、「インポート」（セクション6.2.2）および「エクスポート」（セクション6.2.1）セクションで詳細にカバーされています。
The remainder of this section describes the second method, which is direct relabeling. The choice of which method to use for relabeling is an implementation decision outside the scope of this document.
このセクションの残りの部分では、直接的な再生である2番目の方法について説明します。リラブル化に使用する方法の選択は、このドキュメントの範囲外の実装決定です。
A system that provides on-the-fly relabeling without importing or exporting is basically a special case of the Intermediate System rules listed above. Translation or relabeling takes place AFTER all input checks take place, but before any output checks are done.
インポートまたはエクスポートなしでオンザフライのリラベル付けを提供するシステムは、基本的に上記の中間システムルールの特別なケースです。翻訳または再びは、すべての入力チェックが行われた後に行われますが、出力チェックが行われる前に行われます。
Once a datagram has passed the Intermediate System input processing and input validation described in Section 6.3.1, and has been accepted as valid, the CALIPSO in that datagram may be relabeled. To determine the new Sensitivity Label, first determine the new output DOI.
データグラムが中間システムの入力処理とセクション6.3.1で説明されている入力検証に渡され、有効であると受け入れられると、そのデータグラムのカリッソは再評価される可能性があります。新しい感度ラベルを決定するには、最初に新しい出力doiを決定します。
The selection of the output DOI may be based on any of Incoming DOI, Incoming Sensitivity Label, Destination End System, Destination Network, Destination Subnetwork, Sending Interface, or Receiving Interface, or combinations thereof. Exact details on how the output DOI is selected are implementation dependent, with the caveat that it should be consistent and reversible. If a datagram from End System A to End System B with DOI X maps into DOI Y, then a datagram from B to A with DOI Y should map into DOI X.
出力DOIの選択は、着信DOI、着信感度ラベル、宛先エンドシステム、宛先ネットワーク、宛先サブネットワーク、インターフェイスの送信、またはその組み合わせに基づいている場合があります。出力doiが選択されている方法の正確な詳細は、実装に依存しており、一貫性があり可逆的であるという警告があります。End System AからEnd System Bをdoi xをdoi yにマップしたシステムBまでのデータグラムの場合、Bからdoi yをwith yまでのデータグラムをdoi xにマッピングする必要があります。
Once the output DOI is selected, the output Sensitivity Label is determined based on (1) the input DOI and input Sensitivity Label and (2) the output DOI. In the event the input Sensitivity Label does not map to a valid output Sensitivity Label for the output DOI, then the datagram MUST be silently dropped and the drop event SHOULD be logged as a security fault.
出力DOIが選択されると、出力感度ラベルは（1）入力DOIおよび入力感度ラベル、および（2）出力DOIに基づいて決定されます。入力感度ラベルが出力DOIの有効な出力感度ラベルにマッピングされない場合、データグラムは静かにドロップし、ドロップイベントをセキュリティ障害として記録する必要があります。
Once the datagram has been relabeled, the Intermediate System output procedures described in Section 6.3.3 are followed, with the exception that any error that would cause an ICMP error message to be generated back to the originating End System instead MUST silently drop the datagram without sending an ICMP error message. Such a drop SHOULD be logged as a security fault.
データグラムが再評価されると、セクション6.3.3で説明されている中間システム出力手順に従います。ICMPエラーメッセージの送信。このようなドロップは、セキュリティ障害として記録する必要があります。
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].
このIPv6オプション仕様は、全体的な分散マルチレベルセキュア（MLS）展開のほんの一部です。マルチレベルセキュア（MLS）デバイスの構築方法に関する詳細な手順は、この仕様の範囲をはるかに超えています。MLSエンドシステムの実装など、マルチレベルの安全なオペレーティングシステムの実装に関する追加情報は、さまざまなソース[TCSEC] [TNI] [CMW] [CC] [ISO-15408] [MLOSPP]から入手できます。
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.
通常の5タプル（つまり、ソースIPアドレス、宛先IPアドレス、トランスポートプロトコル、ソースポート、および宛先ポート）は、ラベル付きMLSネットワーク展開内のフローを必ずしも一意に識別しないため、一部のアプリケーションまたはサービスは複数の場合に影響を与える可能性があります。フローマッピングは1つの5タプルになります。これは、このようなアプリケーションプロトコルを使用して、ラベル付きMLSネットワーク展開に予期しない影響を与える可能性があります。たとえば、リソース予約プロトコル（RSVP）、セッション開始プロトコル（SIP）、およびセッション説明プロトコル（SDP）が影響を受ける可能性があります。
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.
多くの商用オフ（COTS）アプリケーション（例：リモートアクセスダイヤルインユーザーサービス（RADIUS）、ハイパーテキスト転送プロトコル（HTTP）、およびトランスポートレイヤーセキュリティ（TLS）Webコンテンツアクセスなど）運用上の困難や特別な変更の必要性なしに、約20年にわたってMLSネットワークの展開に含まれています。これらの一般的なアプリケーションを使用する機能は、MLSの展開では基本的なインターネットアーキテクチャが変更されていないことを示していますが、特定の詳細（たとえば、IPデータグラムにラベルを追加）が変更されます。
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).
歴史的に、RFC 1108は、1つの商用ラベル認識IPルーターによってサポートされていました。著者が知っている限り、RFC 1038もFIPS-188も市販のIPルーターではサポートされていません。ラベル認識ルーターは、必ずしもMLSオペレーティングシステムを使用するわけではありません。代わりに、ラベル認識ルーターは従来のルーターオペレーティングシステムを使用して、拡張機能を追加して、ロジカルインターフェイスラベル指向のアクセス制御リスト（ACLS）をIPパケットに入力してそのルーターのネットワークインターフェイスを離れることを可能にする場合があります。
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.
この提案は、IPルーティングを決して変更しません。既存のラベル認識ルーターは、パス計算、ルーティング情報ベース（RIB）または転送情報ベース（FIB）計算、ルーティングプロトコル、またはパケット転送決定に感度ラベルを使用しません。
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.
同様に、既存のMLSネットワーク展開は、変更なしで多くのプロトコルまたは仕様、例えば差別化されたサービスを使用しています。差別化されたサービスの場合、これは、複数のIPフロー（つまり、カリプソラベル値が異なるフロー）が、単一のフローであるかのように中間システムによって分類および処理されることを意味する場合があります。
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 should make it more practical to create custom logic (e.g., in Verilog) with support for this option and the associated Mandatory Access Controls.
このラベルオプションに基づいて、必須アクセス制御を適用するためのハードウェアサポートがある場合、ルーターのパフォーマンスが最適化されます。CIPSOの問題は、オプションの構文が非常に複雑であることです[FIPS-188]。したがって、このラベルオプションは、簡略化された構文を使用します。これにより、このオプションと関連する必須アクセスコントロールをサポートして、カスタムロジック（verilogなど）を作成することをより実用的にする必要があります。
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.
システム管理者は、異なる重複するコンパートメント範囲を持つ2つのDOIを作成することができます。これを使用して、一部の展開でIPv6感度ラベルオプションのサイズを削減できます。
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.
CalipsoはIPオプションであるため、このドキュメントは、Calipsoオプションを含むIPパケットのネットワーク層処理に焦点を当てています。このセクションでは、いくつかの上層層プロトコルの問題に関するいくつかの議論を提供します。
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].
このセクションは、MLSエンドシステムがCalipsoオプションを含む受信したIPv6パケットを受け入れるという決定が下された後、内部的に情報を処理する方法の完全な仕様ではありません。MLSシステムの実装者は、[TCSEC]、[TNI]、[CMW]、[CC]、[ISO-15408]、および[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.
典型的なMLSエンドシステムでは、ネットワークから受け取った情報（つまり、このドキュメントで説明されているCalipso処理の結果としてネットワークレイヤーによってドロップされていない情報）に、エンドシステムオペレーティングシステム内で内部感度ラベルが割り当てられます。MLS ENDシステムは、Bell-Lapadulaの必須アクセス制御ポリシー[BL73]を使用して、輸送層セッションまたは情報が配信されるアプリケーションなど、その情報の処理方法を決定します。
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.
このセクションでは、明確かつ簡潔にするために、1つの追加表記を使用します。ここでは、文字列「W：XY」は、感度レベルがWであり、XとYが有効になっている唯一のコンパートメントである感度ラベルを定義します。一方、「W ::」は感度レベルがWである感度ラベルを定義します。コンパートメントが有効になっていません。
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.
セクション3から取られた上記の声明には、非自明だが批判的な結果があります。個別の仮想ネットワークがある場合、複数の仮想ネットワークに存在するシステムが同一のTCP接続を持つ可能性があり、それぞれが異なる仮想ネットワークに存在します。
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.
TCP接続は、通常、ソースおよび宛先ポート、およびソースおよび宛先アドレスによって識別されます。システムがCALIPSOオプションを使用してデータグラムをラベル付けする場合（複数の仮想ネットワークに存在する場合は行う必要があります。内部感度ラベル（オプションでは、感度ラベルの範囲）。これにより、RFC 793の技術的エラーが修正され、既知のすべてのMLSオペレーティングシステムの実装[TNI] [RFC793]と一致しています。RFC 793のこの特定の詳細に実際に準拠する現在展開されているTCPインスタンスは既知のものはありません。
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.
TCPやSCTPとは異なり、UDPは少なくとも概念的にステートレスプロトコルです。ただし、UDPの多くの実装にはセッション状態があります（たとえば、4.4 BSDのプロトコル制御ブロック）がありますが、UDPプロトコルの仕様には状態は必要ありません。
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.
これの1つの結果は、UDPとIPv6の広く使用されているエンドシステム実装では、UDPリスナーが、特定のリモートIPアドレスまたはローカルIPアドレスにバインディングすることなく、その最終システムの特定のUDPポートにのみ拘束される可能性があることです。
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.
UDPは、ユニキャストまたはマルチキャストで使用できます。一部の既存のUDPエンドシステムの実装により、単一のUDPパケットを同時に複数のリスナーに配信することができます。必須アクセス制御の適用を除き、特定のシステムの動作は、リスナーへのUDPデータグラムの配信に関して、アプリケーションの動作が何らかの予想外の方法で変わらないように）同じままでなければなりません。
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.
たとえば、UDPポートXのリスナーには、最小の「S：AB」と「S：AB」の感度ラベル範囲がある場合、UDPポートXの宛先と感度ラベルを持つデータグラムのみがS：AB "はそのリスナーに配信されます。
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.
たとえば、UDPポートYのリスナーが最小の「W ::」と最大「X：ABC」（XがWhere where w）を持つ感度ラベル範囲を持っている場合、UDPポートyにアドレス指定されたデータグラムが「W：A」の感度ラベルは、通常そのリスナーに配信されます。
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 SCTP connections, each one existing in a different virtual network.
セクション3から取られた上記の声明には、非自明だが批判的な結果があります。個別の仮想ネットワークがある場合、複数の仮想ネットワークに存在するシステムが同一のSCTP接続を持つことが可能です。それぞれが異なる仮想ネットワークに存在します。
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.
TCPと同様に、SCTPは接続指向の輸送プロトコルであり、かなりのセッション状態を持っています。TCPとは異なり、SCTPは同じエンドノードでのIPアドレス間のセッションエンドポイントの移行をサポートでき、SCTPは1対1および1対1のコミュニケーションセッションの両方をサポートできます。
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.
シングルレベルのエンドシステムでは、1対1のモードでは、単一のローカルSCTPセッションのSCTPセッション状態には、単一のリモートSCTPインスタンスのリモートIPアドレスのセット、ローカルIPアドレスのセット、リモートSCTPのセットが含まれています。ポート番号、およびローカルSCTPポート番号。
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.
単一レベルのエンドシステムでは、1対多数のモードでは、単一のローカルSCTPインスタンスのSCTPセッション状態は、いくつかの異なるリモートSCTPピアに複数の同時接続を持つことができます。単一のSCTPインスタンスから特定のリモートSCTPインスタンスに複数の接続を導入することはできません。したがって、シングルレベルのエンドシステムでは、1対多モードでは、ローカルSCTPセッションの状態には、リモートIPアドレスのセット、ローカルIPアドレスのセット、各リモートSCTPインスタンスのリモートSCTPポート番号、および（シングル）ローカルSCTPポート番号。
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.
MLS ENDシステムでは、SCTPモードのいずれかの場合、SCTPセッション状態には、各SCTPセッションの感度ラベルが追加されています。1対1のモードであろうと1対1のモードであろうと、単一のSCTPセッションには、感度ラベルの範囲ではなく、単一の感度ラベルが必要です。
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.
TCPとは異なり、SCTPには、1つ以上のエンドポイントが複数のIPアドレスを持っている場合、既存のSCTPセッションを1つのエンドポイントIPアドレスから同じエンドポイントに属する別のIPアドレスにシフトする機能があります。このようなシフトがMLS展開内で発生した場合、SCTPセッション独自の感度ラベルを含む感度ラベル範囲のIPアドレスにのみ移動することが重要です。
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
さらに、ノードはマルチホームである可能性がありますが、特定の感度ラベル値に対してこれらのインターフェイスの1つのみが到達可能である可能性は完全にあります。たとえば、ノード上の1つのネットワークインターフェイスには、「a ::」から「b：xy」までの感度ラベル範囲がある場合がありますが、同じノード上の異なるネットワークインターフェイスは、感度ラベルの範囲を持つ可能性があります。「u :: "" u :: "（uがuを支配する場所）。その例では、パケットにのカリプソラベルがある場合
"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.
「A：X」、そのパケットは「U」のみのネットワークインターフェイスを使用できません。したがって、SCTP実装は、そのSCTPインスタンスのリモートSCTPインスタンスと通信する独自のIPアドレスのどれを決定する際に、ローカルシステム上の各SCTPインスタンスの感度ラベルを考慮する必要があります。この問題は、SCTPセッションに関する新しい運用上の問題につながる可能性があります。実装者は、このSCTP固有の問題に特別な注意を払う必要があります。
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.
このオプションは、グローバルインターネットに接続されていない適切に保護されたプライベートネットワークでのみ展開に推奨されます。定義上、このようなプライベートネットワークは、信頼できると考えられている信頼できるシステムのみで構成されています。したがって、ロギングの実装に対するサービス拒否攻撃のリスクは、一般的なインターネット展開の場合よりも、意図した展開環境ではるかに低くなっています。
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.
このドキュメントでは、IPv6データグラムに明示的な感度ラベルを追加するメカニズムについて説明します。これらのラベルの主な目的は、この仕様を実装するエンドシステムまたは中間システムでの必須アクセス制御（MAC）の適用を容易にすることです。
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.
懸念は、このラベルが必須アクセス制御に使用されるため、感度ラベルオプションを残りのパケットに結合する方法が必要であることです。このような拘束力がなければ、パケット内の感度ラベルの悪意のある変更は検出されません。したがって、この感度ラベルオプションの実装は、IP認証ヘッダー（AH）のサポートも実装する必要があります。実装は、システム管理者がAHが使用されるかどうかを構成することを許可する必要があります。
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.
null暗号化メカニズムを備えたESPは、IPv6パケットのペイロードのみを保護でき、ホップバイホップオプションではありません。対照的に、AHは、Calipso Hop-by-Hopオプションを含むIPv6パケットのすべての不変ヘッダーとデータを保護します。このドキュメントで定義されているCalipsoオプションは、IPv6ホップバイホップオプションです。これは、CalipsoオプションがPacketにMacポリシーを適用できるようにIPv6ルーターとセキュリティゲートウェイに表示され、配置可能である必要があるためです。
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.
AHが対称認証アルゴリズムで使用されている場合、受信者エンドシステムだけでなく、パスに沿った1つ以上のセキュリティゲートウェイも対称キーの知識を持つことが予想されます。Calipsoラベルを含むパケットを認証します。この場合、対称認証キーを信頼する必要があることを知っているすべてのデバイス。あるいは、AHは非対称認証アルゴリズムで使用される場合があります。そのため、認証キーの知識を持つ受信者とセキュリティゲートウェイは、Calipsoラベルを含むパケットを認証できます。
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.
AHまたはESPがCalipsoの展開内で「ラベル付きIPセキュリティ」を提供するために採用されている場合、特定のパケットに使用されるIPセキュリティアソシエーションの感度ラベルは、そのパケットのCalipsoオプションで運ばれる感度ラベルと同じ意味を持つ必要があります。Macポリシーが正しく適用されることができる、および適用されるため。
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.
IP認証ヘッダーには、保護されたIPv6ヘッダーフィールドにCalipsoオプションが含まれるため、IP認証ヘッダーも含むCalipso-Labled Packetの変更により、結果のパケットがAHセキュリティセッションの宛先ノードで認証を失敗させます。したがって、Calipsoラベルは、IP認証ヘッダーを含むIPv6パケット用に挿入、削除、または翻訳することはできません。
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.
注意事項：IPv6オプションタイプの「トランジット中に変更されていない」ビットは、「AH計算を含む」信号になるように実際に作成されました。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.
中間システムによる変更がポリシーによって必要であるが、AHのために不可能な状況では、代わりにパケットを削除する必要があります。この理由でパケットをドロップする必要がある場合、ICMPの「到達不可能な」エラーメッセージは、「管理的に禁止された」という理由で、ドロップされたパケットのオリジネーターに送り返す必要があります。中間システムのMLS MACポリシーに違反することなくパケットを適切に転送できる場合、そのようなパケット変更は（定義上）必要ありません。
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 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.
ラベル付きネットワークを備えた多くのエラー状況では、セキュリティの問題の作成を避けるために、ICMPエラーメッセージを送信しないでください。他の特定のエラー状況では、ICMPエラーメッセージが送信される場合があります。このようなICMP処理の詳細については、このドキュメントで前述しています。ICMPエラーメッセージが送信された場合でも、MACルール、DOIの違い、またはNODEからICMPエラーメッセージを作成する途中のその他の設定されたセキュリティポリシーにより、意図した宛先に到達する前に途中でドロップされる可能性があります。宛先ノード。次に、これは、ラベル付けされたネットワーク展開の運用上の障害（例：ファイバーカット、誤解）を意味する可能性があります。
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.
このメカニズムは、一連のシステムとネットワークが十分に保護された操作環境にある非常に限られた状況での展開を目的としており、このメカニズムに対する外部または内部攻撃の脅威は、これらのシステムとネットワークの認定者に受け入れられると見なされます。可視パケットラベルを含むIPパケットは、パブリックインターネットを通過しないでください。
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].
この仕様では、可能なすべての秘密チャネルを排除しようとはしません。セクション7.3.1のTCP仕様の明確化は、特定の既知のカバーチャネルの帯域幅を減らすためにたまたま存在しますが、主にネットワーク化されたMLSシステムが常に実装されている方法を明確にするために存在します[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.
もちろん、ローカルセキュリティポリシーに従い、Calipsoラベルを備えた暗号化されたIPv6パケットは、適切な暗号保護を受けた後、パブリックインターネットを横断する可能性があります。たとえば、カリプソ標識パケットは、2つ以上のMLS標識ネットワークセグメントを接続するトンネルモードESP（暗号化付き）VPNトンネルのいずれかを通過する場合があります。あるいは、キャリプソ標識IPv6パケットは、リンクに送信する前にラベル付きパケットを暗号化し、レセプションからレセプション後にラベルパケットを解読する前にラベル付きパケットを暗号化する、評価、認定、認定されたバルク暗号化装置の展開によって保護されている外部リンクを越えて移動する可能性があります。リンク。
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.
特定のCalipsoの展開の認定者は、人事クリアランスと物理的セキュリティの問題だけでなく、電子セキュリティ（Tempestなど）、ネットワークセキュリティ（NETSEC）、通信セキュリティ（COMSEC）、およびその他の問題を考慮する必要があります。この仕様は、MLSネットワーク全体の展開の小さなコンポーネントにすぎません。
An IPv6 Option Number [RFC2460] has been registered for CALIPSO.
IPv6オプション番号[RFC2460]がCalipsoに登録されています。
HEX BINARY
act chg rest
--- --- --- -----
7 00 0 00111 CALIPSO
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.
IPv6オプション番号の場合、最初の2つのビットは、IPv6ノードがこのオプションをスキップし、オプションタイプを認識していない場合はヘッダーの処理を継続することを示します。3番目のビットは、オプションデータが途中で変更してはならないことを示します。
This document is listed as the reference document.
このドキュメントは、参照ドキュメントとしてリストされています。
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:
IANAは、Calipso DOI値のレジストリを作成しました。コロン分離されたクアッド形式に示されているCalipso DOIレジストリの初期値は、次のとおりです。
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.
0：0：0：1から0：255：255：255：プライベートネットワーク内の同意関係者の間での私的使用。
1:0:0:0 to 254:255:255:255 For assignment by IANA to organizations following the Expert Review procedure [RFC5226].
1：0：0：0：0から254：255：255：255専門家のレビュー手順[RFC5226]に続いて、IANAが組織に割り当てる。
255:0:0:0 to 255:255:255:255 Reserved to the IETF for future use by possible revisions of this specification.
255：0：0：0から255：255：255：255この仕様の可能な改訂により、将来使用するためにIETFに予約されています。
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.
Calipso doi値0：0：0：0はnull doiであり、ネットワークや展開では使用されません。
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.
他のすべてのCalipso DOI値は、10進0から始まる：同意者の間で私的使用のために予約されています。この範囲の値は、IANAによって特定のユーザーまたはユーザーコミュニティに割り当てられません。
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値1：0：0：0：0から254：255：255：255（包括的）の場合、IANAはDOI割り当てリクエストを受信したときに専門家のレビュー手順に従う必要があります。
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.
小数255で始まるCalipso DOI値は、この仕様の改訂で将来の潜在的な使用のためにIETFに予約されています。IESGの承認は、その範囲内のDOI値の割り当てに必要です。
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.
このドキュメントは、1992年頃のMike Stjohnsによって書かれた「IPSOの息子（Sipso）」というタイトルのインターネットドラフトから直接導き出されています。それ以来、主にIPv4の代わりにIPv6をサポートするためにさまざまな変更が行われています。ここでの概念、ほとんどの定義、およびほとんどすべての処理ルールは、以前の文書の概念と同じです。
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.
スティーブ・ブレンネマン、L.C。ブルーゼナック、ジェームズ・カールソン、パシ・エロネン、マイケル・フィドラー、ボブ・ヒンデン、アルフレッド・ホーネス、ラス・ヒューズリー、スレシュ・クリシュナン、ジャレット・ルー、ダン・マクドナルド、ポール・ムーア、ジョー・ナル、デイブ・パーカー、タイム・ポーク、ケン・パウエル、ランドール・スチュワート、ビル・ソマーフェルド、Joe Touch（姓によるアルファベット順にリストされている）は、このドキュメントの以前のバージョンに関する具体的なフィードバックを提供しました。
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.
著者はまた、いくつかの匿名のレビュアーのフィードバック、特にMLSネットワーキングとの運用上の考慮事項に関する洞察を共有してくれたことに感謝したいと思います。
The authors would like to thank the IESG as a whole for providing feedback on earlier versions of this document.
著者は、このドキュメントの以前のバージョンに関するフィードバックを提供してくれたIESG全体に感謝したいと思います。
[RFC1662] Simpson, W., Ed., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[RFC1662] Simpson、W.、ed。、「HDLCのようなフレーミングのPPP」、STD 51、RFC 1662、1994年7月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[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.
[bl73]ベル、D.E。and Lapadula、L.J。、「安全なコンピューターシステム：数学的基盤とモデル」、テクニカルレポートM74-244、MITER CORPORATION、ベッドフォード、マサチューセッツ州、1973年5月。
[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.
[CW87] D.D.クラークとD.R.ウィルソン、「商業および軍事のコンピューターセキュリティポリシーの比較」、セキュリティとプライバシーに関するIEEEシンポジウムの議事録、184-194ページ、IEEEコンピューターソサエティ、カリフォルニア州オークランド、1987年5月。
[CMW] US Defense Intelligence Agency, "Compartmented Mode Workstation Evaluation Criteria", Technical Report DDS-2600-6243-91, Washington, DC, November 1991.
[CMW]米国防衛情報機関、「コンパートメントモードワークステーション評価基準」、テクニカルレポートDDS-2600-6243-91、ワシントンDC、1991年11月。
[DoD5200.1-R] US Department of Defense, "Information Security Program Regulation", DoD 5200.1-R, 17 January 1997.
[DOD5200.1-R]米国国防総省、「情報セキュリティプログラム規制」、DOD 5200.1-R、1997年1月17日。
[DoD5200.28] US Department of Defense, "Security Requirements for Automated Information Systems," Directive 5200.28, 21 March 1988.
[DOD5200.28]米国国防総省、「自動情報システムのセキュリティ要件」、指令5200.28、1988年3月21日。
[MLOSPP] US Department of Defense, "Protection Profile for Multi-level Operating Systems in Environments requiring Medium Robustness", Version 1.22, 23 May 2001.
[MLOSPP]米国国防総省、「中程度の堅牢性を必要とする環境におけるマルチレベルオペレーティングシステムの保護プロファイル」、バージョン1.22、2001年5月23日。
[ISO-15408] International Standards Organisation, "Evaluation Criteria for IT Security", ISO/IEC 15408, 2005.
[ISO-15408]国際標準組織、「ITセキュリティの評価基準」、ISO/IEC 15408、2005。
[CC] "Common Criteria for Information Technology Security Evaluation", Version 3.1, Revision 1, CCMB-2006-09-001, September 2006.
[CC]「情報技術セキュリティ評価の共通基準」、バージョン3.1、改訂1、CCMB-2006-09-001、2006年9月。
[TCSEC] US Department of Defense, "Trusted Computer System Evaluation Criteria", DoD 5200.28-STD, 26 December 1985.
[TCSEC]米国国防総省、「信頼できるコンピューターシステム評価基準」、DOD 5200.28-STD、1985年12月26日。
[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.
[TNI]（米国）National Computer Security Center、「信頼できるコンピューターシステム評価基準の信頼できるネットワーク解釈（TNI）」、NCSC-TG-005、バージョン1、1987年7月31日。
[FIPS-188] US National Institute of Standards and Technology, "Standard Security Labels for Information Transfer", Federal Information Processing Standard (FIPS) 188, September 1994.
[FIPS-188]米国国立標準技術研究所、「情報転送のための標準セキュリティラベル」、連邦情報処理標準（FIPS）188、1994年9月。
[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.
[IEEE802.1Q] IEEE、「仮想ブリッジ付きローカルエリアネットワーク」、IEEEローカルおよびメトロポリタンエリアネットワークの標準、802.1Q-2005、ISBN 0-7381-4876-6、IEEE、ニューヨーク、ニューヨーク、米国、2006年5月19日。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC1038] St. Johns, M., "Draft revised IP security option", RFC 1038, January 1988.
[RFC1038]セントジョンズ、M。、「ドラフト改訂IPセキュリティオプション」、RFC 1038、1988年1月。
[RFC1108] Kent, S., "U.S. Department of Defense Security Options for the Internet Protocol", RFC 1108, November 1991.
[RFC1108] Kent、S。、「インターネットプロトコルの米国国防総省セキュリティオプション」、RFC 1108、1991年11月。
[RFC1825] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, August 1995.
[RFC1825]アトキンソン、R。、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 1825、1995年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
Authors' Addresses
著者のアドレス
Michael StJohns Germantown, MD USA
Michael Stjohns Germantown、MD USA
EMail: mstjohns@comcast.net
Randall Atkinson Extreme Networks 3585 Monroe Street Santa Clara, CA USA 95051
ランドールアトキンソンエクストリームネットワーク3585モンローストリートサンタクララ、カリフォルニアUSA 95051
EMail: rja@extremenetworks.com
Phone: +1 (408)579-2800
Georg Thomas US Department of Defense Washington, DC USA
ジョージトーマス米国国防総省ワシントンDC米国