Subject: [midcom] WG feedback solicited - Midcom semantics

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 25 Sep 2003 07:03:54 -0700 (PDT)

Folks,

The authors and I are unable to make much progress due to a basic conflict in
our perception of the Midcom objective and how to go about it. The authors and
I discussed over the phone yesterday and decided that we post you this e-mail
so you can provide the feedback. Your feedback will be valuable in order to
make progress. Thank you.

1. I believe, the objective of the Midcom protocol (and hence the semantics) is
to keep the middleboxes simple, without requiring ALGs. Agents will control
middlebox resources (via midcom) to allow the end-2-end applications to work.
As such, the middleboxes should permit their resources to be controlled by
agents via the midcom protocol.

The authors believe (Correct me if I am wrong) that the objective of the
semantics is to require the agents to be as simple as possible in their
interactions with middlebox. The complexity should be moved to the middlebox.

2. I believe, in order for the agents to control middlebox resources, the
agents ought to have the knowledge of the middlebox configuration.
     - Relevent interface, NAT address map entries, 
       default MaxIdleTimeouts configured.
     - Relevant interface specific firewall filters configured.

The authors believe (correct me, if I am wrong), the agent should not have to
know the middlebox configuration in order to run midcom protocol. 

3. Lastly, I believe, the midcom protocol should allow agents to control all
middlebox resources and parameters. Midcom protocol should be aware of the
middlebox resources and be designed to execute on these resources.
Specifically, the resource for a NAT middlebox are: NAT address map entries,
address/port bindings, and sessions. NAT controllable parameters are:
MaxIdleTimeouts for bindings and sessions. The resources for a firewall are:
permit/deny packet filters. Further to these native parameters, Midcom requires
the middleboxes to support a) resource Lifetimes, b) resource Grouping and b)
asynchronous notification for the resources the agents control. A middlebox
should incorporate these into its resources to support midcom.

The authors create an abstract model of resources for midcom protocol and
mandate middleboxes to meet that abstract resource model. In the semantics
model, the authors argue, there ought to be a one-to-one relationship between
bindings and sessions and that the middlebox should figure out how to make this
happen. The authors donot care to know if a session had 2 bindings, 1 binding
or had no binding.

Well, thats all for now. Thank you.

regards,
suresh

=====

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

---

From: Melinda Shore <[email-masked]>
Date: Thu, 25 Sep 2003 10:12:18 -0400

On Thursday, September 25, 2003, at 10:03 AM, Pyda Srisuresh wrote:
> middlebox resources and parameters.

Thanks for the note.  Your query relates to two decisions
that were made by the working group some time ago: 1) network
topology is out-of-scope, and 2) midcom is not to be a
general-purpose management mechanism, but is intended only to
support traversal of these devices through resource requests.
There was never any intention to support device configuration
and interface management, and those functions are out-of-
scope for the working group.  The last time this was proposed
(by me) it met decidedly, uh, enthusiastic disagreement from
the working group.  We're not going to be revisiting either
decision at this very late date.

Melinda

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 25 Sep 2003 09:42:07 -0700 (PDT)

--- Melinda Shore <[email-masked]> wrote:
> Thanks for the note. 

No problem.

>                       Your query relates to two decisions
> topology is out-of-scope, 

OK. Why do you believe, I was suggestign this? 
Just to be clear, I was not suggesting this.

>                            and 2) midcom is not to be a
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I assume, you meant traversal of applications through the middlebox devices.

Once again, Just to be clear, I neither implied nor intended the Midcom to be a
general-purpose management protocol. The very first note I made was that Midcom
objective was to move ALGs out of middleboxes. So, all the instrumentation that
is necessary to move the ALGs out of middlebox was all I was refering to.

> scope for the working group.  

Most certainly. Device configuration and management is the function of
middleboxes. I.e., NAT and firewall functions require this for their native
operation with or without midcom.

>                               The last time this was proposed

In summary, I am in agreement with what you say. I was not suggesting any of
the items you were alludign to in the e-mail.

regards,
suresh

=====

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 26 Sep 2003 17:11:45 +0200

Hi folks,

--On Thursday, September 25, 2003 07:03:54 -0700 Pyda Srisuresh 
<[email-masked]> wrote:

| Folks,
|
| The authors and I are unable to make much progress due to a basic
| conflict in our perception of the Midcom objective and how to go about
| it. The authors and I discussed over the phone yesterday and decided that
| we post you this e-mail so you can provide the feedback. Your feedback
| will be valuable in order to make progress. Thank you.

Right, and we would really appreciate comments from the mailing list about 
the issues.
|
| 1. I believe, the objective of the Midcom protocol (and hence the
| semantics) is to keep the middleboxes simple, without requiring ALGs.

Right, keeping the ALGs out of the middlebox.

| Agents will control middlebox resources (via midcom) to allow the
| end-2-end applications to work. As such, the middleboxes should permit
| their resources to be controlled by agents via the midcom protocol.

That's agreed, but controlling resources may be to broad, since ALGs want 
to enable communication end-to- and they do not want to deal with middlebox 
internal issues.

|
| The authors believe (Correct me if I am wrong) that the objective of the
| semantics is to require the agents to be as simple as possible in their
| interactions with middlebox. The complexity should be moved to the
| middlebox.

The complexity should stay there where it is anyway:
 - full configuration of middleboxes with all their resources, plus their 
internal configuration, mode of operation, and implementation issues should 
stay in the middlebox
- handling of application logic should stay at the ALGs/proxies.

But application logic should not be loaded with middlebox issues, otherwise 
the actual gain of simplicity would be gone, at least for the ALGs.

|
| 2. I believe, in order for the agents to control middlebox resources, the
| agents ought to have the knowledge of the middlebox configuration.
|      - Relevent interface, NAT address map entries,
|        default MaxIdleTimeouts configured.
|      - Relevant interface specific firewall filters configured.
|
| The authors believe (correct me, if I am wrong), the agent should not
| have to know the middlebox configuration in order to run midcom protocol.

The agent should be able to dynamically configure policy rules at 
middleboxes without (or even less) knowledge. That's keep it simple, stupid.

  Martin

|
| 3. Lastly, I believe, the midcom protocol should allow agents to control
| all middlebox resources and parameters.
|                                        Midcom protocol should be aware
| of the middlebox resources and be designed to execute on these resources.
| Specifically, the resource for a NAT middlebox are: NAT address map
| entries, address/port bindings, and sessions. NAT controllable parameters
| are: MaxIdleTimeouts for bindings and sessions. The resources for a
| firewall are: permit/deny packet filters. Further to these native
| parameters, Midcom requires the middleboxes to support a) resource
| Lifetimes, b) resource Grouping and b) asynchronous notification for the
| resources the agents control. A middlebox should incorporate these into
| its resources to support midcom.
|
| The authors create an abstract model of resources for midcom protocol and
| mandate middleboxes to meet that abstract resource model. In the semantics
| model, the authors argue, there ought to be a one-to-one relationship
| between bindings and sessions and that the middlebox should figure out
| how to make this happen. The authors donot care to know if a session had
| 2 bindings, 1 binding or had no binding.
|
| Well, thats all for now. Thank you.
|
| regards,
| suresh
|
|
|
| =====
|
|
| _______________________________________________
| midcom mailing list
| [email-masked]
| https://www1.ietf.org/mailman/listinfo/midcom

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 29 Sep 2003 06:52:52 -0700 (PDT)

--- Martin Stiemerling <[email-masked]> wrote:
>^^^^^^^^^^^^^^^^
What middlebox internal issues? I was only refering to middlebox resources. You
donot need to understand routing protocols to program a router. But, you do
need to understand route object and how a router uses routes in order to
program the router. 

> internal configuration, mode of operation, and implementation issues should 

Agreed. Configuration and bringup of a middlebox, just as configuration and
bringup of an application is independent of midcom.

> - handling of application logic should stay at the ALGs/proxies.

Yes.

> But application logic should not be loaded with middlebox issues, otherwise 
                                      ^^^^^^
That is what an ALG does. An ALG has to know how to control middlebox
resources.
You cannot be an ALG and not understand middlebox resources.

> the actual gain of simplicity would be gone, at least for the ALGs.

The simplicity is moving ALGs out of middlebox. This reamins.

> middleboxes without (or even less) knowledge. That's keep it simple, stupid.

The ALG (agent) should know the configuration of the middlebox it is
interfacing with. The ALG will not be able to control middelbox resources
blindly.

> | Well, thats all for now. Thank you.

cheers,
suresh

=====