Subject: Re:

From: [email-masked]
Date: Mon, 02 Nov 1998 17:10:10 +0000

The following is being forwarded to the policy mailing list.
Message originally sent by Raju Rajan <[email-masked]>
---------------------------------------------------------------------------

> Message originally sent by "Eyal Felstaine" <[email-masked]>
> ---------------------------------------------------------------------------
> 
> HI,
> 
> I would like to answer to the comments that followed my mail
> regarding draft-rajan-policy-qosschema-00.txt.
> 
> 1) Matching ANY kind of information in packets:
> 
>    I agree that simply looking at a pre-defined offsets in the packets
>    is not enough. It is important to have a different policy conditions
>    definitions for fields in H323,HTTP and other 5-layer protocols(whose
>    offset location might be changed by the application layer).
>    I propose to have a discussion on that in the orlando 43 IETFmeeting.

I think that is a good proposal. We should indeed have that discussion. If there
are any suggestions on this topic, this is as good a time as any to get them
into the open, so that we all come prepared. (I will try and post some thoughts
I have on how IPPolicyConditions should be sub-classed to take care of
Application level headers.)

> 
> 2) Conditions on flows that are met on the first packet only:
>    There are currently several devices in the market that *CAN* trapflows
>    based on the first/third or any of the packets conforming to a condition.
>    Generally it is indeed done by using the 5-tuple for defining the flow's
>    state.
> 
>    I agree with Michael that supplying the information needed to trap TCP
>    flows is of great importance for DEN schemata, since schemata is
> generally
>    used to support VPNs, tunneling, DS marking and the rest.

Maybe I've not stated my doubts on the use of "flows" properly. What we have
right now is an IPPolicyCondition object. This identifies a stream of packets.
For instance if the object contains attribute/value pairs

SourceIPAddressRange 5.3.2.1:5.4.2.1
Protocol             4

then the substream of packets identified by this condition is all TCP packets
from the specified host addresses. If you wish to trap the third packet of the
above-defined stream, you need an attribute, say, PacketNumber and give it a
value 3. (I am trying to understand if this is what you propose, not commenting
on whether such an attribute should be standardized.) This can be done easily.

>    As an example (one of many) consider the following scenario:
> 
>    An ISP wishes to assign high priority to specific
> html-pages/gifs/contents
>    and lower to others according to the type of the content. The name of the
>    content is passed in one of the packets that sends the HTTP GET datagram
>    for the content (usually its the third datagram - the second SYN). Hence,
>    the whole flow priority can be assigned only if matching of the rule on
>    just one packet is supported.
> 
>    This, and many other usages of the above implies that the inclusion of
>    such a condition is of vital importance. It should be noted that the
>    *mechanism* under which packets are trapped is outside the policy WG
> charter.

I fully support the need for the above functionality -- but IMHO this is not an
issue of trapping packet 3 or 5. It would be better to introduce a class called
HTTPPolicyCondition as a subclass of IPPolicyCondition and give it a number of
attributes, including one that identifies the GET message. The rule will then be
interpreted as -- perform the prescribed action for all GET packets from the
given sourceAddressRange, etc. 

The questions I have are the following:
What does a device that does not have the functionality to parse the set of
headers do? Can the vendor claim conformance to the schema or not? In other
words where do we draw the line?

The set of attributes allowed in the PolicyCondition class right now are fairly
generic -- a vendor must support them in order to claim conformance. We must
extend the schema for reasons of functionality. But we cannot expect/require
that each vendor will support it. This is an issue for the working group as a
whole to work out. But I do support your solution.

> 
> 3) Regarding ranges for port numbers and source/dest addresses. I wouldn't
> go
>    religious about that but still like to elaborate the following:
> 
>    I believe that the benefits which can be obtained from using multi-valued
>    attributes rather then multiple attributes to describe a single range
>    of ports/addresses are obvious:
> 
>    A multi-valued attribute can be easily mapped into a *single* condition
> in
>    the enforcement device (as opposed to multiple attribute definitions).
>    This can increase the capacity of the device since less "rules" are
> needed
>    to describe the policy. Similarly, the simplicity of operating the device
>    is increased. The cost of supporting comma's in the enforcement device is
>    marginal.

I think your terminology is confusing -- in LDAP a multi-valued attribute is one
that is allowed to take on mulitple values. Example:

SourcePortNumber 55
                 43             MULTI-VALUED ATTRIBUTE (integer type)
                 32

SourcePortNumber 55,43,32       SINGLE-VALUED ATTRIBUTE (string type)

The first is to be favored whenever the attribute can be stored in its native
type, thus allowing the directory  to perform type checking. It is fairly
trivial to fetch a multi-valued attribute, read out the individual values, and
store them as a comma seperated string, if that is what you desire.

>    Regards,
>                  Eyal Felstaine.                  

Regards,

Raju Rajan