Subject: [midcom] Protocol Requirements Bullet List v2.0

From: Andrew Molitor <[email-masked]>
Date: Wed, 28 Mar 2001 15:31:24 -0600 (CST)

This is a new, improved, version of my earlier bullet list. I
have noted edited bits in the leftmost column with a * so you can skip
the bits I left alone.

	I have a dreadful habit of using tabs sometimes, and eight
spaces other times. Hopefully I didn't do it so much this comes out all
weird on your screen.

	I am particularly interested in the issue of server-to-client
messaging. I list a few possible things the server could tell
the client in my very last bullet. I would very much like:

	- to know about any other sorts of things the middlebox could
	  or should be able to tell the client.
	- what the requirement for acks is on all of these informative
	  messages.

	It is, for example, possible to build a SIP proxy which works
fine without any notifications from the middlebox at all. It might
be useful, nontheless, to report timeouts. This might help the
SIP proxy out in some way, and would at least let the SIP proxy report
that something odd is going on (e.g. a BYE transaction happened but
we never saw it -- so the call went away, the media stopped flowing,
and the NAT elements timed out.)

---------------------------------------------------------------------------

	Throughout, I use this terminology:

	Client - something that requests pinholes and NAT bindings. For
		example, a MIDCOM aware ALG or SIP proxy.

	Server - something which is spoken to by a client. By implication,
		a Server resides in (logically, if not literally) a
		Middlebox, and exposes the services of that Middlebox
		to Clients.

	Middlebox - a firewall or NAT device which is coupled to a
		MIDCOM server, which offers the firewall/NAT services
		to Clients.

	Do we want to require a 1-to-1 relationship between Servers
and Middleboxes?

	Protocol requirements in no particular order:

General Stuff
=============
*	- must support low-latency, high-throughput operation, with
*	  best effort to maintain low latency in the face of a lossy network.
*	  This is necessary for telecom grade operations -- backoff
*	  policies in retransmit timers are not necessarily a good idea
*	  on controlled channels controlling equipment. (This boils
*	  down to: TCP Considered Harmful -- in rather specific
*	  environments.)
*
*	- must also support more ordinary network traffic models for
*	  use on standard networks where backoff policies for retransmit
*	  timers, and the like, are a good ideas. (This boils down to:
*	  TCP is a hell of a good idea most of the time.)
*
*	[ I think the first bullet above pretty much requires UDP
*	  transport with wicked timers, but if there's another option
*	  I'd be pleased to hear about it. The situation I am thinking
*	  of is: some goober in a POP unplugs the wrong cable for
*	  a moment, or there is some other glitch in connectivity.
*	  It would Be Bad if this glitch made TCP back off and make
*	  the POP unable to complete calls for, say, 2 or 3 seconds
*	  AFTER connectivity is restored. This could readily create
*	  irritating post-dial delays for several hundred customers
*	  over the next 10 seconds while the queue clears. This is the
*	  sort of thing that gives telecom geeks nightmares. ]

	- should be transport independent, a la SIP.

	- must support high transaction throughput over highish
	  latency networks (read: must support message streaming.)

	- must support one or more strong authentication models.

*	- must support one or more privacy models.

	- must support client-to-server request/response transactions.

*	- must support server-to-client "alerts" (unacknowledged messages)
*
*	- should support an acknowledged server-to-client messaging
*	  model as well?

	- must support models in which multiple clients talk to
	  multiple servers.

Specific Operations/Scenarios

	Note that these are protocol requirements, not box
requirements. So, while the protocol must support the ability
of a client to ask for a pinhole, the protocol also allows
for a middlebox to return 'NO - I am a NAT, dummy.'

*	- must support a client-to-server transaction which returns
*	  the middlebox capabilities to the client. These capabilities
*	  must include, but not be restricted to:
*		- firewalling
*		- NAT
*			- NAT capabilities (ports and stuff)
*		- Plumbing information (where does NAT fit
*		  relative to other elements, specifically,
*		  THIS MATTERS!)
*
*         and should include:
*		- QoS
*			- QoS flavor(s)
*	[ can someone help out with what one might want to say
*	  if one WERE a QoS capable middlebox? Is this far enough
*	  out of scope to just leave QoS out entirely, burying it
*	  in the 'but not be restricted to' part above? ]

	- must support a client-to-server transaction to open a
	  "pinhole" in the middlebox's traffic policy.

	- must support a client-to-server transaction to request
	  a NAT binding, associating an IP address/port pair on
	  one interface with an IP address/port pair on another.

	- it would sure be nice if these binding requests could
	  specify information about the expected source of the
	  flow initiator. E.G. 'I have a server on the inside
	  at 192.168.1.99 port 5000, and I think someone on the
	  outside at address 209.46.41.61, I don't know the port'
	  will be connecting to my server -- please give me an
	  address/port I can advertise to the remote as the phone's
	  address/port'

*	- must support means for clients to manage redundant middlebox
*	  configurations. This means that it must be possible for a
*	  client or clients to:
*		- apply the same NAT binding across multiple (NAT capable)
*		  middleboxes.
*		- apply the same pinhole across multiple (pinhole capable)
*		  middleboxes (this is actually trivial and impossible
*		  to NOT get right -- included for completeness)
*
*		[ these two boil down to: client can keep a primary
*		  and a spare middlebox in synch ]
*
*		- bring a new middlebox into synch with a set of
*		  synchronized redundant middleboxes.
*
*		[ this boils down to: a client can bring a formerly
*		  dead primary middlebox back into service after repairs,
*		  without bringing the network down.]

	- must support a client-to-server transaction to release an
	  individual NAT binding.

	- must support a client-to-server transaction to release an
	  individual pinhole.

	- should support a way to identify bundles of state (pinholes
	  and NAT) as belonging to the same group (a "session ID"
	  specified by the client in a set of requests)

	- should support a client-to-server transaction to delete all
	  the state bundled under a given session ID.

*	- should support a way to re-session-ID a bundle. That is,
*	  there should be a client-to-server transaction in which
*	  the client asks the middlebox to take all the stuff with
*	  session ID "A" and re-file it under session ID "B"
*
*	[ this is a surprisingly useful operation  but the uses of it
*	  that I know of might be proprietary so I shan't describe them.
*	  There are people reading who know whether they are or are not
*	  proprietary, so if there is curiosity, hopefully explanations
*	  will be forthcoming. Sorry to be so mysterious. ]

	- must support a way to specify a desired timeout value for
	  and piece of state created by a client-to-server transaction.

	- should support both activity based timeouts as well as
	  absolute timeouts (i.e. support both 'if you don't see any
	  packets for 60 seconds, please make this NAT binding go
	  away by itself' AND 'make this NAT binding go away in 60
	  seconds')

	- must support client-to-server transactions to query middlebox
	  state, including but not restricted to:

		- currently installed pinholes
		- currently installed NAT bindings
		- statistics of various sorts

	- should support a client-to-server transaction allowing the
	  client to register to receive notifications of various
	  sorts from the server.

	- should support some server-to-client transactions to inform
	  the client of events such as:

		- timeouts of pinholes and NATs
		- violations of policy
		- other?

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

---

From: "Shai Mohaban" <[email-masked]>
Date: Fri, 30 Mar 2001 14:07:44 -0800

Few comments:

- As noted in the WG meeting I think the terms client and server are
confusing. Why don't we use something like a MidBox and MidBox Controller
and make the terms self explanatory? This would also follow the Media
Gateway vs. Media Gateway Controller decomposition concept and
terminology...

-  I understand the focus on NAT/FW but I would like to add a requirement
that the protocol be easily extendible. Rather than thinking about all the
future primitives I suggest at least the format would be flexible enough to
allow such future extensions (e.g. use TLVs).

- Besides packet/flow dropping and network address translation few examples
of other MidBox primitives include transcoding, encryption and IPv4-IPv6
translations. I am sure there are many others.

- I think we should expect different families of primitives, such as
security related, QoS related, etc. Because of the different nature of these
I think there is a good chance they will be implemented on different
physical devices (e.g. I don't expect a firewall to have DSP resources to
allow transcoding, or to even want to get into this very different business,
and vice versa). This means that a single MidBox Controller might have to
control multiple MidBoxes for each and every controlled flow.

- The current requirements draft indicates (page 3 and also section 3.4 on
page 5) that the MidCom Packet Processor can manipulate the headers.
Applications like transcoding require modifying more than just the headers
so we should generalize this requirement.

- According to section 3.4 the default behavior of the MidBox is not to let
packets pass through it. I think this default behavior should be
configurable (and policy driven) as the requirement may be different for
different applications. E.g. in case of a QoS MidBox I think this will not
be the default behavior.

- One big issue that is not addressed currently is that of order between
primitives. This may be a non-issue when you have just NAT and FW, but might
be more complicated as various primitives start interacting with each other.
It is even more difficult when we try to make the whole thing extendible to
support future primitives...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Andrew Molitor
> Sent: Wednesday, March 28, 2001 1:31 PM
> To: [email-masked]
> Subject: [midcom] Protocol Requirements Bullet List v2.0
>
>

---

From: Andrew Molitor <[email-masked]>
Date: Fri, 30 Mar 2001 16:27:55 -0600 (CST)

> Gateway vs. Media Gateway Controller decomposition concept and

	This is fine with me.

> allow such future extensions (e.g. use TLVs).

	I think the WG is pretty much agreed that extensibility is
extremely desireable, but you are entirely correct -- that should be
actually written down. My bullet list will acquire such an item in
its next edition.

> control multiple MidBoxes for each and every controlled flow.

	Quite. Hence the 'multiple clients, multiple servers' (or,
if you prefer, 'multiple MidBox, multiple MidBox controllers' remark I
and others have made. It is clearly necessary to let a single MidBox
Controller manage a chain of MidBoxen on a path, as well as to let
multiple MidBox controllers access a single MidBox. Carrier networks,
at least, demand this.

> so we should generalize this requirement.

	Err, does transcoding mean going from one audio/video codec
to another? E.G. decode G.711 into PCM and thence into G.723 and
vice versa? I think this is so far out of scope as to be well over
the horizon and completely out of sight.

	I am happy to restrict the scope by defining a middlebox as
something which manipulates headers. This does not mean that a middlebox
cannot logically co-reside with some other box which does other stuff,
only that MIDCOM talks to that aspect of the box which does header
manipulations -- that is, to the middlebox aspect of the device. If
you wanted to build a firewall/NAT/QoS/transcoding device, in this
scenario, that would be excellent. MIDCOM would only let you talk
to the firewall/NAT parts, as is.

	On the other hand, if we want to support niftier devices through
extensibility or mechanisms for tunneling arbitrary other protocols
inside MIDCOM, that's cool too. My feeling is that this is not what
the ADs want, not what the WG wants collectively. Hopefully there will
be enough voices chiming in to make this clear one way or the other.

> different applications. E.g. in case of a QoS MidBox I think this will not

	I concur. This may be one of the things a middlebox can tell
a client in response to the 'hey, what are you, what can you do, and
how are you plumbed' request. The default behavior of the device is
an interesting piece of data. Where possible, it should be configurable,
but recall that we are here to deal with existing middlebox class
devices, not to define their behavior.

> support future primitives...

	NAT and firewalls interact. I have been beating this drum
for a while now, and I am gratified to see that someone else is worried
about it! Hopefully the silence has been due to others not worrying about
it too much, as opposed to it being SO OBVIOUS that I simply look like
a twit for foaming at the mouth about it!

		Andrew