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

From: "Fleischman, Eric W" <[email-masked]>
Date: Wed, 27 Jun 2001 10:27:17 -0700

Thank you, Christian, for this thought-provoking and valuable posting. 

I believe that your "holes are open forever" point (i.e., in your first set of 
bullets) is outside of our scope. That scenario has to do with the policies by 
which a firewall is initially configured, and is not subject to the additional 
class of "pinhole openings" which are within our charter.

If we take the case of a single firewall supporting a very large campus, it is
unlikely and non-scalable to imagine that that firewall can track the state of the
many internal hosts which may easily number in the tens of thousands.

It is more scalable for a midcom agent to track the state of the host which
requested the services, but that agent will at most have visibility in the general
case to the requesting machine, not the destination machine. Therefore I do not
believe that there is any way for the firewall to know the state of its internal 
hosts, since the midcom agent may well be external to the firewall. Therefore, I see 
no way to avoid these anomalies and believe that the protocol must anticipate and 
expect these anomalies to occur -- and potentially compensate for them.

What is an "internal host" to a firewall protecting a domain which includes another
firewall protecting a subdomain? That is, are the hosts behind the second firewall
an "internal host" to the outer firewall? (This isn't mythical, we've got this situation.)

While I don't think we can do anything about your second set of bullets other than
anticipate that these anomalies will occur, I do appreciate and value your (third) final 
set of bullets as viable alternatives for us to consider. Are you proposing that we
leave it up to implementers to select one alternative, rather than designing one (or a 
subset) into the protocol?

--Eric

-----Original Message-----
From: Christian Huitema [mailto:[email-masked]]
Sent: Wednesday, June 27, 2001 9:03 AM
To: Scott Brim; Fleischman, Eric W
Cc: midcom mail-list
Subject: RE: [midcom] Confusion re. text in requirements-01

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
> 
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/midcom

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

---

From: "Fernando Cuervo" <[email-masked]>
Date: Wed, 27 Jun 2001 14:17:36 -0400

Christian, all,

I believe it would be possible and necessary to support all alternatives in
the third set of bullets. 
If we think of the MB as providing a "pinhole-service" to an agent , it
might be possible to express the
conditions of the "service" as either time-dependent, traffic-dependent
(which includes a closed TCP connection
) or control-dependent (which may include authorised 3rd parties). One of
the assumptions about MBs is that
they are policy enabled, therefore, more complex behaviours could be
implemented depending on
the specific knowledge of the agent or the traffic. Ultimately, the "terms"
of the "service" requested by the agent
depend on stuff that only the agent  may know (type of service, service
behaviour when the controller crashes,
etc.)

Fernando Cuervo

> From:	Fleischman, Eric W [SMTP:[email-masked]]
> Sent:	Wednesday, June 27, 2001 1:27 PM
> To:	'Christian Huitema'; Scott Brim
> Cc:	midcom mail-list
	[Cuervo, Fernando [CAR:5N10:EXCH]]  stuff removed...
> From: Christian Huitema [mailto:[email-masked]]
	[Cuervo, Fernando [CAR:5N10:EXCH]]  stuff removed...

---

From: "Fleischman, Eric W" <[email-masked]>
Date: Wed, 27 Jun 2001 11:46:51 -0700

>> Eric Fleischman wrote:
>> My own preference is to exclusively rely upon timers in the 
>> middlebox to close the pinholes, and I'd really prefer not 
>> having keep alives (believing they are non-elegant and waste  
>> bandwidth), but I will defer to the experience of those who 
>> have actually built these systems.
>
>Andrew Molitor wrote:
>I assume you still allow Agents to explicitly close pinholes?
>I had a bad moment when I read the first line, but I think you mean
>that timers, if used, should be in the middlebox itself.

Thank you for pointing out the error in my careless writing. Yes, 
I indeed meant what you stated. I definitely wouldn't want to 
deprecate the midcom agent closing their own pinholes.

>	A wrinkle from SIP-land: A stateless SIP proxy operating as
>a MIDCOM Agent can get keepalives from the endpoints of a call, in
>the form of re-INVITEs. To the vast amusement of those of us not
>intimate with SIP, it turns out the re-INVITEs look pretty much like
>INVITEs, and a stateless proxy can't necessarily tell the difference.

Perhaps I'm not correctly understanding your point, but the proposed 
keep-alives are between the Midcom Agent and the middlebox.	The fact 
that a SIP proxy can be a Midcom Agent and that it can get periodic 
re-Invites does not, by itself, take us where we want to get. For 
example, it doesn't involve the Middlebox in those re-invites. Also, 
I am reluctant to build a framework which relies upon something which 
can happen, since that something can also not happen. That is, if 
we rely upon this "might happen" to become a "must happen" in order 
to support a (potentially complex) keep-alive scenario, then we've 
built in some fairly high risk fate sharing between Midcom and SIP, 
since it anticipates SIP changing their "may" into a "must".

>	I am very dubious of a middlebox-to-Agent 'I am about to delete
>this, do you want it?' transaction. It screams of complexity and race
>conditions.

I share your sentiments.

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 27 Jun 2001 11:11:10 -0700

Well, I have this model of an "off line" agent that only connects to the
middle box when it has something useful to say. The one thing I would
not want is to associate validity of pinholes with the maintenance of a
"session" between the midcom agent and the midcom box. The model of
operation I believe we should enable is to associate a "lifetime" with
every pinhole, and to have the possibility of setting that lifetime as
"infinite." If a finite lifetime expires, the hole is automatically
closed by the midcom box, unless an authorized controller renews it. A
corollary of allowing infinite lifetime is that you have to have a way
to perform an inventory, so an external manager can clear out the
crumbs. (By the way, this is the model adopted by the UPNP forum for NAT
traversal.)

Don't get me wrong, I am not against the concept of having a session
between an agent and the midcom box. There are good reasons to do that,
such as factoring a single session based authentication for multiple
midcom commands in a single session. Since authentication is likely to
be heavy duty, the factoring can give a big performance boost in some
configurations, e.g. sip proxy. But I believe that tying the lifetime of
a pinhole to the life time of the session is just wrong.

-- Christian Huitema

> Sent: Wednesday, June 27, 2001 10:03 AM
> To: Christian Huitema
> Cc: midcom mail-list
> 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.