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

From: Jacques Caron <[email-masked]>
Date: Tue, 19 Jun 2001 17:36:36 +0200

You may want to replace NAS by access device?

Jacques.

At 17:22 19/06/01, Pat Calhoun wrote:
>All,
>
>Below is the proposed text, but I still haven't received any input on
>whether this was an acceptable change.
>
>Thanks,
>
>PatC
>----
>4.4  Derived AVP Data Formats
>
>[...]
>       FilterRule
>          The Filter-Rule 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
>             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.
>
>             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.
>
>                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 NAS 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.
>
>             A NAS that is unable to interpret or apply a deny rule MUST
>             terminate the session.  A NAS that is unable to interpret or
>             apply a permit rule MAY apply a more restrictive rule.  A
>             NAS MAY apply deny rules of its own before the supplied
>             rules, for example to protect the NAS 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.

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

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 19 Jun 2001 08:22:48 -0700

All,

Thanks,

PatC
----

[...]
      FilterRule

            Direction                          (in or out)

            options:

               ipoptions spec

               tcpoptions spec

               established

               tcpflags spec

               icmptypes types

---

From: John Schnizlein <[email-masked]>
Date: Tue, 19 Jun 2001 12:03:02 -0400

How much trouble would it be to include DiffServ Codepoints (DSCPs)?
As long as this is going in the base, we might make it more general.
John

Additions to your specification included below:

At 11:22 AM 6/19/2001, Pat Calhoun wrote:
>Below is the proposed text, but I still haven't received 
>any input on whether this was an acceptable change.
>
>----

             DSCP values                        (no mask or range)

>                         deny - Drop packets that match the rule.

                          color DSCP
                          meter rate color_under color_over

>                       matching fragmented packets.

                DSCP values as defined in RFC 2474. 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.

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 19 Jun 2001 09:26:25 -0700

I'm certainly not opposed to the change. The only caviat is the
statement at the end regarding ipfw.c, and the change you've
requested is probably not supported in that file.

Anyone object to the change? Should I clearly state that DSCP is not
handled by ipfw?

patC

---

From: John Schnizlein <[email-masked]>
Date: Tue, 19 Jun 2001 13:37:15 -0400

Without looking, I assume there is no DSCP in FreeBSD's ipfw(8). 
But your text already said "modified subset".

Only state explicitly that this filter option is not in ipfw(8) if you
are prepared to fight its introduction there and/or revise your document
when/if they realize that a single filter specification is better than
the variety of different ones (just because there are different WGs).

Now that you mention it, should a standards-track document include this
sort of implementation suggestion?

John

At 12:26 PM 6/19/2001, Pat Calhoun wrote:
>...
>> >     and the ipfw.c code may provide a useful base for implementations.

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 19 Jun 2001 10:31:23 -0700

> But your text already said "modified subset".

re-reading the text, you are correct.

> sort of implementation suggestion?

I don't think it hurts.

PatC

---

From: jonas <[email-masked]>
Date: Mon, 25 Jun 2001 10:05:31 +0200

Hi,

Where would directives about the use of NAT and state-full inspection of
filter rules go? 

/jonas

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 25 Jun 2001 05:41:22 -0700

> Where would directives about the use of NAT and state-full inspection of

a separate AVP, IMHO.

PatC