Subject: [midcom] Summary of the informal gathering on thursday (08/09)

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 9 Aug 2001 19:31:22 -0700 (PDT)

Folks,

This is to make public the gist of the informal meeting that
took place today (08/09) to collectively figure out what we need to 
do to make the framework draft through the last call. Thanks to Cedric
Aoun for arranging the Thames suite for the meeting. I called in
over the telephone to parttake in the conversation.

1. Melinda Stated that the objective is not to devoid the framework
   draft of requirements or vice versa. But, it is important that the
   stated or implied requirements be only those that are agreed upon
   (rough consensus). Refer http://www.employees.org/~swb/midcom.html
   for a list of implied requirements in the framework draft

2. Section 2.2: Add a couple of sentences describing 
   traditional Middleboxes that embed application intelligence,
   MIDCOM supported middleboxes that externalize application 
   intelligence and middleboxes that embed application intelligence 
   for some applications and use MIDCOM support for others.

3. Section 2.3: No need to change the defintion of firewall.
   Also, no need to replace the term firewall with "packet filtering".
   Leave the reference to firewall as is.

4. Section 2.6: Change the first sentence as follows:
   Application Level Gateways (ALGs) are entities that possess the 
   application specific intelligence and knowledge of an associated
   middlebox function. 

5. Section 2.8: Mark Duffy will propose new text to replace existing 
   text. There was concern about whether or not intrusive MIDCOM agents
   (in the native path) should be considered In-Path agents. 

6. Section 4.0 - Provide definition of what connection means for 
   the context of this document in the terminology section (section 2.0).
   Connection is described to be a lasting association between a MIDCOM 
   agent and a middlebox and by no means is assumed to be any specific 
   transport layer protocol.

7. Section 6.0 - Paragraph 2 - Last sentence will read as follows.
   In the context of MIDCOM framework, the Policy server does not 
   assist a middlebox in the implementation of the services it 
   provides.

8. Section 6.1 - Second paragraph end - Text on non-Repudiation.
   Looks good. Should stay.

9. Section 6.2 - Provide definition for registration and deregistration
   upfron in terminology section.  
 
10. Section 6.2 - first paragraph - Replace the first paragraph as follows.

   Prior to giving MIDCOM agents access to the middlebox resources,
   a registration process MUST take place. Registration is a
   different process than establishing a transport connection.
   The former requires exchanging agent profile information with the
   middlebox or policy server(s). Agent registration is often a
   manual operation performed by an operator rather than the agent
   itself. The transport connection refers to establishing a MIDCOM 
   transport connection and exchanging security credentials between 
   an agent and a middlebox. The transport connection uses the 
   registered information for connection establishment.

Thats all I have. Thanks.

regards,
suresh

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

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

---

From: Abdallah Rayhan <[email-masked]>
Date: Fri, 10 Aug 2001 12:05:32 -0400 (EDT)

Suresh,

Thanks for the summary. See comments below.

>    registered information for connection establishment.
 
I believe that the idea behind reg/dereg is to address the trust
issue. If an agent registers successfully then it is trusted to 
carry out what it is supposed to do. Restricting that to manual 
operation only and not addressing the possibility of the agent 
doing the reg/dereg process is probably not a desirable outcome. 
I rather refer to this operation as provisioning which is perfectly 
alright if it is manual. IMHO, when an agent registers with an 
middlebox it should indicate the terms under which it is going to
operate whatever those terms are. It could be something like "I am
agent x and want to perform filtering with NAT and no QoS." 
I know QoS is not yet part of any requirements but just an example.

regards
Abdallah

_______________________________________________________
Do You Yahoo!?
Get your free @yahoo.ca address at http://mail.yahoo.ca

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 10 Aug 2001 09:33:59 -0700 (PDT)

> carry out what it is supposed to do. Restricting that to manual 

Abdallah - Registration is merely provisioning agent profile information.
(Read the following pragraph that descriebs what the profile may contain). 
I will replace the text "The former requires exchanging agent profile"
with "The former requires provisioning agent profile" - so the meaning
is clearer.

> agent x and want to perform filtering with NAT and no QoS." 

See my comment above. 

regards,
suresh

---

From: "Brian Hagar" <[email-masked]>
Date: Mon, 13 Aug 2001 09:15:49 -0700

Pyda,

What is the definition of an intrusive midcom agent mentioned below?

Brian

---

From: Mark Duffy <[email-masked]>
Date: Mon, 13 Aug 2001 23:14:45 -0400

>   (in the native path) should be considered In-Path agents. 

Here is the proposed text:

2.8. MIDCOM Agents

MIDCOM agents are entities performing ALG functions, logically external to a middlebox. MIDCOM agents possess a combination of application awareness and knowledge of the middlebox function, which combination enables the agents to facilitate traversal of the middlebox by the application's packets. A MIDCOM agent may interact with one or more middleboxes.

Only "In-Path MIDCOM agents" are considered in this document. In-Path Midcom agents are agents which are within the path of those datagrams that the agent needs to examine and/or modify in fulfilling its role as a MIDCOM agent. "Within the path" here simply means that the packets in question flow through the node that hosts the agent.  The packets may be addressed to the agent node at the IP layer.  Alternatively they may not be addressed to the agent node but may be constrained by other factors to flow through it. In fact, it is immaterial to the MIDCOM protocol which of these is the case. Some examples of In-Path MIDCOM agents are application proxies, gateways, or even end-hosts that are party to the application. 

Agents not resident on nodes that are within the path of their relevant application flows are refered to as "Out-of-Path (OOP) MIDCOM agents" and are out of scope of this document.

---

From: Scott Brim <[email-masked]>
Date: Tue, 14 Aug 2001 07:54:09 -0400

Looks okay to me.  I like the way you finessed the "signaling packets
versus data packets" bit ...

> In-Path Midcom agents are agents which are within the path of those
> datagrams that the agent needs to examine and/or modify in fulfilling
> its role as a MIDCOM agent.

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 14 Aug 2001 09:34:50 -0700 (PDT)

Hi Mark,

Looks good. I do have a comment below. Thanks.

regards,
suresh

--- Mark Duffy <[email-masked]> wrote:
> MIDCOM agents are entities performing ALG functions, logically external to a
> middlebox. MIDCOM agents possess a combination of application awareness and
> knowledge of the middlebox function, which combination enables the agents to
> facilitate traversal of the middlebox by the application's packets. A MIDCOM
> agent may interact with one or more middleboxes.
> 
> Only "In-Path MIDCOM agents" are considered in this document. In-Path Midcom
> agents are agents which are within the path of those datagrams that the agent
> needs to examine and/or modify in fulfilling its role as a MIDCOM agent.
> "Within the path" here simply means that the packets in question flow through
> the node that hosts the agent.  The packets may be addressed to the agent
> node at the IP layer.  Alternatively they may not be addressed to the agent
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> node but may be constrained by other factors to flow through it. In fact, it
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Are you suggesting that a middlebox can be a MIDCOM agent to another
middlebox? This can happen, when packets are not targeted to the
MIDCOM agent.

> is immaterial to the MIDCOM protocol which of these is the case. Some
> examples of In-Path MIDCOM agents are application proxies, gateways, or even
> end-hosts that are party to the application. 
> 
> Agents not resident on nodes that are within the path of their relevant
> application flows are refered to as "Out-of-Path (OOP) MIDCOM agents" and are
> out of scope of this document.

=====

---

From: Scott Brim <[email-masked]>
Date: Tue, 14 Aug 2001 12:44:53 -0400

> > node at the IP layer.  Alternatively they may not be addressed to the agent

By definition the middlebox function and agent function are distinct
(although they could be in the same physical enclosure).  However, I
don't believe that's what he's talking about.

Consider an FTP agent.  The client application knows nothing about the
agent (otherwise it would just be a proxy).  It's sending its packets
toward what it believes is the address of its remote peer.  Some of
those packets are FTP signaling, and some are data.  The agent wiretaps
the FTP communications in general and communicates with the middlebox to
make sure the client succeeds.  This is just like NAT+ALG today, except
for the separation of the NAT and ALG functions and the midcom protocol
between them.  As the text points out, the packets are not addressed to
the agent, they just flow through it.

..Scott

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 14 Aug 2001 11:39:36 -0700 (PDT)

> don't believe that's what he's talking about.
Sure, I wasnt alluding to that either.

> the agent, they just flow through it.
Yes. This is what I was refering to. The text suggests allowing a 
middlebox to be a MIDCOM agent to another middlebox. I am not necessarily
against this. I wanted this to be explicitly understood and agreed upon,
so this doesnt show up later on during last call or IESG review or what
have you.

Perhaps, you could track this along with the requirements you are tracking
- debated, agreed-upon etc...

Thanks.

regards,
suresh

---

From: Melinda Shore <[email-masked]>
Date: Tue, 14 Aug 2001 14:52:49 -0400

At 02:48 PM 8/14/01 -0400, Scott Brim wrote:
>So, the text for the requirement would be "A middlebox can be an agent
>to another middlebox"?

Let's not.  We're trying to reduce the bloat, and the above text
doesn't add anything that's not already in there.

Melinda

---

From: Scott Brim <[email-masked]>
Date: Tue, 14 Aug 2001 14:48:39 -0400

See bottom ...

I'm willing to put it in (I just line 'em up, anyone can bowl 'em over),
but (1) I still don't see how the text above leads to that idea, and (2)
I don't think it makes sense.  Perhaps a single physical enclosure could
contain both a middlebox function and an agent for some other middlebox,
but those would still be distinct functions.

I don't understand how you envision things.  Just because packets are
flowing through something doesn't make it a middlebox.  In the above,
what is the agent doing that makes it a middlebox?

..Scott

---

From: Mark Duffy <[email-masked]>
Date: Tue, 14 Aug 2001 17:38:16 -0400

First Mark wrote:
>> > > Alternatively they may not be addressed to the agent
>> > > node but may be constrained by other factors to flow through it.

>so this doesnt show up later on during last call or IESG review or what

Then Mark said:
Scott's description of the ftp agent is an excellent example of what
I had in mind.  I am a bit mystified as to what in the proposed text 
is leading Suresh to his conclusion.  I don't see anything in the text
to suggest that one mb is acting as agent to another mb.

I think it was Scott who pointed out the irony a few weeks back that
a midcom agent (or the box hosting it) is actually a middlebox of
sorts.  At least, under the definition of middlebox in
draft-carpenter-midtax-02.txt.  Framework-03 seems to narrow the
definition somewhat.  BUT, all that is the case whether the agent
is being addressed at the IP layer or not and I don't see a
connection between that and the text I have proposed for section 2.8.

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 15 Aug 2001 05:04:05 -0700 (PDT)

--- Scott Brim <[email-masked]> wrote:
> > > > > agents are agents which are within the path of those datagrams that
> the
> > > agent
> > > > > node but may be constrained by other factors to flow through it. In
> fact,
> > > it

The requirement I was alluding to is the following.
A MIDCOM agent function can be resident on transit as well as termination
devices that are in the message path of an application. A middlebox is a 
a transit device.
 
> but (1) I still don't see how the text above leads to that idea, and (2)

If I am still not making myself clear, let us drop this thread.

> what is the agent doing that makes it a middlebox?
See my comment above. Not every transit box is a middlebox. But, a
middlebox is a transit box. The comment I made refers to transit
boxes; and hence, by that implication to middleboxes.

regards,
suresh

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 15 Aug 2001 05:14:35 -0700 (PDT)

> to suggest that one mb is acting as agent to another mb.

Mark - Please see my response to Scott. The text suggests any intermediate
device (whether terminating the traffic as in Proxy/Gateway/VPN tunnel or
merely transiting the traffic as in switch/router/middlebox) as a 
candidate for hosting MIDCOM agent. The former was discussed in the 
past. The latter seemed like a new revelation. 

I am not disagreeing with the text, per se. I wanted the distinction to
be recognozed and agreed upon (for future reference). Thanks.

<... stuff deleted>

regards,
suresh

---

From: Melinda Shore <[email-masked]>
Date: Wed, 15 Aug 2001 08:23:54 -0400

>past. The latter seemed like a new revelation. 

I really don't think so.  We've already agreed that we're talking
about functions, not boxes, and that we're not constraining the
placement of functions (other than packet diversion not being
in scope).

Melinda

---

From: Scott Brim <[email-masked]>
Date: Wed, 15 Aug 2001 09:08:01 -0400

> devices that are in the message path of an application. A middlebox is a 

Aha.  I thought you might be talking about an assumption that agents
terminate packets, but I didn't think that made sense.

I think this is a framework issue, a concept/terminology issue, not a
requirement.

You might recall I had trouble with the framework terminology to start
with but, when I finally understood it, I thought you had everything
nicely internally consistent.  Now I'm having trouble again.  The
framework says "MIDCOM agents are entities performing ALG function", and
"An ALG examines application traffic in transit and assists middlebox in
carrying out its function." Note the "in transit", which says to me that
the packets continue on their course.  The only thing mentioned which
actually terminates sessions is a proxy.

Do you really think an agent function terminates all packets it responds
to?  

..Scott

---

From: Scott Brim <[email-masked]>
Date: Wed, 15 Aug 2001 09:10:14 -0400

> past. The latter seemed like a new revelation. 

I don't think so.  A function is defined as an agent based on that fact
that it uses the midcom protocol to speak with one or more middleboxes.
Whether it is explicitly addressed by the client, or it is just
triggered by packets going by -- and whether it terminates/regenerates
packets or just notices them in transit -- is orthogonal to its being an
agent.

This is all framework stuff.

---

From: "Ram Dantu" <[email-masked]>
Date: Wed, 15 Aug 2001 08:53:21 -0500

I completely support Melinda's statement ("we are talking about functions
not boxes). Infact, in some cases, the Middlebox (as a physical entity)
may be in the path of the SIP messages and then the MIDCOM-agent function
can be
inside the this particular Middlebox.

Ram Dantu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Melinda Shore
Sent: Wednesday, August 15, 2001 7:24 AM
To: Pyda Srisuresh; [email-masked]
Subject: Re: [midcom] proposed text for framework sect. 2.8

Melinda

---

From: "Bob Penfield" <[email-masked]>
Date: Wed, 15 Aug 2001 11:08:53 -0400

I think Mark's text is excellent. I do not think any of the issues/questions
in the various e-mails in response to Mark necessitate a change. It is
beyond the scope of MIDCOM how the agents are "in-path".

(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

----- Original Message -----
From: "Mark Duffy" <[email-masked]>
To: "Pyda Srisuresh" <[email-masked]>; <[email-masked]>
Sent: Monday, August 13, 2001 11:14 PM
Subject: [midcom] proposed text for framework sect. 2.8

> MIDCOM agents are entities performing ALG functions, logically external to
a middlebox. MIDCOM agents possess a combination of application awareness
and knowledge of the middlebox function, which combination enables the
agents to facilitate traversal of the middlebox by the application's
packets. A MIDCOM agent may interact with one or more middleboxes.
>
> Only "In-Path MIDCOM agents" are considered in this document. In-Path
Midcom agents are agents which are within the path of those datagrams that
the agent needs to examine and/or modify in fulfilling its role as a MIDCOM
agent. "Within the path" here simply means that the packets in question flow
through the node that hosts the agent.  The packets may be addressed to the
agent node at the IP layer.  Alternatively they may not be addressed to the
agent node but may be constrained by other factors to flow through it. In
fact, it is immaterial to the MIDCOM protocol which of these is the case.
Some examples of In-Path MIDCOM agents are application proxies, gateways, or
even end-hosts that are party to the application.
> Agents not resident on nodes that are within the path of their relevant
application flows are refered to as "Out-of-Path (OOP) MIDCOM agents" and
are out of scope of this document.

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 15 Aug 2001 12:49:40 -0700 (PDT)

> placement of functions (other than packet diversion not being

OK, folks, My mistake. I will gladly take Mark's definition
for "MIDCOM agent" into the FW draft. Thanks, Mark and thanks 
to all for putting up with the innuendo.

cheers,
suresh