Subject: [midcom] some comments on the framework draft

From: "Scott Brim" <[email-masked]>
Date: Fri, 9 Mar 2001 19:07:19 -0500

Suresh: The draft is a great start but needs some cleaning up.  I have
an immediate fairly small question and then I'll mention just the big
issues.  There are lots more smaller ones where these came from :-).

You say:

   ALGs are different from proxies, in that, ALGs are transparent to
   end hosts, unlike the proxies. Proxies terminate sessions with
   both end-hosts. ALGs, on the other hand, do not terminate session
   with either end-host. Instead, proxies examine and optionally 
   modify application payload content to facilitate the flow of 
   application traffic through a middlebox. The objective of
   an ALG is to assist middleboxes in carrying out their function.
   Whereas, the objective of a proxy is to act as a relay agent
   between application clients and servers.

I want to be sure about the sentence beginning on the 4th line.  Where
you say "Instead, proxies", do you mean "Instead, ALGs"?

OK, now to some comments ...

* I don't think proxies as described above should be in this
  architecture at all.  A proxy, as described above, terminates
  connections from clients and originates new sessions on their behalf.
  They might modify content, but they are not modifying packets, they
  are generating new packets.  In essence, from the point of view of
  midcom agents and middleboxes, proxies are clients.  Just as with any
  other client, a proxy might have a midcom agent closely associated
  with it, even sharing the same CPU.  Given the concept of proxy as
  described in this framework, from the point of view of midcom there is
  nothing that distinguishes a proxy from any other client.  Let's treat
  them as such.  Note that something which "proxies" only the signaling
  session is probably best classified as a kind of agent.  Also note
  that the use of proxy here is very different from the use of "proxy"
  in SOCKS, which is fine -- I think we have a better definition.

* "ALG" is a midcom agent function.  "An ALG" is not an entity in and of
  itself.  As you say, "MIDCOM agents are entities performing ALG
  function external to a middlebox" -- i.e.  midcom agents have an ALG
  function, by definition.  An agent exercises application intelligence,
  and if it's not exercising that application intelligence, then it's
  not an agent.  Therefore, I think you should eliminate the big
  section on ALGs and describe the ALG function under "agent".  Where
  you describe the difference between the ALG function and proxy
  function, compare and contrast proxies and agents instead.

* > The policy server must determine trust guidelines for controlling 
  > middleboxes according to the level of (presumed) security of the 
  > host making the request.

  First, this should also be per-function.  Second, which policies are
  per-client and which are per-agent?  We need to poke into the security
  model in more detail once we have our concepts down.

See you soon ... Scott

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

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 11 Mar 2001 17:50:48 -0800 (PST)

> issues.  There are lots more smaller ones where these came from :-).
Thanks, Scott. My comments below.

> you say "Instead, proxies", do you mean "Instead, ALGs"?

Yes. Sorry about the typo.

>   in SOCKS, which is fine -- I think we have a better definition.

Scott - I believe, it is useful to make the distinction between proxy and
and end-host.

>   function, compare and contrast proxies and agents instead.

It is important to preserve the distinction between ALGs
and "MIDCOM agents" because ALGs can exist on a middlebox (as they
do today) and neednt be present just on the MIDCOM agents.

>   model in more detail once we have our concepts down.

I believe, this is covered in some detail in section 5.1. 

> See you soon ... Scott
Sure.

regards,
suresh

=====

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/

---

From: "Christopher A. Martin" <[email-masked]>
Date: Wed, 14 Mar 2001 14:42:13 -0600

comments inline

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Pyda Srisuresh
> Sent: Sunday, March 11, 2001 7:51 PM
> To: Scott Brim; [email-masked]
> Subject: Re: [midcom] some comments on the framework draft
>
>
>
In the case of SIP this is half true, when compared to traditional
firewall-like proxies. SIP proxies forward internal information in the form
of via, record route, route, etc... in this case it is not truly only acting
on behalf of the client, it is also revealing the internal path and
topology, true proxies do not reveal this type of snesitive information. I
believe that it is necessary to include proxy behavoir in order to address
this aspect of SIP proxy behavoir. In this instance it may be better to
utilize an ALG than a true proxy function when traversing firewalls,
especially in the case of NAT.

---

From: "Melinda Shore" <[email-masked]>
Date: Wed, 14 Mar 2001 17:00:57 -0500

> especially in the case of NAT.

The use of the word "proxy" to describe what's evolved
into a call control/mediation function in SIP has, I
think, introduced some muddle around the word "proxy"
and we need to get that cleaned up and nailed down.  I
believe that you and Scott are talking about two different
things - a SIP proxy is much more than a relay.  

Melinda

---

From: "Scott Brim" <[email-masked]>
Date: Wed, 14 Mar 2001 16:58:48 -0500

> especially in the case of NAT.

I believe we're in agreement.  I think classic proxies are more like
hosts acting on behalf of other hosts than anything with midcom
intelligence, while those "proxies" which have more elaborate behavior,
including signaling extra control information or separating signaling
from data, are best thought of as a kind of agent.  The difference
between the types of "proxies" is clearly significant enough to make it
worth splitting them in our model.  Once you do that, dumb proxies are
very close to hosts and (imho) worth separating from them only in
passing mention.  Whether the cleverer proxies are similar enough to the
other midcom agents covered in the framework is an issue we can talk
about later.  

...Scott