Subject: [midcom] State in framework-02

From: "Fleischman, Eric W" <[email-masked]>
Date: Thu, 14 Jun 2001 16:30:30 -0700

The final two paragraphs of Section 4 addresses the 
need for middlebox services to be stateful. I've been
puzzling over these two paragraphs over the last few 
versions because Section 4 itself deals with the Midcom 
protocol, rather than the middlebox, which was described 
in Section 3. It appears to me that these two paragraphs 
are misplaced and should be moved to Section 3. That is, 
it appears that the authors' intent is NOT to make the 
Midcom protocol be stateful between the Midcom Agent and 
the middlebox nor to require that the Midcom Agent itself
be stateful. If so, this point needs to become more 
explicitly stated.

That is, the final paragraph of Section 4 says in part:
"Explicit release of dynamically allocated resources 
happens when the application session is ended or when 
a Midcom agent requests the middlebox to release the 
resource. However, the middlebox must be able to recover 
the dynamically allocated resources at some point in time 
even if the agent that was responsible for the dynamic 
allocation is not alive. ..."

It has been Boeing's experience that application-level
gateways have been unusually expensive and resource-
intensive to maintain over time. This is especially the
case if the protocols which they are "linking" are 
themselves stateful, because should the gateway's
state machine enter an indeterminate state (e.g., due
to an unanticipated melding of the states of the two
protocols), which occurs vastly more often than one would
hope, the gateway inevitably hangs. From protracted
painful and expensive experience, we have learned to 
prefer approaches which are as stateless as possible 
(fully realizing that there are good reasons why many 
protocols need to be stateful) because they tend to be 
easier to maintain and support over time.

Similarly, denial of service exploits are the more
effective for stateful protocols, a point which was 
made in Radia Perlman and Charlie Kaufman's recent article 
in IEEE Internet Computing magazine ("Key Exchange
in IPSec: Analysis of IKE", November/December 2000; see
the Cookies section on page 53).

For these reasons, it would be desirable if we would 
explicitly not require the Midcom Agent to be stateful 
(but allow statefulness there if needed) and, more 
importantly, that we explicitly design a midcom 
protocol that did not require protocol state to be 
kept after the setup. 

That is, the current draft implies that the Midcom
protocol will perform two functions: (1) Setup and (2) 
Teardown where the former opens a hole through the 
middlebox and the latter closes it. The current text 
implies that the latter is optional, and that timers on 
the middlebox will close the hole if no Teardown happens. 
This is great. What I'd like to see is a mention that
if Teardown happens, then it occurs because the Middlebox
has tracked which Midcom agent set up which Session Descriptor. That is, that the teardown occurs solely
because of statefulness of the middlebox rather than
the statefulness of the protocol (i.e., any protocol
linkages between the Setup function and the Teardown
function).

--Eric 

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

---

From: "Melinda Shore" <[email-masked]>
Date: Fri, 15 Jun 2001 10:23:45 -0400

> That is, that the teardown occurs solely

The other situation which hasn't been discussed is
that the application is going to continue to retain
state and that it will notify the agent when it releases
a resource.  The agent then sents the teardown request
to the middlebox, but it's not retaining state itself.

Melinda

---

From: "Scott Brim" <[email-masked]>
Date: Fri, 15 Jun 2001 11:11:55 -0400

> to the middlebox, but it's not retaining state itself.

This is a scenario, but we're still allowing the possibility that an
application may be completely naive, right?

(more later)

...Scott

---

From: "Melinda Shore" <[email-masked]>
Date: Fri, 15 Jun 2001 11:40:10 -0400

> application may be completely naive, right?

Sure - the point was that it's possible for the agent
to request state changes without having to retain state
itself.

Melinda

---

From: "Scott Brim" <[email-masked]>
Date: Fri, 15 Jun 2001 14:48:10 -0400

> to request state changes without having to retain state

Nice and simple, isn't it?  Here are some principles which might
generate some text for Requirements ...

We can use the end-to-end argument & fatesharing, and say the fate of
state in the network should ultimately be controlled by the endpoints
for whom it is installed in the first place.  (Network operators can
install state by configuration, but that's orthogonal.)  This doesn't
mean that endpoints have to say something explicit to get state
installed -- in fact they probably won't -- but that whatever the action
by an endpoint which triggered the installation of that state to start
with, there has to be at least one trigger for removing it which is
based on action or inaction by that endpoint.  The fate of
session-related state rests in the hands of the endpoints, whether they
know it or not.

Agents will either receive explicit cues from endpoints for deleting
state (e.g. call teardown), or there will be reliable implicit cues, or
they will have to have timers (of any kind).  This is protocol-specific
and thus agent-specific.  We don't need to specify anything here.

Since we're trying to minimize the amount of session-related state that
middlefunctions generate for themselves, the midcom protocol must let
agents give middleboxes explicit rules for when to remove state.  Those
rules could be, for example, to wait for explicit instructions from the
agent, to delete when certain traffic (to/from an endpoint) hasn't been
seen for some time, to delete after a certain absolute time, to delete
when certain packets are seen from the endpoint(s), or to query the
agent after a certain amount of time (this is Suresh's timer).  We have
to narrow down this list of possibilities in order to keep middleboxes
simple.  

Also, since we already have multiple requirements on it, what do we do
when contact with the middlebox is lost?  I think we should make room
for including a rule for that in the midcom protocol, but make it
optional, and leave default behavior (per-agent) up to configuration.

...Scott

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 17 Jun 2001 16:00:34 -0700 (PDT)

--- "Fleischman, Eric W" <[email-masked]> wrote:
> are misplaced and should be moved to Section 3. 

Interesting observation. The two paragraphs were indeed moved
from section 3 in a previous rev to section 4.

The text was intended to point out that MIDCOM protocol causes
the middlebox to be stateful. So, it seemed reasonable to move 
this text to section 4, where MIDCOM protocol was discussed.
  
>                                                  That is, 

As you rightly pointed out, none of the above were the intent.
As for MIDCOM protocol being stateful or not, that is not in 
scope for the document - Not until a specific protocol proposal 
is in place.

> allocation is not alive. ..."

The above paragraph says nothing about the statefulness (or the
lack of) of the MIDCOM protocol. Just that it should be able to
recover a resource, in case of a possible unannounced demisal of
an agent.

> easier to maintain and support over time.

I understand, you are advocating a stateless MIDCOM protocol.
Stateless and stateful types are different mechanisms
to accomplish the same MIDCOM protocol. As you point out, 
there are pros and cons.

At best, we could point out the two alternatives, but not mandate
or recommend one over the other at this time.

> the Cookies section on page 53).

See my comment above.

> protocol that did not require protocol state to be 

I dont think, we should mandate one or the other.

> the middlebox will close the hole if no Teardown happens. 

The text does not say that MIDCOM session teardown as optional. 
Specifically, below is the text describing MIDCOM session teardown
in section 4.0.

   A MIDCOM session may be terminated by either of the parties.
   Alternately, a MIDCOM session termination may be triggered by
   one of (a) agent going out of service and not being available
   for further MIDCOM operations, or (b) a policy server notifying
   the middlebox that a particular MIDCOM agent is no longer
   authorized for a particular set of sessions any longer.

The document says that middlebox has to be concerned with agents
disappearing, without prior announcement. As such, the middlebox
shoudl be able to monitor dynamic recources allocated by the agent.

> linkages between the Setup function and the Teardown

I do not understand what you say. 
Why should a teardown (of a MIDCOM session) occur because  of the
statefulness of the middlebox or the statefulness of the MIDCOM 
protocol?
 
> --Eric 

Eric and others - If this whole discussion seems like it is going
overboard, I am OK to get rid of the said two paragraphs (in 
section 4). The specific text is not that critical to the document,
I believe.

Thanks.

cheers,
suresh

__________________________________________________
Do You Yahoo!?
Spot the hottest trends in music, movies, and more.
http://buzz.yahoo.com/