draft-ietf-radext-filter-rules-01.txt   draft-ietf-radext-filter-rules-02.txt 
Networking Working Group Paul Congdon Networking Working Group Paul Congdon
INTERNET-DRAFT Mauricio Sanchez INTERNET-DRAFT Mauricio Sanchez
<draft-ietf-radext-filter-rules-01.txt> Hewlett-Packard Company <draft-ietf-radext-filter-rules-02.txt> Hewlett-Packard Company
A. Lior A. Lior
22 June 2006 Bridgewater Systems 4 March 2007 Bridgewater Systems
F. Adrangi F. Adrangi
Intel Intel
Bernard Aboba Bernard Aboba
Microsoft Microsoft
RADIUS Attributes for Filtering and Redirection RADIUS Attributes for Filtering and Redirection
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 have been or will be disclosed, and any of which he or she becomes
skipping to change at page 1, line 37 skipping to change at page 1, line 37
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December, 22 2006. This Internet-Draft will expire on September 9, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society 2006. All rights reserved. Copyright (C) The IETF Trust 2007. All rights reserved.
Abstract Abstract
In certain scenarios it is desirable to limit user access using This document defines the NAS-Traffic-Rule and Acct-NAS-Traffic-
filters or redirection. This document proposes additional Rule attributes within Remote Authentication Dial In User Service
attributes for this purpose, for use with the Remote (RADIUS) that is based on and extends on the filtering capability
Authentication Dial In User Server (RADIUS). The attributes defined by Diameter's NAS-Filter-Rule Attribute Value Pair (AVP)
described in this document are expected to be useful in a variety described in RFC 4005, and the IPFilterRule syntax defined in RFC
of environments, including enterprise and service provider 3588.
scenarios.
Table of Contents Table of Contents
1. Introduction........................................... 3 1. Introduction........................................... 3
1.1. Terminology...................................... 4 1.1. Terminology...................................... 3
1.2. Requirements Language............................ 4 1.2. Requirements Language............................ 4
1.3. Capability Advertisement ........................ 5 1.3. Capability Advertisement ........................ 4
1.4. Attribute Interpretation......................... 5 1.4. Attribute Interpretation......................... 5
2. RADIUS Authentication.................................. 6 2. RADIUS Authentication.................................. 5
2.5. NAS-Traffic-Rule.................................. 6 2.5. NAS-Traffic-Rule.................................. 5
3. RADIUS Accounting...................................... 15 3. RADIUS Accounting...................................... 15
3.1. Acct-NAS-Traffic-Rule............................. 15 3.1. Acct-NAS-Traffic-Rule............................. 15
4. Table of Attributes.................................... 16 4. Table of Attributes.................................... 16
5. Diameter Considerations................................ 16 5. Diameter Considerations................................ 16
6. IANA Considerations.................................... 17 6. IANA Considerations.................................... 17
7. Security Considerations................................ 17 7. Security Considerations................................ 17
8. References............................................. 18 8. References............................................. 18
8.1 Normative References................................... 18 8.1 Normative References................................... 18
8.2 Informative References............................... 18 8.2 Informative References................................. 19
Appendix A - Traffic Redirection............................ 19 Appendix A - Traffic Redirection.............................. 20
Appendix B - NAS-Traffic-Rule Examples...................... 25 Appendix B - NAS-Traffic-Rule Examples........................ 25
ACKNOWLEDGMENTS............................................... 26 ACKNOWLEDGMENTS............................................... 27
AUTHORS' ADDRESSES............................................ 26 AUTHORS' ADDRESSES............................................ 27
Intellectual Property Statement............................... 27 Intellectual Property Statement............................... 28
Disclaimer of Validity........................................ 28 Disclaimer of Validity........................................ 28
Full Copyright Statement ..................................... 28 Full Copyright Statement ..................................... 29
1. Introduction 1. Introduction
Within the confines of RADIUS authentication, authorization, and Within the confines of RADIUS authentication, authorization, and
accounting (AAA) environments, there is a requirement for accounting (AAA) environments, there is a requirement for
standardized RADIUS attributes to limit user access using filters standardized RADIUS attributes to limit user access using filters
and/or redirection. and/or redirection.
This document describes filtering and redirection attributes that This document describes filtering and redirection attributes that
may prove useful in IEEE 802.1X [IEEE8021X] environments, which may prove useful in IEEE 802.1X [IEEE8021X] environments, which
provides "network port authentication" for IEEE 802 [IEEE802] provides "network port authentication" for IEEE 802 [IEEE802]
media (including Ethernet [IEEE8023] and 802.11 [IEEE80211], media (including Ethernet [IEEE8023] and 802.11 [IEEE80211],
[IEEE80211i] wireless LANS), and a variety of other situations. [IEEE80211i] wireless LANS), and a variety of other situations.
While [RFC2865] Filter-ID attribute already exists for While various filtering attributes already exist for RADIUS, such
provisioning filtering rules, it is not without drawbacks. The as the [RFC2865] Filter-ID or [Filter] NAS-Filter-Rule attributes,
Filter-ID attribute requires the NAS to be pre-populated with the they have drawbacks or lack functionality. The Filter-ID
desired filters. This may be difficult to deploy in roaming attribute requires the NAS to be pre-populated with the desired
scenarios where the home operator may not know what filters have filters. This may be difficult to deploy in roaming scenarios
been pre-populated by the local operator. The filtering where the home operator may not know what filters have been pre-
attributes specified in this document enable explicit description populated by the local operator. The NAS-Filer-Rule attribute
of layer 2 and layer 3 filters as well as redirection, and only offers the same functionality as the Diameter [RFC4005] NAS-
therefore extend the filter language described in [RFC3588]. The Filter-Rule AVP, which is limited to layer 3 filtering.
attributes defined in this document may be used with RADIUS
dynamic authorization [RFC3576].
Besides IEEE 802.1X environments, there is a corollary need within The filtering attributes specified in this document enable
Internet Service Provider (ISP) environments for the attributes description of layer 2 and layer 3 filters as well as redirection,
described in this document to perform hot-lining. For example, an and therefore extend the filter language described in [RFC3588].
ISP may need to restrict a user's access to the Internet and The attributes defined in this document may be used with RADIUS
redirect their traffic to an alternate location because of dynamic authorization [RFC3576].
expiration of a prepaid plan. Another example is where the ISP
desires to restrict access and redirect a user that exhibited
fraudulent behavior.
User traffic redirection is supported with or without tunneling. User traffic redirection is supported with or without tunneling.
Tunneling support is provided using the tunnel attributes defined Tunneling support is provided using the tunnel attributes defined
in [RFC2868]. in [RFC2868].
1.1. Terminology 1.1. Terminology
In this document when we refer to blocking of IP traffic we mean In this document when we refer to blocking of IP traffic we mean
filtering of IP traffic. Additionally, this document uses the filtering of IP traffic. Additionally, this document uses the
following terms: following terms:
Authenticator Authenticator
An authenticator is an entity that requires An authenticator is an entity that requires authentication from
authentication from the supplicant. The authenticator the supplicant. The authenticator may be connected to the
may be connected to the supplicant at the other end of a supplicant at the other end of a point-to-point LAN segment or
point-to-point LAN segment or 802.11 wireless link. 802.11 wireless link.
Authentication server Authentication server
An authentication server is an entity that provides an An authentication server is an entity that provides an
authentication service to an authenticator. This service authentication service to an authenticator. This service
verifies from the credentials provided by the supplicant, verifies from the credentials provided by the supplicant, the
the claim of identity made by the supplicant. 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.
Redirection Redirection
Refers to an action taken by the NAS to redirect the Refers to an action taken by the NAS to redirect the user's
user's traffic to an alternate location. traffic to an alternate location.
Supplicant Supplicant
A supplicant is an entity that is being authenticated by A supplicant is an entity that is being authenticated by an
an authenticator. The supplicant may be connected to the authenticator. The supplicant may be connected to the
authenticator at one end of a point-to-point LAN segment authenticator at one end of a point-to-point LAN segment or
or 802.11 wireless link. 802.11 wireless link.
Terminal Terminal
A terminal is an endpoint, such as an 802.1X supplicant, A terminal is an endpoint, such as an 802.1X supplicant,
attached to the NAS port. attached to the NAS port.
1.2. Requirements Language 1.2. Requirements Language
In this document, several words are used to signify the In this document, several words are used to signify the
requirements of the specification. The key words "MUST", "MUST requirements of the specification. The key words "MUST", "MUST
NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
skipping to change at page 5, line 39 skipping to change at page 5, line 14
1.4 Attribute Interpretation 1.4 Attribute Interpretation
If a NAS conforming to this specification receives an Access- If a NAS conforming to this specification receives an Access-
Accept packet containing an attribute defined in this document Accept packet containing an attribute defined in this document
which it cannot apply, it MUST act as though it had received an which it cannot apply, it MUST act as though it had received an
Access-Reject. Access-Reject.
Similarly, [RFC3576] requires that a NAS receiving a CoA-Request Similarly, [RFC3576] requires that a NAS receiving a CoA-Request
containing an unsupported attribute reply with a CoA-NAK. It is containing an unsupported attribute reply with a CoA-NAK. It is
recommended that an Error-Cause attribute with value set to RECOMMENDED that an Error-Cause attribute with value set to
"Unsupported Attribute" (401) be included in the packet. As "Unsupported Attribute" (401) be included in the packet. As
noted in [RFC3576], authorization changes are atomic so that this noted in [RFC3576], authorization changes are atomic so that this
situation does not result in session termination and the pre- situation does not result in session termination and the pre-
existing configuration remains unchanged. As a result, no existing configuration remains unchanged. As a result, no
accounting packets should be generated. accounting packets should be generated.
2. RADIUS Authentication 2. RADIUS Authentication
This specification introduces one new RADIUS authentication This specification introduces one new RADIUS authentication
attribute. attribute.
2.5. NAS-Traffic-Rule 2.5. NAS-Traffic-Rule
Description Description
The NAS-Traffic-Rule attribute is derived from the Diameter The NAS-Traffic-Rule attribute is derived from the Diameter
IPFilterRule and enables provisioning of base encapsulation IPFilterRule syntax and enables provisioning of base
(Layer 2) rules, Internet Protocol (Layer 3-4) rules, and HTTP encapsulation (Layer 2) rules, Internet Protocol (Layer 3-4)
(Layer 5+) rules on the NAS by the RADIUS server. Compared to rules, and HTTP (Layer 5+) rules on the NAS by the RADIUS
Diameter's IPFilterRule, NAS-Traffic-Rule is a superset in server. Compared to Diameter's IPFilterRule syntax, NAS-
functionality, but is largely based on the same syntax Traffic-Rule is a superset in functionality, but is largely
foundations. based on the same syntax foundations.
Note: This document defines version 1 (v1) of the syntax for
the traffic rule attribute. The facility exists to extend the
syntax by using a new version number as noted in the ABNF
description. Future syntax revisions of this attribute may use
an incremented version number (e.g. v2).
For each rule and depending on the rule type, the NAS can be For each rule and depending on the rule type, the NAS can be
instructed to take a single action as follows: instructed to take a single action as follows:
Rule Type Allowable rule action Rule Type Allowable rule action
------------------- --------------------- ------------------- ---------------------
Base Encapsulation filter, tunnel Base Encapsulation filter, tunnel
Internet Protocol filter, tunnel Internet Protocol filter, tunnel
HTTP filter, redirect HTTP filter, redirect
When specifying a base encapsulation rule, NAS-Traffic-Rule When specifying a base encapsulation rule, NAS-Traffic-Rule
processes packets based on the following information that is processes packets based on the following information that is
associated with it: associated with it:
Direction (in and/or out) Direction (in and/or out)
Base encapsulation type Base encapsulation type
Source and destination MAC address (possibly masked) Source and destination MAC address (possibly masked)
For a base encapsulation rule, the filter action entails having For a base encapsulation rule, the filter action entails having
the NAS permit (i.e. forward) or deny (i.e. block) a user's the NAS permit (i.e. forward) or deny (i.e. block) a user's
skipping to change at page 7, line 50 skipping to change at page 7, line 27
As per the requirements of RFC 2865, Section 2.3, if multiple As per the requirements of RFC 2865, Section 2.3, if multiple
NAS-Traffic-Rule attributes are contained within an Access- NAS-Traffic-Rule attributes are contained within an Access-
Accept or CoA-Request packet, they MUST be maintained in order. Accept or CoA-Request packet, they MUST be maintained in order.
The attributes MUST be consecutive attributes in the packet. The attributes MUST be consecutive attributes in the packet.
RADIUS proxies MUST NOT reorder NAS-Traffic-Rule attributes. RADIUS proxies MUST NOT reorder NAS-Traffic-Rule attributes.
The RADIUS server can return multiple NAS-Traffic-Rule The RADIUS server can return multiple NAS-Traffic-Rule
attributes in an Access-Accept or CoA-Request packet. Where attributes in an Access-Accept or CoA-Request packet. Where
more than one NAS-Traffic-Rule attribute is included, it is more than one NAS-Traffic-Rule attribute is included, it is
assumed that the attributes are to be concatenated to form a assumed that the attributes are to be concatenated to form a
single filter list. Furthermore, if the list contains different single filter list. As noted in [RFC2865] Section 2.3, "the
types of rules, they MUST appear in the following order: flush forwarding server MUST NOT change the order of any attributes
rules, base encapsulation tunnel rules, base encapsulation of the same type", so that RADIUS proxies will no reorder NAS-
filter rules, IP tunnel rules, HTTP redirect rules, IP filter Traffic-Rule attributes.
rules, and HTTP filter rules.
Rules are evaluated in order, with the first matched rule Rules are evaluated in order, with the first matched rule
terminating the evaluation. Each packet is evaluated once. If terminating the evaluation. Each packet is evaluated once. If
no rule matches, then packet is dropped (implicit deny all). no rule matches, then packet is dropped (implicit deny all).
When an HTTP redirect rule matches, the NAS shall reply to the When an HTTP redirect rule matches, the NAS shall reply to the
HTTP request with an HTTP redirect in accordance with [RFC2616] HTTP request with an HTTP redirect in accordance with [RFC2616]
redirecting traffic to specific URL. redirecting traffic to specific URL.
Filter-ID (11) and NAS-Traffic-Rule both define how filters are Filter-ID (11), NAS-Filter-Rule [Filter] and NAS-Traffic-Rule
to be applied in the NAS. These attributes are not intended to attributes define how filters are to be applied in the NAS.
be used concurrently and SHOULD NOT appear in the same RADIUS These attributes are not intended to be used concurrently and
message. Only one type of filtering attribute must be SHOULD NOT appear in the same RADIUS message. Only one type of
processed. If a Filter-ID (11) is present, then the NAS- filtering attribute must be processed. If a Filter-ID (11) is
Traffic-Rule MUST be ignored, if present. present, then the NAS-Traffic-Rule MUST be ignored, if present.
The NAS-Traffic-Rule attribute is shown below. The fields are The NAS-Traffic-Rule attribute is shown below. The fields are
transmitted from left to right: transmitted from left to right:
0 1 2 3 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 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 | Type (TBD) | Length | Text
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Text (cont.) | Text (cont.) |
skipping to change at page 8, line 48 skipping to change at page 8, line 23
>= 3 >= 3
Text Text
The text conforms to the following ABNF [RFC2234] formatted syntax The text conforms to the following ABNF [RFC2234] formatted syntax
specification: specification:
; Start of ABNF description of NAS-Traffic-Rule ; Start of ABNF description of NAS-Traffic-Rule
rule = (flush-rule / permit-all-rule rule = "v1" " " (flush-rule / permit-all-rule
/ l2-filter-rule / l2-tunnel-rule / l2-filter-rule / l2-tunnel-rule
/ ip-filter-rule / ip-tunnel-rule / ip-filter-rule / ip-tunnel-rule
/ http-filter-rule / http-redir-rule) / http-filter-rule / http-redir-rule)
rule-delim rule-delim
; Flush Rule ; Flush Rule
flush-rule = "flush" flush-rule = "flush"
; Permit all rule ; Permit all rule
permit-all-rule = "permit inout any from any to any" permit-all-rule = "permit inout any from any to any"
[" " log-rule]
; Base encapsulation filter rule ; Base encapsulation filter rule
l2-filter-rule = ("permit" / "deny") " " l2-filter-rule = ("permit" / "deny") " "
("in" / "out" / "inout") " " ("in" / "out" / "inout") " "
l2-filter-body [" " log-rule] l2-filter-body [" " log-rule]
l2-filter-body = (l2-proto " from " l2-address " to " l2-filter-body = (l2-proto " from " l2-address " to "
l2-address) / l2-rmon-str l2-address) / l2-rmon-str
l2-proto = "l2:ether2" [":0x" 1*4HEXDIG] l2-proto = "l2:ether2" [":0x" 1*4HEXDIG]
l2-rmon-str = "l2:" 1*DIGIT *("." 1*DIGIT) l2-rmon-str = "l2:" 1*DIGIT *("." 1*DIGIT)
l2-address = ["!"] (macaddr / (macaddr "/" macmask) l2-address = ["!"] (macaddr / (macaddr "/" macmask)
skipping to change at page 11, line 31 skipping to change at page 11, line 4
/ "25" %x30-35 ; 250-255 / "25" %x30-35 ; 250-255
d16 = DIGIT ; 0-9 d16 = DIGIT ; 0-9
/ %x31-35 1*4DIGIT ; 10-59999 / %x31-35 1*4DIGIT ; 10-59999
/ "6" "4" 3DIGIT ; 60000-64999 / "6" "4" 3DIGIT ; 60000-64999
/ "6" "5" %x30-34 2DIGIT ; 65000-65499 / "6" "5" %x30-34 2DIGIT ; 65000-65499
/ "6" "5" "5" %x30-32 1DIGIT ; 65500-65529 / "6" "5" "5" %x30-32 1DIGIT ; 65500-65529
/ "6" "5" "5" "3" %x30-36 ; 65530-65536 / "6" "5" "5" "3" %x30-36 ; 65530-65536
TEXTDATA = %x20-21 / %x23-24 / %x26-7E TEXTDATA = %x20-21 / %x23-24 / %x26-7E
; End of ABNF description of NAS-Traffic-Rule ; End of ABNF description of NAS-Traffic-Rule
Descriptions of notable fields and keywords follow: Descriptions of notable fields and keywords follow:
'permit' Allow packets that match the rule. "v1" Required in every rule to mark rule as being
of 'v1' version of syntax. Future updates to
the rule syntax will be differentiated through
increments to this field (i.e. 'v2', 'v3', etc.).
'deny' Drop packets that match the rule. "permit" Allow packets that match the rule.
'redirect' Redirect packets that match the rule. "deny" Drop packets that match the rule.
'tunnel' Tunnel packets that match the rule. "redirect" Redirect packets that match the rule.
'flush' A flush rule removes all previously assigned "tunnel" Tunnel packets that match the rule.
"flush" A flush rule removes all previously assigned
filter rules. When flush is specified, it can be filter rules. When flush is specified, it can be
followed by other NAS-Traffic-Rule attributes. This followed by other NAS-Traffic-Rule attributes. This
allows for an atomic change of authorization with a allows for an atomic change of authorization with a
single RADIUS message. single RADIUS message.
'permit inout any from any to any' "permit inout any from any to any"
Special rule that matches against all traffic. This Special rule that matches against all traffic. This
allows the implicit deny at the end of a filter allows the implicit deny at the end of a filter
list to be overridden. list to be overridden.
'in' Is from the terminal. "in" Is from the terminal.
"out" Is to the terminal. "out" Is to the terminal.
'inout' Is from and to the terminal. "inout" Is from and to the terminal.
ipv4-address An IPv4 number in dotted-quad form. Only this ipv4-address An IPv4 number in dotted-quad form. Only this
exact IP number will match the rule. exact IP number will match the rule.
ipv6-address An IPv6 number in canonical IPv6 form. Only ipv6-address An IPv6 number in canonical IPv6 form. Only
this exact IP number will match the rule. this exact IP number will match the rule.
ipv4-address/ipv4mask ipv4-address/ipv4mask
An IP number with a mask width of the form An IP number with a mask width of the form
192.0.2.0/24. In this case, all IP numbers from 192.0.2.0/24. In this case, all IP numbers from
192.0.2.0 to 192.0.2.255 will match. 192.0.2.0 to 192.0.2.255 will match.
The bit width MUST be valid for the IP version and The bit width MUST be valid for the IP version and
the IP number MUST NOT have bits set beyond the the IP number MUST NOT have bits set beyond the
mask. For a match to occur, the same IP version mask. For a match to occur, the same IP version
MUST be present in the packet that was used in MUST be present in the packet that was used in
describing the IP address. To test for a describing the IP address. To test for a
particular IP version, the bits part can be set to particular IP version, the bits part can be set to
zero. zero.
'any' Keyword for 0.0.0.0/0 or the IPv6 equivalent. "any" Keyword for 0.0.0.0/0 or the IPv6 equivalent.
'assigned' Keyword for the address or set of addresses "assigned" Keyword for the address or set of addresses
assigned to the terminal. For IPv4, a typical assigned to the terminal. For IPv4, a typical
first rule is often "deny in ip !assigned" first rule is often "deny in ip !assigned"
The sense of the match can be inverted by preceding The sense of the match can be inverted by preceding
an address with the not modifier (!), causing all an address with the not modifier (!), causing all
other addresses to be matched instead. This does other addresses to be matched instead. This does
not affect the selection of port numbers. not affect the selection of port numbers.
layer4-port With the TCP, UDP and SCTP protocols, this field layer4-port With the TCP, UDP and SCTP protocols, this field
specifies ports to match. specifies ports to match.
Note: The '-' notation specifies a range of ports Note: The '-' notation specifies a range of ports
(including boundaries). Fragmented packets that (including boundaries). Fragmented packets that
have a non-zero offset (i.e., not the first have a non-zero offset (i.e., not the first
fragment) will never match a rule that has one or fragment) will never match a rule that has one or
more port specifications. See the 'frag' keyword more port specifications. See the "frag" keyword
for details on matching fragmented packets. for details on matching fragmented packets.
log-rule Increments rule hit counter by one every time a log-rule Increments rule hit counter by one every time a
packet matches on rule. Counters start with a zero packet matches on rule. Counters start with a zero
value at session start and are reset back to a zero value at session start and are reset back to a zero
value every time a successful authorization change value every time a successful authorization change
occurs due to a CoA message being received by the occurs due to a CoA message being received by the
NAS. NAS.
For base encapsulation rules: For base encapsulation rules:
'l2:' Prefix to designate a rule as a base encapsulation "l2:" Prefix to designate a rule as a base encapsulation
rule. rule.
'l2:ether2' Keyword means any Ethernet-II (DIX Ethernet) will "l2:ether2" keyword means any Ethernet-II (DIX Ethernet) will
match. match.
ether2:val Used to specify an Ethernet-II type by hexadecimal ether2:val Used to specify an Ethernet-II type by hexadecimal
number, whereby 'val' is replaced by desired number, whereby "val" is replaced by desired
number. Example: 'l2:ether2:0x800' for IP ethertype number. Example: "l2:ether2:0x800" for IP ethertype
(0x0800). (0x0800).
l2-rmon-str Used to specify base encapsulation per the octet l2-rmon-str Used to specify base encapsulation per the octet
string format defined in [RFC2895], section 4.2. string format defined in [RFC2895], section 4.2.
Example: 'l2:0.0.0.2.0.0.0.240' for Netbios over Example: "l2:0.0.0.2.0.0.0.240" for Netbios over
LLC. LLC.
macaddr For base encapsulation filter rules of 'l2:ether2' macaddr For base encapsulation filter rules of "l2:ether2"
type, the Ethernet MAC address with octet values type, the Ethernet MAC address with octet values
separated by a '-'. Example: '00-10-A4-23-19-C0'. separated by a "-". Example: "00-10-A4-23-19-C0".
macaddr/mask An Ethernet number as above with a mask width of macaddr/mask An Ethernet number as above with a mask width of
the form '00-10-A4-23-00-00/32'. In this case, all the form "00-10-A4-23-00-00/32". In this case, all
MAC addresses from 00-10-A4-23-00-00 to 00-10-A4- MAC addresses from 00-10-A4-23-00-00 to 00-10-A4-
23-FF-FF will match. The MAC address MUST NOT have 23-FF-FF will match. The MAC address MUST NOT have
bits set beyond the mask. The keyword 'any' is bits set beyond the mask. The keyword "any" is
00-00-00-00-00-00/0. 00-00-00-00-00-00/0.
The sense of the match can be inverted by preceding The sense of the match can be inverted by preceding
an address with the not modifier (!), causing all an address with the not modifier (!), causing all
other addresses to be matched instead. other addresses to be matched instead.
Note: macaddr nor macaddr/mask argument is not used Note: macaddr nor macaddr/mask argument is not used
for 'l2:rmon' type rules. for "l2:rmon" type rules.
For IP rules: For IP rules:
"ip" Keyword means any IP protocol will match. "ip" Keyword means any IP protocol will match.
ip-proto An IP protocol specified by number. ip-proto An IP protocol specified by number.
'frag' Match if the packet is a fragment and this is not "frag" Match if the packet is a fragment and this is not
the first fragment of the datagram. frag may not the first fragment of the datagram. frag may not
be used in conjunction with either tcpflags or be used in conjunction with either tcpflags or
TCP/UDP port specifications. TCP/UDP port specifications.
'ipoptions' Match if the IP header contains the comma separated "ipoptions" Match if the IP header contains the comma separated
list of options specified in spec. The supported list of options specified in spec. The supported
IP options are: ssrr (strict source route), lsrr IP options are: ssrr (strict source route), lsrr
(loose source route), rr (record packet route) and (loose source route), rr (record packet route) and
ts(timestamp). The absence of a particular option ts(timestamp). The absence of a particular option
may be denoted with a '!'. may be denoted with a '!'.
'tcpoptions' Match if the TCP header contains the comma "tcpoptions" Match if the TCP header contains the comma
separated list of options specified in spec. The separated list of options specified in spec. The
supported TCP options are: supported TCP options are:
mss (maximum segment size), window (tcp window mss (maximum segment size), window (tcp window
advertisement), sack (selective ack), ts (rfc1323 advertisement), sack (selective ack), ts (rfc1323
timestamp) and cc (rfc1644 t/tcp connection count). timestamp) and cc (rfc1644 t/tcp connection count).
The absence of a particular option may be denoted The absence of a particular option may be denoted
with a '!'. with a '!'.
'established' TCP packets only. Match packets that have the "established" TCP packets only. Match packets that have the
RST or ACK bits set. RST or ACK bits set.
'setup' TCP packets only. Match packets that have the SYN "setup" TCP packets only. Match packets that have the SYN
bit set but no ACK bit. bit set but no ACK bit.
'tcpflags' TCP packets only. Match if the TCP header contains "tcpflags" TCP packets only. Match if the TCP header contains
the comma separated list of flags specified in the comma separated list of flags specified in
spec. The supported TCP flags are: spec. The supported TCP flags are:
fin, syn, rst, psh, ack and urg. The absence of a fin, syn, rst, psh, ack and urg. The absence of a
particular flag may be denoted with a '!'. A rule particular flag may be denoted with a '!'. A rule
that contains a tcpflags specification can never that contains a tcpflags specification can never
match a fragmented packet that has a non-zero match a fragmented packet that has a non-zero
offset. See the 'frag' option for details on offset. See the "frag" option for details on
matching fragmented packets. matching fragmented packets.
'icmptypes' ICMP packets only. Match if the ICMP type is in "icmptypes" ICMP packets only. Match if the ICMP type is in
the list types. The list may be specified as any the list types. The list may be specified as any
combination of ranges or individual types separated combination of ranges or individual types separated
by commas. Both the numeric values and the by commas. Both the numeric values and the
symbolic values listed below can be used. The symbolic values listed below can be used. The
supported ICMP types are: supported ICMP types are:
echo reply (0), destination unreachable (3), source echo reply (0), destination unreachable (3), source
quench (4), redirect (5), echo request(8), router quench (4), redirect (5), echo request(8), router
advertisement (9), router solicitation (10), time- advertisement (9), router solicitation (10), time-
to-live exceeded (11), IP header bad (12), to-live exceeded (11), IP header bad (12),
skipping to change at page 17, line 13 skipping to change at page 16, line 40
entries. entries.
0 This attribute MUST NOT be present in packet. 0 This attribute MUST NOT be present in packet.
0+ Zero or more instances of this attribute MAY be present in 0+ Zero or more instances of this attribute MAY be present in
the packet. the packet.
0-1 Zero or one instance of this attribute MAY be 0-1 Zero or one instance of this attribute MAY be
present in the packet. present in the packet.
5. Diameter Considerations 5. Diameter Considerations
Diameter needs to define identical attributes with the same Type When used in Diameter, the attributes defined in this
values. The attributes should be available as part of the NASREQ specification can be used as Diameter attribute-value pair (AVPs)
application [RFC4005], as well as the Diameter EAP application from the Code space 1-255 (RADIUS attribute compatibility space).
[RFC4072]. 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|
---------------------------------|----+-----+----+-----|----|
NAS-Traffic-Rule OctetString| M | P | | V | Y |
Acct-NAS-Traffic-Rule 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.
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.
6. IANA Considerations 6. IANA Considerations
This specification does not create any new registries.
This document uses the RADIUS [RFC2865] namespace, see This document uses the RADIUS [RFC2865] namespace, see
<http://www.iana.org/assignments/radius-types>. Allocation of two <http://www.iana.org/assignments/radius-types>. Allocation of two
updates for the section 'RADIUS Attribute Types' is requested. The updates for the section "RADIUS Attribute Types" is requested. The
RADIUS attributes for which values are requested are: RADIUS attributes for which values are requested are:
TBD - NAS-Traffic-Rule TBD - NAS-Traffic-Rule
TBD - Acct-NAS-Traffic-Rule TBD - Acct-NAS-Traffic-Rule
7. Security Considerations 7. Security Considerations
Since this document describes the use of RADIUS for purposes of Since this document describes the use of RADIUS for purposes of
authentication, authorization, and accounting in [IEEE8021X] authentication, authorization, and accounting in [IEEE8021X]
enabled networks, it is vulnerable to all of the threats that are enabled networks, it is vulnerable to all of the threats that are
skipping to change at page 18, line 23 skipping to change at page 18, line 41
environment. environment.
8. References 8. References
8.1. Normative references 8.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March, 1997. Requirement Levels", RFC 2119, March, 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
L., Leach P., Berners-Lee T., 'Hypertext Transfer Protocol L., Leach P., Berners-Lee T., "Hypertext Transfer Protocol
-- HTTP/1.1', RFC 2616, June 1999. -- HTTP/1.1", RFC 2616, June 1999.
[RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, Authentication Dial In User Service (RADIUS)", RFC 2865,
June 2000. June 2000.
[RFC2895] Bierman, A., Bucci, C., Iddon, R., 'Remote Network [RFC2895] Bierman, A., Bucci, C., Iddon, R., "Remote Network
Monitoring MIB Protocol Identifier Reference', RFC Monitoring MIB Protocol Identifier Reference", RFC
2895, August 2000 2895, August 2000
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., Arkko, [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., Arkko,
J., "Diameter Base Protocol", RFC 3588, September 2003. J., "Diameter Base Protocol", RFC 3588, September 2003.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., Mitton, D., 'Diameter [RFC4005] Calhoun, P., Zorn, G., Spence, D., Mitton, D., "Diameter
Network Access Server Application', RFC 4005, August 2005. Network Access Server Application", RFC 4005, August 2005.
[IEEE802] IEEE Standards for Local and Metropolitan Area Networks: [IEEE802] IEEE Standards for Local and Metropolitan Area Networks:
Overview and Architecture, ANSI/IEEE Std 802, 1990. Overview and Architecture, ANSI/IEEE Std 802, 1990.
[IEEE8021X] [IEEE8021X]
IEEE Standards for Local and Metropolitan Area Networks: IEEE Standards for Local and Metropolitan Area Networks:
Port based Network Access Control, IEEE Std 802.1X-2004, Port based Network Access Control, IEEE Std 802.1X-2004,
August 2004. August 2004.
8.2. Informative references 8.2. Informative references
[RFC2234] Croker, E., Overell, P., 'Augmented BNF for Syntax [Filter] Congdon, P., Aboba B., and Mauricio S., "Filter Rule
Specifications: ABNF', RFC 2234, November 1997. Attribute ", draft-ietf-radext-filter-08.txt, January 2007.
[RFC2234] Croker, E., Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2607] Aboba, B., Vollbrecht, J., "Proxy Chaining and Policy [RFC2607] Aboba, B., Vollbrecht, J., "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999. Implementation in Roaming", RFC 2607, June 1999.
[RFC2818] Rescorla, E., 'HTTP Over TLS', RFC2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC2818, May 2000.
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M.
and I. Goyret, "RADIUS Attributes for Tunnel Protocol and I. Goyret, "RADIUS Attributes for Tunnel Protocol
Support", RFC 2868, June 2000. Support", RFC 2868, June 2000.
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC
3162, August 2001. 3162, August 2001.
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B.
Aboba,"Dynamic Authorization Extensions to Remote Aboba,"Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 3576, Authentication Dial In User Service (RADIUS)", RFC 3576,
July 2003. July 2003.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003. Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J.,
'IEEE 802.1X Remote Authentication Dial In User Service "IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines', RFC3580, September 2003. (RADIUS) Usage Guidelines", RFC3580, September 2003.
[RFC4072] Eronen, P., Hiller, T., Zorn G., 'Diameter Extensible [RFC4072] Eronen, P., Hiller, T., Zorn G., "Diameter Extensible
Authentication Protocol (EAP) Application', RFC4072, August Authentication Protocol (EAP) Application", RFC4072, August
2005. 2005.
[IEEE8023] [IEEE8023]
ISO/IEC 8802-3 Information technology - Telecommunications ISO/IEC 8802-3 Information technology - Telecommunications
And information exchange between systems - Local and And information exchange between systems - Local and
metropolitan area networks - Common specifications - Part metropolitan area networks - Common specifications - Part
3: Carrier Sense Multiple Access with Collision Detection 3: Carrier Sense Multiple Access with Collision Detection
(CSMA/CD) Access Method and Physical Layer Specifications, (CSMA/CD) Access Method and Physical Layer Specifications,
(also ANSI/IEEE Std 802.3- 1996), 1996. (also ANSI/IEEE Std 802.3- 1996), 1996.
skipping to change at page 21, line 49 skipping to change at page 22, line 21
client and a selected redirection destination will issue an client and a selected redirection destination will issue an
Access-Accept that contains the specification for the tunnel using Access-Accept that contains the specification for the tunnel using
the attributes defined by RFC 2868 and a NAS-Traffic-Rule the attributes defined by RFC 2868 and a NAS-Traffic-Rule
attribute using the tunnel action and arguments. attribute using the tunnel action and arguments.
An example NAS-Traffic-Rule will look like: An example NAS-Traffic-Rule will look like:
tunnel "t1" in ip from assigned to any tunnel "t1" in ip from assigned to any
This will cause all traffic that flows from the client to any This will cause all traffic that flows from the client to any
destination to be tunneled over the named tunnel 't1' to the destination to be tunneled over the named tunnel "t1" to the
tunnel endpoint (TEP). tunnel endpoint (TEP).
+-------+ +------+ +------+ +------+ +-------+ +------+ +------+ +------+
| | | | |Tunnel| | | | | | | |Tunnel| | |
|client +<---------->+ NAS +<==t1===>+ End +<----->+ Dest | |client +<---------->+ NAS +<==t1===>+ End +<----->+ Dest |
| | | | |Point | | | | | | | |Point | | |
+-------+ +------+ +------+ +------+ +-------+ +------+ +------+ +------+
The direction argument takes the values of 'in', 'out' or 'inout' The direction argument takes the values of "in", "out" or "inout"
and is important because it controls how information is routed. and is important because it controls how information is routed.
The following diagram demonstrates how traffic is routed. In all The following diagram demonstrates how traffic is routed. In all
these diagrams time is increasing as we proceed down the page. these diagrams time is increasing as we proceed down the page.
When rule direction is 'in': When rule direction is "in":
client NAS TEP DESTINATION client NAS TEP DESTINATION
| | | | | | | |
|---------->|===t1===>|--------->| |---------->|===t1===>|--------->|
| | | | | | | |
|<----------|<-------------------| (flows directly to NAS) |<----------|<-------------------| (flows directly to NAS)
| | | | | | | |
The inbound traffic from the client matches the specified filter The inbound traffic from the client matches the specified filter
rule and the IP packet is placed in the tunnel to the TEP. The TEP rule and the IP packet is placed in the tunnel to the TEP. The TEP
skipping to change at page 23, line 5 skipping to change at page 23, line 24
|---------->|===t1===>|--------->| |---------->|===t1===>|--------->|
| | | | | | | |
|<----------|<==t1====|<---------| |<----------|<==t1====|<---------|
The client establishes a connection to the Destination, but the The client establishes a connection to the Destination, but the
TEP acting as NAT, changes the source address of the IP packet (as TEP acting as NAT, changes the source address of the IP packet (as
NATs do) to that of the TEP/NAT. Now any replies from the NATs do) to that of the TEP/NAT. Now any replies from the
Destination are sent to the TEP/NAT. The TEP/NAT then forwards Destination are sent to the TEP/NAT. The TEP/NAT then forwards
these packets to the client through the NAS. these packets to the client through the NAS.
When the TEP is acting as a NAT, using the direction argument 'in' When the TEP is acting as a NAT, using the direction argument "in"
is important. The direction argument set to 'out' will have no is important. The direction argument set to "out" will have no
effect on traffic coming from the tunnel since all traffic to the effect on traffic coming from the tunnel since all traffic to the
client should come from the TEP/NAT inside the tunnel. The client should come from the TEP/NAT inside the tunnel. The
direction argument set to 'inout' will have the same effect as if direction argument set to "inout" will have the same effect as if
it were set to 'in'. it were set to "in".
The TEP/NAT forwards all traffic for the client into the tunnel to The TEP/NAT forwards all traffic for the client into the tunnel to
the NAS. The NAS always forwards any egressing traffic from the the NAS. The NAS always forwards any egressing traffic from the
tunnel to the client. It does not apply any redirection rules on tunnel to the client. It does not apply any redirection rules on
traffic egressing a tunnel. The NAS does not care whether the TEP traffic egressing a tunnel. The NAS does not care whether the TEP
is transparent or is acting as a NAT. is transparent or is acting as a NAT.
A.2 HTTP Redirection A.2 HTTP Redirection
Another method of redirection is at the application layer, Another method of redirection is at the application layer,
skipping to change at page 23, line 52 skipping to change at page 24, line 23
If HTTP redirection is required to be applied to a service that If HTTP redirection is required to be applied to a service that
has already been started then the RADIUS server can push the has already been started then the RADIUS server can push the
redirection rules, and optionally the filter rules, to the NAS redirection rules, and optionally the filter rules, to the NAS
within a NAS-Traffic-Rule(TBD) attribute using a CoA-Request within a NAS-Traffic-Rule(TBD) attribute using a CoA-Request
message. The NAS will then commence to apply the redirection rules message. The NAS will then commence to apply the redirection rules
and/or the filter rules. and/or the filter rules.
Alternatively, the RADIUS server can request that the NAS re- Alternatively, the RADIUS server can request that the NAS re-
authorize the session using the procedures defined in [RFC3576]. authorize the session using the procedures defined in [RFC3576].
The RADIUS server responds with an Access-Accept message (with The RADIUS server responds with an Access-Accept message (with
Service-Type(6) set to 'Authorize Only' that will contain the Service-Type(6) set to "Authorize Only" that will contain the
redirection and optionally filtering rules within a NAS-Traffic- redirection and optionally filtering rules within a NAS-Traffic-
Rule(TBD) attribute. Rule(TBD) attribute.
A.2.3 HTTP Redirection Removal A.2.3 HTTP Redirection Removal
HTTP Redirection rules can be automatically removed mid-session HTTP Redirection rules can be automatically removed mid-session
from the NAS using the redir-cnt parameter or explicitly removed from the NAS using the redir-cnt parameter or explicitly removed
from the RADIUS server. The RADIUS server can explicitly turn HTTP from the RADIUS server. The RADIUS server can explicitly turn HTTP
redirection off mid-session in two ways. It can push new redirection off mid-session in two ways. It can push new
redirection rules within a NAS-Traffic-Rule(TBD) attribute using a redirection rules within a NAS-Traffic-Rule(TBD) attribute using a
CoA-Request message or it can send the NAS a CoA-Request message CoA-Request message or it can send the NAS a CoA-Request message
requesting it to re-authorize. requesting it to re-authorize.
When using CoA-Request message to return the redirection and When using CoA-Request message to return the redirection and
filtering back to 'normal,' there needs to be either a filter rule filtering back to "normal," there needs to be either a filter rule
(or filter-id) or redirection rule that corresponds to the (or filter-id) or redirection rule that corresponds to the
'normal' state. If normally the session did not have any filter "normal" state. If normally the session did not have any filter
and or redirection rules applied, the RADIUS server can send a and or redirection rules applied, the RADIUS server can send a
NAS-Traffic-Rule(TBD) with the action of 'flush' in the CoA- NAS-Traffic-Rule(TBD) with the action of "flush" in the CoA-
Request message. This action will cause all the filter rules and Request message. This action will cause all the filter rules and
redirection rules previously assigned to the session to be redirection rules previously assigned to the session to be
removed. removed.
A.3 Accounting A.3 Accounting
Every time a session is redirected and every time the redirection Every time a session is redirected and every time the redirection
is reverted back a new session is created and the old one is is reverted back a new session is created and the old one is
terminated. Therefore the NAS MUST generate and Accounting- terminated. Therefore the NAS MUST generate and Accounting-
Request(Stop) for the old session and an Accounting-Request(Start) Request(Stop) for the old session and an Accounting-Request(Start)
skipping to change at page 25, line 23 skipping to change at page 25, line 44
which will then return a page back to the subscriber indicating which will then return a page back to the subscriber indicating
that he needs to replenish his account. that he needs to replenish his account.
Appendix B - NAS-Traffic-Rule Filter Examples Appendix B - NAS-Traffic-Rule Filter Examples
This appendix presents a variety of filter examples utilizing the This appendix presents a variety of filter examples utilizing the
syntax definition described in section 3.5 syntax definition described in section 3.5
Example #1: Permit all user traffic, regardless of type. Example #1: Permit all user traffic, regardless of type.
permit inout any from any to any v1 permit inout any from any to any
Example #2: Permit only L2 traffic coming from and going to a Example #2: Permit only L2 traffic coming from and going to a
user's Ethernet MAC address. Block all other traffic. Assume user's Ethernet MAC address. Block all other traffic. Assume
user's MAC address is 00-10-A4-23-19-C0. user's MAC address is 00-10-A4-23-19-C0.
permit in l2:ether2 from 00-10-A4-23-19-C0 to any v1 permit in l2:ether2 from 00-10-A4-23-19-C0 to any
permit out l2:ether2 from any to 00-10-A4-23-19-C0 v1 permit out l2:ether2 from any to 00-10-A4-23-19-C0
Example #3: Tunnel all L2 traffic coming from and going to a user. Example #3: Tunnel all L2 traffic coming from and going to a user.
Assume tunnel name is: tunnel '1234'. Assume tunnel name is: tunnel "1234".
permit tunnel 'tunnel \'1234\'' inout l2:ether2 from any to any v1 permit tunnel "tunnel \"1234\"" inout l2:ether2 from any to
any
Example #4: Permit only L3 traffic coming and going to from a Example #4: Permit only L3 traffic coming and going to from a
user's IP address. Block all other traffic. Assume user's IP user's IP address. Block all other traffic. Assume user's IP
address is 192.0.2.128. address is 192.0.2.128.
permit in ip from 192.0.2.128 to any v1 permit in ip from 192.0.2.128 to any
permit out ip from any to 192.0.2.128 v1 permit out ip from any to 192.0.2.128
Example #5: Permit only L3 traffic coming and going to the user's Example #5: Permit only L3 traffic coming and going to the user's
assigned IP address. Block all other traffic. assigned IP address. Block all other traffic.
permit in ip from assigned to any v1 permit in ip from assigned to any
permit out ip from any to assigned v1 permit out ip from any to assigned
Example #6: Allow user to generate ARP requests, DNS requests, and Example #6: Allow user to generate ARP requests, DNS requests, and
HTTP (port 80) requests. Assume user's MAC address is 00-10-A4-23- HTTP (port 80) requests. Assume user's MAC address is 00-10-A4-23-
19-C0 and IP address is 192.0.2.128. 19-C0 and IP address is 192.0.2.128.
permit in l2:ether:0x0806 from 00-10-A4-23-19-C0 to any v1 permit in l2:ether:0x0806 from 00-10-A4-23-19-C0 to any
permit out l2:ether:0x806 from any to 00-10-A4-23-19-C0 v1 permit out l2:ether:0x806 from any to 00-10-A4-23-19-C0
permit in 17 from 192.0.2.168 to any 53 v1 permit in 17 from 192.0.2.168 to any 53
permit out 17 from any 53 to 192.0.2.168 v1 permit out 17 from any 53 to 192.0.2.168
permit in 6 from 192.0.2.168 80 to any v1 permit in 6 from 192.0.2.168 80 to any
permit out 6 from any 80 to 192.0.2.168 v1 permit out 6 from any 80 to 192.0.2.168
Example #7: Allow user to generate ARP requests, DNS requests, and Example #7: Allow user to generate ARP requests, DNS requests, and
HTTP (port 80) requests, any of which are redirected to HTTP (port 80) requests, any of which are redirected to
http://www.goo.org. Assume user's MAC address is 00-10-A4-23-19-C0 http://www.goo.org. Assume user's MAC address is 00-10-A4-23-19-C0
and IP address is 192.0.2.128. and IP address is 192.0.2.128.
permit in l2:ether:0x0806 from 00-10-A4-23-19-C0 to any v1 permit in l2:ether:0x0806 from 00-10-A4-23-19-C0 to any
permit out l2:ether:0x806 from any to 00-10-A4-23-19-C0 v1 permit out l2:ether:0x806 from any to 00-10-A4-23-19-C0
permit in 17 from 192.0.2.168 to any 53 v1 permit in 17 from 192.0.2.168 to any 53
permit out 17 from any 53 to 192.0.2.168 v1 permit out 17 from any 53 to 192.0.2.168
redirect http://www.goo.org in from 192.0.2.168 to any 80 v1 redirect http://www.goo.org in from 192.0.2.168 to any 80
Example #8: Allow user to generate ARP requests, DNS requests, and Example #8: Allow user to generate ARP requests, DNS requests, and
HTTP (port 80) requests, of which only requests to HTTP (port 80) requests, of which only requests to
http://www.goo.org are redirected to http://www.goo.org. Assume http://www.goo.org are redirected to http://www.goo.org. Assume
user's MAC address is 00-10-A4-23-19-C0 and IP address is user's MAC address is 00-10-A4-23-19-C0 and IP address is
192.0.2.128 192.0.2.128
permit in l2:ether:0x0806 from 00-10-A4-23-19-C0 to any v1 permit in l2:ether:0x0806 from 00-10-A4-23-19-C0 to any
permit out l2:ether:0x806 from any to 00-10-A4-23-19-C0 v1 permit out l2:ether:0x806 from any to 00-10-A4-23-19-C0
permit in 17 from 192.0.2.168 to any 53 v1 permit in 17 from 192.0.2.168 to any 53
permit out 17 from any 53 to 192.0.2.168 v1 permit out 17 from any 53 to 192.0.2.168
redirect http://www.goo.org in from 192.0.2.168 to any 80 v1 redirect http://www.goo.org in from 192.0.2.168 to any 80
http://www.goo.org http://www.goo.org
Acknowledgments Acknowledgments
The authors would like to acknowledge Joseph Salowey of Cisco, The authors would like to acknowledge Dave Nelson, Joseph Salowey
David Nelson of Enterasys, Chuck Black of Hewlett Packard, and of Cisco, Chuck Black of Hewlett Packard, and Ashwin Palekar
Ashwin Palekar of Microsoft. of Microsoft.
Authors' Addresses Authors' Addresses
Paul Congdon Paul Congdon
Hewlett Packard Company Hewlett Packard Company
HP ProCurve Networking HP ProCurve Networking
8000 Foothills Blvd, M/S 5662 8000 Foothills Blvd, M/S 5662
Roseville, CA 95747 Roseville, CA 95747
EMail: paul.congdon@hp.com EMail: paul.congdon@hp.com
skipping to change at page 28, line 4 skipping to change at page 28, line 19
Bernard Aboba Bernard Aboba
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
EMail: bernarda@microsoft.com EMail: bernarda@microsoft.com
Phone: +1 425 706 6605 Phone: +1 425 706 6605
Fax: +1 425 936 7329 Fax: +1 425 936 7329
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be The IETF takes no position regarding the validity or scope of any
claimed to pertain to the implementation or use of the Intellectual Property Rights or other rights that might be claimed
technology described in this document or the extent to which to pertain to the implementation or use of the technology
any license under such rights might or might not be available; described in this document or the extent to which any license
nor does it represent that it has made any independent effort under such rights might or might not be available; nor does it
to identify any such rights. Information on the procedures represent that it has made any independent effort to identify any
with respect to rights in RFC documents can be found in BCP 78 such rights. Information on the procedures with respect to rights
and BCP 79. in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of assurances of licenses to be made available, or the result of an
an attempt made to obtain a general license or permission for attempt made to obtain a general license or permission for the use
the use of such proprietary rights by implementers or users of of such proprietary rights by implementers or users of this
this specification can be obtained from the IETF on-line IPR specification can be obtained from the IETF on-line IPR repository
repository at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be proprietary rights that may cover technology that may be required
required to implement this standard. Please address the to implement this standard. Please address the information to the
information to the IETF at ietf-ipr@ietf.org. IETF at ietf-ipr@ietf.org.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided This document and the information contained herein are provided on
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION an
HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2006). This document is Copyright (C) The IETF Trust (2007).
subject to the rights, licenses and restrictions contained in
BCP 78, and except as set forth therein, the authors retain all This document is subject to the rights, licenses and restrictions
their rights. contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Open issues
Open issues relating to this specification are tracked on the
following web site:
http://www.drizzle.com/~aboba/RADEXT/
 End of changes. 87 change blocks. 
194 lines changed or deleted 232 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/