Subject: [midcom] framework comments

From: Eliot Lear <[email-masked]>
Date: Thu, 26 Jul 2001 15:30:11 -0700

2.3 Definition of Firewall

"packet filtering" is but one type of firewall.  We should borrow a 
better definition from elsewhere.

Figure 3 - you skipped or removed step "5".

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.

It is necessary for authorization to occur within the midcom protocol. 
 The conditions of that authorization may be based on characteristics 
taken from any part of the protocol stack.  That is the nature of 
policy.  However, the communication that is authorized is a 
TCP/UDP/SCTP/etc. tuple.

The way these decisions are made may require the midcom agent to pass to 
the middlebox opaque application level information that it MAY in turn 
pass onto an appropriate policy server.  This information does need to 
be structured and supported by the protocol, and may even be multiple 
blocks that are passed to different policy servers.  Consider a policy 
server that handles voice, allowing voice sessions of < 64 kb/s for 
lengths of time <= 4 hours, but a separate policy server that restricts 
communications with my competitors and stock broker ;-)

I want to be able to make some statement about "no gnutella files of 
type mpg or avi, but allow mp3" or not.

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

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 30 Jul 2001 20:39:24 -0700 (PDT)

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

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

> communications with my competitors and stock broker ;-)

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

> type mpg or avi, but allow mp3" or not.

Thanks.

regards,
suresh

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

---

From: Scott Brim <[email-masked]>
Date: Tue, 31 Jul 2001 12:08:11 -0400

> (Refer last paragraph in section 2.9).

That's not what I recall.  Obviously policy interactions which don't
involve a middlebox aren't our concern.  However, I and others were
saying that the middlebox may wish to communicate with a policy server
for AAA for specific agent transactions.  I will attach some excerpts at
the end of this.  As far as I can tell these were the last comments.
They didn't get a response, the conversation was never resolved and the
draft remains unchanged.  It's on the list of things I decided to let
go, but since it's come back, I think it should be resolved.

Eliot has a good point.  The assumption that there is "a policy server"
is not necessary and is restrictive.  Easiest fix would be to say
"policy services".  You can also add a *tentative* statement that the
midcom protocol will need to indicate somehow what type of request this
is (as in Eliot's example), which could either be in the protocol, or in
agent registration, or somewhere.  Meanwhile, in the requirements
document, we need to decide what exactly is required.  In any case, it's
a valid point that a single policy server should be required to know
everything.

Mail excerpts follow.  

Melinda in response to Suresh:

> > I believe, the policy server is a repertoire of information
> > pertaining to various agents (that can connect to middlebox). The
> > Policy server has no knowledge of middlebox service and as such
> > cannot help a middlebox with any of the run-time policy decisions
> > pertaining to middlebox resource control.
> 
> All the policy server can do is manage and distribute policy data.
> That data could potentially be pretty much anything, and since we
> haven't yet talked much about what kind of data would be needed to
> support firewall and NAT services I think it's premature to say that
> it will never be consulted during a middlebox transaction.

Scott in response to Suresh:

> > > Second, as discussed on the mailing list, there are two different
> > > kinds of information which can be obtained from a policy server.
> > > You have the them bundled together.  The first is general
> > > authorization and limits for an agent.  The second is information
> > > regarding a particular request from an agent.  While a middlebox
> > > might obtain an agent "profile" either before or when it first
> > > makes contact with that agent, it does not necessarily obtain
> > > complete rules for treatment of requests from that agent at that
> > > time.  The text above requires that (or if it doesn't, then you
> > > don't mention request-specific rules anywhere :-)).  I would add
> > > another sentence, something along the lines of "Policy regarding
> > > treatment of specific agent requests may be obtained when the
> > > agent is first authorized or at any time thereafter."
> > >
> > What sort of agent requests would require the middlebox to consult
> > the Policy Server at run time? DO you have a specific example?
> >
> > We had a discussion on this thread. Somewhat inconclusive.  SO, I
> > didnt add any text that is suggestive or not-suggestive of the use
> > of Policy Server at run-time by the middlebox.
> 
> As I said, many conversations are inconclusive until we get this close
> to last call.  Now's the time we work things out.
> 
> OK, here's an example: I have a middlebox which handles communications
> for potentially millions of clients, although only a small number
> (hundreds?) will be active at any one time.  Each customer is
> potentially different enough in enough ways that it would take
> significant effort to create aggregate rules for them. I don't want to
> store rules for all the millions of them in the middlebox since that
> would cost me more in hardware and in any case the initialization time
> would ruin my availability numbers.  So I feed the middlebox some
> general policy to start with -- such as which agents are authorized
> for what, in general terms -- and when it gets a specific connection
> request, it queries the policy server which generates the
> customer-specific policy on the fly (from info in a database) and
> returns it.  See?  Agent-related policy comes first, then
> customer-related policy later.  They don't have to, but I want to
> allow this possibility for the service providers.
> 
> My concern here is that your language explicitly mentions the agent
> profile and stops as if that's all there is.  Perhaps you could say
> something like ... "gain access to middlebox resources.  A middlebox
> and a policy server may communicate further if the policy server's
> policy changes or if a middlebox needs further information."

---

From: Eliot Lear <[email-masked]>
Date: Tue, 31 Jul 2001 15:41:24 -0700

Hi,

Comments in line.

> I believe, the current definition will suffie for the purposes of

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.

> Were you going to suggest somethign specific to framework draft?

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

> (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]