Subject: RE: [midcom] Confusion re. text in requirements-01

From: "Scott Brim" <[email-masked]>
Date: Wed, 27 Jun 2001 13:02:30 -0400

Christian, I think we already have agreement on the possibilities (see,
for example, my mail on June 15th).  We should go further and narrow
them down.  A midcom protocol which requires agents and middleboxes to
support all possible mechanisms for state control will not be lean and
mean.  Let's try to decide, up front, if some are universally better
than others, or at least that some are no worse than others, and
eliminate alternatives.

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

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 27 Jun 2001 09:02:39 -0700

The current text introduces a confusion between the objective, which is
garbage collection of stale pinholes, and the means, for which they
suggest tying pinholes to a continued association between the agent and
the firewall. There is no debate that there is a requirement to be able
to perform efficient garbage collection. However, if you analyze the
scenarios, you find the following usage:

1) Some holes are just open forever. An example would be, "map incoming
connections on TCP port 25 to the internal mail server." 

2) Some holes are open by a "controller" and may well be renewed or
closed by another controller. Think of enabling firewall traversal for a
legacy server that has does not understand midcom, using some kind of
management console.

I think that a good replacement would be the insertion of a text like
what follows here:

-- Begin proposed text --

A firewall control protocol will create "state" on both a firewall and
an internal host. This state must be kept coherent. Failure to do so can
result in the following anomalies:

*	An internal server is advertised in the DNS and is up and
running on the internal network, but the firewall mapping has been lost:
the external clients who attempt to use the service see their connection
fail; the server does not receive any connection request.

*	An internal server crashes. A backup server tries to take over,
but the port is still reserved to the previous server in the firewall; a
request to map the same port to the new server is refused.

*	A connection between an internal host and an external peer has
been established by a signaling server. The signaling server crashes, so
that when the session ends there is no way to close the port in the
firewall. The firewall maintains the port open, possibly forever.

*	A signaling server that had crashed comes back on line, and asks
the firewall to close all ports open during the previous incarnation; as
a result, media sessions between internal and external peers are
suddenly interrupted.

It is important that the firewall control protocol contains adequate
ways to recover from the crash of either the firewall or the controlling
device. Among the possible solutions are:

*	Assigning a time to live to all openings,

*	Allowing the firewall to close an opening if no traffic is
observed during a specified time,

*	Allowing the firewall to close an opening upon the end of a TCP
connection,

*	Allowing controllers to draw an inventory of the existing
openings,

*	Allowing authorized entities, different from the original
requester, to explicitly close existing openings.

Each of these methods has advantages and drawbacks. For example,
assigning a time to live guarantees that port openings will be
automatically closed if the internal requester fails to renew the
opening request, but it will cause media connections to be closed if a
signaling server crashes. Allowing an automatic close after an observed
lack of traffic would allow communication to persist even if a signaling
server crashes, but require a steady flow of traffic; this is adequate
for most multimedia applications, but inadequate for applications such
as shared white boards, which can remain "silent" for long periods; it
is also inadequate for servers who are waiting for external connections.
The specific method of closing the state may in fact be a combination of
these methods.

-- End proposed text --

-- Christian Huitema

> -----Original Message-----
> From: Scott Brim [mailto:[email-masked]]
> Sent: Wednesday, June 27, 2001 8:00 AM
> To: Fleischman, Eric W
> Cc: midcom mail-list
> Subject: Re: [midcom] Confusion re. text in requirements-01
> 
> On 26 Jun 2001 at 16:49 -0700, Fleischman, Eric W apparently wrote:
> > In Section 5.3.2
> > Where the communication relationship between a Middlebox and a
MIDCOM
> > Agent are broken, all existing pin-holes must be closed.
> >
> > 	Question: Are you requiring "keep alive" overheads?
> 
> The question is whether "we" are requiring them.
> 
> A middlebox needs to be able to kill off pinholes for whatever reason.
> That means keeping state information, in order to remember to do so.
> That state could be an absolute timer, and that's a reasonable option
> but too rigid to have as the only one.  The alternatives are observed
> traffic and/or keepalives.  If an agent chooses to use an absolute
> timer, that's fine.  If it chooses to use keepalives, who should be
> responsible for the keepalives?  The middlebox has to have state
anyway,
> in order to kill off the pinhole eventually.  The agent *may* need
> state, but not all agents do.  I'm leaning toward having the middlebox
> send a query toward the agent -- "do you still want this?", but I
still
> haven't done a decent analysis.
> 
> ...Scott
> 
>