draft-ietf-radext-filter-rules-02.txt   draft-ietf-radext-filter-rules-03.txt 
Networking Working Group Paul Congdon Networking Working Group Paul Congdon
INTERNET-DRAFT Mauricio Sanchez INTERNET-DRAFT Mauricio Sanchez
<draft-ietf-radext-filter-rules-02.txt> Hewlett-Packard Company <draft-ietf-radext-filter-rules-03.txt> Hewlett-Packard Company
A. Lior A. Lior
4 March 2007 Bridgewater Systems 3 July 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 September 9, 2007. This Internet-Draft will expire on January 3, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust 2007. All rights reserved. Copyright (C) The IETF Trust 2007. All rights reserved.
Abstract Abstract
This document defines the NAS-Traffic-Rule and Acct-NAS-Traffic- This document defines the NAS-Traffic-Rule and Acct-NAS-Traffic-
Rule attributes within Remote Authentication Dial In User Service Rule attributes within Remote Authentication Dial In User Service
(RADIUS) that is based on and extends on the filtering capability (RADIUS) that is based on and extends on the filtering capability
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Introduction........................................... 3 1. Introduction........................................... 3
1.1. Terminology...................................... 3 1.1. Terminology...................................... 3
1.2. Requirements Language............................ 4 1.2. Requirements Language............................ 4
1.3. Capability Advertisement ........................ 4 1.3. Capability Advertisement ........................ 4
1.4. Attribute Interpretation......................... 5 1.4. Attribute Interpretation......................... 5
2. RADIUS Authentication.................................. 5 2. RADIUS Authentication.................................. 5
2.5. NAS-Traffic-Rule.................................. 5 2.5. NAS-Traffic-Rule.................................. 5
3. RADIUS Accounting...................................... 15 3. RADIUS Accounting...................................... 16
3.1. Acct-NAS-Traffic-Rule............................. 15 3.1. Acct-NAS-Traffic-Rule............................. 16
4. Table of Attributes.................................... 16 4. Table of Attributes.................................... 17
5. Diameter Considerations................................ 16 5. Diameter Considerations................................ 17
6. IANA Considerations.................................... 17 6. IANA Considerations.................................... 18
7. Security Considerations................................ 17 7. Security Considerations................................ 18
8. References............................................. 18 8. References............................................. 19
8.1 Normative References................................... 18 8.1 Normative References................................... 19
8.2 Informative References................................. 19 8.2 Informative References................................. 20
Appendix A - Traffic Redirection.............................. 20 Appendix A - Traffic Redirection.............................. 22
Appendix B - NAS-Traffic-Rule Examples........................ 25 Appendix B - NAS-Traffic-Rule Examples........................ 27
ACKNOWLEDGMENTS............................................... 27 ACKNOWLEDGMENTS............................................... 28
AUTHORS' ADDRESSES............................................ 27 AUTHORS' ADDRESSES............................................ 28
Intellectual Property Statement............................... 28 Intellectual Property Statement............................... 29
Disclaimer of Validity........................................ 28 Disclaimer of Validity........................................ 30
Full Copyright Statement ..................................... 29 Full Copyright Statement ..................................... 30
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 various filtering attributes already exist for RADIUS, such While various filtering attributes already exist for RADIUS, such
as the [RFC2865] Filter-ID or [Filter] NAS-Filter-Rule attributes, as the [RFC2865] Filter-ID or [RFC4849] NAS-Filter-Rule
they have drawbacks or lack functionality. The Filter-ID attributes, they have drawbacks or lack functionality. The
attribute requires the NAS to be pre-populated with the desired Filter-ID attribute requires the NAS to be pre-populated with the
filters. This may be difficult to deploy in roaming scenarios desired filters. This may be difficult to deploy in roaming
where the home operator may not know what filters have been pre- scenarios where the home operator may not know what filters have
populated by the local operator. The NAS-Filer-Rule attribute been pre-populated by the local visited operator. The NAS-Filer-
only offers the same functionality as the Diameter [RFC4005] NAS- Rule attribute only offers the same functionality as the Diameter
Filter-Rule AVP, which is limited to layer 3 filtering. [RFC4005] NAS-Filter-Rule AVP, which is limited to layer 3
filtering.
The filtering attributes specified in this document enable The filtering attributes specified in this document enable
description of layer 2 and layer 3 filters as well as redirection, description of layer 2 and layer 3 filters as well as redirection,
and therefore extend the filter language described in [RFC3588]. and therefore extend the filter language described in [RFC3588].
The attributes defined in this document may be used with RADIUS Layer 2 filters are useful in filtering Protocol Data Unit (PDU)
traffic, such as IEEE 802.1D's [IEEE8021D] Bridge Protocol Data
Units (BPDU), for which layer 3 filters have no effect. The
attributes defined in this document may be used with RADIUS
dynamic authorization [RFC3576]. dynamic authorization [RFC3576].
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
skipping to change at page 7, line 40 skipping to change at page 7, line 45
Traffic-Rule attributes. Traffic-Rule attributes.
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), NAS-Filter-Rule [Filter] and NAS-Traffic-Rule Filter-ID (11), NAS-Filter-Rule [RFC4849] and NAS-Traffic-Rule
attributes define how filters are to be applied in the NAS. attributes define how filters are to be applied in the NAS.
These attributes are not intended to be used concurrently and These attributes are not intended to be used concurrently and
SHOULD NOT appear in the same RADIUS message. Only one type of SHOULD NOT appear in the same RADIUS message. Only one type of
filtering attribute must be processed. If a Filter-ID (11) is filtering attribute must be processed. If a Filter-ID (11) is
present, then the NAS-Traffic-Rule MUST be ignored, if present. present, then the NAS-Traffic-Rule MUST be ignored, if present.
A NAS-Traffic-Rule attribute may contain a partial rule, one
rule, or more than one rule. Rules may be contained across
attribute boundaries, so implementations cannot assume that
individual traffic rules begin or end on attribute boundaries.
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 18 skipping to change at page 8, line 31
Type Type
TBD TBD
Length Length
>= 3 >= 3
Text Text
The text conforms to the following ABNF [RFC2234] formatted syntax The text conforms to the following ABNF [RFC4234] formatted syntax
specification: specification:
; Start of ABNF description of NAS-Traffic-Rule ; Start of ABNF description of NAS-Traffic-Rule
rule = "v1" " " (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
skipping to change at page 10, line 19 skipping to change at page 10, line 31
;HTTP Filter Rule ;HTTP Filter Rule
http-filter-rule= ("permit" / "deny") org-url " " http-filter-rule= ("permit" / "deny") org-url " "
("in" / "out" / "inout") filter-body ("in" / "out" / "inout") filter-body
[" " log-rule] [" " log-rule]
;HTTP Redirect Rule ;HTTP Redirect Rule
http-redir-rule= "redirect " [redir-cnt " "] redir-url http-redir-rule= "redirect " [redir-cnt " "] redir-url
filter-body [" " org-url] filter-body [" " org-url]
[" " log-rule] [" " log-rule]
redir-cnt = 1*DIGIT redir-cnt = 1*DIGIT
org-url = http_URL org-url = http-URL
;Note: Syntax for http_URL defined in ;Note: Syntax for http-URL defined in
;[RFC2616], section 3.2.2 ;[RFC2616], section 3.2.2
redir-url = http_URL redir-url = http-URL
;Common ;Common
filter-body = " from " ip-address [" " layer4-ports] filter-body = " from " ip-address [" " layer4-ports]
" to " ip-address [" " layer4-ports] " to " ip-address [" " layer4-ports]
tunnel-id = DQUOTE tunnel-id = DQUOTE
1*(TEXTDATA / ("%" 2HEXDIG)) 1*(TEXTDATA / ("%" 2HEXDIG))
DQUOTE DQUOTE
log-rule = "cnt" log-rule = "cnt"
;Primitives ;Primitives
skipping to change at page 12, line 17 skipping to change at page 12, line 30
"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. If not specified, the
rule will match against all ports.
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
skipping to change at page 19, line 18 skipping to change at page 20, line 10
[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
[Filter] Congdon, P., Aboba B., and Mauricio S., "Filter Rule
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
skipping to change at page 19, line 52 skipping to change at page 20, line 38
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.
[RFC4234] Croker, E., Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC4849] Congdon, P., Aboba B., and Mauricio S., "Filter Rule
Attribute", RFC4849, April 2007.
[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.
[IEEE80211] [IEEE80211]
Information technology - Telecommunications and information Information technology - Telecommunications and information
skipping to change at page 20, line 27 skipping to change at page 21, line 21
[IEEE80211i] [IEEE80211i]
Institute of Electrical and Electronics Engineers, Institute of Electrical and Electronics Engineers,
"Supplement to Standard for Telecommunications and "Supplement to Standard for Telecommunications and
Information Exchange Between Systems - LAN/MAN Specific Information Exchange Between Systems - LAN/MAN Specific
Requirements - Part 11:Wireless LAN Medium Access Control Requirements - Part 11:Wireless LAN Medium Access Control
(MAC) and Physical Layer (MAC) and Physical Layer
(PHY) Specifications: Specification for Enhanced Security", (PHY) Specifications: Specification for Enhanced Security",
June 2004. June 2004.
[IEEE8021D]
IEEE Standard for Local and Metropolitan Area Networks:
Media Access Control (MAC) Bridges, IEEE St. 802.1D-2004,
June 2004.
Appendix A - Traffic Redirection Appendix A - Traffic Redirection
There are several ways to redirect the user's traffic. Which There are several ways to redirect the user's traffic. Which
method will be used depends on the capabilities available at the method will be used depends on the capabilities available at the
NAS and Service Provider's preference. This Appendix describes NAS and Service Provider's preference. This Appendix describes
various methods to redirect user traffic by using the new various methods to redirect user traffic by using the new
attributes outlined in this document in conjunction with existing attributes outlined in this document in conjunction with existing
attributes, which are: attributes, which are:
1) Tunneling; and 1) Tunneling; and
skipping to change at page 25, line 40 skipping to change at page 27, line 19
and redirect any port 80 traffic to the Service Provider's Prepaid and redirect any port 80 traffic to the Service Provider's Prepaid
Portal. Upon detecting that there is no service, the user Portal. Upon detecting that there is no service, the user
launches his browser and regardless of which web site is being launches his browser and regardless of which web site is being
accessed the browser traffic will arrive at the Prepaid Portal accessed the browser traffic will arrive at the Prepaid Portal
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 NAS-Traffic-Rule syntax.
Example #1: Permit all user traffic, regardless of type. Example #1: Permit all user traffic, regardless of type.
v1 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.
v1 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
skipping to change at page 26, line 23 skipping to change at page 27, line 51
v1 permit in ip from 192.0.2.128 to any v1 permit in ip from 192.0.2.128 to any
v1 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.
v1 permit in ip from assigned to any v1 permit in ip from assigned to any
v1 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 to anyone, DNS
HTTP (port 80) requests. Assume user's MAC address is 00-10-A4-23- requests to any DNS server, and HTTP (port 80) requests to any
19-C0 and IP address is 192.0.2.128. HTTP server. Assume user's MAC address is 00-10-A4-23-19-C0 and IP
address is 192.0.2.128.
v1 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
v1 permit out l2:ether:0x806 from any to 00-10-A4-23-19-C0 v1 permit out l2:ether:0x0806 from any to 00-10-A4-23-19-C0
v1 permit in 17 from 192.0.2.168 to any 53 v1 permit in 17 from 192.0.2.168 to any 53
v1 permit out 17 from any 53 to 192.0.2.168 v1 permit out 17 from any 53 to 192.0.2.168
v1 permit in 6 from 192.0.2.168 80 to any v1 permit in 6 from 192.0.2.168 to any 80
v1 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.
v1 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
v1 permit out l2:ether:0x806 from any to 00-10-A4-23-19-C0 v1 permit out l2:ether:0x0806 from any to 00-10-A4-23-19-C0
v1 permit in 17 from 192.0.2.168 to any 53 v1 permit in 17 from 192.0.2.168 to any 53
v1 permit out 17 from any 53 to 192.0.2.168 v1 permit out 17 from any 53 to 192.0.2.168
v1 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
v1 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
v1 permit out l2:ether:0x806 from any to 00-10-A4-23-19-C0 v1 permit out l2:ether:0x0806 from any to 00-10-A4-23-19-C0
v1 permit in 17 from 192.0.2.168 to any 53 v1 permit in 17 from 192.0.2.168 to any 53
v1 permit out 17 from any 53 to 192.0.2.168 v1 permit out 17 from any 53 to 192.0.2.168
v1 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 Dave Nelson, Joseph Salowey The authors would like to acknowledge Joseph Salowey of Cisco,
of Cisco, Chuck Black of Hewlett Packard, and Ashwin Palekar David Nelson of Enterasys, Chuck Black of Hewlett Packard, and
of Microsoft. Ashwin Palekar 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
 End of changes. 23 change blocks. 
52 lines changed or deleted 68 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/