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

From: [email-masked]
Date: Tue, 4 Sep 2001 16:04:13 +0300

Pat,

Would it be inappropriate at this time to ask the QoSFilterRule to be
extended to include an optional IPv6 flow label value (20 bits) to be
matched by the filter?

	Jarno

> -----Original Message-----
> From: ext Pat Calhoun [mailto:[email-masked]]
> Sent: 1. heinäkuuta 2001 2:40
> To: [email-masked]
> Subject: [AAA-WG]: Issue 87: Move filter-rule AVP to base
> 
> 
> All,
> 
> Below is the proposed text for this issue. Comments 
> appreciated, but proposed
> text even more :)
> 
> Thanks,
> 
> PatC
> ----
>       IPFilterRule
>          The IPFilterRule 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.
> 
>          IPFilterRule filters 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
> 
> 
> 
> Calhoun et al.           expires December 2001                
>  [Page 34]
> 
> 
> 
> 
> 
> Internet-Draft                                                
>  June 2001
> 
> 
>                                     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, UDP and SCTP 
> 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
> 
> 
> 
> Calhoun et al.           expires December 2001                
>  [Page 35]
> 
> 
> 
> 
> 
> Internet-Draft                                                
>  June 2001
> 
> 
>                        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 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
> 
> 
> 
> Calhoun et al.           expires December 2001                
>  [Page 36]
> 
> 
> 
> 
> 
> Internet-Draft                                                
>  June 2001
> 
> 
>          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.
> 
>       QoSFilterRule
>          The QosFilterRule 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 marked or
>          metered 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)
>             DSCP values                        (no mask or range)
> 
>          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
>          treated as best effort.
> 
>          QoSFilterRule filters MUST follow the format:
> 
>             action dir proto from src to dst [options]
> 
>                          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]
> 
> 
> 
> 
> Calhoun et al.           expires December 2001                
>  [Page 37]
> 
> 
> 
> 
> 
> Internet-Draft                                                
>  June 2001
> 
> 
>                          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, UDP and SCTP 
> protocols, optional
>                          ports may be specified as:
> 
>                             {port|port-port}[,port[,...]]
> 
>                          The `-' notation specifies a range of ports
>                          (including boundaries).
> 
>             options:
> 
>                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.
> 
> 
> 
> 
> Calhoun et al.           expires December 2001                
>  [Page 38]
> 
> 
> 
> 
> 
> Internet-Draft                                                
>  June 2001
> 
> 
>                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.
> 
>          The rule syntax is a modified subset of ipfw(8) from FreeBSD,
>          and the ipfw.c code may provide a useful base for
>          implementations.
>

---

From: John Schnizlein <[email-masked]>
Date: Tue, 04 Sep 2001 10:25:53 -0400

Yes, it would be inappropriate. The meaning of flow labels was clearly
not defined in Minneapolis (IETF 50). The draft minutes from London
http://playground.sun.com/pub/ipng/html/minutes/ipng-minutes-aug2001.txt
indicated some controversy remains, with a call for 
"Further discussion on mailing list."

John

At 09:04 AM 9/4/2001, [email-masked] wrote:
>>...
>>                                     this exact IP number will match 
>>                                     the rule.
>>                                     The bit width MUST be valid for the
>>                          instead.  This does not affect the selection 
>>                          of port numbers.
>> 
>>                             address or set of addresses assigned 
>> 
>>                             to the terminal.  The first rule SHOULD 
>> 
>>                             be "deny in ip !assigned".
>> 
>>                          With the TCP, UDP and SCTP protocols, 
>> 
>>                          optional ports may be specified as:
>> 
>>                        of DSCP values is required (no masks or ranges).
>>                        The metering option provides Assured Forwarding,
>>                        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,
>>                        color_over options contain the drop preferences,
>>                        option may contain the keyword "drop" to prevent