Network Working Group J. Luciani
Request for Comments: 2520 Nortel Networks
Category: Experimental H. Suzuki
Cisco Systems
N. Doraswamy
Nortel Networks
D. Horton
CiTR Pty Ltd
February 1999
NHRP with Mobile NHCs
Status of this Memo
このメモの位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
This document describes an extension to NHRP [1] which would allow Mobile NHCs to perform a registration with and attach to an NHS in their home LIS in an authenticated manner.
この文書では、モバイルNHCSが登録を行い、認証された方法で、自宅のLISにNHSに接続できるようになるNHRP [1]の拡張機能について説明します。
As described in this document, Mobile NHCs are NHCs which are not configured with enough information to find a specific serving NHS in their home LIS, but which have a mechanism to find an NHS (which may or may not be a serving NHS) to which they will attach. As described in [1], an NHC may attach to a 'surrogate' NHS by using a mechanism such as an anycast address. In this case, the NHC may use the surrogate NHS to send a NHRP Registration Request toward the NHC's home LIS where a serving NHS resides. However, as defined in [1], packet authentication is performed on a hop by hop basis. In the mobile NHC case, it is not practical for the mobile NHC be in a security relationship with every surrogate NHS, thus it is presumably desirable to have some form of end to end only authentication for the case of a mobile NHC's registration. This document describes an authentication extension for NHRP which has such end to end only semantics.
この文書に記載されているように、モバイルNHCSは自宅のLISにNHSをサービング特定を見つけるために十分な情報で構成されていないNHCSがあるが、これは（またはサービングNHSであってもなくてもよい）NHSのを見つけるための機構を有しています彼らが添付されます。 [1]に記載されているように、NHCは、エニーキャストアドレスのようなメカニズムを使用して、「代理」NHSに取り付けることができます。この場合、NHCは、サービングNHSが常駐NHCのホームLISに向けてNHRP登録要求を送信するために代理NHSを使用することができます。ただし、で定義されるように[1]、パケットの認証は、ホップバイホップで行われます。モバイルNHCは、すべての代理NHSとの安全保障関係にあるため、携帯NHC場合、それはこのように、携帯NHCの登録の場合のみ認証をエンド・ツー・エンドのいくつかのフォームを持っていると思われることが望ましいが、実用的ではありません。この文書では、唯一のセマンティクスを終了するには、このような端部を有するNHRPための認証拡張について説明します。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [4].
キーワードは、REQUIREDは、、、、、MAYを推奨、オプション、彼らは、この文書に表示されたときに、で説明したように解釈されるすべきでないないものとものとしてはなりませんしなければならない[4]。
This document describes an extension for Mobile NHCs to use when they wish to register with their home LIS but initially connect to a non-serving NHS to do so. The reader is encouraged to read [1] for more details on the NHRP registration process.
この文書では、彼らは彼らのホームLISに登録したが、最初はそうする非サービングNHSに接続したいときに使用するモバイルNHCSの拡張について説明します。読者はNHRP登録処理の詳細については、[1]を読み出すことが奨励されます。
Compulsory = 1
Type = 10 (proposed)
Length = variable
The NHRP Mobile NHC Authentication Extension is carried in NHRP Registration packets to convey end to end authentication Information. This extension is defined in contrast to the NHRP Authentication Extension defined in [1] which has hop by hop semantics.
NHRPモバイルNHC認証拡張機能は、認証情報をエンドツーエンドを伝えるためにNHRP登録パケットで運ばれます。この拡張は、[1]のホップセマンティクスによりホップを有する、定義されたNHRP認証拡張とは対照的に定義されています。
This new extension is used when a mobile NHC initially connects to an NHS which is not one of its serving NHSs and the mobile NHC and nonserving NHS are not in a security relationship. The mobile NHC does this in order to send an NHRP Registration Request, via normal routing and forwarding processes, to one of its serving NHSs with which it does have a security relationship. As defined in [1], a serving NHS is an NHS in the NHC's home LIS with which the NHC will register. Upon receiving such an NHRP Registration Request, the serving NHS will do the following: authenticate the sender NHC, set up a VC to the NHC, and then send an NHRP Resolution Reply in response on that new VC.
モバイルNHCが最初にそのNHSSとモバイルNHCにサービスを提供し、nonserving NHSの一つは、セキュリティ関係にされていないではありませんNHSに接続したときに、この新しい拡張機能が使用されています。モバイルNHCは、それが安全保障関係を持っていたとそのサービス提供NHSSの一つに、通常のルーティングおよび転送プロセスを経て、NHRP登録要求を送信するためにこれを行います。 [1]で定義されているように、サービス提供NHSは、NHCが登録されるNHCのホームLISにNHSです。このようNHRP登録要求を受信すると、サービングNHSは、次の操作を行います：、送信者を認証NHC NHCにVCを設定し、その新しいVCに応じて返信NHRP解決を送ります。
Note that, as defined in [1], a transit NHS (such as the one to which the mobile NHC initially connects) must ignore an extension which it does not understand and that an NHS must not change the order of extensions in an NHRP packet. Thus, the end to end semantics of this extension are preserved without causing changes to existing implementations.
[1]で定義されるように、なお、（モバイルNHCが最初に接続するものとして）通過NHSそれが理解していない拡張子を無視し、NHSがNHRPパケット内の拡張の順序を変更してはならないことをしなければなりません。従って、この拡張のセマンティクスをエンドツーエンドは、既存の実装に対する変更を引き起こすことなく保存されます。
If a serving NHS receives a packet which fails the hop by hop authentication test defined in [1] then the NHS MUST generate an Error Indication of type 'Authentication Failure' and discard the packet. However in the case where the NHRP Mobile NHC Authentication Extension is used as described above, sending an Error Indication is not possible since no route exists back toward the mobile NHC assuming a VC does not already exist between the mobile NHC and the serving NHS which received the NHRP Registration Request. In this case, the NHRP Registration Request is merely dropped.
サービングNHSは、で定義されたホップ認証試験によりホップを失敗パケットを受信した場合[1]次に、NHSは、タイプ「認証失敗」のエラー表示を生成し、パケットを破棄しなければなりません。 NOルートVCが既に受信した移動NHCとなるNHSとの間に存在しないと仮定すると、モバイルNHC向かってバックが存在しないのでエラー表示を送信し、上記のようにNHRPモバイルNHC認証拡張機能を用いた場合には不可能ですNHRP登録要求。この場合、NHRP登録要求は単に廃棄されます。
The authentication header has the following format:
認証ヘッダは、以下の形式を有します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Security Parameter Index (SPI)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Addr... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Security Parameter Index (SPI) can be thought of as an index into a table that maintains the keys and other information such as a hash algorithm. Src and Dst communicate either offline using manual keying or online using a key management protocol to populate this table. The sending NHRP entity always allocates the SPI and the parameters associated with it.
セキュリティパラメータインデックス（SPI）は、ハッシュアルゴリズムのようなキーおよび他の情報を保持するテーブルへのインデックスとして考えることができます。 SrcとDSTは、この表を移入する鍵管理プロトコルを使用して手動キーイングまたはオンラインを使用してオフラインのいずれかを伝えます。送信NHRPエンティティは常にSPIおよびそれに関連するパラメータを割り当てます。
The Src Addr field is a variable length field which contains the address assigned to the outgoing interface. The length of the field is obtained from the source protocol length field in the mandatory part of the NHRP header. The tuple <spi, src addr> uniquely identifies the key and the other parameters that are used in authentication.
SrcのADDRフィールドは、発信インターフェイスに割り当てられたアドレスを含んでいる可変長フィールドです。フィールドの長さは、NHRPヘッダの必須の部分でソースプロトコル長フィールドから得られます。タプル<SPI、SRC ADDR>一意キーと認証に使用される他のパラメータを識別する。
The length of the authentication data field is dependent on the hash algorithm used. The Authentication Data field contains the keyed hash calculated over the following fields: fixed part (with hop count, packet size and checksum being treated as if set to zero), mandatory part, and extensions up to and including the Mobile NHC Authentication extension.
認証データフィールドの長さは、使用するハッシュアルゴリズムに依存しています。固定部（ホップ数、パケットサイズおよびチェックサムがゼロに設定されている場合のように治療されると）、必須の部分、及びモバイルNHC認証拡張を含むまでと拡張：認証データフィールドには、次のフィールドにわたって計算キー付きハッシュを含んでいます。
Note that [1] defines an explicit ordering of extensions such that:
：[1]その結果、拡張の明示的な順序付けを定義することに注意してください
(a) If the Responder Address extension exists then it must appear before the Authentication Extension.
レスポンダアドレスの拡張子が存在する場合（a）は、それが認証拡張の前に現れなければなりません。
(b) Any extensions that may be modified in transit (e.g., Forward Transit Extension, Hop by Hop Authentication Extension) must appear after the Mobile NHC Authentication Extension.
（B）中に変更され得る任意の拡張子（例えば、ホップ認証拡張により前方トランジット拡張、ホップ）モバイルNHC認証拡張の後に現れなければなりません。
SPI's can be negotiated either manually or using an Internet Key Management protocol. Manual keying MUST be supported. The following parameters are associated with the tuple <SPI, src>- lifetime, Algorithm, Key. Lifetime indicates the duration in seconds for which the key is valid. In case of manual keying, this duration can be infinite. Also, in order to better support manual keying, there may be multiple tuples active at the same time (Dst being the same).
SPIのは、手動またはインターネット鍵管理プロトコルを使用してネゴシエートすることができます。手動キー入力をサポートしなければなりません。生涯、アルゴリズム、キー - 次のパラメータは、タプル<SPI、SRC>に関連しています。寿命は、キーが有効である秒数を示します。手動キー入力の場合には、この期間は無限にすることができます。また、より良好な手動キーイングをサポートするために、同時にアクティブな複数のタプルが存在してもよい（DSTは同じです）。
Algorithm specifies the hash algorithm agreed upon by the two entities. HMAC-MD5-128 [2] is the default algorithm and MUST be implemented. Other algorithms MAY be supported by defining new values. IANA will assign the numbers to identify the algorithm being used as described in [1].
このアルゴリズムは、2つのエンティティが合意したハッシュアルゴリズムを指定します。 HMAC-MD5-128 [2]はデフォルトのアルゴリズムであり、実施されなければなりません。他のアルゴリズムは、新しい値を定義することによってサポートされるかもしれません。 IANAは、[1]に記載のように使用されるアルゴリズムを識別するために番号を割り当てます。
Any Internet standard key management protocol MAY so be used to negotiate the SPI and parameters.
任意のインターネット標準の鍵管理プロトコルはとてもSPIとパラメータを交渉するために使用されるかもしれません。
Unauthenticated 'Mobile' Registration Request processing proceeds as follows [1]:
認証されていない「モバイル」登録要求処理は以下のように進行する[1]：
- the NHC inserts the internetwork address of a serving NHS in the 'Destination Protocol Address' field; If the NHS address is unknown, then the NHC inserts its own internetwork address. A ' responder address' extension is optionally added. - the non-serving NHS forwards the packet along the routed path based on the contents of the 'Destination Protocol Address' field. - the serving NHS which receives the NHRP Registration Request will set up a direct VCC to NHC after authenticating the request - the serving NHS will then send the NHRP Registration Reply back to the NHC on that new VCC. Note that the NHS MUST wait some configured interval before doing this reply in order to prevent a race condition from occurring between the VC setup and sending the NHRP reply packet. - the NHC will subsequently send all NHRP traffic to the serving NHS on the direct VCC.
- NHCは、「宛先プロトコルアドレス」欄におけるサービス提供NHSのインターネットアドレスを挿入します。 NHSアドレスが不明な場合は、NHCは独自のインターネットアドレスを挿入します。 「応答アドレス」拡張は、必要に応じて添加されます。 - 非サービングNHSは、「宛先プロトコルアドレス」フィールドの内容に基づいてルーティングされたパスに沿ってパケットを転送します。 - NHRP登録リクエストを受信提供NHSは、要求を認証した後、NHCに直接VCCを設定します - サービス提供NHSは、その新しいVCCに戻っNHCにNHRP登録応答を送信します。 NHSは、VCのセットアップとの間で発生するとNHRP応答パケットを送信することから、競合状態を防ぐために、この返信を行う前に、いくつか設定された間隔を待たなければならないことに注意してください。 - NHCはその後、直接VCCに役立つNHSへのすべてのNHRPトラフィックを送信します。
When the NHC adds the authentication extension header, it performs a table look up in order to fetch the SPI and the security parameters based on the outgoing interface address. If there are no entries in the table and if there is support for key management, the NHC initiates the key management protocol to fetch the necessary parameters. The NHC constructs the Authentication Extension payload and calculates the hash by zeroing out the authentication data field. The result is placed in the authentication data field. The src address field in the payload is the internetwork address assigned to the outgoing interface.
NHCは、認証拡張ヘッダを追加すると、テーブルはSPIと発信インタフェースアドレスに基づいて、セキュリティ・パラメータを取得するためにルックアップ行います。何のエントリがテーブルに存在しないと鍵管理のためのサポートがある場合ならば、NHCは必要なパラメータを取得するための鍵管理プロトコルを開始します。 NHCは、認証拡張ペイロードを構築し、認証データフィールドをゼロにすることによってハッシュを計算します。結果は、認証データフィールドに置かれています。ペイロードのsrcアドレスフィールドには、発信インターフェイスに割り当てられたインターネットアドレスです。
If key management is not supported and authentication is mandatory, the packet is dropped and this information is logged.
鍵管理がサポートされていないと、認証が必須の場合、パケットはドロップされ、この情報が記録されます。
On the receiving end, the serving NHS fetches the parameters based on the SPI and the internetwork address in the authentication extension payload. The authentication data field is extracted before being zeroed out in order to calculate the hash. It computes the hash on the entire payload and if the hash does not match, then an "abnormal event" has occurred.
受信側では、サービングNHSは、SPI、認証拡張ペイロード内のインターネットアドレスに基づいてパラメータを取り出します。認証データフィールドは、ハッシュを計算するためにゼロにされる前に抽出されます。これは、ペイロード全体にハッシュを計算し、ハッシュが一致しない場合は、「異常事象は、」発生しました。
The keys used by the mobile NHC for communicating with the serving NHS in NHRP Registration Requests can be used in subsequent resolution and purge requests made directly to the serving NHS after receiving the NHRP Registration Reply. However, the authentication extension defined in [1] MUST be used when these keys are applied to resolution and purge packets.
NHRP登録要求に役立つNHSと通信するためのモバイルNHCによって使用されるキーは、NHRP登録応答を受信したサービングNHSに対して直接行わ後続の解像度とパージ要求で使用することができます。これらのキーは、解像度及びパージパケットに適用される場合しかし、[1]で定義された認証拡張を使用しなければなりません。
Hop by Hop Authentication[1] and End to End authentication MAY be used in combination to provide protection against both spoofing and denial of service attacks. If only an end-to-end Mobile NHC Authentication Extension is present, it MAY be the policy of each transit NHS to reject the NHRP Registration Request based on the requirement for having a Hop by Hop authentication present. Such a requirement is a local matter.
[1]ホップ認証によってホップと認証はなりすましやサービス拒否攻撃の両方に対する保護を提供するために組み合わせて使用されるかもしれエンドツーエンド。唯一のエンドツーエンドのモバイルNHC認証拡張が存在する場合、ホップ認証存在によりホップを有するための要件に基づいてNHRP登録要求を拒否するために、各中継NHSの方針であるかもしれ。このような要件は、ローカルの問題です。
It is important that the keys chosen are strong since the security of the entire system depends on the keys being chosen properly.
システム全体のセキュリティが適切に選択されたキーに依存するので、選択したキーが強いことが重要です。
End-to-end authentication counters spoofing attacks on the home subnet through not relying on the potentially compromised chain of trust. The use of end-end authentication is further described in [3].
信頼の潜在的に危険にさらさチェーンに頼らないを通じてホームサブネット上の攻撃を偽装エンドツーエンドの認証カウンター。エンド・エンド認証の使用はさらに、[3]に記載されています。
Hop-by-hop authentication prevents denial of service attacks by introducing access control at the first point of contact to the NHRP infrastructure.
ホップバイホップ認証がNHRPインフラストラクチャへの接触の最初の時点でのアクセス制御を導入することにより、サービス拒否攻撃を防止します。
The security of this extension is performed on an end to end basis. The data received can be trusted only so much as one trusts the end point entities in the path traversed. A chain of trust is established amongst NHRP entities in the path of the NHRP Message. If the security in an NHRP entity is compromised, then security in the entire NHRP domain is compromised.
この拡張機能のセキュリティは、最終的にエンドで行われます。受信したデータは1つが横断パス内のエンドポイントエンティティを信頼するようにのみそんなに信頼することができます。信頼の連鎖は、NHRPメッセージのパスでNHRPのエンティティ間で確立されています。 NHRPエンティティのセキュリティが侵害された場合には、全体のNHRPドメインのセキュリティが侵害されます。
Data integrity covers the entire NHRP payload up to and including the Mobile NHC Authentication Extension. This guarantees that the data and extensions covered by this authentication hash were not modified and that the source is authenticated as well. If the authentication extension is not used or if the security is compromised, then NHRP entities are liable to both spoofing attacks, active attacks, and passive attacks.
データの整合性は、モバイルNHC認証拡張機能を含めへとアップ全体NHRPペイロードをカバーしています。これは、この認証ハッシュによってカバーされたデータと拡張が変更されていないことを保証し、ソースも同様に認証されていること。認証拡張を使用しない場合や、セキュリティが侵害された場合、その後、NHRP実体は、スプーフィング攻撃、能動的な攻撃、および受動的攻撃の両方に責任を負います。
There is no mechanism to encrypt the messages. It is assumed that a standard layer 3 confidentiality mechanism will be used to encrypt and decrypt messages. It is recommended to use an Internet standard key management protocol to negotiate the keys between the neighbors. Transmitting the keys in clear text, if other methods of negotiation is used, compromises the security completely.
メッセージを暗号化するメカニズムはありません。標準のレイヤ3機密性のメカニズムは、メッセージの暗号化と復号化に使用されることが想定されます。近隣諸国との間の鍵を交渉するために、インターネットの標準的な鍵管理プロトコルを使用することをお勧めします。交渉の他の方法が使用されている場合はクリアテキストでキーを送信し、完全なセキュリティを危うくします。
References
リファレンス
[1] Luciani, J., Katz, D., Piscitello, D., Cole, B. and N. Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
[1]ルチアーニ、J.、カッツ、D.、Piscitello、D.、コール、B.およびN. Doraswamy、 "NBMAネクストホップ解決プロトコル（NHRP）"、RFC 2332、1998年4月。
[2] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed Hashing for Message Authentication", RFC 2104, February 1997.
[2] Krawczyk、H.、ベラー、M。およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ"、RFC 2104、1997年2月。
[3] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[3]パーキンス、C.、 "IPモビリティサポート"、RFC 2002、1996年10月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
Authors' Addresses
著者のアドレス
James V. Luciani Nortel Networks 3 Federal Street Mail Stop: BL3-03 Billerica, MA 01821
ジェームズ・V.ルチアーニNortel Networksの3連邦ストリートメール停止：BL3-03ビレリカ、MA 01821
Phone: +1 978 916 4734 EMail: luciani@baynetworks.com
電話：+1 978 916 4734 Eメール：luciani@baynetworks.com
Hiroshi Suzuki Cisco Systems 170 West Tasman Dr. San Jose, CA 96134
鈴木浩シスコシステムズ170西タスマン博士サンノゼ、CA 96134
Phone: +1 408 525 6006 EMail: hsuzuki@cisco.com
電話：+1 408 525 6006 Eメール：hsuzuki@cisco.com
Naganand Doraswamy Nortel Networks 3 Federal Street Mail Stop: BL3-03 Billerica, MA 01821
Naganand Doraswamy Nortel Networksの3連邦ストリートメール停止：BL3-03ビレリカ、MA 01821
Phone: +1 978 916 4734 EMail: naganand@baynetworks.com
電話：+1 978 916 4734 Eメール：naganand@baynetworks.com
David Horton CiTR PTY Ltd Level 2 North Tower 339 Coronation Drive Milton, Australia 4064
デビッド・ホートンCITR Pty Ltdのレベル2のノースタワー339戴冠式ドライブミルトン、オーストラリア4064
Phone: +61 7 32592222 EMail: d.horton@citr.com.au
電話：+61 7 32592222 Eメール：d.horton@citr.com.au
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。