One document matched: draft-ietf-radext-ieee802-00.txt
Networking Working Group Paul Congdon
INTERNET-DRAFT Mauricio Sanchez
<draft-ietf-radext-ieee802-00.txt> Hewlett-Packard Company
A. Lior
10 July 2005 Bridgewater Systems
F. Adrangi
Intel
Bernard Aboba
Microsoft
VLAN, Priority, and Filtering Attributes
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January, 10 2006.
Copyright Notice
Copyright (C) The Internet Society 2005. All rights reserved.
Abstract
In certain scenarios it is desirable to limit user access using
dynamic VLANs, filters or redirection. This documents proposes
additional attributes for this purpose, for use with the Remote
Authentication Dial In User Server (RADIUS). The attributes
described in this document are expected to be useful in a variety
of environments, including enterprise and service provider
scenarios.
Congdon, et al. Informational [Page 1]
INTERNET-DRAFT VLAN, Priority, and Filtering Attributes 9 June 2005
Table of Contents
1. Introduction........................................... 3
1.1. Terminology...................................... 3
1.2. Requirements Language............................ 4
2. Overview............................................... 5
2.1. Capability Advertisement ........................ 6
2.2. Attribute Interpretation......................... 6
3. RADIUS Authentication.................................. 7
3.1. Egress-VLANID.................................... 7
3.2. Ingress-Filters.................................. 8
3.3. VLAN-Name........................................ 9
3.4. User-Priority-Table.............................. 10
3.5. NAS-Filter-Rule.................................. 11
3.6. QoS-Filter-Rule.................................. 18
4. RADIUS Accounting...................................... 19
4.1. Acct-NAS-Filter-Rule.............................. 19
4.2. Acct-EAP-Auth-Method............................. 19
5. Table of Attributes.................................... 21
6. IANA Considerations.................................... 21
7. Security Considerations................................ 21
7.1. Packet modification or forgery................... 22
7.2. Dictionary Attacks............................... 22
7.3. Known Plaintext Attacks.......................... 22
8. References............................................. 23
8.1 Normative References................................... 23
8.2 Informative References................................. 24
Appendix A - Traffic Redirection.............................. 25
ACKNOWLEDGMENTS............................................... 29
AUTHORS' ADDRESSES............................................ 29
Intellectual Property Statement............................... 29
Disclaimer of Validity........................................ 30
Full Copyright Statement ..................................... 30
Congdon, et al. Informational [Page 2]
INTERNET-DRAFT VLAN, Priority, and Filtering Attributes 9 June 2005
1. Introduction
Within the confines of RADIUS authentication, authorization, and
accounting (AAA) environments, there is a general dearth of
standardized RADIUS attributes to limit user access using dynamic
VLANs, filters or redirection.
For example, in IEEE 802.1X [IEEE8021X] environments, which
provides "network port authentication" for IEEE 802 [IEEE802]
media, including Ethernet [IEEE8023], Token Ring and 802.11
[IEEE80211i] wireless LANS, there exists a strong desire to
control authorization beyond just the untagged VLAN parameter
based on tunnel attributes in [RFC2868].
This document describes VLAN, filtering and re-direction
attributes that may prove useful in IEEE 802.1X and a variety of
situations. The attributes defined in this document may be used
with RADIUS dynamic authorization [RFC3576].
The Filter-ID attribute defined in [RFC2865] requires the NAS to
be pre-populated with the desired filters. This may be difficult
to deploy in roaming scenarios where the home realm may not know
what filters have been pre-populated by the local operator. The
filtering attributes specified in this document enable explicit
description of layer 2 and layer 3 filters as well as redirection,
and therefore extend the filter language described in [RFC3588].
User traffic redirection is supported with or without tunneling.
Tunneling support is provided using the tunnel attributes defined
in [RFC2868]. Redirection of traffic in mid-session may break
applications.
IEEE 802.1X-2004 [IEEE8021X] provides "network port
authentication" for IEEE 802 [IEEE802] media, including Ethernet
[IEEE8023], Token Ring and 802.11 wireless LANs [IEEE80211i].
While [RFC3580] enables support for VLAN assignment based on the
tunnel attributes defined in [RFC2868], it does not provide
support for the full set of VLAN functionality. The VLAN
attributes defined in this document provide support within RADIUS
analogous to the MIB variables supported in [IEEE-802.1Q]. In
addition, this document enables support for a wider range of
[IEEE8021X] configuration.
Congdon, et al. Informational [Page 3]
INTERNET-DRAFT VLAN, Priority, and Filtering Attributes 9 June 2005
1.1. Terminology
In this document when we refer to Blocking of IP traffic we mean
Filtering of IP traffic. Additionally, this document uses the
following terms:
Access Point (AP)
A Station that provides access to the distribution services
via the wireless medium for associated Stations.
Association
The service used to establish Access Point/Station mapping
and enable Station invocation of the distribution system
services.
Authenticator
An authenticator is an entity that require authentication
from the supplicant. The authenticator may be connected to
the supplicant at the other end of a point-to-point LAN
segment or 802.11 wireless link.
Authentication server
An authentication server is an entity that provides an
authentication service to an authenticator. This service
verifies from the credentials provided by the supplicant,
the claim of identity made by the supplicant.
Hot-lining
Blocking and redirection of users traffic is known as hot-
lining of accounts. In this document, hot-lining is used as
the motivation for these attributes and an illustration of
how they would be used. However, the attributes may be used
together or separately to provide other features.
Port Access Entity (PAE)
The IEEE8021.X protocol entity associated with a physical or
virtual (802.11) Port. A given PAE may support the
IEEE8021.X protocol functionality associated with the
Authenticator, Supplicant or both.
Redirection
Refers to an action taken by the NAS to redirect the user's
traffic to an alternate location.
Station (STA)
Any device that contains an IEEE 802.11 conformant medium
access control (MAC) and physical layer (PHY) interface to
the wireless medium (WM).
Congdon, et al. Informational [Page 4]
INTERNET-DRAFT VLAN, Priority, and Filtering Attributes 9 June 2005
Supplicant
A supplicant is an entity that is being authenticated by an
authenticator. The supplicant may be connected to the
authenticator at one end of a point-to-point LAN segment or
802.11 wireless link.
1.2. Requirements Language
In this document, several words are used to signify the
requirements of the specification. 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].
An implementation is not compliant if it fails to satisfy one or
more of the must or must not requirements for the protocols it
implements. An implementation that satisfies all the must, must
not, should and should not requirements for its protocols is said
to be "unconditionally compliant"; one that satisfies all the must
and must not requirements but not all the should or should not
requirements for its protocols is said to be "conditionally
compliant".
2. Overview
As described in the Introduction section, it may be desirable to a
control user's access to network resources (e.g. the Internet)
with greater standardized explicitness than what current RADIUS
attributes provide. In this section we will examine these
requirements in more detail.
Besides IEEE 802.1X networks, there is a corollary need within
Internet Service Provider (ISP) environments for standardized
authorization attributes. From time to time, an ISP requires to
restrict a user's access to the Internet and redirect their
traffic to an alternate location. For example, the user maybe on
a prepaid plan and all the resources have been used up. In this
case the ISP would block the user's access to the Internet and
redirect them to a portal where the user can replenish their
account. Another example where the ISP would want to restrict
access and redirect a user that was involved in some fraudulent
behavior. Again the ISP would want to block the user's access to
the Internet and redirect to a portal where they can inform the
user as to their state and allow them to inform the user of their
concerns and potentially rectify the situation.
The ability to block user's traffic is required at service
initiation and once service has been established. These
capabilities must also be available across access technologies and
Congdon, et al. Informational [Page 5]
INTERNET-DRAFT VLAN, Priority, and Filtering Attributes 9 June 2005
various business scenarios. For example, the ability to block and
redirect traffic is required for TCP users, cell phone users, WiFi
users. As well, this capability must work whether the user is in
their home network or roaming in a visited network which may or
may not have a direct roaming relationship with the user's home
network.
Blocking access refers to setting up access control rules at the
NAS such that when the user initiates IP traffic, the NAS examines
the set of rules associated with the service granted to the user.
These rules determine what traffic is allowed to proceed through
the NAS and what traffic will be blocked. Today this capability
is supported in RADIUS and is configurable during service
establishment and mid-service via the Filter-Id(11) attribute. To
use Filter-Id to control access to network resources the rules
need to be configured apriori at each NAS. Filter-Id(11) is used
in an Access-Accept to specify the name of the filter rule(s) to
apply to this session. To effect a change mid-service
(dynamically), the Filter-Id(11) is included in a Change-of-
Authorization (COA) packet as described in [RFC3676]. Upon
receiving the Filter-Id(11) the NAS starts to apply the rules
specified by the Filter-Id(11).
As pointed out by [NASREQ] the use Filter-Id is not roaming
friendly and it is recommended that instead one should use NAS-
Filter-Rule(TBD) AVP. For this reason, this document introduces
NAS-Filter-Rule(TBD) to RADIUS.
2.1. Capability Advertisement
RADIUS does not currently define a method by which a NAS can
advertise its capabilities and in many instances, it would be
desirable for the home network to know what capabilities are
supported by the NAS to ensure proper operational behavior. The
attributes defined in this document are intended to be used to
enforce policy by the NAS. If a NAS does not recognize these
attributes it will most likely ignore them and the desired policy
will not be enforced. A method for the NAS advertising the
capability to support these attributes would help the RADIUS
server understand if the intended policies can be enforced. As a
result, the attributes in this document, in particular NAS-Filter-
Rule(TBD), can benefit from capability advertisement, if
available.
2.2 Attribute Interpretation
Unless otherwise noted in the individual description of an
attribute contained herein, a NAS that conforms to this
specification and receives an Access-Accept message that contains
an attribute from this document that it does not recognize or
Congdon, et al. Informational [Page 6]
INTERNET-DRAFT VLAN, Priority, and Filtering Attributes 9 June 2005
cannot apply MUST interpret this though an Access-Reject had been
sent and MUST terminate the session. If accounting is enabled on
the NAS, it MUST generate an Accounting-Request(Stop) message upon
session termination.
Similarly, if a NAS conforming to this specification receives a
CoA message that contains an attribute from this document that it
does not recognize or cannot apply, it MUST NOT terminate the
session and MUST generate a CoA-NAK packet with ERROR-CAUSE(101)
set to "Unsupported Attribute"(401). If accounting is enabled on
the NAS, it MUST NOT generate an Accouting-Request(Stop) message
in such instances.
3. RADIUS Attributes
This specification introduces seven new RADIUS attributes.
3.1. Egress-VLANID
Description
The Egress-VLANID attribute represents an allowed IEEE 802
Egress VLANID for this port. The Egress-VLANID contains two
parts: the first part indicates if the VLANID is allowed for
tagged or untagged packets and the second part is the VLANID.
Multiple Egress-VLANID attributes can be delivered in an
authentication response; each attribute adds the specified VLAN
to the list of allowed egress VLANs for the port.
The Egress-VLANID 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 | Integer
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer(cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD
Length
6
Congdon, et al. Informational [Page 7]
INTERNET-DRAFT VLAN, Priority, and Filtering Attributes 9 June 2005
Integer
The Integer field is four octets in length. The format of the
Integer field consists of two parts, the first consuming high-
order octet and the second consuming the remaining three lower-
order octets. The high-order octet field indicates if the
VLANID is allowed for tagged or untagged packets. The second
part is the 12-bit 802.1Q VLAN VID value that has been padded
out to consume the remaining three lower-order octets. A
sample encoding follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Option | Pad (12-bit) | VLANID (12-bit) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Values for the Tag Option part include:
1 = Tagged
2 = Untagged
Padding bits SHOULD be 0 (zero).
VLANID is the 12-bit 802.1Q-2003 VID value.
3.2. Ingress-Filters
Description
The Ingress-Filters attribute corresponds to Ingress Filter
per-port variable defined in IEEE 802.1Q clause 8.4.5. When
the attribute has the value "Enabled", the set of VLANs that
are allowed to ingress a port must match the set of VLANs that
are allowed to egress a port. Only a single Ingress-Filters
attribute MAY be sent within an Access-Accept or CoA-Request;
this attribute MUST NOT be sent within an Access-Request,
Access-Challenge, Access-Reject, or Disconnect-Request.
Type
TBD
Length
6
Congdon, et al. Informational [Page 8]
INTERNET-DRAFT VLAN, Priority, and Filtering Attributes 9 June 2005
Integer
The values include:
1 - Enabled
2 - Disabled
3.3. VLAN-Name
Description
Clause 12.10.2.1.3 (a) in [IEEE8021Q] describes the
administratively assigned VLAN Name associated with a VLAN ID
defined within an 802.1Q bridge. The VLAN-Name attribute
represents an allowed VLAN for this port. It works similar to
the Egress-VLANID attribute except that the VLAN-ID itself is
not specified or known, rather the VLAN name is used to
identify the VLAN within the system.
The VLAN-Name attribute contains two parts; the first part
indicates if frames on the VLAN for this port are to be
represented in tagged or untagged format, the second part is
the VLAN name.
Multiple VLAN-Name attributes can be delivered in an
authentication response; each attribute adds the named VLAN to
the list of allowed egress VLANs for the port.
Type
TBD
Length
>= 4
String
The first octet of this string indicates whether the frames on
the VLAN are tagged 0x01 or Untagged 0x02. The remaining
octets represent the VLAN Name as defined in 802.1Q-2003 clause
12.10.2.1.3 (a). UTF-8 encoded 10646 characters are
recommended, but a robust implementation SHOULD support the
field as undistinguished octets.
Congdon, et al. Informational [Page 9]
INTERNET-DRAFT VLAN, Priority, and Filtering Attributes 9 June 2005
3.4. User-Priority-Table
Description
IEEE 802.1D clause 7.5.1 discusses how to regenerate (or re-
map) 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. The management variables are described in clause
14.6.2.2.
This attribute represents the IEEE 802 prioritization that will
be applied to packets arriving at this port. There are eight
possible user priorities, according to the IEEE 802 standard.
Type
TBD
Length
10
String
The table, expressed as an 8 octet string, maps the incoming
priority (if one exists - the default is 0) into one of seven
regenerated priorities. The format of this attribute is an
eight byte octet string, where 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
packet.
It is thus possible to either remap incoming priorities to more
appropriate values; or to honor the incoming priorities; or to
override any incoming priorities, forcing them to all map to a
single chosen priority.
The [IEEE 8021D] specification, Annex G, provides a useful
description of traffic type - traffic class mappings.
3.5. NAS-Filter-Rule
Description
The NAS-Filter-Rule attribute is derived from the Diameter
IPFilterRule and enables the provisioning of base encapsulation
(Layer 2), Internet Protocol (Layer 3-4), and HTTP (Layer 5+)
Congdon, et al. Informational [Page 10]
INTERNET-DRAFT VLAN, Priority, and Filtering Attributes 9 June 2005
filter rules and Internet Protocol and HTTP redirect rules on
the NAS by the RADIUS server.
When specifying a base encapsulation filter rule, NAS-Filter-
Rule processes packets based on the following information that
is associated with it:
Direction (in and/or out)
Base encapsulation type
Source and destination MAC address (possibly masked)
When specifying an Internet Protocol filter or tunnel rule,
NAS-Filter-Rule processes packets based on the following
information that is associated with it:
Direction (in and/or out)
Source and destination IP address (possibly masked)
Protocol
Source and destination port (lists or ranges)
TCP flags
IP fragment flag
IP options
ICMP types
When specifying an HTTP filter or redirect rule, NAS-Filter-
Rule process packets based on the following information that is
associated with it:
HTTP URL
Source and destination IP address (possibly masked)
It should be noted that an HTTP filter or redirect rule is only
useful with plain-text HTTP and not HTTPS. Redirection or
filtering of HTTPS is outside the scope of this document.
As per the requirements of RFC 2865, Section 2.3, if multiple
NAS-Filter-Rule attributes are contained within an Access-
Request or Access-Accept packet, they MUST be maintained in
order. The attributes MUST be consecutive attributes in the
packet. RADIUS proxies MUST NOT reorder NAS-Filter-Rule
attributes.
The RADIUS server can return multiple NAS-Filter-Rule
attributes in an Access-Accept or CoA-Request packet. Where
more than one NAS-Filter-Rule attribute is included, it is
assumed that the attributes are to be concatenated to form a
single filter list. Furthermore, the concatenated filter list
must abide to the following rules of precedence and ordering:
1) A flush rule MUST appear before all other rule types.
Congdon, et al. Informational [Page 11]
INTERNET-DRAFT VLAN, Priority, and Filtering Attributes 9 June 2005
2) Base encapsulation filter rules MUST appear after a
flush rule and before IP tunnel, HTTP redirect, IP
filter, and/or HTTP filter rules.
3) IP tunnel rules MUST appear after any base encapsulation
rules and before any HTTP redirect, IP filter, and/or
HTTP filter rules
4) HTTP redirect rules MUST appear after any IP tunnel
rules and before any IP filter and/or HTTP filter rules.
5) IP filter rules MUST appear after any HTTP redirect
rules and before any HTTP filter rules.
6) HTTP filter rules MUST appear after any other rules.
Rules are evaluated in order, with the first matched rule
terminating the evaluation. Each packet is evaluated once. If
no rule matches, then packet is dropped (implicit deny all).
When an HTTP redirect rule matches, the NAS shall reply to the
HTTP request with an HTTP redirect in accordance with [RFC2616]
redirecting traffic to specific URL.
Filter-ID (11) and NAS-Filter-Rule both define how filters are
to be applied in the NAS. Both are not intended to be used
concurrently and SHOULD NOT appear in the same RADIUS message.
Only one type of filtering attribute must be processed. If a
Filter-ID (11) is present, then the NAS-Filter-Rule MUST be
ignored, if present..
The NAS-Filter-Rule 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 (TBD) | Length | Text |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Text (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD
Length
>= 3
Congdon, et al. Informational [Page 12]
INTERNET-DRAFT VLAN, Priority, and Filtering Attributes 9 June 2005
Text
The text conforms to the following specification:
NAS-Filter-Rule MUST follow the general format:
action [args] dir proto from src to dst [options]
action
permit - Allow packets that match the rule.
deny - Drop packets that match the rule.
redirect - Redirect packets that match the rule.
tunnel - Tunnel packets that match the rule.
flush - Remove all previously assigned filter rules.
When flush is specified, it can be followed
by other NAS-Filter attributes. This allows
for an atomic change of authorization with a
single RADIUS message.
args <[redir_cnt] redir_URL|tunnel_id>
For HTTP redirect rules:
redir_cnt Specifies the number of redirect rule matches
that should transpire before removing this
rule from the active rule set. Upon removal
from the active rule set, traffic is no
longer evaluated against this rule.
redir_URL An HTTP URL. When the 'redirect' rule matches
(src/dst), HTTP requests are redirected to
redir_URL address in accordance with
[RFC2616] redirection traffic to specific
URL.
For IP tunnel rules:
tunnel_id A tunnel id. When the 'tunnel' rule matches,
traffic is redirected over the tunnel with
the specified tunnel_id. Traffic can only be
redirected to or from named tunnels that have
been established per [RFC2868] and named
Congdon, et al. Informational [Page 13]
INTERNET-DRAFT VLAN, Priority, and Filtering Attributes 9 June 2005
using the Tunnel-Assignment-ID attribute
described therein.
dir "in" is from the terminal, "out" is to the
terminal, "inout" is from and to the terminal.
proto <l2:<ether2[:val]|rmon_str>> type[:val]|ipprot|ip|http>
For base encapsulation filter rules:
"l2" Prefix on any base encapsulation rule to
designate as rule as such.
"ether2" keyword means any Ethernet-II (DIX Ethernet)
will match.
ether2:val Used to specify an Ethernet-II type by
hexadecimal number, whereby "val" is replaced
by desired number. Example: "l2:ether2:0x800"
for IP ethertype (0x0800).
"rmon_str" Used to specify base encapsulation per the
octet string format defined in [RFC2895],
section 4.2. Example: "l2:0.0.0.2.0.0.0.240"
for Netbios over LLC.
For IP filter or tunnel rules:
"ip" keyword means any IP protocol will match.
ipprot An IP protocol specified by number.
For HTTP filter or redirect rules:
"http" keyword used to designate rule as of http
type.
src, dst <address/mask> [ports]
For base encapsulation filter rules of "l2:ether2" type,
<address/mask> may be specified as:
macaddr An Ethernet MAC address with octet values
separated by a "-". Example: "00-10-A4-23-
19-C0".
macaddr/mask An Ethernet number as above with a mask
width of the form "00-10-A4-23-19-C0/24".
In this case, all MAC addresses from 00-
10-A4-00-00-00 to 00-10-A4-FF-FF-FF will
match. The MAC address MUST NOT have bits
set beyond the mask. The keyword "any" is
00-00-00-00-00-00/0.
The sense of the match can be inverted by
preceding an address with the not modifier
Congdon, et al. Informational [Page 14]
INTERNET-DRAFT VLAN, Priority, and Filtering Attributes 9 June 2005
(!), causing all other addresses to be
matched instead.
Note: macaddr nor macaddr/mask argument is
not used for "l2:rmon" type rules. Also,
[ports] optional argument not valid for MAC
filter rules.
For IP filter or tunnel rules, the <address/mask> may be
specified as:
ipno An IPv4 or IPv6 number in dotted-quad or
canonical IPv6 form. Only this exact IP
number will match the rule.
ipno/bits An IP number as above with a mask width of
the form 1.2.3.4/24. In this case, all IP
numbers from 1.2.3.0 to 1.2.3.255 will match.
The bit width MUST be valid for the IP
version and the IP number MUST NOT have bits
set beyond the mask. For a match to occur,
the same IP version MUST be present in the
packet that was used in describing the IP
address. To test for a particular IP
version, the bits part can be set to zero.
The keyword "any" is 0.0.0.0/0 or the IPv6
equivalent. The keyword "assigned" is the
address or set of addresses assigned to the
terminal. For IPv4, a typical first rule is
often "deny in ip !assigned"
The sense of the match can be inverted by
preceding an address with the not modifier
(!), causing all other addresses to be
matched instead. This does not affect the
selection of port numbers.
With the TCP, UDP and SCTP protocols, optional ports
may be specified as:
{port/port-port}[,ports[,...]]
The '-' notation specifies a range of ports
(including boundaries). Fragmented packets that
have a non-zero offset (i.e., not the first
fragment) will never match a rule that has one
or more port specifications. See the frag
option for details on matching fragmented
packets.
Congdon, et al. Informational [Page 15]
INTERNET-DRAFT VLAN, Priority, and Filtering Attributes 9 June 2005
options
For all rule types other than 'flush', there is an
optional argument that can be specified:
Cnt Increments rule hit counter by one every
time a packet matches on rule. Counters
start with a zero value at session start
and are reset back to a zero value every
time an authorization change occurs due to
a CoA message.
For IP filter or tunnel rules, there are several
optional arguments that can be specified:
frag Match if the packet is a fragment and this
is not the first fragment of the datagram.
frag may not be used in conjunction with
either tcpflags or TCP/UDP port
specifications.
ipoptions spec
Match if the IP header contains the comma
separated list of options specified in
spec. The supported IP options are:
ssrr (strict source route), lsrr (loose
source route), rr (record packet route)
and ts(timestamp). The absence of a
particular option may be denoted with a
'!'.
tcpoptions spec
Match if the TCP header contains the comma
separated list of options specified in
spec. The supported TCP options are:
mss (maximum segment size), window (tcp
window advertisement), sack (selective
ack), ts (rfc1323 timestamp) and cc
(rfc1644 t/tcp connection count). The
absence of a particular option may be
denoted with a '!'.
established
TCP packets only. Match packets that have
the RST or ACK bits set.
setup TCP packets only. Match packets that have
the SYN bit set but no ACK bit.
tcpflags spec
Congdon, et al. Informational [Page 16]
INTERNET-DRAFT VLAN, Priority, and Filtering Attributes 9 June 2005
TCP packets only. Match if the TCP header
contains the comma separated list of flags
specified in spec. The supported TCP
flags are:
fin, syn, rst, psh, ack and urg. The
absence of a particular flag may be
denoted with a '!'. A rule that contains
a tcpflags specification can never match
a fragmented packet that has a non-zero
offset. See the frag option for details
on matching fragmented packets.
icmptypes types
ICMP packets only. Match if the ICMP type
is in the list types. The list may be
specified as any combination of ranges or
individual types separated by commas.
Both the numeric values and the symbolic
values listed below can be used. The
supported ICMP types are:
echo reply (0), destination unreachable
(3), source quench (4), redirect (5), echo
request(8), router advertisement (9),
router solicitation (10), time-to-live
exceeded (11), IP header bad (12),
timestamp request (13), timestamp reply
(14), information request (15),
information reply (16), address mask
request (17) and address mask reply (18).
Concise syntax statements for each rule type follow:
A NAS-Filter-Rule expressing a flush of all rules MUST follow
the syntax:
<flush>
A NAS-Filter-Rule expressing an base encapsulation filter rule
MUST follow the syntax:
<permit|deny> <in|out|inout> <l2:<ether2[:val]|rmon_str>> from
<address/mask> to <address/mask> [options]
A NAS-Filter-Rule expressing an IP tunnel or filter rule MUST
follow the syntax:
Congdon, et al. Informational [Page 17]
INTERNET-DRAFT VLAN, Priority, and Filtering Attributes 9 June 2005
<permit|deny|redirect <tunnel <tunnel_id>> <in|out|inout>
<ip|ip_proto> from <address/mask> to <address/mask> [ports]
[options]
A NAS-Filter-Rule expressing a HTTP redirect or filter rule
MUST follow the syntax:
<permit|deny|redirect> [redir_cnt] <redir_URL> <in|out|inout>
from <address/mask> to <address/mask> [options]
A NAS that is unable to interpret or apply a deny rule MUST
terminate the session. A NAS MAY apply deny rules of its own
before the supplied rules, for example to protect the access
device owner's infrastructure.
3.6. QoS-Filter-Rule
Description
The QoS-Filter-Rule attribute enables the provisioning of QoS
filters on the NAS by the RADIUS server. The QoS-Filter-Rule
attribute is defined as follows:
Type
TBD
Length
>=3
Text
The Text field contains a QoS filter, utilizing the syntax
defined for the QoSFilterRule derived data type defined in
[RFC3588], Section 4.3. Note that this definition contained an
error, so that the complete syntax is described in the
definition of the QoS-Filter-Rule AVP, defined in [NASREQ].
[Editorial: Is there a need to mention the possibility for
attribute fragmentation. Dave N. to provide RFC reference that
talks about the fragmentation of an AVP >256 over multiple
RADIUS attributes]
The RADIUS server can return multiple QoS-Filter-Rule
attributes in an Access-Accept or CoA-Request packet. Where
more than one QoS-Filter-Rule Rule attribute is included, it is
assumed that the attributes are to be concatenated to form a
single QOS filter.
Congdon, et al. Informational [Page 18]
INTERNET-DRAFT VLAN, Priority, and Filtering Attributes 9 June 2005
Whereas the maximum allowable message size in [NASREQ] is
greater than RADIUS' maximum allowable message size, it is
assumed that QOS filters that exceed RADIUS' allowable message
size will be broken into multiple QoS-Filter-Rule attributes by
the RADIUS server and concatenated back into a single QOS
filter by the NAS.
As per the requirements of RFC 2865, Section 2.3, if multiple
QoS-Filter-Rule attributes are contained within an Access-
Request or Access-Accept packet, they MUST be maintained in
order. The attributes MUST be consecutive attributes in the
packet. RADIUS proxies MUST NOT reorder QoS-Filter-Rule
attributes.
4. RADIUS Accounting
4.1. Acct-NAS-Filter-Rule
Description
Acct-NAS-Filter-Rule enables a RADIUS client to include NAS-
Filter-Rule[TODO] rule match counters as part of the accounting
message.
The Acct-NAS-Filter-Rule 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 (cont.)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD
Length
>=3
String
The first eight octets of this string are used for a 64-bit
value of the rule counter. The remaining octets are used to
specify which filter rule the counter value is for. The rule
Congdon, et al. Informational [Page 19]
INTERNET-DRAFT VLAN, Priority, and Filtering Attributes 9 June 2005
specification MUST conform to the syntax rules specified for
NAS-Filter-Rule[TODO].
4.2. Acct-EAP-Auth-Method
Description
Acct-EAP-Auth-Method enables a RADIUS client to include the EAP
method utilized within an accounting packet. The semantics of
this attribute are identical to that of the Acct-EAP-Auth-
Method AVP defined in [DiamEAP], Section 4.1.5. This is a
standard RADIUS attribute.
The Acct-EAP-Auth-Method 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 (cont.)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD
Length
10
String
The Value field is eight octets. In case of expanded types
defined in [RFC3748] Section 5.7, the least significant 32 bits
contain the Vendor-Type field, and the next 24 bits contain the
Vendor-Id field and 8 bits reserved data, which SHOULD be zero.
Congdon, et al. Informational [Page 20]
INTERNET-DRAFT VLAN, Priority, and Filtering Attributes 9 June 2005
5. 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-
Request Accept Reject Challenge Req # Attribute
0 0+ 0 0 0+ TBD Egress-VLANID
0 0-1 0 0 0-1 TBD Ingress-Filters
0 0-1 0 0 0-1 TBD User-Priority-Table
0 0+ 0 0 0+ TBD NAS-Filter-Rule
0 0+ 0 0 0+ TBD QoS-Filter-Rule
Actng- Actng-
Request Response # Attribute
0-1 0 TBD Acct-NAS-Filter-Rule
0-1 0 TBD Acct-EAP-Auth-Method
The following table defines the meaning of the above table
entries.
0 This attribute MUST NOT be present in 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.
6. IANA Considerations
This document uses the RADIUS [RFC2865] namespace, see
<http://www.iana.org/assignments/radius-types>. Allocation of
seven updates for the section "RADIUS Attribute Types" is
requested. The RADIUS attributes for which values are requested
are:
TBD - Egress-VLANID
TBD - Ingress-Filters
TBD - User-Priority-Table
TBD - NAS-Filter-Rule
TBD - QoS-Filter-Rule
TBD - Acct-NAS-Filter-Rule
TBD - Acct-EAP-Auth-Method
7. Security Considerations
Since this document describes the use of RADIUS for purposes of
authentication, authorization, and accounting in IEEE 802.1X-
enabled networks, it is vulnerable to all of the threats that are
present in other RADIUS applications. For a discussion of these
Congdon, et al. Informational [Page 21]
INTERNET-DRAFT VLAN, Priority, and Filtering Attributes 9 June 2005
threats, see [RFC2607], [RFC2865], [RFC3162], [RFC3576],
[RFC3579], and [RFC3580].
Vulnerabilities include:
Packet modification or forgery
Dictionary attacks
Known plaintext attacks
Key management issues
7.1. Packet Modification or Forgery
As noted in [RFC3580], when used with IEEE 802.1X, all RADIUS
packets MUST be authenticated and integrity protected. In
addition, as described in [RFC3579], Section 4.2:
To address the security vulnerabilities of RADIUS/EAP,
implementations of this specification SHOULD support IPsec
[RFC2401] along with IKE [RFC2409] for key management. IPsec
ESP [RFC2406] with non-null transform SHOULD be supported, and
IPsec ESP with a non-null encryption transform and
authentication support SHOULD be used to provide per-packet
confidentiality, authentication, integrity and replay
protection. IKE SHOULD be used for key management.
7.2. Dictionary Attacks
As discussed in [RFC3579] Section 4.3.3, the RADIUS shared secret
is vulnerable to offline dictionary attack, based on capture of
the Response Authenticator or Message-Authenticator attribute. In
order to decrease the level of vulnerability, [RFC2865], Section 3
recommends:
The secret (password shared between the client and the RADIUS
server) SHOULD be at least as large and unguessable as a well-
chosen password. It is preferred that the secret be at least
16 octets.
In addition, the risk of an offline dictionary attack can be
further mitigated by employing IPsec ESP with non-null
transform in order to encrypt the RADIUS conversation, as
described in [RFC3579], Section 4.2.
7.3. Known Plaintext Attacks
Since IEEE 802.1X is based on EAP, which does not support PAP, the
RADIUS User-Password attribute is not used to carry hidden user
passwords. The hiding mechanism utilizes MD5, defined in
[RFC1321], in order to generate a key stream based on the RADIUS
shared secret and the Request Authenticator. Where PAP is in
Congdon, et al. Informational [Page 22]
INTERNET-DRAFT VLAN, Priority, and Filtering Attributes 9 June 2005
use, it is possible to collect key streams corresponding to a
given Request Authenticator value, by capturing RADIUS
conversations corresponding to a PAP authentication attempt using
a known password. Since the User-Password is known, the key stream
corresponding to a given Request Authenticator can be determined
and stored.
The vulnerability is described in detail in [RFC3579], Section
4.3.4. Even though IEEE 802.1X Authenticators do not support PAP
authentication, a security vulnerability can still exist where the
same RADIUS shared secret is used for hiding User-Password as well
as other attributes. This can occur, for example, if the same
RADIUS proxy handles authentication requests for both IEEE 802.1X
(which may hide the Tunnel-Password, MS-MPPE-Send-Key and MS-MPPE-
Recv-Key attributes) and GPRS (which may hide the User-Password
attribute).
The threat can be mitigated by protecting RADIUS with IPsec ESP
with non-null transform, as described in [RFC3579], Section 4.2.
In addition, the same RADIUS shared secret MUST NOT used for both
IEEE 802.1X authentication and PAP authentication.
8. References
8.1. Normative references
[RFC1321] Rivest, R. and S. Dusse, "The MD5 Message-Digest
Algorithm", RFC 1321, April 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March, 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
L., Leach P., Berners-Lee T., "Hypertext Transfer Protocol
-- HTTP/1.1", RFC 2616, June 1999.
[RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865,
June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2867] Zorn, G., Mitton, D. and B. Aboba, "RADIUS Accounting
Modifications for Tunnel Protocol Support", RFC 2867, June
2000.
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M.
and I. Goyret, "RADIUS Attributes for Tunnel Protocol
Support", RFC 2868, June 2000.
Congdon, et al. Informational [Page 23]
INTERNET-DRAFT VLAN, Priority, and Filtering Attributes 9 June 2005
[RFC2895] Bierman, A., Bucci, C., Iddon, R., "Remote Network
Monitoring MIB Protocol Identifier Reference", RFC
2895, August 2000
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC
3162, August 2001.
[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 Support for Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., Arkko,
J., "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.
[IEEE8021X]
IEEE Standards for Local and Metropolitan Area Networks:
Port based Network Access Control, IEEE Std 802.1X-2004,
August 2004.
[IEEE802.11i]
Institute of Electrical and Electronics Engineers,
"Supplement to Standard for Telecommunications and
Information Exchange Between Systems - LAN/MAN Specific
Requirements - Part 11:Wireless LAN Medium Access Control
(MAC) and Physical Layer
(PHY) Specifications: Specification for Enhanced Security",
June 2004.
8.2. Informative references
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999.
[IEEE802] IEEE Standards for Local and Metropolitan Area Networks:
Overview and Architecture, ANSI/IEEE Std 802, 1990.
[IEEE8021Q]
IEEE Standards for Local and Metropolitan Area Networks:
Draft Standard for Virtual Bridged Local Area Networks,
P802.1Q, January 1998.
Congdon, et al. Informational [Page 24]
INTERNET-DRAFT VLAN, Priority, and Filtering Attributes 9 June 2005
[IEEE8021D]
IEEE Standards for Local and Metropolitan Area Networks:
Media Access Control (MAC) Bridges, IEEE Std 802.1D-2004,
June 2004.
[IEEE8023]
ISO/IEC 8802-3 Information technology - Telecommunications
And information exchange between systems - Local and
metropolitan area networks - Common specifications - Part
3: Carrier Sense Multiple Access with Collision Detection
(CSMA/CD) Access Method and Physical Layer Specifications,
(also ANSI/IEEE Std 802.3- 1996), 1996.
[IEEE80211]
Information technology - Telecommunications and information
exchange between systems - Local and metropolitan area
networks - Specific Requirements Part 11: Wireless LAN
Medium Access Control (MAC) and Physical Layer (PHY)
Specifications, IEEE Std. 802.11-1999, 1999.
Appendix A - Traffic Redirection
There are several ways to redirect the user's traffic. Which
method will be used depends on the capabilities available at the
NAS and Service Provider's preference. This Appendix describes
various methods to redirect user traffic by using the new
attributes outlined in this document in conjunction with existing
attributes, which are:
1) Tunneling; and
2) HTTP Redirection;
For each method we describe how redirection is done at service
initiation and mid-session. We also describe how redirection is
removed when it is no longer desired.
A.1 Tunneling
User traffic can be redirected by tunneling the user's traffic to
an alternate location. Tunneling will typically redirect all of
the user's traffic for the Service. When tunneling is used to
redirect all the traffic, then filtering may not be necessary.
Congdon, et al. Informational [Page 25]
INTERNET-DRAFT VLAN, Priority, and Filtering Attributes 9 June 2005
A.1.1 Service Initiation
Redirect using tunnels at service initiation requires that the
RADIUS server send the appropriate [RFC2868] tunnel attributes and
NAS-Filter-Rule attributes to the NAS. The [RFC2868] tunnel
attributes describe the tunnel endpoint and the type of tunnel to
construct. The "tunnel <tunnel_id>" option for the NAS-Filter-
Rule allows the specification of a traffic rule for which to
redirect traffic to a named tunnel.
A.1.2 Mid-session Tunnel Redirection
Redirection of traffic using tunnels mid-session involves sending
the tunnel attributes as per [RFC2868] to the NAS using Change-of-
Authorization (CoA) message. The operation is described in
[RFC3576]. Careful attention should be paid to the security
issues in [RFC3576].
Note that if the session is already tunneled (eg. Mobile-IP) then
the CoA message with a new tunnel specification can be sent to the
NAS or alternatively the redirection can occur at the tunnel
endpoint (the Home Agent) using any one of these methods.
A.1.3 Tunnel Redirection Removal
If the normal mode for the session was to tunnel the session and
redirection was sent to the NAS, the RADIUS Server can send the
original tunnel attributes to the NAS in a CoA message. The NAS
will tear down the tunnel and establish a connection back to the
original tunnel endpoint.
However, if the normal mode for the session is not to use
tunneling then there is a problem because RADIUS does not have a
mechanism whereby it can de-tunnel. Receiving a CoA message
without tunnel attributes would not have an effect on an existing
tunnel. In order to de-tunnel the session, the RADIUS server has
to send the NAS a CoA message with Service-Type(6) set to
"Authorize-Only" causing the NAS to perform a re-Authorization.
In response to the re-Authorization, the RADIUS server will send
an Access-Accept packet without the tunneling information. Upon
receiving the corresponding Access-Accept packet the NAS MUST
apply the new authorization attributes. If these do not contain
tunnel attributes, then the NAS MUST tear down the tunnel.
A.2 HTTP Redirection
Another method of redirection is at the application layer,
specifically the HTTP layer. An HTTP aware NAS redirects traffic
by issuing an HTTP Redirect response causing the users browser to
navigate to an alternate Web Portal.
Congdon, et al. Informational [Page 26]
INTERNET-DRAFT VLAN, Priority, and Filtering Attributes 9 June 2005
The same NAS-Filter-Rule(TBD) attribute described above is used to
convey the redirection rules to use for HTTP redirection. HTTP
redirection rules within the NAS-Filter-Rule attribute supports
the encoding of a redirection URL to apply when a rule is matched.
A.2.1 Service Initiation
As with previous call flows, the RADIUS MAY send multiple HTTP
redirect or filtering rules within a NAS-Filter-Rule(TBD)
attribute to the NAS in the Access-Accept message.
A.2.2 Mid-session HTTP Redirection
If HTTP redirection is required to be applied to a service that
has already been started then the RADIUS server can push the
redirection rules, and optionally the filter rules, to the NAS
within a NAS-Filter-Rule(TBD) attribute using a CoA message. The
NAS will then commence to apply the redirection rules and/or the
filter rules.
Alternatively, the RADIUS server can request that the NAS re-
authorize the session using the procedures defined in [RFC3576].
The RADIUS server responds with an Access-Accept message (with
Service-Type(6) set to "Authorize Only" that will contain the
redirection and optionally filtering rules within a NAS-Filter-
Rule(TBD) attribute.
A.2.3 HTTP Redirection Removal
The RADIUS serve can turn HTTP redirection off mid-session in two
way. It can push new redirection rules within a NAS-Filter-
Rule(TBD) attribute using a CoA message or it can send the NAS a
CoA message requesting it to re-authorize.
When using CoA message to return the redirection and filtering
back to "normal," there needs to be either a filter rule (or
filter-id) or redirection rule that corresponds to the "normal"
state. If normally the session did not have any filter and or
redirection rules applied, the RADIUS server can send a NAS-
Filter-Rule(TBD) with the action of "flush" in the CoA message.
This action will cause all the filter rules and redirection rules
previously assigned to the session to be removed.
A.3 Accounting
Congdon, et al. Informational [Page 27]
INTERNET-DRAFT VLAN, Priority, and Filtering Attributes 9 June 2005
Every time a session is redirected and every time the redirection
is reverted back a new session is created and the old one is
terminated. Therefore the NAS MUST generate and Accounting-
Request(Stop) for the old session and an Accounting-Request(Start)
for the new session.
A.4 Example Scenarios
The following two examples illustrate the user's experience when
being redirected.
For the first example assume an IEEE 8021X environment, whereby a
user connects to the enterprise LAN and initiates an
authentication handshake. As part of the overall authentication
process, it is also possible to pass endpoint state such as patch
level, virus signature status, etc., all of which can be verified
by a back-end server for policy compliancy and alter the
authentication and authorization decision. In instances that an
end-host is not in compliancy, the NAS may be instructed to limit
network access in some fashion (i.e. quarantine) and limit network
access to remediation services and a web-based information site.
A user may sense degraded network performance and open a web
session, which the NAS would redirect to the web-based information
site for compliancy status, remediation actions, etc.
For the second example assume an ISP environment, whereby a
prepaid user is roaming the net in their hotel room over WiFi is
to be Hot-lined because their account has no more funds. The
user's Service Provider instructs the NAS to block all traffic,
and redirect any port 80 traffic to the Service Provider's Prepaid
Portal. Upon detecting that there is no service, the user
launches his browser and regardless of which web site is being
accessed the browser traffic will arrive at the Prepaid Portal
which will then return a page back to the subscriber indicating
that he needs to replenish his account.
Acknowledgments
The authors would like to acknowledge Dorothy Stanley of Agere,
Joseph Salowey of Cisco, David Nelson of Enterasys, Chuck Black
of Hewlett Packard, and Ashwin Palekar of Microsoft.
Authors' Addresses
Paul Congdon
Hewlett Packard Company
HP ProCurve Networking
8000 Foothills Blvd, M/S 5662
Roseville, CA 95747
Congdon, et al. Informational [Page 28]
INTERNET-DRAFT VLAN, Priority, and Filtering Attributes 9 June 2005
EMail: paul.congdon@hp.com
Phone: +1 916 785 5753
Fax: +1 916 785 8478
Mauricio Sanchez
Hewlett Packard Company
HP ProCurve Networking
8000 Foothills Blvd, M/S 5559
Roseville, CA 95747
EMail: mauricio.sanchez@hp.com
Phone: +1 916 785 1910
Fax: +1 916 785 1815
Avi Lior
Bridgewater Systems Corporation
303 Terry Fox Drive
Suite 100
Ottawa, Ontario K2K 3J1
Canada
Phone: (613) 591-6655
EMail: avi@bridgewatersystems.com
URI: TCP://.bridgewatersystems.com/
Farid Adrangi
Intel Corporation
2111 North East 25th
Hillsboro, Oregon 97124
United States
Phone: (503) 712-1791
EMail: farid.adrangi@intel.com
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
Intellectual Property Statement
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
Congdon, et al. Informational [Page 29]
INTERNET-DRAFT VLAN, Priority, and Filtering Attributes 9 June 2005
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.
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.
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Congdon, et al. Informational [Page 30]
| PAFTECH AB 2003-2026 | 2026-04-23 08:59:38 |