Subject: [midcom] Protocol Requirements -

From: Andrew Molitor <[email-masked]>
Date: Mon, 26 Mar 2001 17:36:27 -0600 (CST)

Since the issue of what goes IN to a requirements document has
been resolved to 'requirements for a middlebox control protocol' I will
now trot out the bullet list of protocol requirements I have. Feel
free to shoot at it. If/when I peceive rough consensus having been
acheived, I will more carefully format and submit more formally to the
editor.

	Throughout, I use this terminology:

	Client - something that requests pinholes 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 operate over standard IP transports, UDP required, TCP
	  optional.

	- 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.

	- should support one or more privacy models (I am weak on this
	  because, in general, not much you are saying is a big
	  secret -- traffic flows will pretty much reveal the state
	  of the box anyways)

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

	- must support server-to-client informational messages (or
	  transactions?)

	- 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
	  should include, but not be restricted to:
		- firewalling
		- NAT (including port translations)
		- QoS
		- Plumbing information (where does NAT fit
		  relative to other elements, specifically,
		  THIS MATTERS!)

	- 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 a method for mirroring an existing NAT
	  binding allocated by one middlebox into another middlebox,
	  for redundancy. There are a few ways to build this,
	  I don't know or care how the protocol does it, but
	  this capability must be supported.

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

	- must support a client-to-server transation 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.

	- 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 transation 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: "Melinda Shore" <[email-masked]>
Date: Tue, 27 Mar 2001 08:53:25 -0500

> - must operate over standard IP transports, UDP required, TCP

Transport specification is an answer, not a question.  i.e.
we need to describe transport requirement characteristics.

>   secret -- traffic flows will pretty much reveal the state

To varying degrees.  It's pretty common to do VPN termination
on firewalls, and while you can infer a lot from tunnelled
traffic characteristics at least the actual destination
address itself is protected in the case where the VPN is
encrypted.

> - must support server-to-client informational messages (or

"Transaction" implies that a response would be expected.
We had talked about asynchronous alerts from the middlebox
to the midcom client and agreed that it's necessary - can
you describe a scenario in which you'd like a response
back to the middlebox?

>   this capability must be supported.

I'm actually not convinced about that, but even so,
a mechanism to do this that required communication
among middleboxes is out of scope.  A mechanism that
made the client responsible for requesting a particular
binding is not.  Either way, how the address of the
NAT itself is failed over is absolutely not our concern,
yet if that's not done the question of transferring
existing bindings is pretty much moot.

Melinda

---

From: Andrew Molitor <[email-masked]>
Date: Tue, 27 Mar 2001 08:44:56 -0600 (CST)

> we need to describe transport requirement characteristics.

	Point taken. Is it fair to devise a maze of constraints
which rule out everything except 'UDP, with a TCP option'? For
a large number of fairly vague reasons which I would, if necessary,
take the time to refine and write down, I think that any other
transport description would be lunacy.

	I am, nontheless, happy to phrase the answer in the form
of a requirement!

> address itself is protected in the case where the VPN is

	What I meant was this:

	If I open a pinhole allowing traffic from A to B, the fact
that I have will be obvious pretty soon, when A starts sending traffic
to B. This is somewhat more trivial than VPN traffic analysis. Of course,
I conveniently forgot NAT and the fact that people like to hide their
private addresses when I wrote that.

	Again, point taken, and thanks.

> you describe a scenario in which you'd like a response

	I cannot. As a potential server-end MIDCOM implementor, I
REALLY like the plan to send alerts optimistically into the void
and hope for the best.

> existing bindings is pretty much moot.

	I actually meant to indicate a mechanism whereby a client
can do the heavy lifting. The point was that the MIDCOM protocol
should support:

	- returning enough information to the client to allow a
	  NAT binding to be installed on a parallel middlebox
	- a way to install said information on same

	The difficulty is that the Middlebox-NAT really needs to
be allocating stuff (port numbers and whatnot) in the normal case.
Otherwise the multiple-client case breaks entirely, and the
clients have to do way too much computation and address/port space
management.

	However, in the redundant middlebox case, the "spare" middlebox
has to simply told what the other one did. Then, if all the clients
agree which one is the primary and which one is the spare, we
don't have Middlebox A and Middlebox B allocating the same
IP address/port to two different things.

	This is actually a solution too. What is needed is a way,
any way, to allow a bunch of clients to collectively keep a bunch
of middleboxes all configured the same.

	The idea of middlebox-middlebox communications a) gives me
the willies and b) doesn't solve the problem. You really need
a single logical allocator of IP addresses and ports to avoid
problems.

	Thanks much for your comments!

---

From: "Melinda Shore" <[email-masked]>
Date: Tue, 27 Mar 2001 10:34:49 -0500

> transport description would be lunacy.

Sorry!  Presumably you've got reasons for preferring
one transport over another, and it's those reasons that
need to go into the requirements document.

> - a way to install said information on same

I think that probably a properly-specified request
primitive should be sufficient.  A request can be
sent to the NAT saying "gimme a binding," allowing
the NAT to select the protocol/address/port tuple.
The NAT would return a description of what was allocated.
A request can also be sent to the NAT saying "gimme a
binding, and I'd prefer that it use protocol/address/
port <x,x,x>," in response to which the NAT would
return what it actually allocated.  Similarly, a
request could say "assign me <x,x,x> and do nothing
if it's not available."

> a single logical allocator of IP addresses and ports to avoid

Think shared memory (but think it someplace else!).

Melinda

---

From: "Michael W. Condry" <[email-masked]>
Date: Fri, 30 Mar 2001 10:27:49 -0800

is there some consistency that the MidTax folks are supposed
to define here?

>         Protocol requirements in no particular order:

Michael W. Condry
Director, Network Edge Technology

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Mar 2001 13:24:01 -0600

Well, I hadn't thought of doing formal terminology as part of the
midtax effort... would it be useful?

   Brian

---

From: "Scott Brim" <[email-masked]>
Date: Fri, 30 Mar 2001 15:24:24 -0500

> 	Do we want to require a 1-to-1 relationship between Servers

Interesting.  Am I right in understanding that

  - your Client is Suresh's Agent, something speaking on behalf of the
    originating end node
  - your Server is something which speaks on behalf of the middlebox.  

?

I thought about whether we needed the extra decoupling and indirection
we would get from this kind of Server, and decided we *probably* didn't
need it.  Something like this might come in handy in the future when we
want to make sure we have coordination between middleboxes, but a single
client-side agent could probably coordinate its specific protocol realm
just as well.  So I don't think we need your Server separated from the
middlebox.  In the future if we need to we can separate them without the
rest of the world noticing.

> 	- should be transport independent, a la SIP.

Why?  (You're going to see that question a lot.)

btw as I recall SIP's transport independence was added afterward.

> 	  latency networks (read: must support message streaming.)

What are you expecting to carry in this protocol that you would want
message streaming?  I think of it as a small-message control protocol.  

> 	- must support server-to-client informational messages (or

Depends on what you mean by transactions -- what your actual requirement
is.  COPS started out with a pure transaction model (iirc) and added
unsolicited messages without much trouble.

> 	- must support models in which multiple clients talk to

Yes.  We're going to have to deal with robustness/reliability, scaling
and multihoming.

> 		  relative to other elements, specifically,

Are you trying, say, to find all middleboxes close to you with
capability X (or a list of capabilities X,Y...)?  If so then I don't
getting a single middlebox to tell you everything it's capable of is
what you're after.  Are you a network operator doing diagnostics?
Finally, I believe all of this is modulo policy, that some clients may
never get to hear about certain capabilities.  I think the requirement
here is a requirement on the network as a whole, that of discovery of
specific capabilities.

> 	  I don't know or care how the protocol does it,

Exactly :-)

>         but

This might not be a requirement on us.  We have to have it in the
framework, and we have to have some idea about how it *might* be done,
but it could be done by a number of completely different control
functions.

> 		- statistics of various sorts

Modulo policy.

I like the rest.

...Scott

---

From: "Scott Brim" <[email-masked]>
Date: Fri, 30 Mar 2001 15:28:11 -0500

I hope midtax will be involved, but it's up to midcom to define the
functions better.  Names are easy compared to functional models.

...Scott

---

From: Andrew Molitor <[email-masked]>
Date: Fri, 30 Mar 2001 15:18:43 -0600 (CST)

>   - your Server is something which speaks on behalf of the middlebox.  

	I think this is exactly right. I view this as natural in the
light of the original meaning of client/server. The Client is something
that wants services, and the server is something that has them. I
therefore think that these Client and Server usages make sense,
even for cases in which the Server initiates communications.

> rest of the world noticing.

	I view the middlebox as a single entity, which talks MIDCOM
to clients and also has NAT and/or firewally stuff in it. That said,
I find it useful to separate it into Server and Middlebox functions
not by way of proposing two boxes or even two separate pieces of
software, but simply as a way to speak of the two aspects of the device
clearly. I actually stole this from Richard Swale's document, more
or less.

> btw as I recall SIP's transport independence was added afterward.

	I think I havve addressed this in my followup bullet list?

> message streaming?  I think of it as a small-message control protocol.  

	I am thinking of cases in which a SIP proxy wants to control
a middlebox that is many many milliseconds away. If the middlebox is
N milliseconds away, and you want to do NAT and firewalling, you are
optimistically limited to 1000 / (8 * N) calls per second in the
absence of streaming

(4 messages at 2*N millseconds round trip = 8*N milliseconds/call)

	which is really low for N bigger than about 4 or 5.

> here is a requirement on the network as a whole, that of discovery of

	This transaction is strictly a Single Client asking a
Single Middlebox 'what are you and what can you do?' The point is
to simplify configuration of applications which are MIDCOM clients.
This capability allows Client configurations boil down to something
not too far from 'these are the networks you care about, these
are the IP addresses in them, and there are middleboxes here,
here, and here.'

	It's also very useful for network manangement and whatnot.

	The plumbing thing is critical, so the Client knows what
addresses to use in specifying pinholes in a combination firewall/NAT
box. This more or less has to be automatically discoverable by the
Client, since Joe User is going to go insane if Joe User has to manually
configure this information into the Clients.

> >       [ mirroring NAT and other state ]

	I'm sort of ok with the idea of just decreeing that MIDCOM
should avoid making this impossible. Still, if we want to define The
Way a thing like a SIP Proxy talks to a thing like a NAT, I think it
might be best to include useful primitives. I'm pretty sure that, at
least sometimes:

	- a SIP Proxy or similar will want to control redundancy.
	- the aforementioned application will use MIDCOM to talk to
	  NAT devices.
	- the aforementioned application will need some way to discover
	  NAT binding information and to install it.
	- the authors of the aforementioned application will be unamused
	  if the answer is 'oh, talk to the REPLICON working group
	  about their protocol for doing that.'

	With this in mind, my sense is that MIDCOM should provide the
communication aspects of solving this problem. Whether this is with
explicit state query/copy mechanisms, or if it can be made to simply
drop out as a consequence of getting some other primitives right, or
if it occurs by black magic, I don't care.

> > 		- statistics of various sorts

	Absolutely! Clearly, the middlebox can reply with
PERMISSION_DENIED to anything, any time. I think it's equally clear that
the problem of specifying 'who can do what to me' middlebox policy it out
of scope, but we surely need to allow for it.

	Thanks for your comments! I hope I was able to clarify myself.

		Andrew