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

From: "Yang, Lily L" <[email-masked]>
Date: Wed, 11 Dec 2002 15:50:49 -0800

Alan -- Thanks. See my reply in line.
Lily

> -----Original Message-----
> From: Alan DeKok [mailto:[email-masked]]
> Sent: Wednesday, December 11, 2002 2:13 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Comments on draft-yang-forces-model-01.txt
>
>
>   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.

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. I consider the two quite distinctively
diffrent and by the IETF spirit of "walk before you run", I personally
thought it appropriate to draw a line here. But of course, this is up to the
list for debate.

>
>
> Page 6, Section 4. "FE Model"
>
>   Very nice.  I have no comments here, other than to say it's clear,
> descriptive, and well written.

Thanks. It is nice to know someone actually read the draft. Even nicer to
hear this kind of comments :-)

>
>
> 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.

While this draft does not intend to provide detailed specification for each
function, but it should provide enough informational modeling guideline. So
if you can contribute more comments/content for IP forwarding, for example,
we will be VERY grateful!

>
>
> 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.

This particular section needs more work that is for sure. Personally I am
not very satisfied with it either. We will keep your comments in mind when
we revise this part.

>   Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 19 Dec 2002 16:49:43 -0500

"Yang, Lily L" wrote:
> 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.