Subject: Comments on draft-yang-forces-model-01.txt

From: Alan DeKok <[email-masked]>
Date: Wed, 11 Dec 2002 17:13:21 -0500

I was unable to attend IETF Atlanta, so I thought I'd post my comments
on the list (and it's been pretty quiet lately).

Page 6:  "... CE's might even be allowed to download a given
functionality onto FE's at run time. ... this is still considered a
research area, and is not being considered here".

  That depends on what the "given functionality" is.  One example is
IDS, or firewall applications.  There is a requirement to download new
"rules" for classification, but it's not clear where the "rule" becomes
"functionality".

  e.g. New firewall rules don't appear to add new "functionality", as
they're usually for existing, and well-known protocols.  But it's not a
large step forward to download new protocols to a firewall for
filtering/metering.  The firewall doesn't have to *pass* the traffic,
but it would be useful to allow it to *account* such traffic.

  I may be nitpicking here.  My main concern is that the programming of
programmable devices shouldn't be described as "downloading new
functionality", and rejected out of hand.  There are network
applications in the market today which permit some amount of
downloading.  It would be useful to address this (or the limits thereof)
in the model document.

Page 6, Section 4. "FE Model"

  Very nice.  I have no comments here, other than to say it's clear,
descriptive, and well written.

Page 11, Section 4.2.5 "Forwarding functions"

  The other sections appear to describe inputs/outputs/modifications of
the FE blocks (as described in 4.2).  Similar text appears to be missing
here.

  I have more comments on IPv4 forwarding, and it's unification of
classification/packet-modification, but they should probably be
addressed to a document describing the IPv4 FE block in more detail.

Page 13, Section 4.3.2 "Topological versus Encoded State Approaches"

  The discussion of the two different approaches is good, but I believe
that some combination of the two will be a requirement.

  e.g. Some chips have 1 physical input, with 2 physical outputs, each
of which can have metadata (encoded state) information attached.

  If we choose one approach over the other, then there are some systems
which can't be mapped to the model.  The documents implicit approach of
"smaller pictures are better" is a reasonable one.

  Alan DeKok.

---

From: "Yang, Lily L" <[email-masked]>
Date: Mon, 23 Dec 2002 16:54:04 -0800

Alan -- Thanks for the detailed description. I understand your concern and
agree with your conclusion that "Forces should allow these systems to be
configured and controlled, and should not treat these capabilities as new
functionality". So it doesn't appear to me that we have any fundamental
disagreement on the issue. It might just be terminology that causes he
confusion.
I will check the draft to make sure it is clear of such confusion. If you
see any specific text/wording that is causing your concern, please be so
kind to point out to me.

Thanks, and Happy Holiday to you and everyone on the list who is still
working or listening :-)

Lily

> -----Original Message-----
> From: Alan DeKok [mailto:[email-masked]]
> Sent: Thursday, December 19, 2002 1:50 PM
> To: Forwarding and Control Element Separation; Yang, Lily L
> Subject: Re: Comments on draft-yang-forces-model-01.txt
>
>
> "Yang, Lily L" wrote:
> >
> > By "downloading new functionality" I meant (or more
> precisely, imagined)
> > things like CE telling an FE to add a firewall block in the
> FE graph even
> > though the FE has no firewall block pre-installed -- so the
> CE has to
> > download the firewall code onto the FE on the fly. So
> downloading new
> > filtering rules definetely does not count toward this while
> downloading new
> > protocols to a frewall probably does.
>
>   My concern is that most people use the terms "protocol" and "packet
> description" interchangably.  They're *very* different.  Packet
> descriptions are static, involving defining a layout of bits on the
> wire. Protocols use packet descriptions to drive state changes in a
> system.  These state changes  are driven by received packets,
> and cause
> other packets to be emitted in turn.
>
>  e.g. Downloading packet descriptions for new protocols to a
> firewall.
> The firewall can filter and count these packets, even if it doesn't do
> anything else with the packets.
>
>   e.g. Firewalls which strictly filter TCP packets with
> unknown flags.
> When a new variant of TCP is released, you would like to treat these
> packets as "known, but unsupported", until you upgrade your firewall.
> These packets then fall into a different logical class than "nmap
> packets with weird flags".
>
>
>   The reason I'm concerned about this issue is two-fold.
> One, clear and
> consistent terminology helps communication.  Two, there are systems
> today (IDS, firewall, virus detectors), which allow new packet
> descriptions to be downloaded on the fly.  Forces should allow these
> systems to be configured and controlled, and should not treat these
> capabilities as "new functionality".
>
>   Alan DeKok.
>