RFC4849 日本語訳

Network Working Group                                         P. Congdon
Request for Comments: 4849                                    M. Sanchez
Category: Standards Track                      ProCurve Networking by HP
                                                                B. Aboba
                                                   Microsoft Corporation
                                                              April 2007

コメントを求めるワーキンググループP.コングドンの要求をネットワークでつないでください: 4849年のM.サンチェスカテゴリ: マイクロソフト社2007年4月にB.Abobaをhpでネットワークでつなぐ標準化過程ProCurve

                      RADIUS Filter Rule Attribute

半径フィルタ規則属性

Status of This Memo

このメモの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(2007)。

Abstract

要約

   While RFC 2865 defines the Filter-Id attribute, it requires that the
   Network Access Server (NAS) be pre-populated with the desired
   filters.  However, in situations where the server operator does not
   know which filters have been pre-populated, it is useful to specify
   filter rules explicitly.  This document defines the NAS-Filter-Rule
   attribute within the Remote Authentication Dial In User Service
   (RADIUS).  This attribute is based on the Diameter NAS-Filter-Rule
   Attribute Value Pair (AVP) described in RFC 4005, and the
   IPFilterRule syntax defined in RFC 3588.

RFC2865はFilter-イド属性を定義しますが、それは、Network Access Server(NAS)は必要なフィルタを前もって置いておかれるのを必要とします。 しかしながら、サーバオペレータが、どのフィルタが前もって置いておかれたかを知らない状況で、明らかにフィルタ規則を指定するのは役に立ちます。 このドキュメントはRemote Authentication Dial In User Service(RADIUS)の中でNASフィルタ規則属性を定義します。 この属性はAttribute Value Pair(AVP)がRFC4005で説明したDiameter NASフィルタ規則、およびRFC3588で定義されたIPFilterRule構文に基づいています。

Congdon, et al.             Standards Track                     [Page 1]

RFC 4849                 Filter Rule Attribute                April 2007

コングドン、他 規格はフィルタ規則属性2007年4月にRFC4849を追跡します[1ページ]。

Table of Contents

目次

   1. Introduction ....................................................2
      1.1. Terminology ................................................2
      1.2. Requirements Language ......................................3
      1.3. Attribute Interpretation ...................................3
   2. NAS-Filter-Rule Attribute .......................................3
   3. Table of Attributes .............................................5
   4. Diameter Considerations .........................................5
   5. IANA Considerations .............................................6
   6. Security Considerations .........................................6
   7. References ......................................................7
      7.1. Normative References .......................................7
      7.2. Informative References .....................................7
   8. Acknowledgments .................................................7

1. 序論…2 1.1. 用語…2 1.2. 要件言語…3 1.3. 解釈を結果と考えてください…3 2. NASフィルタ規則属性…3 3. 属性のテーブル…5 4. 直径問題…5 5. IANA問題…6 6. セキュリティ問題…6 7. 参照…7 7.1. 標準の参照…7 7.2. 有益な参照…7 8. 承認…7

1.  Introduction

1. 序論

   This document defines the NAS-Filter-Rule attribute within the Remote
   Authentication Dial In User Service (RADIUS).  This attribute has the
   same functionality as the Diameter NAS-Filter-Rule AVP (400) defined
   in [RFC4005], Section 6.6, and the same syntax as an IPFilterRule
   defined in [RFC3588], Section 4.3.  This attribute may prove useful
   for provisioning of filter rules.

このドキュメントはRemote Authentication Dial In User Service(RADIUS)の中でNASフィルタ規則属性を定義します。 この属性に、[RFC4005]、セクション6.6、および[RFC3588](セクション4.3)で定義されたIPFilterRuleと同じ構文で定義されたDiameter NASフィルタ規則AVP(400)と同じ機能性があります。 この属性はフィルタ規則の食糧を供給するために有用であることが分かるかもしれません。

   While [RFC2865], Section 5.11, defines the Filter-Id attribute (11),
   it requires that the Network Access Server (NAS) be pre-populated
   with the desired filters.  However, in situations where the server
   operator does not know which filters have been pre-populated, it is
   useful to specify filter rules explicitly.

[RFC2865](セクション5.11)はFilter-イド属性(11)を定義しますが、それは、Network Access Server(NAS)は必要なフィルタを前もって置いておかれるのを必要とします。 しかしながら、サーバオペレータが、どのフィルタが前もって置いておかれたかを知らない状況で、明らかにフィルタ規則を指定するのは役に立ちます。

1.1.  Terminology

1.1. 用語

   This document uses the following terms:

このドキュメントは次の用語を使用します:

   Network Access Server (NAS)
      A device that provides an access service for a user to a network.

アクセス・サービスをユーザに提供するAccess Server(NAS)Aデバイスをネットワークにネットワークでつないでください。

   RADIUS server
      A RADIUS authentication server is an entity that provides an
      authentication service to a NAS.

RADIUSサーバA RADIUS認証サーバはNASへの認証サービスを提供する実体です。

   RADIUS proxy
      A RADIUS proxy acts as an authentication server to the NAS, and a
      RADIUS client to the RADIUS server.

RADIUSプロキシA RADIUSプロキシはNASへの認証サーバ、およびRADIUSサーバへのRADIUSクライアントとして務めます。

Congdon, et al.             Standards Track                     [Page 2]

RFC 4849                 Filter Rule Attribute                April 2007

コングドン、他 規格はフィルタ規則属性2007年4月にRFC4849を追跡します[2ページ]。

1.2.  Requirements Language

1.2. 要件言語

   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 [RFC2119].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?

1.3.  Attribute Interpretation

1.3. 属性解釈

   If a NAS conforming to this specification receives an Access-Accept
   packet containing a NAS-Filter-Rule attribute that it cannot apply,
   it MUST act as though it had received an Access-Reject.  [RFC3576]
   requires that a NAS receiving a Change of Authorization Request
   (CoA-Request) reply with a CoA-NAK if the Request contains an
   unsupported attribute.  It is RECOMMENDED that an Error-Cause
   attribute with value set to "Unsupported Attribute" (401) be included
   in the CoA-NAK.  As noted in [RFC3576], authorization changes are
   atomic so that this situation does not result in session termination,
   and the pre-existing configuration remains unchanged.  As a result,
   no accounting packets should be generated because of the CoA-Request.

この仕様に従うNASがそれが適用できないNASフィルタ規則属性を含むAccess受け入れているパケットを受けるなら、それはまるでAccess-廃棄物を受けたかのように行動しなければなりません。 [RFC3576]は、Requestがサポートされない属性を含んでいるならAuthorization Request(CoA-要求)のChangeを受けるNASがCoA-NAKと共に返答するのを必要とします。 「サポートされない属性」(401)への選択値群があるError-原因属性がCoA-NAKに含まれているのは、RECOMMENDEDです。 承認変化が[RFC3576]に述べられるように原子であるので、この状況はセッション終了をもたらしません、そして、先在の構成は変わりがありません。 その結果、CoA-要求のために会計パケットを全く生成するべきではありません。

2.  NAS-Filter-Rule Attribute

2. NASフィルタ規則属性

   Description

記述

   This attribute indicates filter rules to be applied for this user.
   Zero or more NAS-Filter-Rule attributes MAY be sent in Access-Accept,
   CoA-Request, or Accounting-Request packets.

この属性は、このユーザのために適用されるためにフィルタ規則を示します。 ゼロ、属性がAccess受け入れた状態で送られるかもしれないというより多くのNASフィルタ規則、CoA-要求、またはAccounting-リクエスト・パケット。

   The NAS-Filter-Rule attribute is not intended to be used concurrently
   with any other filter rule attribute, including Filter-Id (11) and
   NAS-Traffic-Rule [Traffic] attributes.  NAS-Filter-Rule and NAS-
   Traffic-Rule attributes MUST NOT appear in the same RADIUS packet.
   If a NAS-Traffic-Rule attribute is present, a NAS implementing this
   specification MUST silently discard any NAS-Filter-Rule attributes
   that are present.  Filter-Id and NAS-Filter-Rule attributes SHOULD
   NOT appear in the same RADIUS packet.  Given the absence in [RFC4005]
   of well-defined precedence rules for combining Filter-Id and NAS-
   Filter-Rule attributes into a single rule set, the behavior of NASes
   receiving both attributes is undefined, and therefore a RADIUS server
   implementation cannot assume a consistent behavior.

同時にNASフィルタ規則属性がいかなる他のフィルタ規則属性と共にも使用されることを意図しません、Filter-イド(11)とNASトラフィック規則[トラフィック]属性を含んでいて。 NASフィルタ規則とNASトラフィック規則属性は同じRADIUSパケットに現れてはいけません。 NASトラフィック規則属性が存在しているなら、この仕様を履行するNASは静かにどんな存在しているNASフィルタ規則属性も捨てなければなりません。 フィルタイドとNASフィルタ規則属性SHOULD NOTは同じRADIUSパケットに現れます。 Filter-イドとNASフィルタ規則属性をただ一つの規則セットに結合するための明確な先行規則の[RFC4005]の不在を考えて、両方の属性を受けるNASesの動きは未定義です、そして、したがって、RADIUSサーバ実装は一貫した振舞いを仮定できません。

   Where multiple NAS-Filter-Rule attributes are included in a RADIUS
   packet, the String field of the attributes are to be concatenated to
   form a set of filter rules.  As noted in [RFC2865], Section 2.3, "the
   forwarding server MUST NOT change the order of any attributes of the
   same type", so that RADIUS proxies will not reorder NAS-Filter-Rule
   attributes.

複数のNASフィルタ規則属性が含まれているところに、形成するために連結されるように、1セットのフィルタ規則はRADIUSパケット、属性のString分野に、あります。 [RFC2865]に述べられるようにセクション2.3、「推進サーバは同じタイプのどんな属性の注文も変えてはいけません」、RADIUSプロキシがそうしないように追加注文NASフィルタ規則属性です。

Congdon, et al.             Standards Track                     [Page 3]

RFC 4849                 Filter Rule Attribute                April 2007

コングドン、他 規格はフィルタ規則属性2007年4月にRFC4849を追跡します[3ページ]。

   A summary of the NAS-Filter-Rule Attribute format is shown below.
   The fields are transmitted from left to right.

NASフィルタ規則Attribute形式の概要は以下に示されます。 野原は左から右まで伝えられます。

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |      String...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 結びます。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

タイプ

      92

92

   Length

長さ

      >=3

>=3

   String

ストリング

      The String field is one or more octets.  It contains filter rules
      in the IPFilterRule syntax defined in [RFC3588], Section 4.3, with
      individual filter rules separated by a NUL (0x00).  A NAS-Filter-
      Rule attribute may contain a partial rule, one rule, or more than
      one rule.  Filter rules may be continued across attribute
      boundaries, so implementations cannot assume that individual
      filter rules begin or end on attribute boundaries.

String分野は1つ以上の八重奏です。 それは[RFC3588]で定義されたIPFilterRule構文でフィルタ規則を含んでいます、セクション4.3、独特のフィルタ規則がNUL(0×00)によって切り離されている状態で。 NAS規則をフィルターにかけるのである属性は部分的な規則、1つの規則、または1つ以上の規則を含むかもしれません。 フィルタ規則が属性境界の向こう側に続けられるかもしれないので、実装は、独特のフィルタ規則が属性境界で始まるか、または終わると仮定できません。

      The set of NAS-Filter-Rule attributes SHOULD be created by
      concatenating the individual filter rules, separated by a NUL
      (0x00) octet.  The resulting data should be split on 253-octet
      boundaries to obtain a set of NAS-Filter-Rule attributes.  On
      reception, the individual filter rules are determined by
      concatenating the contents of all NAS-Filter-Rule attributes, and
      then splitting individual filter rules with the NUL octet (0x00)
      as a delimiter.

独特のフィルタ規則を連結することによって作成されて、NUL(0×00)八重奏で切り離されたNASフィルタ規則属性SHOULDのセット。 結果として起こるデータは、1セットのNASフィルタ規則属性を得るために253八重奏の境界で分けられるべきです。 レセプションでは、独特のフィルタ規則はすべてのNASフィルタ規則属性のコンテンツを連結することによって、決定します、そして、次に、個々のフィルタを分けるのはデリミタとしてNUL八重奏(0×00)で統治されます。

Congdon, et al.             Standards Track                     [Page 4]

RFC 4849                 Filter Rule Attribute                April 2007

コングドン、他 規格はフィルタ規則属性2007年4月にRFC4849を追跡します[4ページ]。

3.  Table of Attributes

3. 属性のテーブル

   The following table provides a guide to which attributes may be found
   in which kinds of packets, and in what quantity.

以下のテーブルは属性がどの種類のパケット、およびどんな量に見つけられるかもしれないガイドを提供します。

   Access- Access- Access- Access-   CoA-  Acct-
   Request Accept  Reject  Challenge Req   Req   #   Attribute
    0       0+      0       0        0+    0+    92  NAS-Filter-Rule

アクセスアクセスアクセスアクセスCoA- Acct廃棄物挑戦Req Req#属性0 0+0 0 0+0+92NASフィルタ規則を受け入れるよう要求してください。

   The following table defines the meaning of the above table entries.

以下のテーブルは上のテーブル項目の意味を定義します。

     0     This attribute MUST NOT be present in the packet.
     0+    Zero or more instances of this attribute MAY be
           present in the packet.
     0-1   Zero or one instance of this attribute MAY be
           present in the packet.

0 この属性はパケットに存在しているはずがありません。 0+ゼロかこの属性の、より多くのインスタンスがパケットに存在しているかもしれません。 0-1 この属性のゼロか1つのインスタンスがパケットに存在しているかもしれません。

4.  Diameter Considerations

4. 直径問題

   [RFC4005], Section 6.6, defines the NAS-Filter-Rule AVP (400) with
   the same functionality as the RADIUS NAS-Filter-Rule attribute.  In
   order to support interoperability, Diameter/RADIUS gateways will need
   to be configured to translate RADIUS attribute 92 to Diameter NAS-
   Filter-Rule AVP (400) and vice versa.

[RFC4005](セクション6.6)はRADIUS NASフィルタ規則属性と同じ機能性でNASフィルタ規則AVP(400)を定義します。 相互運用性をサポートするために、Diameter/RADIUSゲートウェイは、(400) 逆もまた同様にDiameter NASフィルタ規則AVPにRADIUS属性92を翻訳するために構成される必要があるでしょう。

   When translating Diameter NAS-Filter-Rule AVPs to RADIUS NAS-Filter-
   Rule attributes, the set of NAS-Filter-Rule attributes is created by
   concatenating the individual filter rules, separated by a NUL octet.
   The resulting data SHOULD then be split on 253-octet boundaries.

Diameter NASフィルタ規則AVPsをRADIUS NAS規則をフィルターにかけるのである属性に翻訳するとき、NASフィルタ規則属性のセットは、NUL八重奏で切り離された独特のフィルタ規則を連結することによって、創設されます。 結果として起こるデータSHOULD、そして、253八重奏の境界で分けられてください。

   When translating RADIUS NAS-Filter-Rule attributes to Diameter NAS-
   Filter-Rule AVPs, the individual rules are determined by
   concatenating the contents of all NAS-Filter-Rule attributes, and
   then splitting individual filter rules with the NUL octet as a
   delimiter.  Each rule is then encoded as a single Diameter NAS-
   Filter-Rule AVP.

RADIUS NASフィルタ規則属性をDiameter NASフィルタ規則AVPsに翻訳するとき、独特の規則は、すべてのNASフィルタ規則属性のコンテンツを連結することによって断固としていて、デリミタとしてNUL八重奏で独特のフィルタ規則を分けて、そして断固としています。 そして、各規則は独身のDiameter NASフィルタ規則AVPとしてコード化されます。

   Note that a translated Diameter message can be larger than the
   maximum RADIUS packet size (4096 bytes).  Where a Diameter/RADIUS
   gateway receives a Diameter message containing a NAS-Filter-Rule AVP
   that is too large to fit into a RADIUS packet, the Diameter/RADIUS
   gateway will respond to the originating Diameter peer with a Result-
   Code AVP with the value DIAMETER_RADIUS_AVP_UNTRANSLATABLE (5018),
   and with a Failed-AVP AVP containing the NAS-Filter-Rule AVP.  Since
   repairing the error will probably require re-working the filter
   rules, the originating peer should treat the combination of a
   Result-Code AVP with value DIAMETER_RADIUS_AVP_UNTRANSLATABLE and a
   Failed-AVP AVP containing a NAS-Filter-Rule AVP as a terminal error.

翻訳されたDiameterメッセージが最大のRADIUSパケットサイズ(4096バイト)より大きい場合があることに注意してください。 Diameter/RADIUSゲートウェイが受信されるところでは、値のDIAMETER_RADIUS_AVP_UNTRANSLATABLE(5018)、およびFailed-AVP AVPがNASフィルタ規則AVPを含んでいて、RADIUSパケット、Diameter/RADIUSゲートウェイに収まることができないくらい大きいNASフィルタ規則AVPを含むDiameterメッセージはResultコードAVPと共に起因しているDiameter同輩に応じるでしょう。 以来誤りを修理するのは、たぶんフィルタ規則を作りなおすのを必要として、起因している同輩は値のDIAMETER_RADIUS_AVP_UNTRANSLATABLEへのResult-コードAVPの組み合わせと端末の誤りとしてNASフィルタ規則AVPを含むFailed-AVP AVPを扱うべきです。

Congdon, et al.             Standards Track                     [Page 5]

RFC 4849                 Filter Rule Attribute                April 2007

コングドン、他 規格はフィルタ規則属性2007年4月にRFC4849を追跡します[5ページ]。

5.  IANA Considerations

5. IANA問題

   This specification does not create any new registries.

この仕様はどんな新しい登録も作成しません。

   This document uses the RADIUS [RFC2865] namespace, see
   <http://www.iana.org/assignments/radius-types>.  One value has been
   allocated in the section "RADIUS Attribute Types".  The RADIUS
   attribute for which a value has been assigned is:

このドキュメントはRADIUS[RFC2865]名前空間を使用して、<が>をhttp://www.iana.org/課題/半径でタイプするのを確実にしてください。 「半径属性タイプ」というセクションに1つの値を割り当てました。 値を割り当ててあるRADIUS属性は以下の通りです。

      92 - NAS-Filter-Rule

92--NASフィルタ規則

   This document also utilizes the Diameter [RFC3588] namespace.  A
   Diameter Result-Code AVP value for the
   DIAMETER_RADIUS_AVP_UNTRANSLATABLE error has been allocated.  Since
   this is a permanent failure, the allocation (5018) is in the 5xxx
   range.

また、このドキュメントはDiameter[RFC3588]名前空間を利用します。 DIAMETER_RADIUS_AVP_UNTRANSLATABLE誤りのためのDiameter Result-コードAVP価値を割り当てました。 これが永久的な失敗であるので、配分(5018)が5xxx範囲にあります。

6.  Security Considerations

6. セキュリティ問題

   This specification describes the use of RADIUS for purposes of
   authentication, authorization and accounting.  Threats and security
   issues for this application are described in [RFC3579] and [RFC3580];
   security issues encountered in roaming are described in [RFC2607].

この仕様はRADIUSの認証、承認、および会計の目的の使用について説明します。 このアプリケーションのための脅威と安全保障問題は[RFC3579]と[RFC3580]で説明されます。 ローミングで遭遇する安全保障問題は[RFC2607]で説明されます。

   This document specifies a new attribute that can be included in
   existing RADIUS packets, which are protected as described in
   [RFC3579] and [RFC3576].  See those documents for a more detailed
   description.

このドキュメントは[RFC3579]と[RFC3576]で説明されるように保護される既存のRADIUSパケットに含むことができる新しい属性を指定します。 より詳細な記述に関してそれらのドキュメントを見てください。

   The security mechanisms supported in RADIUS and Diameter are focused
   on preventing an attacker from spoofing packets or modifying packets
   in transit.  They do not prevent an authorized RADIUS/Diameter server
   or proxy from modifying, inserting, or removing attributes with
   malicious intent.  Filter attributes modified or removed by a
   RADIUS/Diameter proxy may enable a user to obtain network access
   without the appropriate filters; if the proxy were also to modify
   accounting packets, then the modification would not be reflected in
   the accounting server logs.

攻撃者がパケットを偽造するか、またはトランジットでパケットを変更するのを防ぐのにRADIUSとDiameterでサポートされたセキュリティー対策は集中しています。 彼らは、認可されたRADIUS/直径サーバかプロキシが悪意で属性を変更するか、挿入するか、または取り除くのを防ぎません。 RADIUS/直径プロキシによって変更されたか、または取り除かれたフィルタ属性は、ユーザが適切なフィルタなしでネットワークアクセスを得るのを可能にするかもしれません。 また、プロキシが会計パケットを変更するなら、変更は会計サーバログに反映されないでしょうに。

   Since the RADIUS protocol currently does not support capability
   negotiation, a RADIUS server cannot automatically discover whether a
   NAS supports the NAS-Filter-Rule attribute.  A legacy NAS not
   compliant with this specification may silently discard the NAS-
   Filter-Rule attribute while permitting the user to access the
   network.  This can cause users to improperly receive unfiltered
   access to the network.  As a result, the NAS-Filter-Rule attribute
   SHOULD only be sent to a NAS that is known to support it.

RADIUSプロトコルが、現在能力が交渉であるとサポートしないので、RADIUSサーバは、NASがNASフィルタ規則属性をサポートするかどうか自動的に発見できません。 ユーザがネットワークにアクセスすることを許可している間、この仕様で言いなりになっていないレガシーNASは静かにNASフィルタ規則属性を捨てるかもしれません。 これで、ユーザは不適切にネットワークへの非濾過のアクセスを受け取ることができます。 その結果、NASフィルタ規則はSHOULDを結果と考えます。単にそれがそれをサポートするのが知られているNASに送ってください。

Congdon, et al.             Standards Track                     [Page 6]

RFC 4849                 Filter Rule Attribute                April 2007

コングドン、他 規格はフィルタ規則属性2007年4月にRFC4849を追跡します[6ページ]。

7.  References

7. 参照

7.1.  Normative References

7.1. 引用規格

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March, 1997.

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
             "Remote Authentication Dial In User Service (RADIUS)", RFC
             2865, June 2000.

[RFC2865] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」、RFC2865(2000年6月)。

   [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
             Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

[RFC3588] カルフーンとP.とLoughneyとJ.とGuttmanとE.とゾルン、G.とJ.Arkko、「直径基地のプロトコル」、RFC3588、2003年9月。

   [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter
             Network Access Server Application", RFC 4005, August 2005.

[RFC4005] カルフーンとP.とゾルンとG.とスペンス、D.とD.ミットン、「直径ネットワークアクセス・サーバーアプリケーション」、RFC4005、2005年8月。

7.2.  Informative References

7.2. 有益な参照

   [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
             Implementation in Roaming", RFC 2607, June 1999.

[RFC2607] Aboba、B.、J.Vollbrecht、および「ローミングにおけるプロキシ推論と政策の実施」、RFC2607、6月1999日

   [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
             Aboba, "Dynamic Authorization Extensions to Remote
             Authentication Dial In User Service (RADIUS)", RFC 3576,
             July 2003.

[RFC3576] 千葉、M.、Dommety、G.、エクルンド、M.、ミットン、D.、およびB.Aboba、「リモート認証へのダイナミックな承認拡大はユーザでサービス(半径)にダイヤルします」、RFC3576、2003年7月。

   [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
             Dial In User Service) Support For Extensible Authentication
             Protocol (EAP)", RFC 3579, September 2003.

[RFC3579]Aboba、B.とP.カルフーン、「拡張認証プロトコル(EAP)の半径(ユーザサービスにおけるリモート認証ダイヤル)サポート」RFC3579(2003年9月)。

   [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese,
             "IEEE 802.1X Remote Authentication Dial In User Service
             (RADIUS) Usage Guidelines", RFC 3580, September 2003.

[RFC3580] コングドン、P.、Aboba、B.、スミス、A.、ゾルン、G.、およびJ.Roese、「ユーザサービス(半径)用法ガイドラインのIEEE 802.1Xのリモート認証ダイヤル」、RFC3580(2003年9月)。

   [Traffic] Congdon, P., Sanchez, M., Lior, A., Adrangi, F., and B.
             Aboba, "RADIUS Attributes for Filtering and Redirection",
             Work in Progress, March 2007.

[トラフィック] コングドン、P.、サンチェス、M.、Lior、A.、Adrangi、F.、およびB.Aboba、「フィルタリングとリダイレクションのための半径属性」が進行中(2007年3月)で働いています。

8.  Acknowledgments

8. 承認

   The authors would like to acknowledge Emile Bergen, Alan DeKok, Greg
   Weber, Glen Zorn, Pasi Eronen, David Mitton, and David Nelson for
   contributions to this document.

作者はこのドキュメントへの貢献のためにエイミール・ベルゲン、アランDeKok、グレッグ・ウェーバー、Glenゾルン、パシEronen、デヴィッド・ミットン、およびデヴィッド・ネルソンを承認したがっています。

Congdon, et al.             Standards Track                     [Page 7]

RFC 4849                 Filter Rule Attribute                April 2007

コングドン、他 規格はフィルタ規則属性2007年4月にRFC4849を追跡します[7ページ]。

Authors' Addresses

作者のアドレス

   Paul Congdon
   Hewlett Packard Company
   ProCurve Networking by HP
   8000 Foothills Blvd, M/S 5662
   Roseville, CA  95747

hp8000山麓の丘Blvd、M/S5662年までにローズビル、カリフォルニア 95747をネットワークでつなぐポールコングドンヒューレットパッカードProCurve社

   EMail: paul.congdon@hp.com
   Phone: +1 916 785 5753
   Fax:   +1 916 785 8478

メール: paul.congdon@hp.com 電話: +1 916 785、5753Fax: +1 916 785 8478

   Mauricio Sanchez
   Hewlett Packard Company
   ProCurve Networking by HP
   8000 Foothills Blvd, M/S 5559
   Roseville, CA  95747

hp8000山麓の丘Blvd、M/S5559年までにローズビル、カリフォルニア 95747をネットワークでつなぐマウリシオサンチェスヒューレットパッカードProCurve社

   EMail: mauricio.sanchez@hp.com
   Phone: +1 916 785 1910
   Fax:   +1 916 785 1815

メール: mauricio.sanchez@hp.com 電話: +1 916 785、1910Fax: +1 916 785 1815

   Bernard Aboba
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052

バーナードAbobaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン 98052

   EMail: bernarda@microsoft.com
   Phone: +1 425 706 6605
   Fax:   +1 425 936 7329

メール: bernarda@microsoft.com 電話: +1 425 706、6605Fax: +1 425 936 7329

Congdon, et al.             Standards Track                     [Page 8]

RFC 4849                 Filter Rule Attribute                April 2007

コングドン、他 規格はフィルタ規則属性2007年4月にRFC4849を追跡します[8ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(2007)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Congdon, et al.             Standards Track                     [Page 9]

コングドン、他 標準化過程[9ページ]