Subject: [AAA-WG]: Issue 87: Move filter-rule AVP to base

From: Pat Calhoun <[email-masked]>
Date: Thu, 28 Jun 2001 14:25:06 -0700

All,

Here is the proposed text for Issue 87. The main difference here is support
for QoS filters.

Comments appreciated,

PatC
----

      FilterRule
         The FilterRule format is derived from the OctetString AVP Base
         Format.  It uses the UTF-8 encoding and has the same
         requirements as the UTF8String. Packets may be filtered based
         on the following information that is associated with it:

            Direction                          (in or out)
            Source and destination IP address  (possibly masked)
            Protocol
            Source and destination port        (lists or ranges)
            TCP flags
            IP fragment flag
            IP options
            DSCP values                        (no mask or range)
            ICMP types

         Rules for the appropriate direction are evaluated in order,
         with the first matched rule terminating the evaluation.  Each
         packet is evaluated once. If no rule matches, the packet is
         dropped if the last rule evaluated was a permit, and passed if
         the last rule was a deny.

         The filters in the Filter-Rule AVP MUST follow the format:

            action dir proto from src to dst [options]

            action       permit - Allow packets that match the rule.
                         deny   - Drop packets that match the rule.
                         tag    - Mark packet with a specific DSCP [49].
                                  The DSCP option MUST be included.
                         meter  - Meter traffic. The metering options
                                  MUST be included.

            dir          "in" is from the terminal, "out" is to the
                         terminal.

            proto        An IP protocol specified by number.  The "ip"
                         keyword means any protocol will match.

            src and dst  <address/mask> [ports]

                         The <address/mask> may be specified as:
                         ipno       An IPv4 or IPv6 number in dotted-
                                    quad or canonical IPv6 form. Only
                                    this exact IP number will match the
                                    rule.
                         ipno/bits  An IP number as above with a mask
                                    width of the form 1.2.3.4/24.  In
                                    this case all IP numbers from
                                    1.2.3.0 to 1.2.3.255 will match.
                                    The bit width MUST be valid for the
                                    IP version and the IP number MUST
                                    NOT have bits set beyond the mask.

                         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.

                            The keyword "any" is 0.0.0.0/0 or the IPv6
                            equivalent.  The keyword "assigned" is the
                            address or set of addresses assigned to the
                            terminal.  The first rule SHOULD be "deny in
                            ip !assigned".

                         With the TCP and UDP protocols, optional ports
                         may be specified as:

                            {port|port-port}[,port[,...]]

                         The `-' notation specifies a range of ports
                         (including boundaries).

                         Fragmented packets which have a non-zero offset
                         (i.e. not the first fragment) will never match
                         a rule which has one or more port
                         specifications.  See the frag option for
                         details on matching fragmented packets.

            options:
               frag    Match if the packet is a fragment and this is not
                       the first fragment of the datagram.  frag may not
                       be used in conjunction with either tcpflags or
                       TCP/UDP port specifications.

               ipoptions spec
                       Match if the IP header contains the comma
                       separated list of options specified in spec. The
                       supported IP options are:

                       ssrr (strict source route), lsrr (loose source
                       route), rr (record packet route) and ts
                       (timestamp). The absence of a particular option
                       may be denoted with a `!'.

               tcpoptions spec
                       Match if the TCP header contains the comma
                       separated list of options specified in spec. The
                       supported TCP options are:

                       mss (maximum segment size), window (tcp window
                       advertisement), sack (selective ack), ts (rfc1323
                       timestamp) and cc (rfc1644 t/tcp connection
                       count).  The absence of a particular option may
                       be denoted with a `!'.

               established
                       TCP packets only. Match packets that have the RST
                       or ACK bits set.

               setup   TCP packets only. Match packets that have the SYN
                       bit set but no ACK bit.

               tcpflags spec
                       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
                       which contains a tcpflags specification can never
                       match a fragmented packet which has a non-zero
                       offset.  See the frag option for details on
                       matching fragmented packets.

               DSCP <color>
                       color values as defined in [49]. Exact matching
                       of DSCP values is required (no masks or ranges).
                       the "deny" can replace the color_under or
                       color_over values in the meter action for rate-
                       dependent packet drop.

               metering <rate> <color_under> <color_over>
                       The metering option provides Assured Forwarding,
                       as defined in [50], and MUST be present if the
                       action is set to meter. The rate option is the
                       throughput, in bits per second, which is used by
                       the access device to mark packets. Traffic above
                       the rate is marked with the color_over codepoint,
                       while traffic under the rate is marked with the
                       color_under codepoint. The color_under and
                       color_over options contain the drop preferences,
                       and MUST conform to the recommended codepoint
                       keywords described in [50] (e.g. AF13).

                       The metering option also supports the strict
                       limit on traffic required by Expedited
                       Forwarding, as defined in [51]. The color_over
                       option may contain the keyword "drop" to prevent
                       forwarding of traffic that exceeds the rate
                       parameter.

               icmptypes types
                       ICMP packets only.  Match if the ICMP type is in
                       the list types. The list may be specified as any
                       combination of ranges or individual types
                       separated by commas.  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).

         There is one kind of packet that the access device MUST always
         discard, that is an IP fragment with a fragment offset of one.
         This is a valid packet, but it only has one use, to try to
         circumvent firewalls.

            An access device that is unable to interpret or apply a deny
            rule MUST terminate the session.  An access device that is
            unable to interpret or apply a permit rule MAY apply a more
            restrictive rule.  An access device MAY apply deny rules of
            its own before the supplied rules, for example to protect
            the access device owner's infrastructure.

         The rule syntax is a modified subset of ipfw(8) from FreeBSD,
         and the ipfw.c code may provide a useful base for
         implementations.

[...]
   [49] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the
        Differentiated Services Field (DS Field) in the IPv4 and IPv6
        Headers," RFC 2474, December 1998.

   [50] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Assured For-
        warding PHB Group," RFC 2597, June 1999.

   [51] V. Jacobson, K. Nichols, K. Poduri, "An Expedited Forwarding
        PHB", RFC 2598, June 1999.

---

From: Barney Wolff <[email-masked]>
Date: Thu, 28 Jun 2001 19:39:43 -0400

Now that fancy metering features have been added, we must specify 
the behavior of the access device if it does not support such
advanced functionality.

Barney

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 28 Jun 2001 17:03:06 -0700

> the behavior of the access device if it does not support such

I'm not sure we do. The RFCs referenced go out of their way to 
define how metering is done. I see no reason why the AAA WG needs
to worry about that (just like we don't discuss how tunneling is
done).

PatC

---

From: Barney Wolff <[email-masked]>
Date: Thu, 28 Jun 2001 21:25:19 -0400

I'm confused.  You mean that support for those two RFCs is now
mandatory?  For all access devices or only those that support
Diameter?  If not, then what should the access device do with
a filter rule that instructs it to meter?  We've said what to
do if you can't exactly implement a drop or permit filter rule,
how is this different?

Barney

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 28 Jun 2001 22:37:56 -0700 (PDT)

A comment. I think you also need to accomodate Layer 2 filters based on
MAC address, Ethertype, etc. Remember, AAA is now implemented on otherwise
purely Layer 2 devices.

---

From: Jacques Caron <[email-masked]>
Date: Fri, 29 Jun 2001 11:12:30 +0200

Mmmm... Stupid question: if a device receives an 'M'-AVP it doesn't know, 
it sends back an error. Shouldn't there be an error also if a device 
receives an 'M'-AVP it doesn't *understand*, i.e. it knows the AVP but 
doesn't understand its contents/format?

Jacques.

>to worry about that (just like we don't discuss how tunneling is

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: Jacques Caron <[email-masked]>
Date: Fri, 29 Jun 2001 11:36:45 +0200

Hi,

Nice. Shouldn't the rate in the "meter" action also include burst/exess 
burst (e.g. Bc/Be) to perfectly define the rate? Also you might want to 
include a simple "permit" (with no color or anything).

Also, I'm not sure all the QoS stuff actually belongs there. In many cases, 
one wants QoS based on a filter-set, not a single filter-rule.

Maybe keeping the original FilterRule syntax, but then adding a specific 
QoSRule syntax that refences a set of FilterRules to then perform the 
metering would be better? This would require to have a way to identify 
filters (= sets of FilterRules), and to specify which are used for 
filtering, and which are used for other (QoS) purposes.

Alternatively, you might want to include a "meter number" in the metering 
rules, so that multiple rules can use the same meter (token bucket) to 
measure multiple types of traffic...

Also, if we're into QoS, what about traffic-shaping?

BTW, how are multiple rules specified? Multiple AVPs, or multiple rules 
within the same AVP (separated with \n maybe)? This isn't clear in the 
description.

Good luck!

Jacques.

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 29 Jun 2001 05:57:30 -0700

> Also, if we're into QoS, what about traffic-shaping?

ok, let me discuss these issues with John. Now that I've read Barney's
comment, I agree that perhaps moving these out of FilterRule, and into
QoSFilterRule (and perhaps renaming FilterRule to IPFilterRule) would
be a good thing. This would allow an access device to reject an AVP of
type QosFilterRule, if it didn't support traffic metering.

Also, following Bernard's comment, it may also make sense to create the
L2FilterRule type as well. Do folks generally agree with this?

> within the same AVP (separated with \n maybe)? This isn't clear in the 

multiple AVPs. I'll make sure that this is clarified.

> Good luck!

Why do I feel like I'll need it :(

PatC