Subject: Re: [midcom] framework comments

From: Melinda Shore <[email-masked]>
Date: Wed, 01 Aug 2001 08:00:58 -0400

At 03:41 PM 7/31/01 -0700, Eliot Lear wrote:
>There are two reasons I would like to find a better definition.  One is
>simply on the faith that someone else has done the work.  The second is
>that I have a specific example in mind: application firewalls are NOT
>packet filtering firewalls.  Perhaps just dropping the words "packet
>filtering" might do fine.

Check out section 2 of RFC 2979 - do you think that something useful
could be distilled from that?

>There was a discussion on the IETF list about layering, which I what I'm
>referring to.

I'm not sure that we want to get too deeply involved in layering
discussions, but the fact that we are violating layers does have
some specific implications with regard to service location/
topology, scaling, error recovery, etc., and perhaps it's those 
implications that do need to be explored more thoroughly.

Melinda

_______________________________________________
midcom mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/midcom

---

From: Scott Brim <[email-masked]>
Date: Wed, 1 Aug 2001 08:36:07 -0400

> could be distilled from that?

I'm having trouble getting excited about this nit.  If forced to choose,
though, I think Suresh's is at least as good.  In the end, regardless of
how much application context goes into the *why*, a firewall filters
packets.

Ned (2979): A "firewall" is an agent which screens network traffic in
some way, blocking traffic it believes to be inappropriate, dangerous,
or both.

Suresh (framework): Firewall is a policy based packet filtering
Middlebox function, typically used for restricting access to/from
specific devices and applications.

6 of one, 6.002 of the other (imho).

---

From: "Christopher A. Martin" <[email-masked]>
Date: Wed, 01 Aug 2001 08:27:51 -0500

RFC 2647 defines firewalls among other things for the purpose of
benchmarking firewall performance, by the Benchmarking Workgroup.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Eliot Lear
Sent: Tuesday, July 31, 2001 5:41 PM
To: Pyda Srisuresh
Cc: [email-masked]
Subject: Re: [midcom] framework comments

Hi,

Comments in line.

Pyda Srisuresh wrote:

> > "packet filtering" is but one type of firewall.  We should borrow a
> > better definition from elsewhere.
> >
>
> Eliot - There may be many variations to the theme, all eventually
> boiling down to packet permitting/filtering. The purpose was merely
> to expose this aspect of the firewall from middlebox function
> perspective.
>
> As I recall, there were multiple semantics associated with the term,
> at the time the discussion got started on the list. Some implying
> NAT function and IPsec Gateway function and so forth - all included
> in the same term.
>
> I believe, the current definition will suffie for the purposes of
> MIDCOM FW.

>
> > Figure 3 - you skipped or removed step "5".
> >
>
> OK.
>
> > I'm also interested in changing some wording to the protocol
> > requirements, and a more general statement about protocol layering.  Bob
> > Braden's recent post to the IETF I think is most concerning.
> >
>
> Not sure what you are talkig about. I didnt see the e-mail from Bob
Braden.
> Were you going to suggest somethign specific to framework draft?

> We discussed this before on ths list. We agreed that the only policy
> server this WG will look into is the policy server authorizng the
> agents. Any application or user specific policy decisions are considered
> out of bounds for this WG.
> (Refer last paragraph in section 2.9).

I largely agree with the caveat that we need a method to pass opaque
information to the policy server in order to make its decision.  I seem to
recall in earlier discussion that I wouldn't want that becoming a huge
chatty conversation, but more of an EHLO-like exchange some of which could
be cached.

--
Eliot Lear
[email-masked]