rfc4675.txt

使用最广泛的radius的linux的源码

      user priority on frames received at a port.  This per-port
      configuration enables a bridge to cause the priority of received
      traffic at a port to be mapped to a particular priority.
      [IEEE-802.1D] clause 6.3.9 describes the use of remapping:

         The ability to signal user priority in IEEE 802 LANs allows
         user priority to be carried with end-to-end significance across
         a Bridged Local Area Network.  This, coupled with a consistent
         approach to the mapping of user priority to traffic classes and
         of user priority to access_priority, allows consistent use of
         priority information, according to the capabilities of the
         Bridges and MACs in the transmission path...

         Under normal circumstances, user priority is not modified in
         transit through the relay function of a Bridge; however,
         network management can control how user priority is propagated.
         Table 7-1 provides the ability to map incoming user priority
         values on a per-Port basis.  By default, the regenerated user
         priority is identical to the incoming user priority.

      This attribute represents the IEEE 802 prioritization that will be
      applied to frames arriving at this port.  There are eight possible
      user priorities, according to the [IEEE-802] standard.
      [IEEE-802.1D] clause 14.6.2.3.3 specifies the regeneration table



Congdon, et al.             Standards Track                     [Page 8]

RFC 4675              VLAN and Priority Attributes        September 2006


      as 8 values, each an integer in the range 0-7.  The management
      variables are described in clause 14.6.2.2.

      A single User-Priority-Table attribute MAY be included in an
      Access-Accept or CoA-Request packet; this attribute MUST NOT be
      sent within an Access-Request, Access-Challenge, Access-Reject,
      Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA-ACK, CoA-
      NAK or Accounting-Request.  Since the regeneration table is only
      maintained by a bridge conforming to [IEEE-802.1D], this attribute
      should only be sent to a RADIUS client supporting that
      specification.

      The User-Priority-Table attribute is shown below.  The fields are
      transmitted from left to right:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    String
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    String            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      59

   Length

      10

   String

      The String field is 8 octets in length and includes a table that
      maps the incoming priority (if it is set -- the default is 0) into
      one of eight regenerated priorities.  The first octet maps to
      incoming priority 0, the second octet to incoming priority 1, etc.
      The values in each octet represent the regenerated priority of the
      frame.

      It is thus possible to either remap incoming priorities to more
      appropriate values; to honor the incoming priorities; or to
      override any incoming priorities, forcing them to all map to a
      single chosen priority.





Congdon, et al.             Standards Track                     [Page 9]

RFC 4675              VLAN and Priority Attributes        September 2006


      The [IEEE-802.1D] specification, Annex G, provides a useful
      description of traffic type - traffic class mappings.

3.  Table of Attributes

   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+   56   Egress-VLANID
    0-1     0-1     0       0        0-1   0-1  57   Ingress-Filters
    0+      0+      0       0        0+    0+   58   Egress-VLAN-Name
    0       0-1     0       0        0-1   0    59   User-Priority-Table

   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.

4.  Diameter Considerations

   When used in Diameter, the attributes defined in this specification
   can be used as Diameter attribute-value pair (AVPs) from the Code
   space 1-255 (RADIUS attribute compatibility space).  No additional
   Diameter Code values are therefore allocated.  The data types and
   flag rules for the attributes are as follows:

                                  +---------------------+
                                  |    AVP Flag rules   |
                                  |----+-----+----+-----|----+
                                  |    |     |SHLD| MUST|    |
   Attribute Name      Value Type |MUST| MAY | NOT|  NOT|Encr|
   -------------------------------|----+-----+----+-----|----|
   Egress-VLANID       OctetString| M  |  P  |    |  V  | Y  |
   Ingress-Filters     Enumerated | M  |  P  |    |  V  | Y  |
   Egress-VLAN-Name    UTF8String | M  |  P  |    |  V  | Y  |
   User-Priority-Table OctetString| M  |  P  |    |  V  | Y  |
   -------------------------------|----+-----+----+-----|----|

   The attributes in this specification have no special translation
   requirements for Diameter to RADIUS or RADIUS to Diameter gateways;
   they are copied as is, except for changes relating to headers,
   alignment, and padding.  See also [RFC3588] Section 4.1 and [RFC4005]
   Section 9.



Congdon, et al.             Standards Track                    [Page 10]

RFC 4675              VLAN and Priority Attributes        September 2006


   What this specification says about the applicability of the
   attributes for RADIUS Access-Request packets applies in Diameter to
   AA-Request [RFC4005] or Diameter-EAP-Request [RFC4072].  What is said
   about Access-Challenge applies in Diameter to AA-Answer [RFC4005] or
   Diameter-EAP-Answer [RFC4072] with Result-Code AVP set to
   DIAMETER_MULTI_ROUND_AUTH.

   What is said about Access-Accept applies in Diameter to AA-Answer or
   Diameter-EAP-Answer messages that indicate success.  Similarly, what
   is said about RADIUS Access-Reject packets applies in Diameter to
   AA-Answer or Diameter-EAP-Answer messages that indicate failure.

   What is said about COA-Request applies in Diameter to Re-Auth-Request
   [RFC4005].

   What is said about Accounting-Request applies to Diameter
   Accounting-Request [RFC4005] as well.

5.  IANA Considerations

   This specification does not create any new registries.

   This document uses the RADIUS [RFC2865] namespace; see
   <http://www.iana.org/assignments/radius-types>.  Allocation of four
   updates for the section "RADIUS Attribute Types" has been made by the
   IANA.  The RADIUS attributes are:

   56 - Egress-VLANID
   57 - Ingress-Filters
   58 - Egress-VLAN-Name
   59 - User-Priority-Table

6.  Security Considerations

   This specification describes the use of RADIUS and Diameter for
   purposes of authentication, authorization, and accounting in IEEE 802
   local area networks.  RADIUS threats and security issues for this
   application are described in [RFC3579] and [RFC3580]; security issues
   encountered in roaming are described in [RFC2607].  For Diameter, the
   security issues relating to this application are described in
   [RFC4005] and [RFC4072].

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




Congdon, et al.             Standards Track                    [Page 11]

RFC 4675              VLAN and Priority Attributes        September 2006


   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 inserting attributes with malicious intent.

   VLAN attributes sent by a RADIUS/Diameter server or proxy may enable
   access to unauthorized VLANs.  These vulnerabilities can be limited
   by performing authorization checks at the NAS.  For example, a NAS
   can be configured to accept only certain VLANIDs from a given
   RADIUS/Diameter server/proxy.

   Similarly, an attacker gaining control of a RADIUS/Diameter server or
   proxy can modify the user priority table, causing either degradation
   of quality of service (by downgrading user priority of frames
   arriving at a port), or denial of service (by raising the level of
   priority of traffic at multiple ports of a device, oversubscribing
   the switch or link capabilities).

7.  References

7.1.  Normative References

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

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

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

   [RFC3629]     Yergeau, F., "UTF-8, a transformation format of ISO
                 10646", STD 63, RFC 3629, November 2003.

   [RFC4363]     Levi, D. and D. Harrington, "Definitions of Managed
                 Objects for Bridges with Traffic Classes, Multicast
                 Filtering, and Virtual LAN Extensions", RFC 4363,
                 January 2006.

   [IEEE-802]    IEEE Standards for Local and Metropolitan Area
                 Networks:  Overview and Architecture, ANSI/IEEE Std
                 802, 1990.

   [IEEE-802.1D] IEEE Standards for Local and Metropolitan Area
                 Networks: Media Access Control (MAC) Bridges, IEEE Std
                 802.1D-2004, June 2004.



Congdon, et al.             Standards Track                    [Page 12]

RFC 4675              VLAN and Priority Attributes        September 2006


   [IEEE-802.1Q] IEEE Standards for Local and Metropolitan Area
                 Networks: Draft Standard for Virtual Bridged Local Area
                 Networks, P802.1Q-2003, January 2003.

7.2.  Informative References

   [IEEE-802.1X] IEEE Standards for Local and Metropolitan Area
                 Networks: Port based Network Access Control, IEEE Std
                 802.1X-2004, December 2004.

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

   [RFC2868]     Zorn, G., Leifer, D., Rubens, A., Shriver, J.,
                 Holdrege, M., and I. Goyret, "RADIUS Attributes for
                 Tunnel Protocol Support", RFC 2868, June 2000.

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

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

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

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

   [RFC4072]     Eronen, P., Hiller, T., and G. Zorn, "Diameter
                 Extensible Authentication Protocol (EAP) Application",
                 RFC 4072, August 2005.

8.  Acknowledgements

   The authors would like to acknowledge Joseph Salowey of Cisco, David
   Nelson of Enterasys, Chuck Black of Hewlett-Packard, and Ashwin
   Palekar of Microsoft.






Congdon, et al.             Standards Track                    [Page 13]

RFC 4675              VLAN and Priority Attributes        September 2006


Authors' Addresses

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

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]


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

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]


   Bernard Aboba
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]



















Congdon, et al.             Standards Track                    [Page 14]

RFC 4675              VLAN and Priority Attributes        September 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   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.

   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 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.

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.

   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.

   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
   [e-mail].

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).







Congdon, et al.             Standards Track                    [Page 15]