Networking Working Group                                Paul Congdon
   INTERNET-DRAFT                                      Mauricio Sanchez
   <draft-ietf-radext-filter-rules-02.txt>      Hewlett-Packard Company
                                                                A. Lior
   4 March 2007                                     Bridgewater Systems
                                                             F. Adrangi
                                                                  Intel
                                                          Bernard Aboba
                                                              Microsoft

              RADIUS Attributes for Filtering and Redirection

      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 September 9, 2007.

   Copyright Notice

      Copyright (C) The IETF Trust 2007.  All rights reserved.

   Abstract

      This document defines the NAS-Traffic-Rule and Acct-NAS-Traffic-
      Rule attributes within Remote Authentication Dial In User Service
      (RADIUS) that is based on and extends on the filtering capability
      defined by Diameter's NAS-Filter-Rule Attribute Value Pair (AVP)
      described in RFC 4005, and the IPFilterRule syntax defined in RFC
      3588.




Congdon, et al.           Proposed Standard                  [Page 1]


INTERNET-DRAFT   Attr. for Filtering and Redirection     4 March 2007

   Table of Contents

   1.     Introduction...........................................    3
      1.1.      Terminology......................................    3
      1.2.      Requirements Language............................    4
      1.3.      Capability Advertisement ........................    4
      1.4.      Attribute Interpretation.........................    5
   2.     RADIUS Authentication..................................    5
      2.5.      NAS-Traffic-Rule..................................   5
   3.     RADIUS Accounting......................................   15
      3.1.      Acct-NAS-Traffic-Rule.............................  15
   4.     Table of Attributes....................................   16
   5.     Diameter Considerations................................   16
   6.     IANA Considerations....................................   17
   7.     Security Considerations................................   17
   8.     References.............................................   18
      8.1 Normative References...................................   18
      8.2 Informative References.................................   19
   Appendix A - Traffic Redirection..............................   20
   Appendix B - NAS-Traffic-Rule Examples........................   25
   ACKNOWLEDGMENTS...............................................   27
   AUTHORS' ADDRESSES............................................   27
   Intellectual Property Statement...............................   28
   Disclaimer of Validity........................................   28
   Full Copyright Statement .....................................   29


























Congdon, et al.           Proposed Standards                  [Page 2]


INTERNET-DRAFT   Attr. for Filtering and Redirection     4 March 2007


   1.  Introduction

      Within the confines of RADIUS authentication, authorization, and
      accounting (AAA) environments, there is a requirement for
      standardized RADIUS attributes to limit user access using filters
      and/or redirection.

      This document describes filtering and redirection attributes that
      may prove useful in IEEE 802.1X [IEEE8021X] environments, which
      provides "network port authentication" for IEEE 802 [IEEE802]
      media (including Ethernet [IEEE8023] and 802.11 [IEEE80211],
      [IEEE80211i] wireless LANS), and a variety of other situations.

      While various filtering attributes already exist for RADIUS, such
      as the [RFC2865] Filter-ID or [Filter] NAS-Filter-Rule attributes,
      they have drawbacks or lack functionality.  The Filter-ID
      attribute requires the NAS to be pre-populated with the desired
      filters. This may be difficult to deploy in roaming scenarios
      where the home operator may not know what filters have been pre-
      populated by the local operator.  The NAS-Filer-Rule attribute
      only offers the same functionality as the Diameter [RFC4005] NAS-
      Filter-Rule AVP, which is limited to layer 3 filtering.

      The filtering attributes specified in this document enable
      description of layer 2 and layer 3 filters as well as redirection,
      and therefore extend the filter language described in [RFC3588].
      The attributes defined in this document may be used with RADIUS
      dynamic authorization [RFC3576].

      User traffic redirection is supported with or without tunneling.
      Tunneling support is provided using the tunnel attributes defined
      in [RFC2868].

   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:

      Authenticator
         An authenticator is an entity that requires 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


Congdon, et al.           Proposed Standards                  [Page 3]


INTERNET-DRAFT   Attr. for Filtering and Redirection     4 March 2007

         verifies from the credentials provided by the supplicant, the
         claim of identity made by the supplicant.

      Redirection
         Refers to an action taken by the NAS to redirect the user's
         traffic to an alternate location.

      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.

      Terminal
         A terminal is an endpoint, such as an 802.1X supplicant,
         attached to the NAS port.

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

   1.3. 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-
      Traffic-Rule(TBD), can benefit from capability advertisement, if
      available.


Congdon, et al.           Proposed Standards                  [Page 4]


INTERNET-DRAFT   Attr. for Filtering and Redirection     4 March 2007


   1.4 Attribute Interpretation

      If a NAS conforming to this specification receives an Access-
      Accept packet containing an attribute defined in this document
      which it cannot apply, it MUST act as though it had received an
      Access-Reject.

      Similarly, [RFC3576] requires that a NAS receiving a CoA-Request
      containing an unsupported attribute reply with a CoA-NAK.  It is
      RECOMMENDED that an Error-Cause attribute with value set to
      "Unsupported Attribute" (401) be included in the packet.  As
      noted in [RFC3576], authorization changes are atomic so that this
      situation does not result in session termination and the pre-
      existing configuration remains unchanged.  As a result, no
      accounting packets should be generated.

   2.   RADIUS Authentication

      This specification introduces one new RADIUS authentication
      attribute.

   2.5.  NAS-Traffic-Rule

      Description

         The NAS-Traffic-Rule attribute is derived from the Diameter
         IPFilterRule syntax and enables provisioning of base
         encapsulation (Layer 2) rules, Internet Protocol (Layer 3-4)
         rules, and HTTP (Layer 5+) rules on the NAS by the RADIUS
         server.  Compared to Diameter's IPFilterRule syntax, NAS-
         Traffic-Rule is a superset in functionality, but is largely
         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
         instructed to take a single action as follows:

            Rule Type               Allowable rule action
            -------------------     ---------------------
            Base Encapsulation      filter, tunnel
            Internet Protocol       filter, tunnel
            HTTP                    filter, redirect



Congdon, et al.           Proposed Standards                  [Page 5]


INTERNET-DRAFT   Attr. for Filtering and Redirection     4 March 2007

         When specifying a base encapsulation rule, NAS-Traffic-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)

         For a base encapsulation rule, the filter action entails having
         the NAS permit (i.e. forward) or deny (i.e. block) a user's
         traffic. The tunnel action entails having the NAS forward user
         traffic to or from a named tunnel that has been established per
         [RFC2868].

         When specifying an Internet Protocol rule, NAS-Traffic-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

         For an Internet Protocol rule, the filter action entails having
         the NAS permit (i.e. forward) or deny (i.e. block) a user's
         traffic.  The tunnel action entails having the NAS forward user
         traffic to or from a named tunnel that has been established per
         [RFC2868].

         When specifying an HTTP rule, NAS-Traffic-Rule processes
         packets based on the following information that is associated
         with it:

            HTTP URL
            Source and destination IP address   (possibly masked)

         For an HTTP rule, the filter action entails having the NAS
         permit (i.e. forward) or deny (i.e. block) a user's [RFC2616]
         request message.  For a deny action, the NAS MAY respond to the
         request message with a code 403 (Forbidden) response in
         accordance with [RFC2616]. For a redirect action the NAS SHOULD
         respond to the user's request with a code 302 (Found) response
         in accordance with [RFC2616].




Congdon, et al.           Proposed Standards                  [Page 6]


INTERNET-DRAFT   Attr. for Filtering and Redirection     4 March 2007

         For the HTTP redirection action, it is also possible to have
         redirection automatically removed by including a redir-cnt
         count parameter along with the rule.  The rule will be removed
         from the active rule set when the rule matches redir-cnt number
         of times. Upon removal from the active rule set, traffic is no
         longer evaluated against this rule.

         It should be noted that an HTTP filter or redirect rule is only
         useful with plain-text HTTP and not [RFC2818] 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-Traffic-Rule attributes are contained within an Access-
         Accept or CoA-Request packet, they MUST be maintained in order.
         The attributes MUST be consecutive attributes in the packet.
         RADIUS proxies MUST NOT reorder NAS-Traffic-Rule attributes.

         The RADIUS server can return multiple NAS-Traffic-Rule
         attributes in an Access-Accept or CoA-Request packet. Where
         more than one NAS-Traffic-Rule attribute is included, it is
         assumed that the attributes are to be concatenated to form a
         single filter list. As noted in [RFC2865] Section 2.3, "the
         forwarding server MUST NOT change the order of any attributes
         of the same type", so that RADIUS proxies will no reorder NAS-
         Traffic-Rule attributes.

         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), NAS-Filter-Rule [Filter] and NAS-Traffic-Rule
         attributes define how filters are to be applied in the NAS.
         These attributes 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-Traffic-Rule MUST be ignored, if present.

      The NAS-Traffic-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


Congdon, et al.           Proposed Standards                  [Page 7]


INTERNET-DRAFT   Attr. for Filtering and Redirection     4 March 2007

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                  Text (cont.)                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         TBD

      Length

         >= 3

      Text

      The text conforms to the following ABNF [RFC2234] formatted syntax
      specification:

         ; Start of ABNF description of NAS-Traffic-Rule

         rule           =  "v1" " " (flush-rule / permit-all-rule
                           / l2-filter-rule / l2-tunnel-rule
                           / ip-filter-rule / ip-tunnel-rule
                           / http-filter-rule / http-redir-rule)
                           rule-delim

         ; Flush Rule
         flush-rule     =  "flush"

         ; Permit all rule
         permit-all-rule = "permit inout any from any to any"
                           [" " log-rule]

         ; Base encapsulation filter rule
         l2-filter-rule =  ("permit" / "deny") " "
                           ("in" / "out" / "inout") " "
                           l2-filter-body [" " log-rule]
         l2-filter-body =  (l2-proto " from " l2-address " to "
                           l2-address) / l2-rmon-str
         l2-proto       =  "l2:ether2" [":0x" 1*4HEXDIG]
         l2-rmon-str    =  "l2:" 1*DIGIT *("." 1*DIGIT)
         l2-address     =  ["!"] (macaddr / (macaddr "/" macmask)
                           / "any")
         macaddr        =  2HEXDIG 5("-" 2HEXDIG)
         macmask        =  DIGIT                ; 0-9
                           / %x31-33 DIGIT      ; 10-39
                           / "4" %x30-38        ; 40-48

         ;Base encapsulation tunnel rule
         l2-tunnel-rule =  "tunnel " tunnel-id " "


Congdon, et al.           Proposed Standards                  [Page 8]


INTERNET-DRAFT   Attr. for Filtering and Redirection     4 March 2007

                           ("in" / "out" / "inout") " "
                           l2-filter-body [" " log-rule]

         ;IP Filter Rule
         ip-filter-rule =  ("permit" / "deny") " "
                           ("in" / "out" / "inout") " "
                           ("ip" / ip-proto) filter-body
                           [" " ip-option] [" " log-rule]
         ip-proto       =  d8
         ip-address     =  ["!"] (ipv4-address ["/" ipv4mask] /
                                  ipv6-address ["/" ipv6mask] /
                                  "any" /
                                  "assigned")
         ipv4-address   =  d8 "." d8 "." d8 "." d8
         ipv4mask       =  DIGIT                   ; 0-9
                           / %x31-32 DIGIT         ; 10-29
                           / "3" %x30-32           ; 30-32
         ipv6-address   =  1*4HEXDIG 7(":" 1*4HEXDIG)
         ipv6mask       =  DIGIT                   ; 0-9
                           / %x31-39 DIGIT         ; 10-99
                           / "1" %x30-31 DIGIT     ; 100-119
                           / "1" %x32 %x30-38      ; 120-128
         layer4-ports   =  layer4-port *("," layer4-port)
         layer4-port    =  d16 / d16 "-" d16
         ip-option      =  "frag" /
                           ["ipoptions " ["!"] ipopt *("," ["!"] ipopt)]
                           ["tcpoptions " ["!"] tcpopt
                            *("," ["!"] tcpopt)]
                           ["established"]
                           ["setup"]
                           ["tcpflags " ["!"] tcpflag
                            *("," ["!"] tcpflag)]
                           ["icmptypes " icmptype *("," icmptype)]
         ipopt          =  "ssrr" / "lsrr" / "rr" / "ts"
         tcpopt         =  "mss" / "window" / "sack" / "ts" / "cc"
         tcpflag        =  "fin" / "syn" / "rst" / "psh" / "ack" / "urg"

         icmptype       =  d8 / d8 "-" d8
                           / "echo reply" / "destination unreachable"
                           / "source quench" / "redirect"
                           / "echo request" / "router advertisement"
                           / "router solicit" / "time-to-live exceeded"
                           / "IP header bad" / "timestamp request"
                           / "timestamp reply" / "information request"
                           / "information reply"
                           / "address mask request"
                           / "address mask reply"

         ;IP Tunnel Rule


Congdon, et al.           Proposed Standards                  [Page 9]


INTERNET-DRAFT   Attr. for Filtering and Redirection     4 March 2007

         ip-tunnel-rule =  "tunnel " tunnel-id " "
                           ("in" / "out" / "inout") " "
                           ("ip" / ip-proto) filter-body
                           [" " ip-option] [" " log-rule]

         ;HTTP Filter Rule
         http-filter-rule= ("permit" / "deny") org-url " "
                           ("in" / "out" / "inout") filter-body
                           [" " log-rule]

         ;HTTP Redirect Rule
         http-redir-rule=  "redirect " [redir-cnt " "] redir-url
                           filter-body [" " org-url]
                           [" " log-rule]
         redir-cnt      =  1*DIGIT
         org-url        =  http_URL
                           ;Note: Syntax for http_URL defined in
                           ;[RFC2616], section 3.2.2
         redir-url      =  http_URL

         ;Common
         filter-body    =  " from " ip-address [" " layer4-ports]
                           " to " ip-address [" " layer4-ports]
         tunnel-id      =  DQUOTE
                           1*(TEXTDATA / ("%" 2HEXDIG))
                           DQUOTE
         log-rule       =  "cnt"

         ;Primitives
         LF             =  %x0A                  ; linefeed
         DIGIT          =  %x30-39               ; 0-9
         DQUOTE         =  %x22                  ; " (Double Quote)
         HEXDIG         =  DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
         rule-delim     =  LF
         d8             =  DIGIT                 ; 0-9
                           / %x31-39 DIGIT       ; 10-99
                           / "1" 2DIGIT          ; 100-199
                           / "2" %x30-34 DIGIT   ; 200-249
                           / "25" %x30-35        ; 250-255
         d16            =  DIGIT                 ; 0-9
                           / %x31-35 1*4DIGIT    ; 10-59999
                           / "6" "4" 3DIGIT      ; 60000-64999
                           / "6" "5" %x30-34 2DIGIT     ; 65000-65499
                           / "6" "5" "5" %x30-32 1DIGIT  ; 65500-65529
                           / "6" "5" "5" "3" %x30-36     ; 65530-65536
         TEXTDATA       =  %x20-21 / %x23-24 / %x26-7E

         ; End of ABNF description of NAS-Traffic-Rule



Congdon, et al.           Proposed Standards                 [Page 10]


INTERNET-DRAFT   Attr. for Filtering and Redirection     4 March 2007

      Descriptions of notable fields and keywords follow:

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

         "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"     A flush rule removes all previously assigned
                     filter rules. When flush is specified, it can be
                     followed by other NAS-Traffic-Rule attributes. This
                     allows for an atomic change of authorization with a
                     single RADIUS message.

         "permit inout any from any to any"
                     Special rule that matches against all traffic. This
                     allows the implicit deny at the end of a filter
                     list to be overridden.

         "in"        Is from the terminal.

         "out"       Is to the terminal.

         "inout"     Is from and to the terminal.

         ipv4-address  An IPv4 number in dotted-quad form.  Only this
                       exact IP number will match the rule.
         ipv6-address  An IPv6 number in canonical IPv6 form.  Only
                       this exact IP number will match the rule.
         ipv4-address/ipv4mask
                    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 to 192.0.2.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.



Congdon, et al.           Proposed Standards                 [Page 11]


INTERNET-DRAFT   Attr. for Filtering and Redirection     4 March 2007

         "any"       Keyword for 0.0.0.0/0 or the IPv6 equivalent.

         "assigned"  Keyword for 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.

         layer4-port With the TCP, UDP and SCTP protocols, this field
                     specifies ports to match.

                     Note: 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" keyword
                     for details on matching fragmented packets.

         log-rule    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 a successful authorization change
                     occurs due to a CoA message being received by the
                     NAS.

      For base encapsulation rules:
         "l2:"       Prefix to designate a rule as a base encapsulation
                     rule.

         "l2: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).

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

         macaddr     For base encapsulation filter rules of "l2:ether2"
                     type, the Ethernet MAC address with octet values
                     separated by a "-". Example: "00-10-A4-23-19-C0".



Congdon, et al.           Proposed Standards                 [Page 12]


INTERNET-DRAFT   Attr. for Filtering and Redirection     4 March 2007

         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
                     MAC addresses from 00-10-A4-23-00-00 to 00-10-A4-
                     23-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 (!), causing all
                     other addresses to be matched instead.

                     Note: macaddr nor macaddr/mask argument is not used
                     for "l2:rmon" type rules.

      For IP rules:
         "ip"        Keyword means any IP protocol will match.

         ip-proto    An IP protocol specified by number.


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




Congdon, et al.           Proposed Standards                 [Page 13]


INTERNET-DRAFT   Attr. for Filtering and Redirection     4 March 2007

         "tcpflags"  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" 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).

      For HTTP redirection rules:
         redir-cnt   Specifies the number of HTTP 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 and/or org_URL ), HTTP requests are
                    redirected to redir_URL address in accordance with
                    [RFC2616] redirection traffic to specific URL.

         org-url    An HTTP URL. Specifies the HTTP URL against which
                    user HTTP requests will be evaluated.  If user HTTP
                    request matches org_URL, then redirection action is
                    taken.

      For base encapsulation and 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


Congdon, et al.           Proposed Standards                 [Page 14]


INTERNET-DRAFT   Attr. for Filtering and Redirection     4 March 2007

                    per [RFC2868] and named using the Tunnel-
                    Assignment-ID attribute described therein.

                    The tunnel id MUST be encapsulated in double quotes
                    and follow the labeling convention defined by the
                    TEXTDATA.
                    Example: A tunnel with the name of tunnel "ppp%1"
                    would be specified as "%22ppp%251%22"

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

      This specification introduces one new RADIUS accounting attribute.

   3.1.  Acct-NAS-Traffic-Rule

      Description

         Acct-NAS-Traffic-Rule enables a RADIUS client to include NAS-
         Traffic-Rule[TBD] rule match counters as part of the accounting
         message.




         The Acct-NAS-Traffic-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     |    Counter (64-bits)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              Counter (cont.)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               Counter (cont.)        |    Text (NAS-Traffic-Rule)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Type
         TBD

      Length
         >=11



Congdon, et al.           Proposed Standards                 [Page 15]


INTERNET-DRAFT   Attr. for Filtering and Redirection     4 March 2007

      Counter

         The Counter field is eight octets in length and contains the
         64-bit hit count for the rule specified in the Text field.

      Text

         The Text field is greater than one octet in length and is used
         to specify the rule for which a hit count is associated with.
         The Text field MUST conform to the syntax rules specified for
         the Text field of the NAS-Traffic-Rule[TBD] attribute.

   4.  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 NAS-Traffic-Rule

      Actng-   Actng-
      Request  Response    #      Attribute
      0-1       0          TBD    Acct-NAS-Traffic-Rule

      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.

   5.  Diameter Considerations

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

                                       +---------------------+
                                       | AVP Flag rules      |
                                       |----+-----+----+-----|----+
                                       |    |     |SHLD| MUST|    |
      Attribute Name        Value Type |MUST| MAY | NOT| NOT |Encr|
      ---------------------------------|----+-----+----+-----|----|
      NAS-Traffic-Rule      OctetString| M  | P   |    | V   | Y  |


Congdon, et al.           Proposed Standards                 [Page 16]


INTERNET-DRAFT   Attr. for Filtering and Redirection     4 March 2007

      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

      This specification does not create any new registries.

      This document uses the RADIUS [RFC2865] namespace, see
      <http://www.iana.org/assignments/radius-types>.  Allocation of two
      updates for the section "RADIUS Attribute Types" is requested. The
      RADIUS attributes for which values are requested are:

      TBD - NAS-Traffic-Rule
      TBD - Acct-NAS-Traffic-Rule


   7.  Security Considerations

      Since this document describes the use of RADIUS for purposes of
      authentication, authorization, and accounting in [IEEE8021X]
      enabled networks, it is vulnerable to all of the threats that are
      present in other RADIUS applications. For a discussion of these
      threats, see [RFC2607], [RFC3162], [RFC3579], and [RFC3580].



Congdon, et al.           Proposed Standards                 [Page 17]


INTERNET-DRAFT   Attr. for Filtering and Redirection     4 March 2007

      This document specifies new attributes that can be included in
      existing RADIUS messages. These messages are protected using
      existing security mechanisms; see [RFC2865] and [RFC3576] for a
      more detailed description and related security considerations.

      The security mechanisms in [RFC2865] and [RFC3576] are primarily
      concerned with an outside attacker who modifies messages in
      transit, inserts new messages, or deletes messages. They do not
      prevent an authorized RADIUS server or proxy from inserting or
      deleting attributes with a malicious purpose in messages it sends.

      An attacker who compromises an authorized RADIUS server or proxy
      can use the attributes defined in this document to influence the
      behavior of the NAS in ways that previously may not have been
      possible. For example, inserting suitable redirection rules to the
      NAS-Traffic-Rule attribute may allow the attacker to eavesdrop or
      modify packets sent by a legitimate client.

      In general, the NAS cannot know whether the attribute values it
      receives from an authenticated and authorized server are well-
      intentioned or malicious, and thus it is not possible to
      completely protect against attacks by compromised nodes. In some
      cases, the extent of the possible attacks can be limited by
      performing more fine-grained authorization checks at the NAS.
      For instance, a NAS could be configured not to accept any
      redirection rules if it is known they are not used in this
      environment.

   8.   References

   8.1. Normative references

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

   [RFC2895] Bierman, A., Bucci, C., Iddon, R., "Remote Network
             Monitoring MIB Protocol Identifier Reference", RFC
             2895, August 2000

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


Congdon, et al.           Proposed Standards                 [Page 18]


INTERNET-DRAFT   Attr. for Filtering and Redirection     4 March 2007


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

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

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

   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
             Implementation in Roaming", RFC 2607, June 1999.

   [RFC2818] Rescorla, E., "HTTP Over TLS", RFC2818, May 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.

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

   [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J.,
             "IEEE 802.1X Remote Authentication Dial In User Service
             (RADIUS) Usage Guidelines", RFC3580, September 2003.

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

   [IEEE8023]


Congdon, et al.           Proposed Standards                 [Page 19]


INTERNET-DRAFT   Attr. for Filtering and Redirection     4 March 2007

             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.

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

   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.

   A.1.1  Service Initiation




Congdon, et al.           Proposed Standards                 [Page 20]


INTERNET-DRAFT   Attr. for Filtering and Redirection     4 March 2007

      Redirect using tunnels at service initiation requires that the
      RADIUS server send the appropriate [RFC2868] tunnel attributes and
      NAS-Traffic-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-Traffic-
      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.1.4 Tunnel Redirection Examples

      The following examples illustrate how traffic flows when subjected
      to a NAS-Traffic-Rule using tunnel redirection.  In these
      scenarios, the following notation is used to represent traffic
      flows:



Congdon, et al.           Proposed Standards                 [Page 21]


INTERNET-DRAFT   Attr. for Filtering and Redirection     4 March 2007

      ------>  Flow in one direction
      <----->  Flow in two directions
      ======>  Flow in a tunnel in one direction
      <=====>  Flow in a tunnel in two directions


      A RADIUS server that wishes all IP traffic to flow between the
      client and a selected redirection destination will issue an
      Access-Accept that contains the specification for the tunnel using
      the attributes defined by RFC 2868 and a NAS-Traffic-Rule
      attribute using the tunnel action and arguments.

      An example NAS-Traffic-Rule will look like:

      tunnel "t1" in ip from assigned 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
      tunnel endpoint (TEP).

         +-------+            +------+         +------+       +------+
         |       |            |      |         |Tunnel|       |      |
         |client +<---------->+ NAS  +<==t1===>+ End  +<----->+ Dest |
         |       |            |      |         |Point |       |      |
         +-------+            +------+         +------+       +------+

      The direction argument takes the values of "in", "out" or "inout"
      and is important because it controls how information is routed.
      The following diagram demonstrates how traffic is routed. In all
      these diagrams time is increasing as we proceed down the page.

      When rule direction is "in":

         client       NAS       TEP    DESTINATION
           |           |         |          |
           |---------->|===t1===>|--------->|
           |           |         |          |
           |<----------|<-------------------|  (flows directly to NAS)
           |           |         |          |

      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
      forwards the packet to the Destination using the destination IP
      address in the packet header. Note that the source address of the
      packet is the address assigned at the NAS. Therefore if the
      destination were to reply to the packet it would use the NAS
      source address and the packet would flow directly to the NAS and
      to the client bypassing the TEP.  The Home network would use this



Congdon, et al.           Proposed Standards                 [Page 22]


INTERNET-DRAFT   Attr. for Filtering and Redirection     4 March 2007

      capability if it was only interested in metering or seeing the
      inbound traffic from the client.

      However, if the home network wanted to see the traffic in both
      directions it could deploy a NAT function at the TEP.

      Here is the flow when the TEP is acting like a NAT:

         client       NAS       TEP/NAT DESTINATION
           |           |         |          |
           |---------->|===t1===>|--------->|
           |           |         |          |
           |<----------|<==t1====|<---------|


      The client establishes a connection to the Destination, but the
      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
      Destination are sent to the TEP/NAT.  The TEP/NAT then forwards
      these packets to the client through the NAS.

      When the TEP is acting as a NAT, using the direction argument "in"
      is important. The direction argument set to "out" will have no
      effect on traffic coming from the tunnel since all traffic to the
      client should come from the TEP/NAT inside the tunnel.  The
      direction argument set to "inout" will have the same effect as if
      it were set to "in".

      The TEP/NAT forwards all traffic for the client into the tunnel to
      the NAS. The NAS always forwards any egressing traffic from the
      tunnel to the client. It does not apply any redirection rules on
      traffic egressing a tunnel. The NAS does not care whether the TEP
      is transparent or is acting as a NAT.

   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 user's browser to
      navigate to an alternate Web Portal.

      The call flow associated with performing redirection at the HTTP
      layer is very similar with the call flow associated with
      redirection done at the IP layer.

      The same NAS-Traffic-Rule(TBD) attribute described above is used
      to convey the redirection rules to use for HTTP redirection.  HTTP
      redirection rules within the NAS-Traffic-Rule attribute supports
      the encoding of a redirection URL to apply when a rule is matched.


Congdon, et al.           Proposed Standards                 [Page 23]


INTERNET-DRAFT   Attr. for Filtering and Redirection     4 March 2007


   A.2.1  Service Initiation

      As with previous call flows, the RADIUS server MAY send multiple
      HTTP redirect or filtering rules within a NAS-Traffic-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-Traffic-Rule(TBD) attribute using a CoA-Request
      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-Traffic-
      Rule(TBD) attribute.

   A.2.3  HTTP Redirection Removal

      HTTP Redirection rules can be automatically removed mid-session
      from the NAS using the redir-cnt parameter or explicitly removed
      from the RADIUS server. The RADIUS server can explicitly turn HTTP
      redirection off mid-session in two ways. It can push new
      redirection rules within a NAS-Traffic-Rule(TBD) attribute using a
      CoA-Request message or it can send the NAS a CoA-Request message
      requesting it to re-authorize.

      When using CoA-Request 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-Traffic-Rule(TBD) with the action of "flush" in the CoA-
      Request message. This action will cause all the filter rules and
      redirection rules previously assigned to the session to be
      removed.

   A.3  Accounting

      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-



Congdon, et al.           Proposed Standards                 [Page 24]


INTERNET-DRAFT   Attr. for Filtering and Redirection     4 March 2007

      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 [IEEE8021X] 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 and
      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.

   Appendix B - NAS-Traffic-Rule Filter Examples

      This appendix presents a variety of filter examples utilizing the
      syntax definition described in section 3.5

      Example #1: Permit all user traffic, regardless of type.

         v1 permit inout any from any to any

      Example #2: Permit only L2 traffic coming from and going to a
      user's Ethernet MAC address. Block all other traffic. Assume
      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 out l2:ether2 from any to 00-10-A4-23-19-C0



Congdon, et al.           Proposed Standards                 [Page 25]


INTERNET-DRAFT   Attr. for Filtering and Redirection     4 March 2007

      Example #3: Tunnel all L2 traffic coming from and going to a user.
      Assume tunnel name is: tunnel "1234".

         v1 permit tunnel "tunnel \"1234\"" inout l2:ether2 from any to
            any

      Example #4: Permit only L3 traffic coming and going to from a
      user's IP address. Block all other traffic. Assume user's IP
      address is 192.0.2.128.

         v1 permit in ip from 192.0.2.128 to any
         v1 permit out ip from any to 192.0.2.128

      Example #5: Permit only L3 traffic coming and going to the user's
      assigned IP address. Block all other traffic.

         v1 permit in ip from assigned to any
         v1 permit out ip from any to assigned

      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-
      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 out l2:ether:0x806 from any to 00-10-A4-23-19-C0
         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 in 6 from 192.0.2.168 80 to any
         v1 permit out 6 from any 80 to 192.0.2.168

      Example #7: Allow user to generate ARP requests, DNS requests, and
      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
      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 out l2:ether:0x806 from any to 00-10-A4-23-19-C0
         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 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
      HTTP (port 80) requests, of which only requests to
      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
      192.0.2.128

         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


Congdon, et al.           Proposed Standards                 [Page 26]


INTERNET-DRAFT   Attr. for Filtering and Redirection     4 March 2007

         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 redirect http://www.goo.org in from 192.0.2.168 to any 80
            http://www.goo.org


   Acknowledgments
      The authors would like to acknowledge Dave Nelson, Joseph Salowey
      of Cisco, 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

      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


Congdon, et al.           Proposed Standards                 [Page 27]


INTERNET-DRAFT   Attr. for Filtering and Redirection     4 March 2007

      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 any license
      under such rights might or might not be available; nor does it
      represent that it has made any independent effort to identify any
      such rights.  Information on the procedures with respect to rights
      in RFC documents can be found in BCP 78 and BCP 79.

      Copies of IPR disclosures made to the IETF Secretariat and any
      assurances of licenses to be made available, or the result of an
      attempt made to obtain a general license or permission for the use
      of such proprietary rights by implementers or users of this
      specification can be obtained from the IETF on-line IPR repository
      at http://www.ietf.org/ipr.

      The IETF invites any interested party to bring to its attention
      any copyrights, patents or patent applications, or other
      proprietary rights that may cover technology that may be required
      to implement this standard.  Please address the information to the
      IETF at ietf-ipr@ietf.org.

   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, THE
      IETF TRUST 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.


Congdon, et al.           Proposed Standards                 [Page 28]


INTERNET-DRAFT   Attr. for Filtering and Redirection     4 March 2007


   Copyright Statement

      Copyright (C) The IETF Trust (2007).

      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.

   Open issues

      Open issues relating to this specification are tracked on the
      following web site:

      http://www.drizzle.com/~aboba/RADEXT/




































Congdon, et al.           Proposed Standards                 [Page 29]