Subject: Re: Extensible SRL ?

From: Nevil Brownlee <[email-masked]>
Date: Wed, 4 Aug 1999 17:18:03 +1200 (New Zealand Standard Time)

Hello Nick:

>                                   It would be good if SRL could
> support that natively. I know that SRL has some distribution values as part
> of the language, but thats fixed. What I am talking about is building in
> more features.
> 
> Secondly, as further protocols emerge SRL has to be changed to deal with
> them. For instance there are a lot of control protocols just above the
> transport layer (RTCP, RSVP, LDAP etc) it would be good if we extend SRL to
> deal with these. I know that we can deal with just the plain TCP/UDP etc up
> to the transport layer, but I feel there is a large amount of control
> traffic that SRL could deal with to reveal some service affecting
> interactions.

This is an interesting topic for discussion!  Let me throw in some 
background material to help it along ..

a) Remember that the RTFM architecture takes the view that the meter
   identifies packets so as to extract values for their 'RTFM Address' 
   attributes.  This make it easy to understand, but means that the
   meter can't identify packets by looking in them for arbitrary patterns.

b) SRL was designed so as to map directly onto the RTFM meter, allowing
   the compiler to make very efficient rulesets from SRL programs.

c) Other 'packet description' languages (e.g. PAX, draft-nossik-pax-pdl- 
   00.txt) provide much more general ways to describe packets, but 
   (because of (a) above) couldn't be compiled into RTFM rulesets.

d) For a long time I've thought it would be nice to be able to identify
   Passive FTP flows.  But this requires the meter to follow the 
   application-level protocol in an FTP control flow, and use this to
   identify the passive flows used for actual data transfer.  Of course
   boxes such as firewalls and traffic shapers do this now, but it
   would require a meter to keep a LOT of state information for flows,
   which would make it a LOT more complicated than it is now!

e) Any packet which can be described in terms of a set of attribute
   values can be handled by SRL.  An easy-to-use way of building libraries
   of such SRL code would be useful.  One way would be to use SRL    
   subroutines, and #include them (this is a NeTraMet extension, not
   part of the language).

In thinking about this, it would help me if people could send to the list 
fragemnts of SRL which identify particular protocols of interest, starting
with the ones Nick listed in his earlier mailing (see above).

I'm certainly eager to enhance the SRL language and compiler (starting
with the version implemented in NeTraMet so as to gather experience
with the changes), but not - at least not initially - keen to make changes
to the meter's Packet Matching Engine!

Comments, further suggetsions, please.

Cheers, Nevil

+---------------------------------------------------------------------+
| Nevil Brownlee                     Director, Technology Development |
| Phone: +64 9 373 7599 x8941        ITSS, The University of Auckland |
|   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand |
+---------------------------------------------------------------------P

---

From: [email-masked]
Date: Fri, 6 Aug 1999 18:19:40 +0100

>  Hello Nevil,
> 
> Thanks for the reply,
> 
> I guess I'm troubled by 2 facets of SRL,
> 
> 1) As you've outlined in your reply, you have particular interests in 
> enhancing SRL to do ftp passive flows. I'm sure that many other users of
> RTFM would also like it to 
> have more features in place. The net result is that SRL would/will suffer
> tremendous churn, that could be very 
> hard to track and maintain, with all the extending libraries, and SNMP
> OIDs.. . So having a general pattern matching scheme could allow this very
> easily. As an example have a 'ruleset' advertise the packet types it was
> interested in taking, and allow the meter to generate a matching pattern
> from it
> 
> 2) The output from a meter is just packets. I feel that this is also a
> limiting factor. Say for instance you wanted to do some sampling of
> passing traffic and wanted to know determine (in near real time) whether a
> node was within
> its QOS policy. So the input is a policy statement, and the output, could
> be a red,amber,green  indication. With  RTFM currently this is just not
> possible. Of course you could log all the packets for that node, with all
> the addressing info, so you could post processes it but its not very
> convenient. It would be nice if you could just output a G,G,G,A,A,R,R,R
> sequence, but again this is not possible as SRL has no real way of
> formatting this.
> 
> I know this is a bit contrived, but I'm sure there are a hundred and one
> different capture requirements and about the same for the way the output
> data is to be represented. Of course if you know SRL and could extend it
> and write a bespoke post processing program you could do some of this, but
> its not lending itself to people using the system !
> 
> I guess I was not around when the group formed its views on what were
> important features of RTFM.
> The trade off then seems to be usage of a language, that efficiently deals
> with packet matching, but accepting the limits of the language; versus a
> more loosely bound scheme where  general pattern matching is employed and
> a arbitrary output format given.
> 
> Is this totally mad, or does it have some credence ?
> 
> Nick
> 
> 
>