[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Changes to draft-ietf-radext-vlan to address IESG DISCUSS Comments
Works for me. But didn't you have a discussion earlier that
user-priority-table would not be mandatory?
--Jari
Bernard Aboba wrote:
> Jari Arkko and Russ Housley have reviewed the VLAN/Priority document.
> In order to address their comments, the following changes are proposed:
>
> Change Section 1 to the following:
>
> "1. Introduction
>
> This document describes Virtual LAN (VLAN) and re-prioritization
> attributes that may prove useful for provisioning of access to IEEE
> 802 local area networks [IEEE-802] with the Remote Authentication
> Dialin User Service (RADIUS) or Diameter.
>
> While [RFC3580] enables support for VLAN assignment based on the
> tunnel attributes defined in [RFC2868], it does not provide support
> for a more complete set of VLAN functionality as defined by
> [IEEE-802.1Q]. The attributes defined in this document provide
> support within RADIUS and Diameter analogous to the management
> variables supported in [IEEE-802.1Q] and MIB objects defined in
> [RFC4363]. In addition, this document enables support for a wider
> range of [IEEE-802.1X] configurations."
>
> In Section 1.1, add the following definitions:
>
> "RADIUS server
> A RADIUS authentication server is an entity that provides an
> authentication service to a NAS.
>
> RADIUS proxy
> A RADIUS proxy acts as an authentication server to the NAS, and a
> RADIUS client to the RADIUS server."
>
> Change Section 4 to the following:
>
> "4. Diameter Considerations
>
> When used in Diameter, the attributes defined in this specification
> can be used as Diameter 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 [RFC 3588] Section 4.1 and [RFC
> 4005] Section 9.
>
> What this specification says about the applicability of the
> attributes for RADIUS Access-Request packets applies in Diameter to
> AA-Request [RFC 4005] or Diameter-EAP-Request [RFC 4072]. What is
> said about Access-Challenge applies in Diameter to AA-Answer [RFC
> 4005] or Diameter-EAP-Answer [RFC 4072] 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
> [RFC 4005].
>
> What is said about Accounting-Request applies to Diameter Accounting-
> Request [RFC 4005] as well."
>
> Change Section 6 to the following:
>
> "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.
>
> 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)."
>
>
>
> --
> to unsubscribe send a message to radiusext-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>
>
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>