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)
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パケットに明示的なパケット機密ラベルを符号化するための任意の方法を説明します。これはのみの両方の信頼できると信頼できるマルチレベルセキュア（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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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 1108 [RFC791] [RFC1038] [RFC1108]で、後にRFC 1038で改訂されました。 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.
一つまたは別のIP機密ラベルオプションは、最も一般的には、政府や軍内部ネットワークで、およそ二十年のために限られた展開になっています。企業のセキュリティポリシーを強制アクセス制御は、機密データに適用することも必要とするいくつかの商業部門の展開もあります。一部の銀行は、合併や買収に関する例については、機密情報を制限するために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の直接の子孫であると商業IPセキュリティオプション信頼できるシステムの相互運用性・グループ（TSIG）の（CIPSO）ワーキンググループ[FIPS-188]で行われた作業に近いいとこです。 BLACKER [RFC1038]と呼ばれたIPv4パケットの暗号化デバイスの守備をサポートする：RFC 1038で定義されたIPセキュリティオプションを念頭に置いて一つの特定の目的で設計されました。このため、これらのドキュメントの定義および仮定は、必ずしも米国国防総省とBLACKERデバイスに焦点を当てました。今日では、IPパケット感度標識は、最も一般的に、多くの場合、ローカルエリアネットワーク（LAN）経由で接続されているコンパートメントモードワークステーション（CMWs）で構成されるマルチレベルセキュア（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パケット標識のための一つの非IETF仕様を引き起こしました。 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.
最後の十年かそこらでは、一般的なイーサネットリンク速度は1 Gbpsの全二重に10 Mbpsの半二重から変更されています。 10 Gbpsの全二重イーサネット規格は、ルータ、イーサネットスイッチでは、さらにいくつかのサーバでは、今日広く利用可能です。 IEEEは、積極的にこれを書いている時点では、両方の40Gbpsイーサネットおよび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]で明示的なパケット機密ラベルの必要性をなくすだろうと予想されました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の仕様は1つが、この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.
それらはコンパートメントであるかのように解放性をコードする一般的に使用される方法も記載されています。この使用法は、いくつかの正式な離型性ポリシーとして正確に同じ意味を持っていませんが、既存のマルチレベルセキュアオペレーティングシステムは、コンパートメントとは別の概念として解放性のためのオペレーティングシステムのサポートが含まれていません。離型エンコーディングのこの種のためのセマンティクスは、正式な方針に近く、今、少なくとも十年のためのさまざまな組織の数で展開されています。
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.
特に、著者は、このメカニズムは、国連での展開（UN）の平和維持活動のため、北大西洋条約機構（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.
最初のシナリオでは、所与のプライベートインターネットワーク内のすべての接続されたノードは、コンパートメントモードワークステーションのようなマルチレベルセキュリティ（MLS）オペレーティングシステム、（CMWs）、そのサポートパケットごとの感度ラベル[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エンドシステムは、「システムハイ」モードで動作します。 「システムハイ」モードでは、システム上のすべての情報は、システム上で最も機密性の高いデータの感度を持っていると考えられています。システムは一つだけ感度レベルでデータを含むようになった場合、これはまた、「システムハイ」の動作の一例だろう。このシナリオでは、任意の単一レベルのエンドシステムを含む各サブネットワークは、IPサブネットワーク上のすべての単一レベルのシステムに適用される1つの「デフォルト」の機密ラベルを持っています。これらの非MLSエンドシステムは、機密ラベルを含むパケットを作成することができず、また、受信したパケットにMACの施行を適用することができないので、そのようなサブネットワークに接続されている（例えば、ラベル対応IPルータであるかもしれない）のセキュリティ・ゲートウェイは、挿入する必要があります感度は、サブネットをオフに転送される「システムハイ」エンドシステムから発信されるパケットにラベルを付けます。 CALIPSOのIPv6オプションは、「認識できない場合は無視する」としてマークされている間、バグといくつかの展開IPv6のエンドシステムがあります。ユーザーはこれらのオペレーティングシステムのバグを修正することはできません。一部のユーザーは、便利な総合的なMLSの展開を持っている既存のIPv6シングルレベルのエンドシステムを統合できるようにする必要があります。だから、単一レベルのエンドシステムを含む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の感度レベルよりも大きいかまたはBの感度レベルに等しく、Aのコンパートメントセットはこの用語が使用されたB.のコンパートメントセットの（適切または不適切な）スーパーセットである場合、感度ラベルAは、機密ラベルBを支配しますこの意味でのマルチレベルセキュア界では、少なくとも二十年のために。
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.
言い換えれば、それだけで「SECRET」のラベルは意味がありません。 1は、文書やデータは、いくつかの特定の組織（例えば、米国国防総省（DoD）、エネルギー（DOE）の米国務省、英国国防省（MOD）、北大西洋条約機構（NATO）、米国に属していることを知っている必要があります国連（UN）、特定の商業事務所）1がデータを受信することが許可されている者を決定する前に。
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内、および推論によって感度レベルとコンパートメントの存在を定義するポリシー、特定のセット（例えば、へのポインタとして使用される不透明な識別子であり、 ）同等のラベル（以下「機密ラベル」を参照してください）。 「認定」または登録またはエンドシステムから発信ラベリングIPデータの標準的な方法でCALIPSO DOI結果として実世界のセキュリティ・ポリシーのセットを定義すると、そのDOI、それらのセキュリティ・ポリシーの制約内で動作するように、「承認しました」。 1は、米国国防総省のためにこれをしなかった場合たとえば、1は、このような「SECRET」と「TOP SECRET」として、すべての許容可能なラベルをリストし、もう一方は[DoD5200.28]と[DoD5200にCALIPSO DOIをリンクします。 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を作成することがありますその内の（おそらく他の人が作成した他のDOIと一緒に）多国籍DOIそのプライベートネットワーク。別の例を提供するために、米国は、それが米国国防総省に主に適用される機密文書とラベルを付け、通常の方法に対応して特定の意味を持つDOIを確立するかもしれないが、それらの特定の意味は、他の関連機関に適用される場合があります。会社または他の組織はまた、唯一の自分自身に適用される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ドメインが異なっており、インターネットSecurity AssociationとKey Managementプロトコル（ISAKMP）/インターネット鍵交換（IKE）解釈のドメインからばらばらです。用語が表面的に似ているように見える場合でも、二つの異なる概念を混同しないことが重要です。
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は、今度はC（A> B> C）よりも敏感であるB、より敏感である場合、例えば、Bレベルのデータへのアクセスは、Cへのアクセスなどを暗示しますうまく。一例として、感度レベルのための共通の英国の用語は、「未分類」、「RESTRICTED」、「CONFIDENTIAL」、「SECRET」、および「MOST SECRET」（ローからハイへ）が挙げられます。
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".
よの注：感度レベルは、機密ラベルの唯一のコンポーネントです。 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」プロジェクトについて、例えば、「金融」データ）で保護されていてもよいです。従業員は、所定の感度レベル（すなわち、その感度レベルにおける任意の特定の区画のための隙間を有することなく）任意の区画に分類される任意のデータへのアクセスを持っていない（例えば、「SECRETファイナンス」、「SECRET」を支配する）のためのクリアランスを有します。
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は、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.
しかしながら、上記区画の例とは異なり、COMPANY CONFIDENTIALはCOMPANY CONFIDENTIAL REL XYZを支配します。これはCOMPANY CONFIDENTIALクリアランスとABCの従業員は、すべての情報にアクセスすることができますしながら、XYZの従業員は、のみアクセスでき離型性材料COMPANY CONFIDENTIAL REL XYZクリアランスを付与されたことを意味します。
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がコンパートメントとして管理された場合、ユーザーはCOMPANY CONFIDENTIAL REL XYZクリアランスが望ましくないABCのCOMPANY CONFIDENTIAL材料、のすべてにアクセスすることができます付与されました。
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.
解放性（例えば、COMPANY ABLE CONFIDENTIAL REL XYZ /）組み合わせることができます。この場合、どちらかCOMPANY CONFIDENTIAL、COMPANY CONFIDENTIAL REL XYZ、COMPANY CONFIDENTIAL REL ABLE、またはABLE COMPANY CONFIDENTIAL REL XYZ /のクリアランスを持つユーザーは、この情報にアクセスすることができます。
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：すべてのコミュニティへの解放はない：これは通常、「いいえ外国人（NO FORN）」として取り扱い制限がエンコードされている方法です。 ABCDの== 1111
Example 2: Releasable only to community A and community C: ABCD == 0101
例2：専用コミュニティAおよびコミュニティCに解放可能：ABCDの== 0101
Example 3: Releasable only to community B: ABCD == 1011
例3：専用コミュニティBに解放可能：ABCDの== 1011
Example 4: Releasable to communities A,B,C, & D: ABCD == 0000
実施例4：ABCDの== 0000：コミュニティA、B、C、およびDに放出可能
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：任意のコミュニティに属していないクリアランス：S /彼は任意の離型コミュニティではないので、このユーザーは、任意の離型性のコミュニティに属する情報を見ることができます。 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：コミュニティ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：このユーザは、解放可能ABCD情報を見たり、（例えば）解放可能AB又は放出BD情報を見ることができない：クリアランスがコミュニティA、B、C、及びDに属します。 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
そのルータインターフェイスの最小ラベルがあることしてみましょう：CONFIDENTIAL RELEASABLE AC
Therefore, this interface has a minimum Releasability of 0101.
したがって、このインターフェースは、0101の最小の離型性を有しています。
Let the MAXIMUM label for that router interface be: TOP SECRET NOT RELEASABLE
そのルータのインターフェイスの最大ラベルがあることしてみましょう：TOP SECRETの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でパケットを考える：1）感度レベル比較：（CONFIDENTIAL <= CONFIDENTIAL <= TOP SECRET）は感度レベルは、そのルータのインタフェースは、「範囲内」です。 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）コンパートメントビットマップ比較：テストは、[> = 0101（0000）および（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）機密ラベルの比較：ラベルの秘密ではないRELEASABLEでパケットを考えてみましょう（CONFIDENTIALを<= SECRET <= TOP SECRET）ので、感度レベルは、そのルータインターフェイスのために、「範囲内」です。 2）コンパートメントビットマップ比較：テストは、[（> = 0101 1111）および（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.
1は、（また、AとB）2つの離型コミュニティの一員である人「ジェーン・ドウ」を考える場合、例えば、彼女は「「放出可能なB」、「リリース可能A」とマークされた紙文書を参照することが許可されるか、または解放可能な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）を検討してください。これらのビットは、「ジェーン・ドウ」は、ユーザが使用する電子ユーザ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」と記された書類を読み取る能力を拒否します。 「放出可能AB」が「00」として符号化されている間、「放出可能A」は、「01」と、「放出可能B」は「10」として符号化される符号化されているためです。 1コンパートメントの支配計算を見た場合、「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.
いくつかの展開では、電子ユーザにいくつかの平行隙間を割り当てることにより、この制限を回避します。この影響（例えば、ことにする必要があるが、上記（架空の）実施例を参照すると、ユーザ「ジェーンドゥ」は、一つの任意の離型離型Aを持つ別の別個隙間なくクリアランス、及び離型Bと第三の別個のクリアランスがあるかもしれません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、感度レベル、コンパートメントの設定、および離型セットからなる四倍です。コンパートメントの設定には区画が適用されない場合に限り、空のセットかもしれません。離型セットがあれば、空集合とすることができ、何の解放性は適用されない場合にのみ。エンドシステム内で使用される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ラベルにMACポリシーを実施することができるようになりますパケットでCALIPSOラベルを含めることができるようになります。
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.
マルチレベルセキュア機能は「システムハイ」モードで動作欠けているオペレーティングシステムを使用してエンドシステム。これは、システム上のすべてのデータがシステム上で最も機密性の高いデータの機密ラベルを持っていると考えられていることを意味します。このようなシステムは、通常、それが発信するパケットで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:
二つの感度ラベル（A及びB）と比較することができます。彼らは強制アクセス制御の決定の一部として比較できるように実際に、機密ラベルは、主に存在します。比較は、一つ機密ラベル（A）で動作する被写体（人物、ネットワーク、等）は、別の機密ラベル（B）に分類される（等ファイル、パケット、ルート）オブジェクトへのアクセスを許可されるべきかどうかを決定するために重要です。 2つのラベル（A及びB）を比較すると、以下の結果のいずれかの（そして唯一の）を返すことができます。
1) A dominates B (e.g., A=SECRET, B=UNCLASSIFIED); A can read B,
1）A）が（例えば、A = SECRET、UNCLASSIFIED B = Bを支配します。 Bを読み取ることができ、
2) B dominates A (e.g., A=UNCLASSIFIED, B=SECRET); A cannot access B,
2）Bは、UNCLASSIFIED（例えば、A = B = SECRET）を支配します。 Bにアクセスすることはできません、
3) A equals B (e.g., A=SECRET, B=SECRET); A can read/write B,
3）AはB（例えば、A = SECRET、B = SECRET）に等しいです。 /書き込み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ファイナンス）に無類です。 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.
範囲は、比較目的のための最小および最大許容機密ラベルの両方を示しており、感度ラベルの対です。範囲は、通常、「<最小>：<最大>」のように表現されており、常に最大感度ラベルが最小機密ラベルを支配する特性を有しています。ターンでは、これは2つの機密ラベルが同等でなければならないことが必要です。
A range where <minimum> equals <maximum> may be expressed simply as "<minimum>"; in this case, the only acceptable Sensitivity Label is <minimum>.
<最小>が<最大>「<最小>」単にとして表すことができる等しい範囲。この場合には、唯一の許容可能な機密ラベルは、<最小値>です。
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
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のコミュニティは中間システムとエンドシステム[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.
システムセキュリティポリシー（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」から「クラス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）ポリシーを持っています。この文書では、ベルLaPadula [BL73]の正式な定義に基づいて構築します。二つの基本的な原則があります：「何を読ん」「ノー書き留めていない」と。
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を有するエンティティが有する情報を読み取ることができてはならないことを意味X.以下感度レベルでマークされている情報を書き込むことができない必要があることを意味します感度レベルは、通常の展開ではX.上、情報が（「書き留め」）自動的に実行してはならないダウングレード、および許可されている場合は、適切な「ダウングレード」権限を持つ人は、手動の前にダウングレードすることが許可されている情報を確認する場合にのみ/彼は、手動で（すなわち、「ダウングレード」）情報のラベル付けを再度行います。このエリアのベルとLaPadulaによるオリジナル作品に続き、この形式モデルは、情報の（「横」）コンパートメントをサポートするように拡張されました。
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]の別々のドメインの概念を収容するベルLaPadulaに延びています。ベル - LaPadulaで述べたように、各DOIは、機密ラベルのシングル同等のドメインを構成しています。異なるドメインからの機密ラベルは、直接ベル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）パケット感度ラベルを符号化するための仕様を提供することに焦点を当て、そして（2）そのような感度ラベルはIP層で解釈され、適用される方法をされています。この文書では、有意にエンドツーエンドシステムのセキュリティポリシーの適用に影響を与えるが、この文書の範囲外である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]の一例です。エンドシステムができる、と機密ラベルのいくつかの範囲にわたり、別の処理に認定されている場合に便利です。そのようなノードは、ネットワークにノードを接続するネットワーク・インターフェース内で、それに関連する範囲を有するであろう。ノードが取り付けられた中間システムでは、それに関連付けられた：一例として、エンドシステムは、レンジ「TOP SECRET SECRET」を有します。 「：SECRET SECRET」ノード最終的に、ネットワークのセグメント：ノード上のSECRET処理は、他の「SECRET SECRET」にネットワークを通過することを許可されています。同様に、ノード上のTOP SECRET処理を介して、ネットワークを通過することを許可されている「TOP SECRET：TOP SECRET」セグメント、最終的にいくつかの「TOP SECRET：TOP SECRET」をノード。この場合、ノードがこのノードのユーザーが、SECRETとTOP SECRETリソースにアクセスできるようにすることができ、ユーザーが適切なクリアランスを保持し、正しく設定されていました。
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.
与えられたネットワークに対して、それぞれ異なる感度ラベルは、同じ物理ネットワークを共有する別の仮想ネットワークを表します。さまざまな仮想ネットワーク間で情報を移動するためのルールがあります。私たちは、この文書内で使用モデルはベル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.
よの注：私たちは、「承認していない」と言うどこ、我々はまた、「クリアされない」を意味し、「認定を受けていない」、および/または1つの運用コミュニティで該当する「認定ません」。
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は、典型的には、連立トラフィックに使用される、いくつかの異なっCALIPSO DOIは、典型的には非連合トラフィック（その特定のネットワーク・リンクを所有し、作動政府に特異的である、すなわち、トラフィック）のために使用されるであろう。同時に非英NATOに終端/発信さについては、別のNATO DOIを使用しながら、例えば、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をサポートしている場合、展開がスムーズ、ロスレス、ゼロで異なるDOI値に1つの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.
したがって、この仕様を実装するノードは、同時に少なくとも二つCALIPSOのDOIをサポートできなければなりません。以上の2つの同時CALIPSOのDOIのサポートが奨励されています。少なくとも二つ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の使用もまた、区画の非常に大きな数字を持っている単回投与した展開で運用に便利です。たとえば、このような展開は一対一CALIPSO DOIの関連コンパートメントのセットと異なるCALIPSO DOIでの区画の異なるセットを持っているかもしれません。一部の区画は、おそらく異なるのDOIに区画ビットマップの異なるビット位置で、両方のDOIに存在するかもしれません。これは、いくつかの実装が複雑になるかもしれないが、また、データパケット内のIPv6 CALIPSOオプションの典型的なサイズを小さくするために使用される可能性があります。
Moving information between any two DOIs is permitted -- if and only if -- the owners of the DOIs:
DOIのが許可されている任意の2つの間の情報の移動 - 場合にのみ - の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.
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を接続するために使用される物理的なネットワークセグメントに関連付けられます。一つ以上の機密ラベルの範囲は、各物理ネットワークインターフェイスに関連付けられています。複数の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].
所定の論理ネットワークインタフェースは、複数の物理インタフェースに関連付けされるかもしれません。例えば、スイッチ/ルータは、1つのVLANは、単一のIPv6サブネット[IEEE802.1Q]にマッピングされた同一の仮想ローカルエリアネットワーク（VLAN）に関連付けられている2つの別個のイーサネットポートを持っているかもしれません。
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つの論理ネットワークインタフェースを有するかもしれません。あるいは、また、一例として、1つのイーサネットポートは、各VLANは別々の論理ネットワークインタフェースとすることができる場合、それに関連する複数の仮想LAN（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.
一つ以上の機密ラベルの範囲は、各論理ネットワークインタフェースに関連付けられています。複数の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機密ラベルの内容に基づいて強制アクセス制御を適用することができ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ゲートウェイ」、輸入1 DOIからのデータと他のDOIにエクスポートの概念があり、有効機密ラベルが変更されていませんが、単に異なるDOIを用いて表現されるようになっています。言い換えれば、このようなデバイスは、信頼できる、信頼、および単一DOI内のエンドシステムの完全なシステム間の境界でのパケットのオンザフライ再ラベル付けを提供する権限を与えます。典型的には、このようなシステムは、展開又は使用前に特定の認証（S）と認定（複数可）を必要とします。
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準拠のエンドシステムと中間システムのデフォルトの動作を説明します。実装はこの動作から変化するコンフィギュレーションノブを実装してもよい（MAY）、以下に説明するように、デフォルトの動作（すなわち、システム管理者が明示的にデバイスの構成動作を変更しない場合）であることを条件とします。実装者は、このような構成のノブを実装することを選択した場合、彼らは有効または無効に設定パラメータや行動は、それらのデバイスのシステム管理者の利益のために文書化する必要があります。
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セッションの終了点で、単に、CALIPSO標識したパケットが通過する各ホップ上の中間システムによって適用される必要はありません。一例として、より高い感度レベルでのパケット（例えば、「MOST SECRET」）トランジットには最高のリンクは感度レベルは、その最初の感度レベル（例えば、「SECRET未満であるため、デフォルトMLS MACポリシーの違反があります「）。
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.
WELL注：最初のホップルータは、未標識のIPv4パケットを受信した場合、発行日時点で存在するいくつかのIPv4 MLSネットワークの展開において、ルータは、上述のように、その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は、セキュリティゲートウェイまたはルータがパケットによって運ばCALIPSOラベルに基づいてIPv6パケットにアクセス制御を適用することができることを保証するために、むしろIPv6宛先オプションよりも、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セキュリティ内部パケットのための機密保護を提供していない特殊なケースでは、外側のCALIPSO機密ラベルは、内側CALIPSO感度と同じ意味を持っている必要がありますラベル。例えば、（UNCLASSIFIED）の外側の機密ラベルとパケット内部（SECRET、なし区画）の機密ラベルで暗号化されていない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.
1が別のラベル付きIPパケット内にカプセル化（トンネル化）されたラベルされた平文のIPパケットを持っている場合、一般的な原則として、機密ラベルの意味は同じでなければなりません。これは、1つは、IPv6がIPv6でトンネリングされたIPv6、IPv4のトンネリングされた、またはIPv6は、IPv4でトンネリングされたかどうか本当です。これは、適切な強制アクセス制御を維持するために不可欠です。
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ネットワーク展開がガード（警備員として、時にはいくつかの演技）として機能する中間システムが含まれていることが、今一般的です。このような保護デバイスは、非常に急速に、各パケット内の機密ラベルを解析する入力インターフェイスMACポリシーを適用し、パケットの機密ラベルを意識しながら、パケットを転送した後、出力インターフェイス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.
少なくとも一つの前に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.
CALIPSOオプションデータは、（1）「DOI翻訳」は、信頼できる中間システムによって実行される（2）CALIPSOオプションは、非標識IPv6パケットを受信すると、信頼できる中間システムによって挿入される、または（場合を除き、途中で変更してはいけません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ルータは、これらのルータは、これらのパケットにMLS強制アクセス制御を適用することができるようにCALIPSOラベルを見ることができるようにする必要があるため、このルールが存在します。
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オプションを包むホップバイホップオプションヘッダの必要な（最初の）二つのフィールドと共にCALIPSOオプションを示しています。 CALIPSOオプションの設計は、HDR EXT LENフィールドとCALIPSOオプションの開始との間のパディングの16ビットの必要性を回避するために配置されています。それは通常、32ビット整列されるように、また、解釈フィールドのCALIPSOドメインがレイアウトされています。
------------------------------------------------------------
| 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オプションを認識していないにもかかわらず、ルータが正常に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パケットが断片化されたイベントでは、このオプションは断片化にコピーされなければなりません。事実上、すべてのユーザーが、このオプションを認証し、（b）に関連したIPv6パケットには、このオプションをバインドするIP認証ヘッダ（A）を使用しての選択をしたいです。
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ビット・ワードでコンパートメントビットマップフィールドの長さを測定すると、64ビット、32ビットを無駄にすることなく、IPv6のガイドラインに従って、整列するヘッダを許可することに注意してください。コンパートメントビットマップフィールドの長さのサイズのための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が何の区画を有していないし、その値とCALIPSO表現各々ゼロであり、単一のレベルを有します。 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.
RFC 1662の付録C [RFC1662]で定義されるように、この16ビットのフィールドは、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」ビットは、その、このパケット内のデータを保護しなければならない規則の下で別々の区画を表します。従って、各「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ビットの整列ルールを維持しなければなりません。必要とすることなく、 - コンパートメントビットマップフィールドは64ビットで整列される全体的なCALIPSOオプションの長さを可能にする32ビット・ワード（例えば、0ビット、32ビット、64ビット、96ビット）の量子の長さを有していることに注意してくださいすべてCALIPSOオプションを使用してNULLパディングの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つの機密ラベルの間で行われる方法を説明します。正しくこの比較を実装すると、入力するか、システムから送信されるトラフィックをネットワークすることを目的と強制アクセス制御（MACの）を提供するMLSシステムにとって非常に重要です。
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:
機密ラベル「M」は、特定の範囲は、「範囲内」である「LO：HI」場合に限り：
(M.DOI == LO.DOI == 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))
（（Lolev <= haylev）&&（lokap <= haykap））
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)
（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.
(LO.COMP <= M.COMP <= HI.COMP)
（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.
(M.DOI == LO.DOI == HI.DOI)
（M.DOI == == LO.DOI HI.DOI）
AND EITHER
いずれか
2. The Sensitivity Level of M is less than the
Sensitivity Level of 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.
(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」、LOはMを支配し、LOはMに等しくない場合
A Sensitivity Label "M" is "greater than" some Sensitivity Label "HI" if and only if:
機密ラベル「M」であり、いくつかの機密ラベル「HI」「より大きい」場合に限り：
(M.DOI == HI.DOI)
（M.DOI == HI.DOI）
AND EITHER
いずれか
2A. M's Sensitivity Level is above HI's Sensitivity Level.
図2（a）。 Mの感度レベルは、HIの感度レベルを上回っています。
(M.LEV > HI.LEV)
（M.LEV> HI.LEV）
OR
または
2B. M's Compartment Set is greater than HI's Compartment Set.
図2（b）。 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はHIを支配し、MはHIに等しくない場合。
A Sensitivity Label "A" is "equal to" another Sensitivity Label "B" if and only if:
機密ラベルは「」「等しい」である別の機密ラベル「B」の場合に限り：
(A.DOI == B.DOI)
（A.DOI == B.DOI）
(A.LEV == B.LEV)
（A.LEV == B.LEV）
(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:
これらの条件のいずれかに該当する場合、機密ラベルは「」別の機密ラベル「B」からばらばらです。
(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) ))
（^（（A <B）||（A> B）||（==の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のコンパートメントセットAのコンパートメントの設定を支配していないBのコンパートメントセットとBのコンパートメントの設定を支配していません。
(^( (A.COMP >= B.COMP) || (A.COMP <= B.COMP) ))
（^（（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:
ネットワークにデータを送信エンドシステムは、ネットワークへの「輸出」それをすると言われています。データグラムがエンドシステムを残すことができますし、ネットワークを介して送信する前に、次の順序の手順を行う必要があります：
a) If the upper-level protocol selects a DOI, then that DOI is selected.
上位プロトコルがDOIを選択した場合A）、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）そうでなければ、DOIが選択され、その、送信論理インタフェース（すなわち、IPアドレス）に関連付けられた特定の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などのいくつかの適切なエラーで、例えば）接続の失敗を示すべきです。この障害は、それが中間システムを介してDOIことでIPv6パケットを送信することが許可されていないノードのための中間システムまたは終端システム又は（2）正しい動作のいずれかの（1）誤った構成を表します。
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が異なる感度の範囲に対応する）の思いやりの使用は、そのような展開に適切なシステム構成を容易かもしれません。
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機密ラベルにマップされない場合には、エラーが上位レベルのプロトコルに返されるべきであると、そのエラーが記録されることがあります。このデータグラムを送信するためにこれ以上の試みがなされるべきではありません。
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.
データグラムがマークされ、送信論理インターフェイスは、（ルーティング・コードによって）選択されると、データグラムの機密ラベルは、論理インタフェースに関連付けられた機密ラベル範囲（S）と比較されます。データグラムを送信するためには、インタフェースが許容DOIのの一つとして、データグラムの機密ラベルの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.
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.
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のパケットフォーマットは、1が最低感度レベルとの中間システムを構成できるように設計され、最大感度レベル、最小コンパートメントビットマップ、および最大コンパートメントビットマップされました - その後、詳細な人間の意味を知るために、システムを強制することなく、そのシステムを導入します各感度レベルまたはコンパートメントビット値。最小値と最大値のラベルが設定されたら、代わりに、中間システムは、パケットが所定のインターフェイスのための範囲内であるか否かを判断するために単純なアルゴリズムを適用することができます。この設計は、オプションのフォーマットは、シンプルで解析が容易であることから、特定用途向け集積回路（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.
中間システムは、エンドシステムが行うよりも処理のマークデータグラムのために、わずかに異なるルールを持っています。主に、中間システムは、彼らはちょうどそれらを転送し、中継データグラムをインポートまたはエクスポートしません。また、ほとんどの展開では、中間システムは、複数のサブネットワークを通過するパケットに強制アクセス制御を提供するために使用されています。
The following checks MUST occur before any other processing. Upon receiving a CALIPSO-labeled packet, an Intermediate System must:
以下のチェックは、任意の他の処理の前に発生しなければなりません。 CALIPSO - ラベル付きパケットを受信すると、中間システム必要があります：
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.
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.
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.
この時点で、データグラムは中間システムのための許容範囲内にあるので、適切なICMPエラーメッセージは、データグラムの転送に関するバック元のエンドシステムへのIPモジュールによって生成することができます。これらの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に1つの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.
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.
禁止DOIを持つか、範囲外の機密ラベル3.データグラムを下げなければなりません。任意のドロップイベントは、適切なデータグラムがドロップされたかについての詳細とその理由を含め、セキュリティ違反としてログインする必要があります。
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.
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から別の「翻訳」と言われています。データグラムが再ラベル付けすることができる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機密ラベルが直接新しい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.
このセクションの残りの部分は、直接再ラベル付けである第二の方法を記載しています。再ラベル付けに使用する方法の選択は、この文書の範囲外の実装決定です。
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に記載中間システム入力処理と、入力検証を通過した、有効なものとして受け入れられていると、そのデータグラムにCALIPSOの再ラベル付けされてもよいです。新しい機密ラベルを決定するには、まず新しい出力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が選択されている方法についての正確な詳細は、それが一貫して可逆的であることを警告して、実装に依存しています。 DOI YにDOI XマップとシステムBのエンドツーエンドのシステムAからのデータグラムならば、BからDOI 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エラーメッセージの原因となるエラーが静かにせずにデータグラムをドロップしなければならない代わりに、元のエンドシステムに戻って生成されることを除いて、続いています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ネットワーク展開内の流れを特定していないので、いくつかのアプリケーションやサービスは、複数によって影響を受ける可能性がありますマッピングは、単一の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コンテンツへのアクセス）は操作上の困難や特別な変更を必要とせずに、およそ二十年のためにMLSネットワークの展開に含まれて。これらの一般的なアプリケーションを使用する機能は、特定の詳細（例えば、IPデータグラムにラベルを追加するには）変更を行うが、基本的なインターネットアーキテクチャは、MLSの展開に変わらないままであることを示しています。
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オペレーティングシステムを使用していません。代わりに、ラベル対応ルータは、そのルータのネットワークインタフェース（複数可）を入力し、残してIPパケットにあたり-論理インタフェースラベル指向のアクセス制御リスト（ACL）の適用を可能にする拡張機能の追加、従来のルータ・オペレーティング・システムを使用する場合があります。
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ネットワークの展開は、変更せずに、例えば、差別化サービス、多くのプロトコルや仕様を使用します。彼らは、単一の流れであるかのように差別化サービスについては、これは（すなわち、そのCALIPSOラベル値のみが異なるフロー）複数の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
このラベルオプションに基づいて強制アクセス制御を適用するためのハードウェアサポートがある場合は、ルータのパフォーマンスが最適化されています。 CIPSOの問題は、オプションの構文は[FIPS-188]非常に複雑であるということです。だから、このラベルオプションは単純化された構文を使用しています。この
should make it more practical to create custom logic (e.g., in Verilog) with support for this option and the associated Mandatory Access Controls.
このオプションと関連する強制アクセス制御をサポートする（例えば、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].
このセクションでは、決定はCALIPSOオプションを含む受信したIPv6パケットを受け入れるようになされた後MLSエンドシステムが内部的に情報を処理する方法のための完全な仕様ではありません。 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エンドシステムは、その情報へのトランスポート層セッションを含む、処理され、またはそのアプリケーション情報が配信される方法を決定するためにベル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.
このセクション内では、我々は明確かつ簡潔両方する試みで、一つの追加の表記を使用しています。ここでは、文字列「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オプションを使用してデータグラム（それが複数の仮想ネットワーク内に存在する場合、それはしなければならない - 例えば、「マルチレベルセキュア」システム）ラベル場合は、TCP接続が送信元と宛先ポートによって識別され、送信元と送信先アドレスを、内部機密ラベル（必要に応じて、機密ラベル範囲）。これは、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.
特定のリモートIPアドレスまたはローカルIPアドレスに結合することなく - この1つの結果は、UDPとIPv6の広く使われているエンドシステムの実装では、UDPリスナーが唯一のエンドシステム上の特定の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.
「：AB S」との最大UDPポートX上のリスナーが最小感度ラベル範囲がある場合、例えば、「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はWを支配する）、次いで、データグラムはとUDPポートY宛て機密ラベル「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 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対多の通信セッションをサポートすることができます。
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.
単一レベルのエンドシステムでは、一対一のモードでは、単一のローカル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インスタンスへの複数の接続が存在することはできません。従って、単一レベルのエンドシステムにおいて、一対多モードでは、ローカル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エンドシステムでは、SCTPモードのいずれかのために、SCTPセッション状態は、さらに、各SCTPセッションのための機密ラベルを含んでいます。単一の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アドレスを持っている同じエンドポイントに属し異なるIPアドレスに一方のエンドポイントのIPアドレスから既存のSCTPセッションをシフトする能力を持っています。そのようなシフトは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
ノードがあるかもしれないが、さらに、マルチホーム、これらのインターフェースの一方だけが所与の機密ラベル値が到達可能であることは完全に可能です。例えば、ノード上のネットワークインターフェイスは、機密ラベルの範囲を持っているかもしれないから「::」に：（BはA支配）「B XY」、同じノード上の異なるネットワークインタフェースから機密ラベル範囲を有するかもしれないが"U ::" "U ::"（AがUを支配します）。その例では、パケットがのCALIPSOラベルを持っている場合
"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.
ESPヌル暗号化メカニズムでのみIPv6パケットのペイロードではなく、任意のホップバイホップオプションを保護することができます。対照的に、AHはCALIPSOホップバイホップオプションを含むIPv6パケットのすべての不変のヘッダとデータを、保護します。 CALIPSOオプションは、彼らがパケットにMACポリシーを適用できるように、IPv6ルーターとセキュリティゲートウェイによってに見え、かつ解析可能にする必要があるため、この文書で定義されたCALIPSOオプションは、常に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をするために使用することができるように - AHが受信者エンドシステム、だけでなく、パスに沿って1つまたは複数のセキュリティゲートウェイではないだけにして、左右対称の認証アルゴリズムで使用されている場合、対称鍵の知識を持っていることが予想されますCALIPSOのラベルを含め、パケットを認証します。この場合には、その対称認証キーを知っているすべてのデバイスは、信頼される必要があるであろう。受信者と認証キーの知識を持つ任意のセキュリティゲートウェイは、CALIPSOのラベルを含め、パケットを認証できるように、また、AHは、非対称認証アルゴリズムを使用することができます。
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標識パケットの変更は、結果のパケットが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の違い、あるいは他の構成されたセキュリティポリシーは、意図に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仕様明確化は、主に、常に[TNI] [MLOSPP】実装されている方法ネットワークMLSシステム明確にするために特定の既知の隠れチャネルの帯域幅を低減するために起こるが、存在します。
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パケットはよく、適切な暗号保護を受けた後、パブリックインターネットを通過する可能性があります。例えば、CALIPSO標識されたパケットは、（暗号化）トンネルモードESP二つ以上のMLS-標識されたネットワークセグメントを接続するVPNトンネルを介して移動する可能性があります。また、CALIPSO標識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].
専門家レビュー手順[RFC5226]以下の組織にIANAによって割り当てについては255：255：255：254から0：0：0：1。
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：この仕様の可能性改正により、将来の使用のためにIETFに予約されて255。
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.
小数0で始まる他のすべてのCALIPSO DOI値は：パーティーの同意の間で私的使用のために予約されています。この範囲の値は、任意の特定のユーザまたはユーザコミュニティに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.
0：0：0から254：255：255：CALIPSO DOIは1の値に対して（包括的）255をDOI割り当て要求を受信したとき、IANAは、専門家レビュー手順に従ってください。
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年の様々な変更は、IPv6ではなくIPv4のをサポートするために、主に、それ以来行われてきた年頃のマイクStJohnsによって書かれた「IPSOの息子（SIPSO）」と題したインターネットドラフトに由来しています。コンセプト、ほとんどの定義、およびほぼすべてここでの処理ルールのは、その以前の文書と同一です。
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. Bruzenak、ジェームズ・カールソン、パシEronen、マイケル・フィドラー、ボブHindenとアルフレッドHoenes、ラスHousley、スレシュクリシュナン、ジャレット呂、ダン・マクドナルド、ポール・ムーア、ジョーナル、デーブ・パーカー、ティムポーク、ケン・パウエル、ランドール・スチュワート、ビルゾンマーフェルト、そして、（姓のアルファベット順にリストされている）ジョー・タッチは、このドキュメントの以前のバージョンで特定のフィードバックを提供します。
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]シンプソン、W.、エド。、 "PPP HDLCのようなフレーミングで"、STD 51、RFC 1662、1994年7月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、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. 、テクニカルレポートM74-244、MITRE社、ベッドフォード、マサチューセッツ州、1973年5月：とLaPadula、L.J.は、「数学基礎とモデルのコンピュータシステムをセキュア」。
[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.セキュリティとプライバシー、頁184から194、IEEEコンピュータ学会、オークランド、CA、1987年5月にIEEEシンポジウムでウィルソン、「商業の比較と軍事コンピュータセキュリティポリシー」、。
[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、ワシントンD.C.、1991年11月。
[DoD5200.1-R] US Department of Defense, "Information Security Program Regulation", DoD 5200.1-R, 17 January 1997.
[DoD5200.1-R]米国国防省、 "情報セキュリティプログラム規程"、国防総省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]米国国防省、 "信頼されたコンピュータシステム評価基準"、国防総省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] NCSC-TG-005（米国）国家のコンピュータセキュリティセンター、 "信頼されたコンピュータシステム評価基準の信頼できるネットワークの解釈（TNI）"、バージョン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、ニューヨーク、NY、USA、2006年5月19日。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC1038] St. Johns, M., "Draft revised IP security option", RFC 1038, January 1988.
[RFC1038]セントジョンズ、M.、1988年1月、RFC 1038 "ドラフトは、IPセキュリティオプションを改訂しました"。
[RFC1108] Kent, S., "U.S. Department of Defense Security Options for the Internet Protocol", RFC 1108, November 1991.
[RFC1108]ケント、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
Authors' Addresses
著者のアドレス
Michael StJohns Germantown, MD USA
マイケルStJohnsジャーマンタウン、MD USA
EMail: mstjohns@comcast.net
メールアドレス：mstjohns@comcast.net
Randall Atkinson Extreme Networks 3585 Monroe Street Santa Clara, CA USA 95051
ランドール・アトキンソンエクストリームネットワークス3585モンローストリートサンタクララ、CA USA 95051
EMail: rja@extremenetworks.com Phone: +1 (408)579-2800
メールアドレス：rja@extremenetworks.com電話：+1 (408)579-2800
Georg Thomas US Department of Defense Washington, DC USA
防衛ワシントンD.C. USAのゲオルク・トーマス米国務省