Subject: [midcom] draft-ietf-midcom-requirements-01.txt

From: "Bob Penfield" <[email-masked]>
Date: Fri, 22 Jun 2001 17:34:16 -0400

I am very encouraged by the progress made in this draft. I have a number of
questions/issues that follow. Some are related to those discussed by Scott,
Melinda, and Andrew, but I will add my two cents.

In section 4.1, it says:

         The Middlebox must support the explicit forwarding of application
         control session information received on one, or more, destination
         address/port combinations to an appropriate MIDCOM Agent(e.g. an
         application gateway) as described in section 7.

This sounds a lot like the Out-of-path agents and diversion functions that
have been debated over the last week or so. In-path agents will not require
this because they are explicit targets of the flow. Also, to me, section
7.1.1 states that diversion is the only way to get packets to the MIDCOM
agent. With in-path agents, we only need to NAT or admit the control flow so
that it can reach the in-path agent. This is the same function we need to
get data flows thru the middlebox.

I do not see a need to make an explicit distinction in the protocol between
control flows and content flows. The pin-hole request to allow the control
flow thru to an in-path agent is basically the same as a pin-hole request to
allow the content flow thru for a given session. Why does the middlebox need
to know that one pin-hole is for control flow and the other is for content
flow?

Section 5.2.2 mentions an identification of pin-holes, but I think we also
need to consider a session identification to associate multiple
pin-holes/flows with a session. This will be quite helpful when the MIDCOM
agent wants to update pin-holes specs (e.g. extend timers) or terminate all
the pin-holes for a given session.

Section 5.3.2 states that all pin-holes associated with a MIDCOM agent need
to be closed when the communication between the MIDCOM agent and the
middlebox is broken. This breaks redundancy and high availability where a
MIDCOM agent needs to failover without losing stable sessions. I think the
pin-hole specification needs to include an indication of whether or not the
pin-hole should be closed if the MIDCOM session with the MIDCOM agents
terminates. We need to consider the case when the MIDCOM agent fails and
when the MIDCOM Agent closes the connection normally. We should be able to
maintain the pin-holes in both cases (e.g. operator initiated switchover
from one MIDCOM agent to another). The normal close might include an
indication of whether pin-holes should be maintained. This is related to the
requirements that the middlebox resources can be shared by multiple MIDCOM
Agents. If one MIDCOM Agent can open a pin-hole and a different MIDCOM Agent
can close it, we might want to leave the pin-hole open when one of the
agents goes away and the let another MIDCOM agent close the pin-hole when
the session is truly over.

In section 5.5, what does "Application Stream Session" mean?

Section 6.2 talks about Deregistration. Is this suppose to be an explicit
function or is this normal closing of the MIDCOM Session? If it is normal
closing, I disagree with the requirement to close all the pin holes (see
above).

I think the last paragraph of section 9 places a requirement on the
middlebox that is outside the scope of the protocol requirements. Whether or
not a middlebox allows packets across itself is up to the middlebox's own
policy configuration. This statement basically says that only pin-hole specs
installed by MIDCOM agents are allowed.

Section 10.5 says that MIDCOM agents talk to MIDCOM policy servers, but
figure 1 shows the middlebox talking to the policy server. I believe figure
1 matches the picture and text in the framework draft.

Section 10.8 seems to be more about inter-version interoperability rather
than extensibility.

cheers,

(-:bob

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

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

---

From: Andrew Molitor <[email-masked]>
Date: Fri, 22 Jun 2001 20:16:13 -0500 (CDT)

> to know that one pin-hole is for control flow and the other is for content

	This is an excellent point. A reasonable way to deploy these
things (in the fullness of time when this is all mature) would be to set
up the middlebox as a completely opaque box which passes NO traffic.
As Agents for various protocols come up, or notice that the middlebox
is up, they would open static pinholes for themselves. For example,
the Enterprise' SIP proxy would open pinholes for UDP and TCP port
5060 to itself, and so on.

	As another example, there is a pretty neat workable model
for IP Centrex (where the SIP registrar function is 'outside' the
middlebox) which involves the external device opening pinholes and
doing NAT bindings to send signaling to individual phones on the
inside, on a call-by-call basis.

	The middlebox definitely should NOT know or care which pinholes
are used for what. More or less by definition, it cannot know.
 
> the pin-holes for a given session.

	This appeared in my defunct and unlamented bullet list of
requirements. It's an absolute requirement for high capacity IP telephony
environments, but I don't know how useful it is anywhere else. My
opinion is that the protocol must support it, but Agents don't need
to use it, and middleboxes don't need to implement it.

		Andrew